How to find and fix orphan pages on WordPress

1. Archive pagination

This is the big one. Your blog index links the ten most recent posts. Everything older is reachable only by walking pagination, and each page of pagination is itself one click further from the homepage. A post on page 12 sits fourteen clicks deep in a structure that looks shallow on paper. Technically it is linked; practically it is starved. See crawl depth explained for why that distance matters as much as the link itself.

2. Noindexed category and tag archives

Most SEO plugins recommend noindexing tag archives to avoid thin-content issues, and that advice is reasonable. The trap is when a tag archive was the only path to a group of posts. Noindexing a page does not remove it from the crawl path, but it does devalue it as an authority conduit — and if the plugin is configured to noindex and nofollow, or the archive is removed from the sitemap and the nav simultaneously, the posts underneath lose their only real support.

3. Attachment pages

WordPress generates a standalone page for every uploaded media file. These are near-empty pages carrying a single image, and they are linked from almost nothing. Modern versions of Yoast and Rank Math redirect them to the parent post by default, but sites that predate that change, or that switched plugins, often still have hundreds of them live.

4. Page-builder and landing pages

Pages built in Elementor, Divi or Beaver Builder for a campaign are typically published, added to the sitemap, and never linked from anywhere — because they were meant to be reached from an ad or an email. When the campaign ends the page stays, indexed and unlinked, competing with your real pages for the same terms.

5. Custom post types without archives

A CPT registered with has_archive set to false has no index page. If nothing else links its entries — no widget, no related-items block, no menu — every single entry is an orphan the moment it is published. This catches testimonials, case studies, team members and portfolio items constantly.

Your Yoast or Rank Math sitemap is the best source of truth here, because it is generated from the WordPress database and therefore lists posts regardless of whether anything links to them. Compare it against a crawl that starts from the homepage and follows links:

1. Open your sitemap index (usually /sitemap_index.xml for Yoast, /sitemap_index.xml or /sitemap.xml for Rank Math).
2. Note that it is split by post type — posts, pages, and each CPT get their own file. Collect all of them.
3. Crawl the site from the homepage, following links only.
4. Every URL in the sitemap that the crawl never reached is an orphan candidate.

Cross-reference the survivors against Search Console impressions. A WordPress post with no internal links that still draws impressions is your highest-value fix.

• chevron_rightPagination — stop relying on it. Build topic hub pages that link directly to every post in a cluster, and link those hubs from the nav. This replaces a fourteen-click path with a two-click one.
• chevron_rightRelated posts — a related-posts block gives every post a handful of contextual inbound links automatically. Prefer plugins that match on taxonomy and content rather than showing the newest posts, which recreates the recency bias you are trying to fix.
• chevron_rightAttachment pages — enable the redirect-to-parent setting in Yoast or Rank Math. This removes them rather than linking them, which is the correct fix.
• chevron_rightCampaign pages — either link them contextually from relevant content, or noindex them if they exist only for paid traffic. Leaving them indexed and unlinked is the worst of both options.
• chevron_rightCustom post types — register the archive (has_archive), or add a template that lists entries and link it from the nav.
• chevron_rightContextual links in post bodies — the highest-value fix and the one no plugin does well. A link inside a paragraph passes far more than one in a sidebar widget; see contextual vs navigation links.

Before attributing orphans to content, rule out the theme — because a theme problem produces a false orphan list that sends you fixing the wrong thing for a day.

Is the menu in the HTML?

View source on your homepage (Ctrl+U, not Inspect Element — Inspect shows the page after JavaScript has run). Search for a menu item's text. If it is not in the raw source, your navigation is built client-side, and any text-only crawl will report nearly every page as orphaned. That is a crawl configuration issue first and possibly a real SEO issue second.

Are your related-posts links real links?

Some related-posts and popular-posts widgets load over AJAX after page render. They look like internal links in the browser and are invisible in the HTML, so the inbound links you think each post has may not exist as far as a crawler is concerned. Same test: view source, search for the target URL.

Where do the links sit on the page?

A link in a sidebar widget that appears on every post passes far less than one inside a paragraph of related content. If your entire internal linking strategy is a "Recent Posts" widget, the technical orphan count will look fine while the pages stay starved. This is the distinction between technically-linked and meaningfully-linked, covered in contextual vs navigation links.

WooCommerce inherits every WordPress orphan pattern and adds two of its own, which is why product catalogues orphan faster than blogs.

First, shop archives paginate exactly like blog archives, so product 400 of 600 sits behind twenty pages of pagination. Second, out-of-stock products usually stay published while quietly dropping out of the default catalogue query — the product URL remains live and indexed, but the archive that was its only inbound link no longer lists it. It becomes an orphan without anyone touching it.

• chevron_rightCategory and tag archives are the primary link path — make sure every product is in at least one category that is itself linked from the nav.
• chevron_rightRelated products and cross-sells give each product contextual inbound links; configure them by attribute rather than leaving the default random selection.
• chevron_rightVariable product variations can generate URLs with attribute parameters that nothing links to — decide which are indexable and noindex the rest.
• chevron_rightOut-of-stock products: either keep them in the archive with a stock badge, redirect them to the category, or noindex them. Leaving them live and unlinked is the option that helps least.
• chevron_rightLink products from buying guides and blog posts. This is the highest-value fix and the one almost no store does.

WPML and Polylang create a full URL set per language, and the orphaning happens in the gaps. When a post is translated into three of five languages, the two untranslated versions often still have URLs generated, sitting outside every menu. Worse, language switchers commonly link only to the translated homepage rather than the equivalent page, so an entire language tree can hang off a single link.

• chevron_rightCrawl each language root separately — a crawl from the English homepage may never enter the German tree at all.
• chevron_rightCheck that the language switcher links page-to-equivalent-page, not page-to-homepage.
• chevron_rightConfirm hreflang annotations match the URLs that actually exist; a hreflang pointing at an untranslated URL creates a page nothing else links to.
• chevron_rightTranslate internal links too. A translated post that still links to English targets leaks its authority out of its own language tree.

Adding one link to every orphan from a single hub page technically de-orphans them and does very little, because a hub with eighty outbound links passes almost nothing to each. The order matters: fix the orphans that already earn impressions, link them from pages that actually hold authority, and use anchor text that describes the target. How to fix orphan pages covers that sequencing in full.

RankForge crawls any WordPress site from the outside — no plugin, no admin access — compares the crawl against your sitemap, and ranks each orphan by the authority a link would move, naming the source post, anchor text and paragraph to put it in.

Adding links is not the end of the job, because on WordPress it is genuinely common for a fix to not take — a caching layer serves the old HTML, a page builder saves the link into a revision that never publishes, or the block you edited sits in a template that only renders on some post types.

1. Purge your page cache and any CDN cache. WP Rocket, LiteSpeed and Cloudflare will all happily serve pre-fix HTML to crawlers for hours.
2. View source on the source post and confirm the new anchor is present in the raw HTML.
3. Re-crawl and confirm the previously-orphaned URL now appears with at least one inbound internal link.
4. Check the target's inbound link count, not just its presence. One link from a low-authority post is technically a fix and practically not much of one.
5. Give it a few weeks, then check impressions in Search Console for the target URL.

Set a recurring check rather than treating this as done. WordPress will keep producing orphans as posts age out of the archive, so the useful measure is whether the count trends down between audits — see how often to audit internal links.