Which Pages on Your Site Does Nothing Link To?

Which Pages on Your Site Does Nothing Link To?

Almost every site we audit has some. They are called orphan pages: real, published URLs that no internal link points to. Google's own guidance is that a site whose pages are properly linked can usually be discovered in full, so an orphan is a page you have quietly cut off.

They are easy to create and hard to notice. A landing page from a campaign that ended. A blog post whose category got renamed. A pricing page you replaced but never removed. Nothing on your site points at them, so nothing on your site helps them rank.

This is a short, practical walkthrough of how we find them, how we decide what to do with each one, and how to stop making new ones.

What Is an Orphan Page?

Screaming Frog puts it plainly: "An orphan page is a page that cannot be found by crawling the internal links of a website from the start page." So if you begin at your homepage and follow every link, and you never arrive at a URL, that URL is an orphan. It may still exist, load fine, and even get traffic.

The word "orphan" sounds worse than it sometimes is. A thank-you page after a form submission is technically unlinked, and that is correct. The problem is the pages you meant to be part of the site and forgot.

Why Do Orphan Pages Happen at All?

Because sites change faster than their navigation does. In our work the usual causes are dull and repeatable, which is good news, because dull and repeatable problems can be checked for.

A CMS collection gets restructured, and old items stop appearing in any list. A navigation menu gets simplified before a launch, and three pages fall out of it. A paid campaign builds a landing page that lives outside the main site tree on purpose, then the campaign ends and nobody revisits it. A redesign ships with a new blog index that only shows posts tagged a certain way.

Google names the same risk in its sitemap documentation, noting that on large sites "it's more difficult to make sure that every page is linked by at least one other page on the site." Size makes it worse, but small sites are not immune. A 40 page marketing site can easily carry six orphans.

Does an Orphan Page Still Get Indexed?

It can, especially if it sits in your sitemap. But a sitemap is a weaker signal than a link. Google is explicit 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."

Links do more than help with discovery. Google's link best practices documentation says the company "uses links as a signal when determining the relevancy of pages and to find new pages to crawl." An orphan gets neither the relevancy signal nor the anchor text that tells Google what the page is about.

So the usual outcome is not a page that vanishes. It is a page that underperforms quietly, forever, and nobody can say why. That is a harder problem than a page that simply 404s.

How Do You Actually Find Orphan Pages?

You cannot find them with a crawl alone, and this is the part people get wrong. A crawler that starts at your homepage and follows links will never see a page that no link points to. You have to feed it URL lists from somewhere outside the link graph, then compare.

Screaming Frog's documented method is to bring in three extra URL sources: XML sitemaps plus the Google Analytics and Search Console APIs. Its orphan pages report is a list of URLs collected from the Google Analytics API, the Search Console Search Analytics API and your XML sitemap that were not matched against URLs found in the crawl.

The logic is simple once you see it. A URL that Search Console says got impressions, but your crawl never reached, is a page Google knows about and your site does not link to. That is your orphan list.

What Do You Need Before You Run the Crawl?

Three settings and one extra step. Screaming Frog names each one. Turn on "Crawl Linked XML Sitemaps" under Configuration, Spider, Crawl. Turn on "Crawl New URLs Discovered In Google Analytics" under Configuration, API Access, Google Analytics. Turn on "Crawl New URLs Discovered In Google Search Console" under Configuration, API Access, Search Console.

Then run Crawl Analysis after the crawl finishes. This is the step people skip. The tool's own explanation is that it "will only know which URLs are missing from an XML Sitemap and vice versa when the entire crawl completes." Until you run that post-crawl pass, the orphan filters stay empty and you conclude, wrongly, that you have no orphans.

The results land in three places: an Orphan URLs filter under the Sitemaps tab, another under Analytics, another under Search Console, plus a combined Orphan Pages report under Reports for export.

How Do You Tell a Real Problem From a Harmless One?

Sort the list into three buckets before you touch anything. We do this in a spreadsheet, and it takes about twenty minutes on a normal marketing site.

Bucket one is pages that should be linked and are not. A service page, a comparison page, an integration page, a blog post that still gets impressions. These are the wins. Bucket two is pages that are correctly unlinked by design: thank-you pages, gated confirmation pages, campaign-only landing pages you do not want in organic search. Leave them, and check they are noindexed if that was the intent. Bucket three is pages that should not exist. Old duplicates, dead campaign pages, a staging page that shipped by accident.

Search Console impressions are the fastest sorter. A URL with real impressions and no internal link is almost always bucket one. A URL with zero impressions in twelve months and no clear purpose is usually bucket three.

What Do You Do With Each Orphan You Find?

Bucket one gets links, from somewhere that makes sense to a reader. Not a footer dump. Put the link in the body of a related page where a person would plausibly click it, with anchor text that describes the destination. Google's guidance on anchor text is that it "tells people and Google something about the page you're linking to," and an empty or vague link text is called out as bad practice in the same document.

Bucket two gets left alone, with one check: make sure the page's indexing directive matches your intention. Bucket three gets removed and redirected to the closest living equivalent, or left to 404 if there is no equivalent and nothing links to it anyway.

We covered the wider practice of putting links where they earn their keep in our guide to internal linking for SEO, and the question of how deep a page should sit in site architecture and click depth. Orphan cleanup is the emergency version of both.

How Often Should You Run This Check?

Quarterly for a stable site, and once immediately after any redesign, migration, or navigation change. Those three events create most orphans, and they create them all at once.

It is also worth a look whenever a CMS structure changes. On a site like Gow-Gates, which runs on four Webflow CMS collections for services, products, industries and careers, a change to how one collection is filtered on a listing page can silently unlink a whole group of items. Nothing breaks. The pages just stop being reachable.

If you have a small site, Google's own advice is not to over-invest in the Page indexing report: its documentation says if your site has fewer than 500 pages, you probably do not need that report, and suggests site: searches and the URL Inspection tool instead. That does not remove the need for an orphan check. It just means you can do the check without living inside Search Console.

What Does Fixing This Actually Get You?

Usually a modest, cheap improvement on pages you already paid to build. That is the honest pitch. You are not creating anything new. You are reconnecting work that already exists to the rest of the site, so Google can read it as part of your site rather than as a stray URL.

It is also one of the few SEO tasks with almost no downside risk. Adding a sensible contextual link to a real page cannot hurt you. Deleting a genuinely dead duplicate cannot hurt you. Compared with a content refresh programme or a technical migration, an orphan audit is a small afternoon with a predictable payoff, which is why we run one on every site we inherit. The related question of what to delete outright is covered in pruning old blog posts.

If you want us to run this on your site, or you have inherited a site and have no idea what is connected to what, we are happy to take a look. You can reach us at phoenix.studio.