How to Fix Orphan Pages — and Find Them First

To fix an orphan page you add at least one internal link to it from a page that is itself crawled — but the hard part is not the fix, it is the finding. An orphan page has no internal links pointing at it, and a site crawler discovers pages by following internal links, so a crawl cannot reach one by definition. Every reliable method for locating orphans is therefore a join: you take a list of URLs from somewhere outside the link graph — your XML sitemap, your analytics, Search Console, your server logs, your CMS export — and subtract everything the crawl already found. What is left over is the candidate set. This guide covers the whole job end to end: how to build that join in the tools most people already own, how to triage the results so you are not linking to pages that should be deleted, and which of the resulting URLs are not worth touching at all.

Why a crawl cannot find them on its own

This is the single most useful thing to understand before you open a tool, and it is the step most guides skip straight past.

A site crawler works the way a search engine crawler works: it starts at a seed URL, reads the links on that page, queues them, and repeats. Google describes the same behaviour in its own documentation — crawlers "crawl the web by accessing URLs found in previously crawled pages", which is exactly why its sitemap guidance flags a site as needing a sitemap when it is large enough that not every page is linked from another page. A page with zero inbound internal links is unreachable by that process. It is not that the crawler is inattentive; there is no path to it.

So a clean crawl report showing no problems tells you nothing about orphans. The set of orphan URLs is, by construction, the set of URLs the crawl did not return. You can only see it by holding the crawl up against a second list built some other way, and subtracting.

That second list is where the method lives, and each source has a different blind spot. Analytics only knows about pages someone actually visited. Search Console only knows about pages that earned an impression. A sitemap only knows what your CMS chose to emit — and a page orphaned by a botched redesign is very often missing from the sitemap too, which is precisely the case a sitemap-only check cannot catch. Server logs see the most but are the hardest to get. Nobody source is complete, which is why serious audits run two or three and pool the results.

How to find orphan pages: five sources, one subtraction

The recipe is the same whichever tool you use. Crawl the site. Import an external URL list. Ask the tool which imported URLs it never met during the crawl. What follows is how that plays out in practice, cheapest first.

Your XML sitemap

The cheapest check you own, and the one to run first. Configure your crawler to fetch and crawl the linked XML sitemap alongside the site, then look for URLs present in the sitemap but absent from the crawl. It costs nothing and takes minutes. Its weakness is the one named above: a sitemap generated by the same CMS that lost the internal link will often have dropped the page as well. Treat a clean sitemap check as a floor, never a clearance. If you are not confident the file itself is sound, the conventions are covered in our guide to XML sitemap best practices.

Analytics

Pull a landing-page report over a long window — twelve months, not thirty days, because an orphan by definition gets very little traffic and a short window will hide it under the reporting floor. Any landing page that received sessions but never appeared in your crawl is an orphan candidate. This source is good at catching pages people still reach from email, ads or external links, and blind to pages nobody visits at all.

Google Search Console

Two angles here. The Performance report gives you every URL that earned an impression, which you can diff against the crawl the same way. More diagnostic is the Pages report: orphaned URLs cluster under Discovered — currently not indexed and Crawled — currently not indexed, because a URL Google knows about from a sitemap but cannot reach through links is a weak candidate for indexing. What each of those statuses actually means is set out in Google Search Console indexing statuses, and the broader diagnostic path in why isn't my page indexed.

Orphan pages: Screaming Frog, configured correctly

Screaming Frog is the tool most people reach for, and here the documented behaviour is worth quoting because it trips up a great many audits. Its Orphan Pages report, in Screaming Frog's own words, lists URLs "collected from the Google Analytics API, Google Search Console (Search Analytics API) and XML Sitemap that were not matched against URLs discovered within the crawl" — and the documentation states plainly that the report "will be blank, unless you have connected to Google Analytics, Search Console or configured to crawl an XML Sitemap" (Screaming Frog user guide).

Read that carefully, because it is the trap. An unconfigured run and a genuinely clean site produce the identical output: an empty report. Nothing on screen distinguishes them. Before you conclude a site has no orphans, confirm you actually connected a source and that crawl analysis has been run — otherwise you have measured nothing and filed it as a pass. The report's source column tells you which list each URL came from, which is also how you audit your own configuration.

Using an orphan page checker

Several vendors ship a hosted orphan page checker that automates the same join for you, and for a small site that is a perfectly reasonable shortcut — ours is free and runs the sitemap join described above: the EnterpriseSEO orphan page checker. Judge one on a single question: which external URL sources does it actually read? A checker that only compares your sitemap against its crawl is running the weakest of the five sources and will report clean on the redesign case. If it can authenticate against Search Console or analytics, it is doing the real work; if it cannot, it is a sitemap diff with a nicer interface.

Server logs and the CMS itself

Two sources worth knowing about even if you rarely use them. Server logs contain every URL anything requested, including pages no analytics tag ever fired on — the most complete list available, and the most work to obtain. And your CMS holds an authoritative list of every page it has published, which on most platforms exports in a couple of clicks. On a small site, diffing the CMS export against the crawl is faster than everything above and misses nothing that was published through the CMS.

Triage: not every orphan needs a link

Most orphan-pages SEO advice stops at "add an internal link", and following that uncritically will make a site worse. A list of orphan URLs is a list of candidates, and it will contain several kinds of thing that should not be linked into your navigation at all.

• Deliberately unlinked pages. Paid-ad landing pages, gated download thank-you pages, transactional confirmation screens and campaign microsites are frequently orphaned on purpose. Leave them. If they should also stay out of search results, that is a noindex decision, not a linking one.
• Pages that should be deleted or redirected. Expired offers, retired products, superseded posts. An orphan is often just an unfinished cleanup. Redirect it to the closest live equivalent, or let it 410, rather than restoring a link to something you would not publish today.
• Duplicates and parameter variants. Filtered, sorted and session-parameter URLs turn up in analytics and logs in bulk. These need canonicalisation or parameter handling, not links.
• Pages worth keeping but not worth promoting. Thin, dated content that still serves a small purpose. Either bring it up to standard — the process in our guide to content freshness — or retire it.
• Genuine orphans that should rank. The residue after the four categories above, and usually a much shorter list than the raw export suggested. These are the ones to fix.

Sorting the export into those five buckets before touching anything is the difference between an internal-linking improvement and an indiscriminate link dump. On a large site the triage pass takes longer than the fix.

How to fix orphan pages, once you have the list

For every URL that survived triage, the fix has three parts. Do all three; the first alone is what people mean when they say the fix did not work.

1. Add contextual links from pages that are themselves crawled. One link ends the orphan status; two or three from topically related pages is what actually moves anything. The linking pages must be reachable from the homepage themselves, or you have simply moved the problem one hop out. Place the links in body copy where the topic is genuinely being discussed, and write anchor text that describes the destination. Our internal linking strategy guide covers anchor text and placement in full.
2. Link it into a structure, not just a page. A single link from an unrelated post technically de-orphans a URL and leaves it isolated. Attach it to the cluster it belongs to — the hub page that covers the topic, and the sibling pages at the same level — so it inherits context as well as a path. That is the mechanism described in topic clusters, and the reason a fixed orphan often gains more than the one link would suggest is that it starts receiving internal link equity for the first time.
3. Confirm the fix landed. Re-crawl and check the URL now appears with at least one inbound internal link. Then use URL Inspection in Search Console on the affected page to confirm Google can fetch it. A fix you did not verify is a fix you are assuming.

Then prevent the recurrence, which is the part that decides whether you do this again next year. Make "link to it from at least one existing page, and add it to its cluster hub" a required step in your publishing process rather than a thing you remember. Re-run the orphan page audit on a schedule — quarterly is enough for most sites, monthly if you publish heavily or migrate often.

What causes orphan pages in the first place

Orphans are almost always a side effect of something else, and knowing which cause you are looking at tells you where the rest of them will be.

• Publishing without linking. New content goes live, nothing links to it, and the author moves on. The most common cause and the easiest to prevent.
• Redesigns and navigation changes. A menu is rebuilt, a category is retired, a template stops rendering a link block. This is the cause that produces orphans in batches rather than singly — find one, look for its neighbours.
• Deleting or unpublishing the page that did the linking. The orphan itself was never touched; its only inbound link was on a post someone pruned.
• Migrations. URLs change, some redirects are written, internal links elsewhere on the site are not updated, and pages fall out of the graph.
• Campaign and ad landing pages. Built outside the normal templates, deliberately unlinked, then forgotten after the campaign ends — at which point a deliberate orphan quietly becomes an accidental one.
• Links that exist but cannot be followed. A page linked only from a JavaScript-driven widget, a form, or an onclick handler is effectively orphaned for a link-following crawler. The mechanics are in our guide to website crawlability.

Documented, versus widely believed

Three claims separated by what actually supports them.

• Documented. A sitemap entry is not a substitute for an internal link. Google's sitemap documentation states that a sitemap "helps search engines discover URLs on your site, but it doesn't guarantee that all the items in your sitemap will be crawled and indexed" (Google Search Central). The same page describes a comprehensively internally linked site as one where Googlebot can find every important page by following links from the homepage. So "it is in the sitemap, it will be fine" is contradicted by the primary source.
• Documented. A crawler alone will not report your orphans. Screaming Frog's user guide states its Orphan Pages report is blank unless Google Analytics, Search Console or an XML sitemap crawl has been configured. Widely believed: that running a standard crawl and seeing no orphans flagged means a site has none.
• Consensus, not documented. That orphan pages are penalised. There is no documented penalty for an orphan page. The observed effect is ordinary and mechanical — poorer discovery and no internal link equity — not a sanction. Treating it as a penalty leads people to panic-link pages that should have been deleted.

And one honest gap: we have no published measurement of how much traffic a typical fixed orphan gains, and are not presenting an estimate as if we did. The size of the effect depends almost entirely on whether the page deserved to rank in the first place.

Frequently asked questions

How do you find orphan pages on a website?

Crawl the site, then compare the crawl against a URL list built outside the link graph — your XML sitemap, an analytics landing-page report over twelve months, Search Console's Performance and Pages reports, a CMS export, or server logs. URLs that appear on the outside list but never in the crawl are your orphan candidates. A crawl on its own cannot find them, because a crawler discovers pages by following links and an orphan has none pointing at it.

Why is Screaming Frog's orphan pages report empty?

Almost always because no external URL source was connected. Screaming Frog's documentation states the report will be blank unless you have connected Google Analytics or Search Console, or configured the crawl to include the XML sitemap — and that crawl analysis has to be run to populate it. An unconfigured crawl and a site with genuinely no orphans produce the same empty report, so confirm the configuration before you record the result as a pass.

Are orphan pages always bad for SEO?

No. Some are orphaned deliberately and correctly: paid-ad landing pages, thank-you pages, checkout confirmations and campaign microsites often should not sit in your navigation. Others are the residue of content that should be deleted or redirected rather than relinked. The genuinely harmful case is a page you want to rank that nothing links to, because it is hard to discover and receives no internal link equity. Triage the list before you fix anything.

What causes orphan pages?

Six common causes: publishing content without adding a link to it from an existing page; redesigns and navigation changes that drop a link block; deleting the page that carried the only inbound link; migrations where URLs change but internal links are not updated; campaign or ad landing pages built outside the normal templates; and links that exist only inside JavaScript widgets or forms, which a link-following crawler cannot traverse. Redesigns and migrations are worth checking first because they create orphans in batches.

Will a page still get indexed if it is in the sitemap but has no internal links?

It might, and you should not rely on it. Google documents that a sitemap helps search engines discover URLs but does not guarantee they will be crawled and indexed. In practice, sitemap-only URLs frequently sit under Discovered — currently not indexed in Search Console, and even when indexed they receive no internal link equity, so they compete on whatever external links they have earned alone.

How many internal links does a fixed page need?

One ends the orphan status. Two or three from topically related pages, at least one of them a hub or category page in the same cluster, is what tends to produce a visible change. There is no documented threshold, so treat those numbers as a working convention rather than a rule — and check that the pages doing the linking are themselves reachable from the homepage, or you have moved the problem rather than solved it.

Where to go next

If your orphans turned out to be a symptom of a broader discovery problem — pages buried deep, redirect chains, robots rules blocking directories — start with website crawlability rather than with linking. If the link graph itself is the issue, internal linking strategy covers anchor text, contextual placement and audit cadence, and link equity explains what those links are actually moving around. For the indexing side, indexation covers what happens after discovery succeeds. You can check a single URL's crawl and index status with our free crawlability checker.

If you would rather this ran as a standing audit than a quarterly reminder — the join built, the results triaged, the links placed and re-verified — that is what Cluster Mesh does.