Fixing orphan pages with internal links

Orphan pages, fixed with links your editors can place in minutes

An orphan is a page nothing on your own site links to. Search engines and readers can only reach them through the sitemap or a lucky search. This workflow finds exactly where existing articles can link to each orphan, chooses the anchor from words already in the paragraph, and hands your team a list of verified options to apply.

Python scripts do the checking inside Claude Code. Nobody rewrites a sentence to make a link fit.

Why orphan pages hurt SEO quietly

An orphan page usually isn't broken. It loads, it's in the sitemap, and it may even rank for something. But with no internal links pointing at it, it collects none of the authority the rest of the site has built, and a reader who would benefit from it never gets there.

They pile up for boring reasons: a page published from a campaign, a template that stopped linking to its children, a redesign that dropped a section of the navigation. By the time someone notices, there are dozens.

How to find orphan pages first

The workflow starts from a list, not a guess. Orphans usually come from a site crawl that compares pages linked from the site against pages in the sitemap, or from the client's own SEO audit. The workflow takes that list as its input and doesn't try to redetect it.

Then it builds its own map of the site: every URL in every sitemap, checked to confirm it's live, and every article's body text indexed paragraph by paragraph, with the navigation, footer and forms stripped out.

How to fix orphan pages without rewriting anything

For each orphan, the workflow looks for articles that already discuss its topic, then reads their eligible paragraphs:

1. Search the indexed prose for passages about the orphan's subject, and rank donor articles by relevance.
2. Show Claude the eligible paragraphs from each donor, and have it choose a three-to-four word anchor that already appears in the text.
3. Record the position in the article, the sentence around the anchor, and a one-line reason the link helps the reader.
4. Verify every anchor is an exact match to the live text before it goes on the list.

Scripts never pick the anchors. Choosing them with pattern matching was tried early and dropped, so that judgement stays with the model and the checks stay in code.

The rules a paragraph must pass

A paragraph can only receive a link if it clears every one of these:

On top of that, two orphans can't claim the same spot in the same article, and a new batch can't place links next to ones from the batch before. When a conflict can't be resolved automatically, the run stops until a person decides.

What the client receives

The output is one spreadsheet. Each row is an option: the orphan, the donor article, the position, the exact anchor, the sentence it sits in and why the link belongs there. Most orphan-and-donor pairs come with two or three options, and the editor places one link per pair by wrapping text that's already on the page.

For Reply.io, the first batch covered 32 orphans with 192 donor pairs, and the editors used one of the offered options on 186 of them, 97%. The second batch covered 42 orphans with 227 pairs and 519 options, and every one of the 519 anchors matched the live text word for word.

Two lessons from the first batches

During the first batch, a temporary server fault made around 305 URLs return errors. Several research agents confirmed the pages were gone, which was wrong: once the fault was fixed, a second sweep found 304 of the 305 live again. A failure that hits hundreds of pages at once is now treated as a problem to recheck, not a finding.

The second lesson was about measurement. Counting adoption per offered option made the first batch look 49% used, when the real figure, counted per pair, was 97%. That wrong number came close to being reported as nearly 200 unused links.

How this differs from ongoing internal linking

Internal linking automation suggests links for new and existing articles as part of the publishing routine. This is a targeted repair for pages that already have no links at all, run in batches, with stricter placement rules and a record of every decision.

When an orphan batch pays off

Run a batch when a crawl shows more than a handful of orphans that deserve traffic, and your articles cover the same topics. It suits teams that would rather apply a list of safe, pre-checked options than have a tool edit live posts directly.

It won't rescue a page that shouldn't exist. If an orphan has nothing a donor article would naturally link to, the honest verdict is to merge it or let it go.

What an orphan batch costs

The scripts run locally and the model reads only the shortlisted paragraphs, so a batch of 40 orphans costs little to process. The time goes into reviewing collisions and judging borderline anchors.

Batches run under execution capacity, which is $2,000 a month for the agents and automations route on top of a fractional Head of Content retainer. The first batch on a new site takes one to two weeks, including indexing it.

Start with your orphan list

Send the orphan pages from your last crawl and your sitemap address. On a call we'll run one orphan through the whole process, so you can see the options your editors would get.