An orphan page is a page on your own site that nothing links to, not your navigation, not another post, not even your sitemap in some cases. I found four of them on a client site last month by accident, while checking something unrelated in Search Console: pages that had once ranked, then quietly stopped getting crawled because every internal link pointing to them had been removed during a redesign. Nobody deleted the pages. Nobody deleted the content. The links just disappeared, and so did the traffic.
What an Orphan Page Actually Is
A page with zero internal links pointing to it. It can still be indexed (Google may have found it through an old sitemap entry or an external backlink), but with no internal links, it gets almost no crawl priority and passes no link equity to or from the rest of your site. Over time, an orphan page’s rankings tend to fade even if the content itself never changed, because internal links are one of the strongest signals you control for telling Google (and readers) a page matters.
It’s worth being precise about the definition, because the term gets used loosely. A page linked only from a footer or a legal-pages menu is technically not an orphan (something links to it), but it’s so weakly linked that it behaves almost like one in practice. A page that used to be linked and lost its links last month is a fresh orphan. A page that was never linked from anywhere except a one-time email campaign is a permanent orphan unless you deliberately fix it. Treating all three the same during an audit is how real orphans get missed.
Also Read: Internal Linking Strategy for WordPress: A Practical 2026 Playbook if you want the full linking system this fixes into.
Orphan Pages vs Other Pages That Look Similar
It helps to separate orphan pages from three other problems people confuse them with:
- Noindexed pages. Deliberately excluded from search, which is a different, intentional state. Don’t “fix” a noindex tag someone set on purpose while hunting orphans.
- Thin or low-quality pages. These can have plenty of internal links and still underperform, because the content itself is weak. Linking doesn’t fix a page with nothing useful to say.
- Crawl-blocked pages. Blocked in robots.txt or behind a login. Even a heavily internally linked page won’t get crawled if robots.txt stops it, which is a separate technical fix from adding links.
Confusing these categories during a site audit wastes time: you’ll add links to a page that was never going to rank regardless, or spend an hour rewriting content on a page that’s actually blocked at the crawler level and needs a robots.txt fix, not more prose.
How Pages Become Orphans
The usual causes, in order of how often I actually see them: a site redesign that rebuilds navigation and drops old category or tag links, a post that was only ever linked from a newsletter or a since-deleted homepage section, a page created for a campaign that nobody thought to interlink afterward, and old blog posts that used to be linked from a sidebar widget that got removed. None of these are rare mistakes. They’re normal maintenance byproducts that quietly compound over a few years.
A less obvious cause worth naming: pagination. If your blog archive only shows page 1 through page 5 in its paginated navigation and a post sits on page 12, and nothing else links to it, that post is functionally orphaned even though it’s technically part of the archive structure. Category and tag pages that go many pages deep hide old content this way constantly, especially on sites that have been publishing for several years.
How to Actually Find Them
There’s no single WordPress screen that shows this, so it takes cross-referencing two lists: everything that’s published, and everything that’s actually linked to internally.
- Export a full list of published URLs from your XML sitemap or the WordPress admin.
- Run a crawl of your site with a tool that maps internal links (Screaming Frog’s free tier handles most sites, or use an SEO audit tool with a site crawler built in).
- Compare the two lists. Any URL that’s live and indexable but shows zero inbound internal links in the crawl is an orphan.
- Cross-check against Search Console’s Pages report for URLs marked “Indexed, not submitted in sitemap” or with unusually low or zero click history despite being old, which often correlates with orphaned status.
Also Read: Google Search Console for WordPress: Setup and the Reports That Matter for the full Search Console workflow this pairs with.
Comparing the Actual Tools
None of these tools have a single button labeled “find orphan pages,” so the workflow above is manual regardless of which one you use, but each has a different way of surfacing the raw data:
- Screaming Frog (free up to 500 URLs). Crawl your site, then cross-reference the crawl’s “Inlinks” count against your sitemap in a spreadsheet. Slower to set up, no cost, works on any site size once you buy the license past 500 URLs.
- Ahrefs Site Audit. Has a built-in “Orphan pages (no incoming internal links)” filter under Internal link opportunities, which is the closest thing to a one-click version of this check. Requires a paid Ahrefs subscription.
- Semrush Site Audit. Similar built-in orphan-page report under its Internal Linking section, also paid.
- Google Search Console (free, but incomplete alone). Doesn’t have an orphan-page report by name, but the Pages report combined with a manual link check on suspect URLs gets you most of the way for a small site without buying a crawler.
For most WordPress sites under a few hundred pages, the free Screaming Frog tier plus a spreadsheet comparison is genuinely enough. The paid tools save time on larger sites, not accuracy.
How to Fix an Orphan Page
Don’t just add one random link and call it done. Find genuinely relevant existing posts (ones that already rank and get traffic) and add a contextual link from inside their body copy, not just a footer or sidebar link, which crawlers and readers weight less. If the orphan page’s content is thin, outdated, or overlaps too closely with a stronger page, the better fix is sometimes a 301 redirect into that stronger page rather than reviving a duplicate. If it’s a genuinely useful page, add it to your site’s main navigation or a relevant category/hub page as well, not just one blog post.
A Priority Framework: Which Orphans to Fix First
If your audit turns up a dozen orphan pages, fixing all of them at once is rarely the best use of an afternoon. Work through them in this order instead:
- Pages with existing backlinks. Check each orphan against a backlink tool. A page with external links pointing to it is already earning authority that internal linking would actually compound, so these come first.
- Pages that used to rank. If Search Console or your analytics history shows the page had real traffic before it went orphaned, reviving it recovers something you already proved works.
- Pages that fill a genuine content gap. Even with no history, if the topic is one your site doesn’t cover anywhere else, it’s worth linking in rather than redirecting away.
- Everything else. Thin, outdated, or fully duplicated pages with no backlinks and no history are usually better redirected into a stronger page than revived.
A Quick Real Example
On the client site I mentioned earlier, one of the four orphans was a genuinely useful “how to migrate” guide that had been linked only from a homepage banner removed eighteen months prior. It still had 40+ referring domains pointing to it from when it was actively promoted. That page went straight to the top of the priority list: I added three contextual links from newer, related posts, and it recovered roughly 60% of its previous organic traffic within about six weeks, without a single word of the content itself being rewritten. The other three orphans were old, thin category-explainer posts nobody had ever linked to. Those got 301-redirected into a single, stronger, updated guide instead of being revived individually.
Orphan Pages and Crawl Budget
On a small site, crawl budget rarely matters much, Google will crawl a 200-page site thoroughly regardless. On a large site (thousands of pages, frequent publishing, or a big e-commerce catalog), orphan pages compound a different problem: every URL Google has to rediscover without a clear internal-link path is a URL that competes for a limited crawl allowance against your actual priority pages. Cleaning up orphans on a large site isn’t just about reviving individual pages, it’s about making sure Googlebot’s attention goes toward the content that matters most, not toward re-finding pages your own site structure has effectively hidden.
Orphan Pages on E-Commerce and Large Content Sites
The pattern looks slightly different once you’re dealing with thousands of URLs instead of a few hundred. On a WooCommerce store, orphan pages are usually old product pages left behind after a category restructure, or seasonal landing pages that got a burst of promotion once and were never linked from the permanent navigation again. On a large publisher or documentation site, they’re usually old articles that fell off the bottom of a paginated archive years ago, or tag pages nobody actually uses that quietly accumulate orphaned posts underneath them.
The fix scales differently too. On a small site, manually adding two or three contextual links per orphan is realistic. On a large catalog, the more sustainable fix is structural: a “related products” or “related articles” block that automatically surfaces relevant internal links based on category or tags, so newly orphaned pages get picked up without anyone having to notice and fix them one by one. A dynamic block like this, built with something like Nexter Blocks’ Repeater block pulling from ACF or JetEngine data, effectively prevents future orphans at the template level instead of chasing them after the fact.
Preventing Orphan Pages at Publish Time
The cheapest fix is never letting a page become an orphan in the first place. Two habits catch most of it: before publishing any new page, add at least two links to it from existing relevant content in the same session, not “later,” which tends to mean never. And before removing a navigation item, a sidebar widget, or a homepage section during a redesign, export the list of URLs it links to first, so you have a checklist to re-link elsewhere rather than discovering the gap six months later in Search Console.
Make This a Recurring Check, Not a One-Time Cleanup
Orphan pages come back. Every redesign, every navigation menu change, every old post’s sidebar widget you remove creates the same risk again. Rerun the sitemap-vs-crawl comparison every quarter, and treat it as part of your normal technical SEO checklist, not a separate emergency project. Put a recurring calendar reminder on it; audits that only happen “whenever someone notices” are the reason orphan pages accumulate for years before anyone catches them.
Frequently Asked Questions
Can an orphan page still rank in Google?
It can stay indexed for a while, especially if it has external backlinks, but without internal links it typically loses crawl priority and ranking strength over time. Don’t assume “still indexed” means “still healthy.”
Is being in the XML sitemap enough to avoid orphan status?
No. A sitemap entry helps Google discover a URL, but it’s not an internal link and carries far less weight for passing link equity or signaling importance. A page can be in your sitemap and still be a true orphan.
How many orphan pages is “normal” for a site?
There’s no universal number, but a handful on a site that’s gone through a redesign or two is common. What matters more is whether they’re pages worth fixing (real content, real past traffic) versus pages worth simply redirecting or removing.
Should I always redirect an orphan page instead of relinking it?
No, only when the page is thin, outdated, or duplicates a stronger page you already have. A genuinely useful orphan with real content or existing backlinks is usually worth reviving with contextual links rather than redirecting away.
Suggested Reading
- Internal Linking Strategy for WordPress: A Practical 2026 Playbook
- The Technical SEO Checklist for WordPress
- Google Search Console for WordPress: Setup and the Reports That Matter
- How to Find, Fix and Submit Your WordPress Sitemap
