Guides

How to fix an orphan page with no incoming internal links

October 15, 2026 · 8 min read

The warning "Orphan page has no incoming internal links" means one specific thing: a page your sitemap lists has nothing on your site pointing at it. Not too few links, none at all. The page is in the sitemap, so it can be found, and it is not in the navigation or in any article, so nothing connects it to the rest of the site.

It is one of the few audit findings with a straight answer. Nothing is broken, no markup is malformed, and no content has to be rewritten. Either the page earns a link from pages that are genuinely about the same subject, or the page should not exist. This guide walks the steps below in order, and the order matters: deciding whether to keep the page before you hunt for places to link it saves you linking something you were about to delete.

Step 1: Find every orphan, not just the one in the warning

Start from a whole site crawl rather than from the page in the warning. Audit tools print the warning per page, so it is easy to fix that one URL and stop, then find the same warning on four more addresses a month later.

A single page check cannot produce the list at all, and that is not a limitation of any one tool. A page nothing links to is invisible from inside every other page, so the only way to be sure a page has no incoming internal links is to read the pages your sitemap lists and count the links between them. That is what a crawl from the sitemap does.

Treat two lists as the output. The first is pages with no incoming links at all. The second is the contextual orphans, the pages whose only incoming links come from the template: the navigation, the header, the footer. That second list is usually longer, and its fix is the same as the first list's fix, so work them together. Export both before you start editing, because a CSV is a record of what the crawl actually found and you will want it when you re-run.

Step 2: Decide whether the page should exist

One question per page, and the answer decides which of three routes you take.

  • Keep and link it. The page answers a question somebody asks, or it is a product or service page that earns signups or enquiries, or it carries search traffic you would rather not lose. It stays, and you give it links.
  • Merge it into a stronger page. The topic is real but this URL duplicates a better page, or the content is too thin to stand on its own. Move anything useful into the page that should rank, then redirect the orphan to that page. A redirect keeps any link from another site working and sends the visitor somewhere useful instead of a dead end.
  • Remove it. The page is outdated, describes an event that has passed, a product you no longer sell, or a page you never meant to publish. Delete it and return a not found status, or a gone status if you want search engines to drop it faster.

Two shortcuts are worth avoiding. Do not link a page you intend to delete just to clear the warning, and do not leave a page in the sitemap after removing it. The check is applied to the pages the sitemap lists, so a page removed from the sitemap stops being reported. That is not the same as being fixed, and the next crawl reads it as gone rather than repaired.

Step 3: Link it from pages that are actually about the same thing

Now the useful part. A link from a relevant page does two jobs: it takes the page off the orphan list, and the sentence around the link tells a crawler what the page is about.

  • Choose sources by subject, not by authority. The best source is a page that already discusses this topic, the section hub the page belongs to, a category page, a related guide, or the parent product page. A rough rule: if a reader on the source page would want this page next, the link belongs there.
  • Reuse a sentence that already exists. The strongest anchor is a phrase that already appears on the source page and matches the target page's subject, because then the link reads like part of the sentence rather than a label bolted on. A suggestion in a crawl report gives you the anchor and the source sentence for exactly this reason.
  • Write anchor text that describes the destination. The words in the link should name the page's topic. "Read the guide" describes nothing; "orphan page with no incoming internal links" tells the reader and the crawler what is on the other side.
  • Put the link in the body content, not in the template. A link added to the navigation or the footer clears the orphan warning, because the page now has an incoming link, and it leaves the page a contextual orphan, because a template link appears on every page and says nothing about this one. Both lists are in the report, so a template link just moves the page from one to the other.
  • A few good links beat many weak ones. Two to five links from pages that share the topic are worth more than a dozen from pages that do not. When the page is a hub, link the children from it and link back to it from one or two of them, so a reader can move in both directions.

One technical point that catches people. Add the link so it exists in the HTML the server sends. If the link is injected by a script that runs in the browser, a crawler reading the static HTML never sees it, and the warning will not clear no matter how many times you check the page in a browser and find the link there.

Step 4: Update the sitemap

The sitemap is the list a crawler starts from, so it has to agree with the decision you just made.

  • A page you kept that returns a normal 200 response and should be indexed belongs in the sitemap. If it was missing, add it now.
  • A page you redirected or deleted comes out of the sitemap. A sitemap should list canonical, indexable pages, and leaving a redirect or a dead address in it wastes the crawler's budget on an address that no longer serves the page.
  • A page marked noindex should not be in the sitemap either, because the two instructions contradict each other: the sitemap says index this, the meta tag says do not.
  • If the sitemap is generated by your framework, check that the generator reads the live pages rather than a hand-maintained list, and that its last modified dates are real. If it is maintained by hand, this is the moment it drifts.

Step 5: Re-run the crawl and confirm the warning cleared

Re-crawl the site and read the orphan list again. The page should be gone. If it is still there, work through this short list, because each of these produces the same warning for a different reason.

  • The link is in the rendered page but not in the raw HTML, so the crawler never saw it.
  • The link points at an address that redirects, so the target counted is not the page you meant.
  • The target page does not return a normal 200 response: it is a redirect, a soft 404, or blocked by robots.txt.
  • The page is linked only from the template, which means it left the orphan list and joined the contextual orphan list.
  • The change lives on your machine or in a staging environment, and production has not been updated.
  • The page you edited is itself not in the sitemap or was not crawled, so its links were never counted.

Fix pages by what they are worth, not by what order they appear in. A page with search traffic and no internal links comes first, then hubs and product pages, then the archive. The free plan allows three crawls a month, which is enough to re-run after each batch of edits, and the exported CSV is the before and after record for the work.

To find the whole list for your own site, start with the orphan page finder. If you are not yet sure how the warning is defined or what makes a page count, read what is an orphan page first, then come back to the steps above.