How to Automate Internal Linking in a Content Automation System

To automate internal linking well, a content system decides each post's links before the draft exists, puts every link on the words that name the page it goes to, and checks the whole site on every build for pages no sentence points at. The insertion is the easy part; the map and the check are what keep it honest. Plugins that scan old posts for a keyword and wrap it in a link skip both, which is how a blog ends up with hundreds of links and a handful of pages carrying all of them. This guide is how linking works as a checked step in a pipeline, with numbers from this site's own link audit.

How to automate internal linking: what the job actually is

Automating internal linking means turning three decisions into a repeatable step: which pages a new post should send its reader to, which words each link sits on, and which existing pages should now point back at the new one. A content system makes those decisions from a map of the site, not from a keyword match, and then checks the result the same way every time. The automation is in the planning and the checking. The sentence that carries the link is still written by whoever writes the post.

That is a narrower definition than most tools sell. The common product reads your archive, finds every occurrence of a phrase, and links it to the page you nominated for that phrase. It is fast and it scales, and it produces links nobody chose. Google's guide to link best practices for Google asks for anchor text that is "descriptive, reasonably concise, and relevant to the page that it's on and to the page it links to", and warns that stuffing keywords into links "is a violation of our spam policies". A phrase-matching plugin can satisfy the first half of that sentence only by accident.

Two parts of the subject already have their own guides here. Why a cluster of posts needs links between its pillar and its spokes is in how internal linking connects a content cluster, and how to choose the clusters in the first place is in the cluster section of the SEO playbook for a Content OS. This post is about what happens after the clusters exist: the link as a step a pipeline performs and then proves it performed. It is the part of automated website SEO that runs on every single post.

The map comes first: every post knows its hub before it is drafted

The first rule of automated linking is that each post's main links are decided in its brief, before a word of the draft is written, because a link added afterwards is a link looking for a sentence. The brief names the one commercial page the post serves, the two or three sibling posts it leans on, and the sections of older posts it deliberately leaves alone. The draft is then written with those destinations in mind, so the sentences that carry them say something about them.

On this site every brief carries an up-link line and an anchor line. The up-link is looked up in a table that pairs each subject with the service page it routes to. A post about internal linking or schema routes to the website SEO page, a post about LinkedIn to the LinkedIn page, and a post about approval gates to the automation section of the services page. Nobody chooses it by feel, so the service pages get their links consistently. The anchor line records the words the link will sit on, so the next brief can choose different ones.

The map also records what a post must not repeat. If an older post already explains something properly, the brief says so and the new post links to that section rather than arguing it again. That is linking as a defence against duplication: two posts covering the same ground compete for the same search, and one of them should simply point at the other. Our SEO and AI search guides are kept apart from each other this way, each owning one question and linking out for the rest. The map can be a table in the repository or a field in the brief template; what matters is that the check at the end reads the same map the brief did.

Anchor text that names where it goes, and changes from post to post

Good anchor text names the page it leads to, in words a reader would recognise as that page's subject, and it varies from one post to the next instead of repeating one target phrase forever. The W3C's guidance on link purpose in context states the reader's side of this: the criterion exists to "help users understand the purpose of each link so they can decide whether they want to follow the link". A link reading "here" or "this guide" asks the reader to click before telling them why.

Nielsen Norman Group's study of writing hyperlinks that are salient and descriptive adds the scanning reader. It reports that people mostly look at the first two words of a link, and that "when users see the same link twice on the same page they assume that it goes to the same place." So the words should front-load the destination's subject, and two different pages should never share one label. A pipeline can enforce both of those mechanically.

The check we run is deliberately simple: a link's own words must share at least one word with the destination's title, heading, description or address. When it was first switched on it flagged about one in seven of the links already on the blog, and most of those turned out to be fine, because the anchor quoted a source and the sentence around it named the source. Reading the sentence as well as the anchor brought it to about one in seventeen, and what was left were anchors that genuinely said nothing about where they went: "written down", "the choice between them", "what we build". Those are the habit the check exists to end.

Variation is the other half, and it is where automated linking goes wrong most quietly. A tool that links one phrase to one page produces the same anchor on every post, and the site ends up repeating one keyword at its own commercial page. The brief's anchor line exists so that each new post can see the words the last three used, and choose others.

Orphan pages, and the pages no sentence argues for

An orphan page is a page no other page on the site links to, and on a modern site with a full navigation and footer it barely exists; the more useful test is which pages no piece of content links to. A page reachable only from a menu is findable by a crawler, but no sentence anywhere has told a reader why it matters. Google's own phrasing is the standard to hold: "Every page you care about should have a link from at least one other page on your site."

Crawlers discover most pages by following links. Google's overview of what a sitemap is and when you need one says that "if your site's pages are properly linked, Google can usually discover most of your site", and that a sitemap "doesn't guarantee that all the items in your sitemap will be crawled and indexed." A sitemap is a list of addresses. A contextual link is a recommendation, and it is the recommendation that a page with no content links is missing.

We learned the discovery half on the day this site launched. Search Console's URL Inspection tool reported the homepage indexed and every other page as "URL is unknown to Google", which means Google had not yet seen the address at all. The sitemap fixed discovery. It did nothing for the other question, which is the one an orphan check should keep asking every week: which pages have we published that our own writing never mentions?

The check itself is cheap. Read every post's content, leaving out the navigation, the footer and any block repeated on every page, collect the internal links, and count how many posts point at each page. A page at zero is either a page the content should be sending readers to, or a page that should not exist. Search Console's Links report shows a version of this from Google's side, but its help page is clear that it "isn't a comprehensive list of every link on your site", so it is a cross-check, not the check.

The inbound edit: older posts link to the new one

Every new post should leave the build with two or three existing posts edited to link to it, because a post with no inbound links starts life as an orphan however well it links out. This is the step that is skipped most often, since it means opening pages that are already finished. It is also the step a pipeline can make impossible to forget, by refusing to call a post done until enough older pages point at it.

The edit is a sentence, not a list entry. Find the older posts that already discuss the new post's subject, and in each one find the paragraph where a reader would want the new post next. Then add a link on words that describe it, or a short sentence that does. A link added to a "related posts" box carries almost no context; a link inside the argument tells the reader and the crawler how the two pages relate.

On this site the rule is enforced in two places. The blog audit fails a new post that no existing post links to, and warns until at least two do. A separate filing check reads every post's body, and if a post names a platform three or more times it must either be listed on that platform's guide page or be recorded as a passing mention with a written reason. That second rule exists because the platform guide pages are the place a reader browsing by platform starts, and a post that is really about TikTok but never filed there is invisible to them.

The inbound edit has one constraint worth stating. It changes the older post's words, so it should change as few as possible and never the older post's argument, title or date. The new post is the one that bends to fit what is already published; the older post only gains a door.

When every post links the same five pages

Left alone, an automated linking step converges on the same handful of destinations, because the pages that are easiest to link are the ones that were linked last time. The result is a blog where a few pages are linked from nearly every post and dozens are linked from none. It looks like a lot of linking, and it is really five recommendations repeated.

The fix is to measure it per post. For every destination, count how many earlier posts already link it. A page linked by a quarter or more of the earlier posts is stock: useful, but it is not news to anyone who has read two posts. A page linked by two or fewer is quiet. Our rule for a new post is twelve to fifteen different internal pages, no more than four of them stock and at least three of them quiet, and no more than six shared with any of the three posts written just before it.

Quiet pages are rarely obscure. They are usually the newest posts, the topic and platform guide pages, and the newer service pages, all of which arrived after most of the archive was written and so were never in anyone's habits. Linking one of them from a sentence that is genuinely about it is the most useful internal link a new post can carry, because it is the one the reader has not already been shown.

Schema.org has a property for the links a page cares about most, significantLink, defined as "one of the more significant URLs on the page", typically "the non-navigation links that are clicked on the most". We do not use it in our markup, but it describes what a content link should be: chosen for this page, not navigation repeated in prose. Its neighbour, relatedLink, is "a link related to this web page", which is closer to what an automatic related-posts box produces.

Which links a script finds, and which a person decides

A script should find the candidates, count the links, catch the broken ones and refuse a post that breaks the rules; a person should decide which candidate a sentence is really about and write the sentence. Everything that is counting or matching is better done by a machine, which never forgets to check the forty-third post. Everything that is judging relevance belongs to whoever knows the subject, because a link is a claim that the other page is worth the reader's time.

The line is the same one we draw everywhere in a content system, set out in what to automate in your content and what not to: automate what is repeatable and checkable, keep what needs taste and accountability. Linking happens to split very cleanly along it.

A model can propose candidates, and its proposals are often good. But a model asked to add links will add them, bending sentences to carry them, so the writer places every link.

A worked example: this site's link audit, 31 October 2026

Here is the method on a real archive: this blog, measured on the day this post was written. The site has 142 pages, 73 of them blog posts. We counted only the links inside each post's own content, leaving out the navigation, the footer, the author note and the disclosure. On that count the pillar page for content automation is linked from 54 of the 73 posts, and the post on what to automate from 53. Thirteen pages are linked from no post at all.

Some of the thirteen are correct at zero. The homepage, the contact page, the privacy page and the blog listing are reached from the navigation and the footer on every page, and no argument needs to send a reader to them. The rest are the finding.

The TikTok content guides page, the systems thinking topic page, the Medium content automation page, the knowledge hub and the author's profile are on the list.

So are four tool pages added two days earlier, among them the Zapier guides page and the Make.com guides page. Each of those is a page we published, put in the sitemap, and then never mentioned in our own writing.

It was worse two weeks earlier. On 17 October the same count found 29 pages linked from no post, every topic and platform guide page among them, and the two tool homepages linked from 53 posts each. That measurement is why the link rule in the section above exists. The quiet-page minimum is the part that moved the number: every post since has had to send readers to pages the archive was ignoring, and the orphan list shrank as a side effect of writing normally.

The anchor count is the other finding. Of the 54 posts linking the pillar page, 24 use the identical words "content automation". That is no penalty in itself, but it is exactly the repetition the anchor line in the brief is meant to prevent, and it shows the habit clearly: when nobody records the last three anchors, everyone reaches for the same two words.

The tooling is ordinary. The count runs as a script in the repository, in the same Claude Code project the posts are written in. Claude Code's hooks reference describes a PostToolUse event that runs "after a tool call succeeds", so the same check can run after every edit and show its findings to the model straight away.

A team whose site lives in a CMS rather than a repository can do the same weekly with n8n: its Schedule Trigger node runs a workflow "at fixed intervals and times", which is all an orphan report needs.

What link upkeep takes after the first month

After the first month, internal linking costs a few minutes per post and almost nothing in between, as long as the map and the checks were built at the start. The expensive part is the first pass on an existing archive: counting what links where, deciding what each orphan should be, and writing the sentences that link the quiet pages. It falls on someone who knows what each page is for.

From then on each new post costs its writer a little time at two points. The brief takes a minute longer because it names destinations and anchors. The finish takes a few minutes more because two or three older posts need a sentence each. The checks themselves cost nothing to run and catch the mistakes a tired editor would make, including a link to a page that was renamed.

Renames are the hidden cost. A page that changes its address breaks every link to it unless the old address redirects, and the fragment after a "#" is its own trap: the URI standard, RFC 3986's section on fragments, says a fragment is "dereferenced solely by the user agent", so no server will ever report that a section heading was renamed. Only a check that opens the target page and looks for the heading will find those. Ours does not do that yet: it confirms every linked page exists and ignores the part after the "#", so section links are checked by hand when the post is reviewed. That is a gap we know about and have written down. Repairing links after an edit is the job of the links-and-dates step of the content refresh loop.

What it buys is a site where every page has a reason to be found and every link a reader meets was chosen for them. If you would rather have the checks built into your own site than maintain them by hand, they are part of the website SEO automation setup, which we quote separately because the work depends on the site, and part of what an SEO content system runs on every article.

Frequently asked questions

Can internal linking be fully automated?

Internal linking can be mostly automated, but the final choice of each link should stay with the writer. A script can rank the pages closest to a new post, count how often each is already linked, find orphans and broken links, and refuse a post that breaks the rules. Deciding which page a sentence is really about, and writing the words the link sits on, needs someone who understands the argument.

How many internal links should a blog post have?

There is no ideal number, and Google says so directly in its link guidance. Our own rule for a new post is twelve to fifteen different internal pages in its content, because that is enough to reach most sections without crowding any paragraph. What matters more than the count is that each link is relevant to its sentence and that the set is not the same set every other post carries.

What is the difference between an orphan page and a page with no content links?

An orphan page has no internal links pointing to it at all, so a crawler following links cannot find it. A page with no content links is still reachable from the navigation or footer, but no post or page mentions it in a sentence. The first is a discovery problem a sitemap partly fixes; the second is an endorsement problem only better writing fixes.

Should anchor text use the exact keyword of the page it links to?

Anchor text should describe the destination in the sentence's own words, which sometimes includes the page's keyword and often does not. Repeating one exact phrase on every link to a page reads as keyword stuffing, which Google's link guidance calls a spam policy violation. Varying the words across posts while keeping them descriptive is better for readers and safer for search.

Do links to a section of the same page count as internal links?

Links to a section of the same page are useful for navigation, but they do not send a reader to another page, so we do not count them toward a post's internal links. A table of contents, for example, scrolls the reader down rather than recommending anything new. Links to a section of a different page do count, as one link to that page.

How often should a site be checked for orphan pages?

A site should be checked for orphan pages on every build if it is built from a repository, and at least weekly if it lives in a CMS. The check is a count of how many pieces of content link to each page, which takes seconds to run. The decision about each orphan, whether to link it or retire it, can wait for a monthly review.

Will better internal linking improve rankings?

Better internal linking helps search engines discover pages and understand how they relate, but no one can promise it will move a ranking. What it reliably does is make sure every page you care about is reachable and recommended, and that readers find the next useful page. Treat it as making the site easier to understand rather than as a lever with a guaranteed result.

Where to start

Run the count this week. List every page on your site, read the content of every post with the navigation and footer left out, and write down how many posts link to each page. Sort it both ways. The pages at the top are the ones every post already recommends, and the pages at zero are the ones your own writing has forgotten. Pick the three zeros that matter most, and in your next post, find a sentence that is genuinely about one of them. That single habit, repeated, is most of what automating internal linking is.

Keep reading

• Content clusters: the bridge between knowledge and content — why a pillar and its spokes need links before any pipeline places them.
• How to automate content refreshes without losing quality — the loop that repairs links and dated claims after a page changes.
• How to build content Google and AI search can both understand — the same checking discipline, applied to the sources a page cites.