Automating Internal Linking Across a Growing Blog

You can automate internal linking by treating your blog as a graph the machine can read: build the link map from the source files, find posts nobody links to, and let a script propose links that a rule set checks before anything merges. The model suggests. The rules decide.

Skip the rules and a link plugin will happily stuff exact-match anchors into every paragraph. Skip the graph and you will keep adding posts that nothing points at.

Below is the loop we would run: what to measure, what the machine may insert, what it may never touch, and which checks stop a bad link from shipping.

Why does internal linking break as a blog grows?

Internal linking breaks because each new post is written linking backward, to older posts, while nothing in the process sends links forward to the new one. The newest posts end up with no inbound links. Search engines and AI retrieval find them late, or rate them as unimportant.

Google’s link best practices, last updated in December 2025, state the baseline plainly: every page you care about should have a link from at least one other page on your site. Ahrefs defines an orphan page as a URL with no incoming internal links, found only through a sitemap or as a crawl seed.

The failure is structural, not a writing lapse. A writer adding post 60 cannot hold posts 1 to 59 in their head. The fix has to be a process step that runs every time, not a habit.

We hit this ourselves. In September 2026 an audit of our own blog found posts with no inbound links, because we publish daily and each new post linked back to only one or two older ones. We fixed it with a link-only repair pass and then moved the check into the pipeline.

What should the machine measure first?

Measure three things per post: how many internal links point in, how many point out, and whether each target resolves. Those counts come straight from the source files, so they need no model and no crawler. A script that reads the posts folder and builds a map of who links to whom is the foundation.

From the map you get a short report:

• Orphans: posts with zero inbound links. These are the first job.
• Thin posts: pages you care about, such as service-adjacent guides, with only one or two inbound links.
• Dead links: any internal link whose target no longer exists, usually from a renamed or deleted slug.
• Hoarders: pages that send out far more links than they receive, which dilute their own outbound value.

Everything on that list is a fact about files. Nothing needs to be guessed, which is the point: a model that has to invent the audit will invent the audit.

How should the machine find where a link belongs?

The machine should read the orphan and each candidate donor post, and propose one specific sentence in the donor where the link fits already. It matches by topic, not by keyword count. Its output is a patch: the donor file, the existing phrase to become the anchor, and the target slug.

Use the donor’s own words. The rule we like is that the anchor is a phrase already present in the sentence, so the machine inserts a link and rewrites nothing. A model asked to “add an internal link” will rewrite the sentence to make room, and now your edit is a content change, not a link change.

Google’s guidance supports this shape. Its docs say anchor text tells people and Google something about the page you link to, and should be descriptive and concise rather than generic text like “click here.” A phrase lifted from a real sentence meets that by default.

Prefer donors that already rank or get read. A link from a page nobody visits adopts the orphan in the graph and adds no real discovery.

What are the hard limits on an automated link?

Limit each patch to one new link, in an existing sentence, to a target that exists, with a descriptive anchor. Cap the links per donor, never repeat a target inside one post, and ban link-only edits that change any other text. If a patch breaks a limit, it is rejected, not repaired by the model.

Here is the rule set, and how each rule is checked:

Rule	Why it exists	How a script checks it
Target slug exists	Dead links waste a crawl	Resolve against the posts folder
Anchor is not generic	”Read more” tells no one anything	Match against a banned-anchor list
Anchor text is unchanged prose	Link edits must not rewrite content	Diff: only link markup added
One link per target per post	Repeats add nothing	Count targets per file
Required link types untouched	Service and proof links are fixed by the brief	Compare required links before and after
Donor not already crowded	Too many links hide the important ones	Count outbound links per post

The last row matters more than the old “100 links per page” folklore suggests. Google has no published internal link quota, but its John Mueller said in a 2021 Search Central hangout that when every page links to every page, Google cannot see which pages you think are important.

Why is a diff check better than reading the result?

A diff check proves the edit only added a link. Reading the new post proves nothing, because a fluent model produces fluent prose even when it quietly changed a number or removed a caveat. The script compares old and new text and fails any patch where the only change is not link markup.

This is the same discipline we describe in how AI content quality checks work, applied to an edit rather than a draft. The rules exist before the model runs. A script applies them, so nobody has to notice.

A refresh pass has the same shape. When we describe refreshing old posts without breaking what ranks, the locked elements include “internal links that other pages point at,” which is exactly what this loop protects from the other side.

What should you leave to a person or a rule, not the model?

Leave three decisions out of the model’s hands: which pages are your priority pages, which pages must never receive links, and the link caps. Those are strategy, and strategy is a short written list. The model proposes within the list. It does not edit the list.

Which pages matter is the one most teams skip. The graph shows what is linked, not what is valuable. A service page with three inbound links and a forgotten announcement with thirty both look fine to a counter. Write the priority list once, and weight your reports by it.

That list is a human input, the same as a topic queue or a voice rulebook. Once it exists, the loop runs on its own: scan, propose, check, merge on green gates. No one approves individual links.

Does internal linking matter for AI search too?

Yes, and Google says so directly. Its AI features documentation, updated in December 2025, lists making your content easily findable through internal links as one of the practices that still apply for AI Overviews and AI Mode. It adds that there are no additional technical requirements beyond standard Search eligibility.

That is a useful corrective to the idea that AI search needs a special trick. The page has to be crawlable, indexed and discoverable. An orphan fails the third test before any model reads it.

If you want your posts quoted back by an assistant, the boring work comes first: structured data that machines can parse and a link graph with no dead ends.

What does the full loop look like?

The full loop has five steps and runs on every publish: rebuild the link map, list orphans and thin posts, propose link-only patches from existing sentences, run the rule checks, and merge what passes. The new post is checked as a target before it ships, so it never starts life as an orphan.

1. Map. Parse every post’s links from source.
2. Score. Rank targets by need: orphans first, then priority pages with thin inbound counts.
3. Propose. For each target, pick a donor and an existing phrase.
4. Check. Scripts verify the six rules above. A failed patch is dropped.
5. Merge. Passing patches ship together as one small change, with the link map attached.

The ordering that matters is that step 1 runs before a post is merged, not months later in an audit. We learned that the expensive way.

How we install this

We build this inside our Content Engine: the same pipeline shape we run for our own blog, with the link map, the patch rules and the link-only diff check included. How the original pipeline performs is on our inbound machine proof page.

A tomte, our word for one production agent with one defined job, runs the proposal step. A script, not the tomte, decides whether the patch ships.

If your blog has outgrown the memory of whoever writes it and you want the graph kept honest automatically, Start async. You get a written reply within one business day, and there is no call to book.