Internal linking: understand it, prioritize it, optimize smartly

You have probably been setting internal links the way they came up while writing. A fitting reference to the older post or a link from the overview into the detail page. That is not a bad method. While writing you know better than any tool what the other text is about.

It gets interesting as soon as that turns into a list. When a tool dumps two hundred missing links at your feet, feel stops helping. What you need then is an order, and that order is in no guide, because it depends on your website.

That is exactly where I stood in late August: my own tool had worked through seo-kreativ.de and suggested 190 additional internal links, without any hint as to which of them would do anything. All sensible. All doable. Just not all in one afternoon.

So I set every suggestion on its own, recalculated the PageRank of the whole domain and looked at what had moved. 190 times in a row. Two of the six strongest links are ones I would never have set first, because in the list they looked completely unremarkable. Four others were right at the top, but only because I had added up percentages belonging to different target pages.

In this article: what an internal link moves, what separates a good one from an arbitrary one, what you do with brand new pages, how I handle the topic myself and in what order you start tomorrow.

Two things, then. And in the guides I read for this article both sit in the same pot. That is already part of the problem.

The first is discoverability. In the Search Central documentation Google describes that it uses links as a signal for the relevance of pages and to look for new pages that should be crawled. The form matters here: according to the same page, generally only an <a> element with an href attribute is crawlable. A pure JavaScript click element without <a href> is therefore not a reliable route to discovery. Google does render JavaScript and may still find an anchor delivered that way, but in the link graph of your own crawler a pure click element usually does not show up at all. I would not rely on it.

The second is distribution, in SEO practice usually called link juice or link equity. The basis is in the PageRank patent by Lawrence Page, filed for Stanford University and granted on 4 September 2001. The rank of a document there is a function of the ranks of the documents that point to it. And now comes the decisive half sentence: the value a page passes on is divided by the number of its outgoing links.

That half sentence changes the whole calculation. A page with 180 outgoing links passes on almost nothing per link, while a page with four links hands over a fair amount. In the model, internal linking therefore does not work on a more is better principle. Anyone who adds twenty links to a strong page arithmetically dilutes every link that was already there. Whether Google calculates the same way internally is not known from the outside.

On top of that, not every link counts the same. A Google patent from 2010 titled Ranking documents based on user behavior and/or feature data describes weights that model how likely a link is to be clicked. According to the patent, links further up in the document get a higher probability than links further down. Font size and topical proximity between source and target page appear as well. Whether and how that works in ranking today is not stated there.

The anchor text describes the target, not the action

“Click here” and “learn more” tell neither readers nor search engines what waits on the other side. The anchor text should describe the target. Every guide agrees on that much and they are right.

The practical part comes after that. When my tool produced 190 suggestions, it proposed the slug of the target page as the anchor text each time. Convenient. And wrong. An anchor with the doggedly repeated title of the target page reads like a footnote and on top of that forces you to build the whole sentence around the link.

The other way round works better: write the paragraph the way you always would and afterwards link the words that already describe the target page in the finished sentence. The link then sits in a place where a reader expects it anyway. And the anchors differ between source pages by themselves, because every paragraph is worded differently.

Body copy or navigation: what counts more?

In the PageRank model every edge counts the same, whether it sits in the menu or in a paragraph. The patent on click probability does suggest that the position in the document plays a part.

In my own measurement menu links were still conspicuous, but for a different reason. They sit on every single page, so the linked targets collect a great many incoming edges while passing hardly anything on through editorial links in body copy. Such pages are basins, not pipes. A single editorial link out of a basin like that moves more in the calculation than a dozen links between two already weak blog posts.

Click depth: the three click rule is a rough guide

The rule of thumb says every important page should be reachable in at most three clicks from the home page. As orientation that is usable, as a metric it is weak.

The reason sits in the model: click depth counts steps, PageRank counts weight. In my simulation a page four clicks deep with a link from a heavily linked overview page gets a higher calculated value than a page two clicks deep with a single footer link. If you have the choice, look at the incoming weight and not at the number of clicks.

How much structure do you need: silo, topic cluster, hub and spoke?

All three terms describe the same basic idea: an overview page bundles a topic, the detail pages hang off it and link to each other. I have described the hub and spoke model in detail elsewhere.

What matters is the order of the questions. Structure is useful because it forces the return paths between overview and detail. Exactly those return paths were the most effective suggestions in my measurement. What structure cannot do is tell you which of those return paths you build first. And a cluster boundary is only as good as the clustering behind it, which cost me a fair amount of time.

How this article is linked itself

An example I did not have to pick: the article you are reading. The link graph counts 120 edges at this page, 99 incoming and 21 outgoing. That sounds like a well connected page. Eight of those edges were written into a paragraph by a human, all the rest are generated by the theme.

That is not a reproach against the theme but the reason why the number of incoming links works poorly as a metric. 94 of those links carry the same anchor text, namely the entire teaser paragraph including author and date. They sit on every page and disappear again as soon as the post rotates out of the box. A tool that only counts reports the all clear here. A look at the anchor texts reports four.

On 23 August 2026 I read the five strongest German results on the topic from end to end. All five explain anchor texts, flat structures and the benefits of internal links. Not one of the five shows a single measured figure of its own on what a particular link achieved. That is not a reproach, because the answer hangs on the individual website. It does leave open the part that makes up the actual work.

The short answer: you set the link, recalculate the PageRank of your domain, compare it with the state before and take the link out again. Simple and above all dogged.

For that you need the real link graph of your website, so every page as a node and every internal link as a directed edge between exactly two nodes. The PageRank on this current state is your baseline and every later comparison runs against it. With 190 suggestions that comes to 191 complete passes over the entire graph. On a small domain that stays in the range of seconds.

For seo-kreativ.de the graph looked like this on 27 August 2026: 231 nodes, 5,770 internal edges. Two weeks earlier there were still 382 nodes. The difference did not come from the linking work but from 153 tag archives that have returned a 404 since then and dropped out of the graph. The suggestions came from two pots with very different behaviour. The rows add up to 203 because thirteen links sit in both pots. That leaves 190 unique recommendations.

The second row is the uncomfortable one: semantic candidates come out of a vector comparison, look absolutely plausible in substance and make most of the writing work, but in the end they move only a good forty percent of what the structural links move.

With the individual values it gets clearer still. The highest percentages in the entire run came from three pages in the main menu: the commodity checker raised the calculated PageRank of my broken-links guide by 110 percent, the plugin overview the same one by 94 percent, the SERP snippet checker the same one by 89 percent.

In total the 50 most effective links deliver 65 percent of the sum of all simulated gains, and the whole rest spreads across 140 further edits in body copy. If you only have one afternoon, you now know where it belongs.

And if I cannot calculate PageRank?

Then a rougher approximation gets you surprisingly far: for every page, count the incoming editorial links and set them against the number of outgoing ones. Pages with many incoming and hardly any outgoing links are your basins. That is exactly where you set your first links.

This does not replace the real measurement. It ignores the value of the referring pages. But it finds the same candidates in the upper half of the list and for a start that is entirely enough.

In the guides I read for this article the instructions stop before this point. Yet it comes up again with every publication. You publish a post. It is good, it has six clean outgoing links, a schema markup and it is in the sitemap. Still nothing points at it.

The reason is structural and not a mistake of yours. Your older posts were written when the new one did not exist yet. No author links into the future. So every publication creates a page that starts practically at zero in the link graph and hangs only off the automatic lists.

Exactly that can be recalculated in the model: a page without editorial edges gets only the base term from the formula there. That is a property of the calculation and not a Google minimum value.

What I do when publishing

I go through two directions, in this order. First the incoming links: I pick three to five pages out of my existing content that already point in this direction anyway. From there I set one link each to the new article. One of them is ideally a page from the main menu, because exactly those links were the strongest in my measurement.

Only after that come the outgoing links, and the new article gets four to six of them to existing pages. No more. An article with twenty links looks industrious and in the model spreads the assumed link mass across twenty edges instead of six. That is not a Google limit, only my working heuristic.

The order is deliberate: anyone who only links outwards ends up with a well connected article that is practically unreachable from the inside, for readers and crawlers alike. That exact mistake lands on my desk regularly when I look at a client project for the first time.

The backlog nobody plans for

The problem has a second half. If you have published for two years without linking backwards, what lies ahead of you is not a single missing link but a whole inventory. For me that was 190 suggestions across 231 pages, plus 188 twins in the English version. Almost four hundred edits.

That is exactly why the order is the decisive question. A single link you set in passing. Four hundred you do not.

I am writing this down because otherwise the method above sounds like love for my own tooling.

My old way of working had exactly one data source: my memory. While writing it occurred to me that I already had something on this point. Then I set the link. That is not wrong. It just does not scale, because your memory does not grow along with your inventory.

Three patterns came out of it that I recognise today in every project that has grown.

I only thought in one direction

Every new article got four or five outgoing links. Whether anything pointed back at it I never checked. The result was an inventory of pages that linked well and were themselves hardly linked. Exactly that is where the 190 suggestions came from later.

I linked what came to mind, not what was missing

Out of memory you always get the same ten to fifteen pages, namely the newest ones and your own favourite articles. Everything older quietly disappeared from my internal linking, even though it was still in the index.

The second language version ran on the side

seo-kreativ.de exists in German and English. I set a link in the German version and regularly forgot the twin in the English one. When I measured for the first time, next to the 190 German gaps stood 188 English ones.

What all three patterns lack is the same thing: a view of the inventory that does not come from me.

I built my own pipeline for this, because the evaluation was in none of the tools I knew. The setup is not tied to my tool though. Anyone who rebuilds the three steps individually arrives at the same result.

Step 1: read in your own inventory

A crawler goes over the complete domain, splits every page into sections and has every section embedded. The resulting vector index of my own texts answers the question of which pages sit close to each other in substance, without me having to remember 231 pages.

The same pass records every <a href> it finds as a directed edge. That is the real link graph and it answers a completely different question: what is actually connected, regardless of what ought to be connected.

Step 2: three comparisons instead of one opinion

Out of these two data sets come three separate lists, and each finds candidates the other two do not see.

• Plan against reality. My planned topic structure is held against the real graph. Missing return paths between overview page and detail page fall out here. That was the most effective pot in the whole run.
• Semantics against link map. Two pages sit close to each other in substance, but there is no edge between them. This list is the longest and moves the least.
• Equity. Pages without incoming links, pages that receive a lot and hand out nothing, pages that are over linked. This is where the pointer to the basins sits.

Step 3: simulate the order instead of guessing it

This is the part that saves the work: for every single recommendation a complete PageRank pass runs over the graph, once with and once without that link. Sorting then happens by the measured gain of the target page. Optionally the demand from Search Console feeds in as a weight, when I want to fetch clicks rather than redistribute authority.

And every link is carried in both language versions. The twin sits on the same list as the original.

Why that works

Four properties make the difference. Three of them I taught myself the hard way.

What gets sorted is the absolute gain, not the percentage. My first priority list sorted by percent and had these three at the top with almost 300 percent between them. By absolute mass moved they sit in positions four, five and six. Ahead of them sits a suggestion with a calculated 48 percent: a link from the handbook to my crawling guide. Percent measures the gain against the starting value of the target page. With a PageRank near zero every crumb looks enormous in percent, while a page with substance grows slowly in percent and strongly in absolute terms.

The tool declares its own coverage. An earlier run found 148 nodes, the next 382. In between lay no change to the website but a default value of 150 maximum URLs to crawl. The first run reported zero orphan pages, which reads like a clean result and in truth only means “not looked at”.

Rules whose basis measures nothing get switched off. The pipeline reported 1,402 violations of cluster boundaries. With 104 clustered pages that arithmetically covers nearly every edge in my graph that crosses a boundary at all. The silhouette score of the clustering was 0.027, so practically zero: the algorithm had drawn dividing lines through a field without recognisable valleys. That rule has been off on this domain ever since.

The three lists stay separate. Precisely that made it possible to measure at all that the semantic candidates move only a good forty percent of what the structural ones move. In a mixed list that difference would never have surfaced.

What I deliberately do not do

I use no plugin that automatically links keywords in the text. Modules like that set the link where the word is. The reader, however, usually has their question in a different place. On top of that they like to link the same target page five times in the same article.

I also build no “you might also like” blocks under every post. They sit on every page, dilute every other link there and in my observation in Search Console they are clicked next to never. A link in body copy at exactly the point where the question comes up is worth more to me than ten automatically generated tiles in the footer area.

Categories can work as standalone overview pages, tag archives often stay thin. The reason has nothing to do with tidiness. Both are usually treated as an ordering system for people, but in the link graph they are something quite different: nodes with a great many edges that collect equity and pass it on like any other page.

A category page links every post in it and is linked back by every post. That makes it a hub in the literal sense: it collects equity from all the posts and returns it to exactly those posts. If your categories match your topic structure, this mechanism works for you.

Tags behave differently and usually less favourably. If your CMS creates an archive page for every tag, some of them end up with a single post hanging off them. The page is created anyway, is linked by exactly that post and returns its value to exactly that one page. With fifty tags like that you have fifty thin pages in the graph that divert equity and for which there was no measurable search demand on my domain.

On seo-kreativ.de I take a special route that I described in the post on breadcrumb navigation: the tag level exists in the breadcrumb schema, the archive pages themselves are set to noindex. The breadcrumb thereby marks up the hierarchy in machine readable form without thin archives getting into the index.

Three questions I ask myself before every new tag:

• Will at least five posts foreseeably hang off this one? With fewer you create an overview page that shows barely more than the post itself.
• Would I give this archive page to a reader as an entry point? If not, it does not belong in the index.
• Is there already a category that covers the same thing? Then the two compete for the same queries.

Maybe. Check first how many pages your crawler actually saw. I learned this question the hard way.

On 23 August I set three of my own tools on the same domain and got three different answers from them: zero, nine and 93 orphan pages. Three tools, one website, one day.

The resolution is unspectacular: the nine came out of audit runs with a graph of only 57 nodes, the 93 were simply the sum of several such incomplete runs. As soon as the crawl covered the domain completely, so 209 URLs at full graph coverage, the same check reported zero.

An orphan is therefore not a property of the page but a statement about the reach of your crawl. If your tool knows only half of your website, then the other half is orphaned for exactly that tool and afterwards stands as a finding in your report. In my audit bundle I therefore report orphan findings only from 95 percent graph coverage upwards.

On top of that comes an imprecision in the term itself: without an internal link a page is not automatically invisible to Google, because it can also be found through your sitemap. Google words it in the sitemap documentation as a sitemap helping search engines find URLs. An assurance that all items from it will be crawled and indexed is expressly not given on that same page. And in the same document it says that Google usually finds most of a site if the pages are properly linked.

Both sentences together give the realistic picture: a link is the reliable route, the sitemap the unreliable one. What an orphan page really lacks is less the discoverability than the equity, because from the inside it simply gets nothing. How discovery and indexing hang together is in my post on crawling and indexing.

Around AI search a lot is currently being written about new file formats and special markup. Google contradicts that in its own documentation on AI features in Search unusually clearly. It says there verbatim: “There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary.” And in the same document: “You don’t need to create new machine readable files, AI text files, or markup to appear in these features.”

More interesting is the sentence on the precondition. Google words it as: “To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet.”

That closes the circle back to the start of this article. Being found is the condition for a page to be indexed at all, though it is not yet a guarantee of indexing. Internal links are the most reliable route there. Google also discovers URLs through sitemaps, external links and redirects among other things. Internal links are therefore no AI trick but an important basis for crawling and internal classification.

For ChatGPT, Perplexity and other systems there is no comparable public documentation. What is weighted how there cannot be evidenced from the outside. The Google text above says nothing about it. What I expressly do not claim: that internal links would be a signal of their own for AI systems. The connection that can be evidenced runs through indexability, not through an AI bonus.

If you want to rebuild the method, you need three things: the real link graph, a PageRank implementation and patience. But you do not have to. Without a tool of your own this order gets you a long way, because it reflects the patterns that were at the very top on my site.

1. Pages with many incoming menu links and few outgoing text links. Home page, service pages, tool pages. In my simulation the three largest gains belonged to links from exactly there. From these pages set one topically fitting link each into the body copy.
2. Missing return paths between overview page and detail page. On my site the structural pot moved around two and a half times the PageRank mass of the semantic one, at less effort.
3. Your newest posts. By structure they have hardly any incoming links, and this item keeps growing with every publication.
4. Pages with demand that are poorly connected internally. Bring in the impressions from Search Console.
5. The semantic candidates last. They are not wrong. They are just last in line.

A note on point 4, because it cost me an afternoon. When in August 2026 I sorted the same list once by pure effect and once by effect times demand, the top 50 overlapped in only 17 cases. Those are almost two different lists. Which one is right for you depends on whether you want to redistribute authority or fetch clicks.

And if your website is bilingual, one more thing comes in that no tool puts on the list by itself: every link applies in both versions. My own run suggested 190 German links and on top of that 188 missing English twins. 378 edits.

Internal linking is one of the few SEO levers that lie entirely in your hands. Neither a competitor nor the next algorithm update decides how you connect your pages with each other.

What I took away from the run in August is less a list than an attitude. The most plausible recommendation is not the most effective one. Your supposedly strongest page may well be a basin that passes nothing on. And what needs your attention most urgently is the page you published yesterday.

You do not have to build your own tool for this. You only have to stop guessing the order.