Most of the technical SEO playbook got rewritten in the last two years. Internal linking did not, and that is the interesting part. Everything about how answers get assembled changed, and the discipline that decides which of your pages a machine can find, reach and correctly categorize came through almost untouched.
It came through because it was never really about passing authority between pages. That was a convenient model, and it was true enough to be useful. What internal linking actually does is describe your site to a machine that cannot see it the way a person does. That job did not go away when the machine started writing paragraphs instead of ranking ten links. If anything it got more consequential, because there are fewer slots in an answer than there are on a results page, and the selection is happening on the basis of what a system believes your page is about.
Chapter 1: What internal links do that they did not do before
The old model was a plumbing model. Authority arrived at your homepage and a few earned pages, then flowed through the internal link graph to everything else, and the job was to route it toward pages that made money. That model still describes something real. It is just no longer the whole job, and on most enterprise sites it is no longer the binding constraint.
Three things changed underneath it.
| WHAT CHANGED | OLD CONSEQUENCE | NEW CONSEQUENCE |
|---|---|---|
| Answers are assembled from a small set of retrieved passages | A weakly linked page ranked lower | A weakly linked page is not in the candidate set at all, so it cannot be cited |
| Context is drawn from surrounding text and link structure | Anchor text was a mild relevance hint | Anchor text and link context help a system decide what the destination page is about before reading it |
| Discovery matters more on large sites than on small ones | Deep pages got crawled eventually | Deep pages compete for a finite crawl and retrieval budget against every other page you publish |
| More engines, more crawlers, less rendering tolerance | One crawler, mature JavaScript handling | Multiple retrieval systems with different tolerance for anything that is not plain markup |
The fourth row is where a lot of enterprise sites lose quietly. Google is explicit in its link documentation that it can only crawl a link that is an anchor element with an href attribute, and it lists the forms it cannot reliably parse: anchor tags without an href, non-anchor elements dressed as links, click handlers with no href, JavaScript URLs, and framework routing attributes. That is a documented constraint on the most capable crawler in the market. Assuming every other retrieval system is more forgiving than the most capable one is not a defensible engineering position.
If your navigation, pagination, faceted filters or related-content modules are built as click handlers rather than real links, you do not have an internal linking strategy. You have an internal linking intention. This is the same class of problem as firewall rules that quietly block legitimate crawler behavior: the site looks fine to every human who checks it, and the machine sees something else entirely.
“A link that requires JavaScript to exist is a link you are hoping about, not a link you have.”
The practical test takes ten minutes. Disable JavaScript, load your five most important templates, and count the links you can still see and click. If your product category pages lose their pagination, or your documentation loses its sidebar, you have found the highest value technical work on your list this quarter, and it is not a content problem.
Chapter 2: The four jobs every internal link is doing
Teams argue about internal linking because they are optimizing for different jobs without saying which one. Naming them settles most of the argument.
Most internal linking failures are one job being optimized at the cost of another. Automated related-content modules do discovery well and description badly, because they generate anchors like the destination title rather than a phrase describing what the destination answers. Hand-curated links do description well and coverage badly, because humans link to what they remember. Navigation does importance well and continuation badly, because a mega menu with two hundred links is signalling that nothing in it is important.
| LINK SOURCE | DISCOVERY | DESCRIPTION | IMPORTANCE | TYPICAL FAILURE |
|---|---|---|---|---|
| Primary navigation | Strong | Weak, labels are short by design | Strong, and diluted by volume | Everything gets added, nothing gets removed, importance signal flattens |
| Contextual body links | Moderate | Strong, full sentence context | Moderate | Coverage depends on who wrote what, so it clusters around recent content |
| Automated related modules | Strong | Weak, template anchors repeat | Weak | Same three anchors sitewide, which teaches a system nothing |
| Hub and index pages | Strong | Moderate | Strong | Built once, never maintained, so new pages never get added |
| Footer link blocks | Moderate | Weak | Weak | Treated as a dumping ground for pages nobody would otherwise link |
Read that table as a portfolio. You need all five sources, doing different jobs, and the common enterprise pattern is four of them working and one of them carrying an unreasonable share of the load. On content-heavy sites it is usually contextual body links doing everything, which means coverage tracks publishing history rather than commercial priority.
Chapter 3: Anchor text is extraction text now
Google's own guidance on anchor text is unglamorous and worth taking literally. It says the text should be descriptive, reasonably concise and relevant, that a reader should understand where a link goes from the anchor alone, and that cramming terms into anchors is keyword stuffing and a spam policy violation. You can read the link best practices documentation in about four minutes and most teams never have.
The reason it matters more now is that the same text is doing double duty. It is a navigation label for a person and a description of the destination for a retrieval system that has not read the destination yet. Those two audiences want almost the same thing, which is lucky, and the place they diverge is exactly where most sites go wrong.
| ANCHOR | READS WELL TO A PERSON? | DESCRIBES THE DESTINATION TO A MACHINE? | VERDICT |
|---|---|---|---|
| Read more | Yes, in context | No, it describes nothing | Fails the description job entirely |
| Pricing | Yes | Barely, and it collides with every other pricing page | Acceptable in navigation, weak in body copy |
| Our enterprise pricing tiers and usage limits | Yes | Yes, specific and self-contained | Strong, and this is the shape to aim for |
| Best enterprise SEO agency pricing cost 2026 | No, it reads as spam | No, stuffing degrades the signal | Violates Google's stated guidance, do not ship it |
| The same anchor, used forty times sitewide | Neutral | No, repetition carries no incremental information | The most common automated-module failure |
Two working rules come out of that. First, vary anchors to the same destination across the site, because a system learns more from five different accurate descriptions than from one description repeated five times. Second, never use the same anchor twice within a single page, which is a rule we enforce mechanically on our own publishing because it is easy to violate by accident.
There is a third rule that only applies to answer engines, and it is worth stating plainly. Write the sentence around the link so the sentence stands alone. Retrieval works on passages, and a passage that says the link above explains this in detail is useless when lifted out of the page. A passage that says our analysis of how AI citations are actually earned found comparison content taking the largest share carries its own meaning wherever it lands. Same link, same page, completely different value once extracted.
Chapter 4: Depth, orphans, and the pages nobody links to
Click depth is the number of clicks from the homepage to a page, following the shortest path of real links. It is a proxy, not a ranking factor, and it is the most useful single number in an enterprise internal linking audit because it correlates with everything else that is wrong.
Our working rule on client sites is that anything commercially important sits within three clicks of the homepage, and anything within three clicks should deserve to be there. Both halves matter. Teams hear the first half and flatten their architecture by adding links everywhere, which makes the importance signal meaningless. The rule is a constraint on both directions.
Illustrative only: how depth typically distributes on an unaudited enterprise site, not measured data
The shape above is illustrative, drawn to show the pattern rather than to report a measurement, and the pattern is what matters: the mass sits deeper than anyone expects and the tail is bigger than anyone expects. When teams run this properly on their own site for the first time, the surprise is rarely that a few pages are deep. It is that a whole template is.
Orphan pages are the extreme case and they are more common on enterprise sites than on small ones, for a boring reason. Pages get created by campaigns, migrations, and integrations, and the thing that would have linked them was a module that got deprecated, a hub page that got redesigned, or a category that got merged. Nobody deletes the page, because deleting things is scary and nobody owns it. So it sits there, in the sitemap, with no internal links, generating crawl requests and no value.
| ORPHAN SOURCE | HOW IT HAPPENS | THE FIX |
|---|---|---|
| Migration remnants | Old templates stop linking, URLs survive the redirect map | Decide per page: link it properly, redirect it, or remove it. Do not leave it |
| Campaign landing pages | Built for paid traffic, never entered the organic structure | Either exclude from indexing deliberately or link from a real hub |
| Deprecated modules | A related-content or filter module was removed in a redesign | Replace the discovery path before the redesign ships, not after |
| Deep pagination | Pages beyond the first few pagination steps become effectively unreachable | Add filtered hub entry points, or accept and prune the tail deliberately |
| Merged categories | Two taxonomies became one, children of the losing branch lost their parent | Rebuild the parent links as part of the merge, in the same release |
The fix list is short because the work is not intellectually hard. It is organizationally hard, since every row on that table is owned by a team that has already moved on. That is the actual reason orphan pages persist on large sites, and it is why this belongs in a technical audit with a named owner rather than in a backlog ticket. It is the same dynamic we see in full technical audits, where the finding is easy and the assignment is the difficult part.
Chapter 5: Hub and spoke, rebuilt around entity coverage
Hub and spoke is still the right structure. What changed is the axis you build it on.
The keyword-cluster version built a hub for a head term and spokes for its long tail variants, which produced a lot of pages that differed mainly in phrasing. Answer engines collapse phrasing variants aggressively, so that structure now produces internal competition instead of coverage. The entity version builds the hub around a thing, and the spokes around the distinct questions a buyer has about that thing.
The rule that keeps this honest is the distinct answer test. If two spokes would answer a question with the same paragraph, they are one page. That test kills roughly a third of most proposed content plans, which is the point. Consolidation is usually the highest return internal linking action available to a large site, because it converts internal competition into a single stronger page and cleans up the anchor pool at the same time.
Link direction matters more than most teams think. The hub should link every spoke, because that is the discovery guarantee. Every spoke should link the hub, because that is the importance signal. And each spoke should link two sibling spokes, chosen by what a reader would want next rather than by similarity score, because that is what turns a star into a graph and it is where the continuation job gets done.
For commercial structures, the spokes also need to reach a page that converts. A cluster that links beautifully to itself and never to a service page or a relevant case study is an educational resource, not a revenue asset. That is a legitimate thing to build on purpose and an expensive thing to build by accident.
Comparison content deserves its own note in this chapter, because it is the format that earns the most citations in our own analysis and it is structurally awkward. It belongs to two entities at once, and teams either duplicate it under both hubs or orphan it between them. Pick one hub as its home, link it from the other, and vary the anchors on each side. The content programs that get this right treat comparison pages as first-class citizens of the structure rather than as blog posts that happen to have a table.
Chapter 6: How to measure internal linking honestly
This is the chapter where most guides start inventing numbers, so here is the honest version. Internal linking is hard to attribute cleanly, and anyone showing you a precise revenue figure for it is showing you a model, not a measurement.
What you can measure reliably falls into three tiers, and being clear about which tier a number belongs to is most of the discipline.
| TIER | WHAT YOU CAN ACTUALLY CLAIM | METRICS |
|---|---|---|
| Structural, measured directly | The structure changed in the way you intended | Orphan count, click depth distribution, internal links per priority page, anchor variety per destination |
| Behavioral, measured with caveats | Machines and people responded to the change | Crawl frequency on affected templates, log-file hits by template, internal click-through on modules |
| Outcome, inferred and contested | The business result moved | Impressions and clicks on affected pages, citation appearance, assisted conversions |
Report all three tiers and label them. A structural claim is defensible in any room: the orphan count went from 4,000 to 300 and the priority templates moved from five clicks deep to three. A behavioral claim needs a caveat about what else shipped. An outcome claim needs the same error bars as any other search measurement, and we have written at length about how wide those error bars actually are and about the trap of comparing visibility across engines.
There is one measurement trap specific to this work and it catches good teams. Internal linking changes are almost never shipped alone. They arrive inside a redesign, a migration, a template refresh or a content consolidation, and every one of those changes moves the same metrics. If you want a defensible outcome claim, you need either a template that changed while a comparable template did not, or a change window with nothing else in it, and on most enterprise release calendars neither exists. When neither exists, say so and report the structural tier. A team that reports what it can prove earns the benefit of the doubt on the tier it cannot, and a team that overclaims once loses the argument permanently.
One specific piece of advice on timing. Internal linking changes on large sites take longer to show up than teams expect, because the crawler has to revisit the linking pages before it acts on the new links. On a site with slow recrawl on archive templates, the discovery benefit of a link added to a 2024 blog post can take weeks to register. Do not judge the work in week two, and do not let anyone else judge it in week two either.
Finally, keep a before snapshot. Export the depth distribution, the orphan list and the anchor inventory before you change anything. The single most common reason internal linking work goes unrewarded internally is that nobody can show what it looked like beforehand, which turns a large structural improvement into an anecdote.
Where to start on Monday
In order, because the order saves work.
Run the JavaScript-off test on your five most important templates first. It takes ten minutes and it either finds nothing or it finds the biggest problem on the list. Everything else in this guide assumes your links exist as links, so verify that assumption before you spend a quarter optimizing anchors that a crawler cannot follow.
Then pull the orphan list and the click depth distribution. Do not fix anything yet. Read them, because they will tell you which of the four jobs is failing on your site, and the answer differs by architecture. Content-heavy sites usually fail on importance and depth. Product catalogs usually fail on discovery in the tail. Documentation sites usually fail on description, because everything is linked and nothing is described.
Third, fix discovery before description. A page nobody links to gains nothing from a better anchor, and a well-described page that is six clicks deep is still six clicks deep. Discovery is binary and description is incremental, so the binary problem comes first every time.
Fourth, take one commercial cluster and rebuild it properly end to end: hub links every spoke, spokes link the hub and two siblings, anchors vary and describe, and at least one path reaches a page that converts. One cluster done completely teaches your team more than a sitewide anchor cleanup, and it gives you a template and a measured before and after to argue with.
Then keep the before snapshot, wait longer than feels comfortable, and report the structural tier honestly while the outcome tier settles. Internal linking is not exciting work and it does not photograph well in a deck. It is simply one of the few remaining levers where the constraint is your own site rather than somebody else's model, and that is a rarer thing every year. Sites that stay easy to traverse and easy to describe keep showing up in answers while their competitors argue about whether any of this is measurable, which is its own kind of answer.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Tyler leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.