Skip to main content
AI crawlers discover deeper content through internal links. Pages with weak contextual linking become AI dead-ends — the crawler reads them but doesn’t find your related content, so AI answers cite the one page it landed on instead of the broader expertise across your site.

​
Methodology

Cited samples up to 5 pages and counts contextual internal links on each — links that live inside the article body, not inside navigation, header, footer, or sidebar elements. Nav and footer links don’t count toward the score because every page has them; they’re not a signal that this specific page connects to related content. For each link we encounter, we classify it as internal vs external (matching the link’s hostname against the page’s hostname), then as contextual vs chrome (checking whether the link sits inside <nav>, <header>, <footer>, or any element whose class or ID contains nav, footer, header, menu, or sidebar). Only links that pass both filters — same host AND not chrome — contribute to the count. The score is based on the average contextual links per page across the sample. Scoring tiers:
  • More than 5 contextual links per page on average earn the full 5/5 — this is the depth band where AI crawlers reliably discover the rest of your site from any starting page.
  • 2 to 5 average earn 3/5 — sufficient for AI to find some related content but not comprehensive.
  • Fewer than 2 average earn 1/5 — flagged as critically thin internal linking. AI crawlers landing on these pages typically don’t discover your broader content.
The signal scores out of 5. Status thresholds: pass at 4/5 (calibrated to require the 5+ tier), partial at 2/5 (the 2-5 tier), fail at 1/5. Why average instead of minimum? AI citation patterns favor consistency — a site where every page has solid internal linking gets cited more than a site with one heavily-linked cornerstone page surrounded by isolated pages. The average rewards consistent depth. What counts as a contextual link? Any <a href> element whose target host matches the page’s host AND whose ancestor chain doesn’t include nav/header/footer elements (by tag name OR by class/ID pattern). A link inside <article> or <main> is contextual. A link inside <nav class="primary-menu"> is chrome and doesn’t count, even if it links to deep content.

​
Verification

You can verify our finding yourself in a browser console. Step 1: Open the pages we sampled. Cited reports the URLs we tested. Open each in a new tab. Step 2: Count contextual internal links via the console. Open DevTools (Cmd+Option+I / Ctrl+Shift+I), Console tab, and run: 
const host = location.hostname;
function isChrome(el) {
  const navTags = new Set(['NAV','HEADER','FOOTER']);
  const pat = /\b(nav|footer|header|menu|sidebar)\b/i;
  let c = el;
  while (c) {
    if (navTags.has(c.tagName)) return true;
    if (pat.test(c.className || '') || pat.test(c.id || '')) return true;
    c = c.parentElement;
  }
  return false;
}
[...document.querySelectorAll('a[href]')].filter(a => {
  try { return new URL(a.href).hostname === host && !isChrome(a); } catch { return false; }
}).length
This returns the same contextual internal link count Cited’s scanner sees. Step 3: List the contextual links. Replace .length with .map(a => a.href) in the snippet above to see the full list. Verify they’re the in-body links you expect (not chrome links the classifier missed). Step 4: Audit chrome misclassification. If the contextual count is much lower than you expect, your site may have nav-like patterns in the main content. Inspect the missing links — if a link is inside <div class="page-nav"> or <aside class="related-sidebar">, those classify as chrome by design. Renaming those containers (e.g., <div class="next-steps">) restores them to contextual status. If your verification disagrees with Cited’s finding, that’s a bug — let us know.

​
Technical detail

Internal linking as a discovery signal traces to the original PageRank paper (Page, Brin, Motwani, Winograd 1998), which formalized how link structure drives content authority. AI crawlers inherit this model — they follow internal links to discover related content and weight pages by how often other pages on the same domain link to them. The chrome-vs-contextual distinction matters because chrome links are noise: every page links to the homepage from the nav, so those links don’t carry topical signal. Extraction logic. Cited’s scanner extracts internal links via DOM parsing:
  • document.querySelectorAll("a[href]") collects every link element
  • Each link’s href is resolved against the page URL (relative paths become absolute)
  • The resolved URL’s hostname is compared to the page’s hostname — links to other hosts are excluded
  • Each link is annotated with isNavOrFooter: boolean based on ancestor classification
Chrome classification. The scanner walks each link’s ancestor chain from the link up to the document root. The link is classified as chrome (isNavOrFooter: true) if any ancestor matches either condition:
  • Tag name is NAV, HEADER, or FOOTER
  • Class name or ID attribute contains any of nav, footer, header, menu, or sidebar (case-insensitive word boundary match)
The class/ID check uses a word-boundary regex (\b(nav|footer|header|menu|sidebar)\b) so a class like navigation-primary matches but innovation doesn’t. The case-insensitive flag covers both Navigation and navigation. Counting logic. Per sampled page, contextual link count = total internal links minus chrome links. Total contextual is summed across all pages, divided by the page count. The score lookup is a flat staircase: avg > 5 → 5, avg >= 2 → 3, else → 1. Edge cases the scanner handles:
  • Same-host subdomains — a link from blog.example.com to shop.example.com is treated as external because hostnames differ. This is intentional; subdomains often have separate content authority.
  • Protocol-relative URLs — //example.com/page resolves correctly via the URL resolver. Hash-only fragments (#section) and JavaScript pseudo-links (javascript:void(0)) resolve to invalid URLs and are excluded.
  • Links inside dynamic chrome — chrome elements added by JavaScript after domcontentloaded plus the 3-second hydration delay are detected. Chrome added much later (e.g., after a user interaction) may be missed.
  • In-article navigation widgets — table-of-contents widgets, “next post” / “previous post” links, and related-posts grids sit on the boundary. If they’re wrapped in elements with chrome-pattern class names (<div class="toc-sidebar">), they classify as chrome. If they use neutral class names, they count as contextual.
  • Skip-to-content accessibility links — typically <a href="#main">Skip to main content</a> inside <nav> or <header>. These classify as chrome by ancestor and don’t contribute to the count.
What this signal does not measure:
  • Anchor text quality. A link with text “click here” counts the same as a link with descriptive text. The signal counts presence, not editorial quality.
  • Link target depth. A link from one page to your homepage counts the same as a link to a deep article. The signal doesn’t model the recipient’s depth or authority.
  • Link uniqueness. If a page links to the same target three times (e.g., “above,” “below,” “see related”), all three count toward the contextual total. AI crawlers may deduplicate; the scanner doesn’t.
  • External links. Links to other domains aren’t counted here — even thoughtful external citation (which AI models weight positively for trust) doesn’t contribute to this signal’s score. External linking is a separate concern.
For brands scoring 1/5, the highest-leverage fix is adding 3-5 in-body links per page to related content. The simplest pattern is a “Related reading” or “See also” block at the end of each article body — placed inside <article> or <main> (not inside a sidebar), so the chrome classifier doesn’t exclude it. See also: Sitemap Accessibility, Content Depth, Page Crawlability.