Orphan pages: finding the pages nothing links to

This is the misconception that keeps orphans alive. The page is in sitemap.xml, so it gets crawled, so what is the problem? The page probably does get crawled. The problem is everything else the link would have carried.

A sitemap is a list of addresses. An internal link is an address plus a context: anchor text describing what is there, a position in the site's structure implying importance, and a share of the authority of the linking page. A sitemap entry supplies exactly the first of those and none of the rest.

So a sitemap gets the page discovered. It does not get the page ranked, and it does not get the page found by a human.

There is a human argument too, and it is usually the larger one. A page nothing links to is a page no visitor can navigate to. If it earns traffic from search it earns it alone, with no path in from the rest of the site and no path onward from itself.

Almost never on purpose, and almost always by one of five events. Knowing which one you are looking at tells you whether to fix the page or the template.

• Campaign and landing pages. Built to be linked from an email or an ad, deliberately kept out of the navigation, then never linked from anywhere once the campaign ends. This is the most common orphan on a marketing site and often the highest-value one.
• Pagination that stops. An archive showing ten items per page with links to pages two and three, but a rolling window that drops older pages as new posts arrive. Everything past the window is orphaned progressively, in order, oldest first.
• A removed taxonomy. A redesign deletes category or tag pages, and every item that was only reachable through them loses its only route. The items are untouched; the path to them is gone.
• Product variants and filtered collections. Reachable through a filter interface that emits links via JavaScript rather than anchors, so a crawler sees no route even though a person can click one.
• Migrations. Content moved to new paths, internal links left pointing at the old ones. The new URLs have no inbound links and the old ones redirect, which hides the problem from anyone clicking around.

The tempting fix is a links block on some page pointing at each orphan. It works, briefly, and it does not stop the next one appearing. The durable fix is a template that cannot produce an unreachable item.

// Every post links to its siblings by date, so a post
// is reachable from its neighbours even if its category
// page is deleted or the archive window rolls past it.
const { prev, next } = await getAdjacentPosts(params.slug)

return (
  <article>
    {/* ...post body... */}
    <nav aria-label="More posts">
      {prev && <Link href={`/blog/${prev.slug}`}>{prev.title}</Link>}
      {next && <Link href={`/blog/${next.slug}`}>{next.title}</Link>}
    </nav>
  </article>
)

Adjacent-post links are unglamorous and structurally strong: they form a chain no rolling window can break, so an old post stays reachable from a newer one indefinitely. A full archive page with no pagination limit does the same job for a small site.

Indirectly, and the mechanism is discovery rather than comprehension. An assistant that fetches a URL reads it fine; being an orphan does not make a page harder to parse. What it affects is whether the page is in the index the assistant is drawing candidates from, and whether anything in your site suggests it matters.

There is a more specific effect worth knowing. When an assistant explores a site rather than a single page, it follows links, the same way a crawler does. A page with no inbound links is not in the neighbourhood of anything, so it never comes up as related context for a question about a topic it covers.

The honest summary: this is a search and navigation problem first, with an AI discovery cost attached. Fix it for the ranking and the human path, and the retrieval benefit arrives with them.