How to Find and Fix Orphan Pages on a Large Website
An orphan page is a URL that has no discoverable internal links from other pages on your website. It may still be accessible through a sitemap, an external link, a campaign email or a direct URL. That is why a standard site crawl alone can miss it.
Orphan pages are not automatically bad. A private campaign landing page may be deliberately isolated. But an important product page, service page or research article with no internal links is harder for visitors and search engines to discover, and may receive less value from the rest of your site.
The practical challenge is not just finding URLs that a crawler cannot reach. It is comparing different sources of URL data, then deciding what each page is for. This guide explains how to find orphan pages on a website at scale and how to fix them without blindly adding links or deleting useful pages.
What counts as an orphan page?
For an audit, define an orphan page as a URL that has no incoming internal links from the crawlable pages in your chosen website scope. The scope matters. You might include only canonical, indexable HTML pages on the main domain, or include subdomains, language versions and certain application areas as well.
A URL can be absent from a crawl and still have links in the website’s rendered interface, or be listed in an XML sitemap without any internal links. Conversely, a URL can have internal links but remain undiscovered by your crawler because it is behind a login, blocked from crawling, or rendered in a way the crawler cannot process.
So treat “orphan” as an audit finding, not a permanent property of a URL. Record which sources were checked and what you counted as a valid internal link. Google’s guidance on crawlable links is a useful reference when assessing whether links can be followed by search systems.
Why orphan pages deserve attention
The consequences depend on the page. An orphaned page may be difficult for users to find through normal navigation, and crawlers may have fewer routes to discover it or understand its relationship to the rest of the site. It can also miss internal link signals that would otherwise help establish its importance.
That does not mean every orphan will be excluded from search results. Search engines can discover URLs through sitemaps, external links and other sources. Nor does the existence of an orphan prove that it caused a traffic or indexing problem. The audit tells you where the site’s link structure and its URL inventory do not agree.
For a large business site, the list often includes several different situations: old campaign pages, products removed from navigation, migrated URLs, regional pages, pagination or filter URLs, and content published in a CMS but never linked from a relevant section. The right response differs for each.
How to find orphan pages on a website
1. Agree the audit scope and URL rules
Before collecting data, decide what you are auditing. Include the relevant hostnames and subdomains, and note whether the scope includes HTTP variants, trailing-slash variants, language folders, staging hosts or application URLs. Set rules for which pages count as candidates—for example, HTML pages that return a successful response, rather than images or tracking endpoints.
Choose how to treat canonical tags, redirects and noindex pages. A redirected URL is not a live content page to link internally, but it may still indicate an outdated link or a stale URL source. A noindex page can be intentionally excluded from search while still needing internal links for users. Keep these states distinct in your data rather than removing them all at the start.
2. Crawl the site from its internal links
Run a crawl that starts from the main site entry points and follows internal links. Include links in the rendered page where practical, especially if navigation or content is added with JavaScript. Save the discovered URL list and, if available, each URL’s incoming internal link count, source pages, status code, canonical target and indexability.
A crawl is your view of what can be reached from the starting points under the crawler’s settings. It is not a complete inventory of every URL the business owns. If the site relies on client-side rendering, verify that your crawler sees the same important links and content that a browser does. Ryse SEO’s guide to testing whether a JavaScript website is rendering SEO content covers practical checks.
3. Build a wider list of known URLs
Collect URLs from sources that do not depend on the crawl following internal links. At minimum, check:
- XML sitemaps: include sitemap indexes and their child files. Google describes sitemaps as a way to tell it about URLs you consider important, while noting that submission does not guarantee crawling or indexing. See its sitemap guidance.
- Google Search Console: export relevant indexed and discovered URLs where available, and inspect examples of URLs reported as indexed, excluded or not found.
- Analytics: find landing pages that received sessions in a suitable period, including pages with little recent activity. A longer date range can help reveal seasonal or campaign pages.
- Server logs: if available, identify URLs requested by search crawlers or visitors that were not in the site crawl. Logs can also show repeated requests to old or orphaned paths.
- CMS and product systems: export published pages, active products, service locations and other records that may not appear in the main navigation.
- External link or campaign records: consider known campaign URLs, partner links and pages used in email or paid media.
Google’s Page indexing report documentation explains the kinds of indexing information available in Search Console. Treat it as one input: it is not a complete list of all URLs on your site, and its reporting can differ from a live crawl.
4. Compare sources and validate candidates
Combine the URL lists, then compare them with the URLs found by your internal crawl. A simple definition is: candidate orphan URLs are in one or more inventory sources but absent from the crawl’s set of internally reachable pages.
Normalize carefully before comparing. Lowercasing paths can be wrong on some systems; removing query strings can hide meaningful page variants; and collapsing trailing slashes can merge URLs that the server treats differently. Start with conservative normalization—usually hostname casing and known tracking parameters—and retain the original URL beside any normalized version.
Then validate likely candidates. Request the URL and record its response status, final URL after redirects, canonical target, robots directives and page type. Check whether a crawl error, robots.txt restriction or authentication requirement explains why it was missed. For a sample of pages, inspect the rendered HTML and look for links that your crawl may not have recognised.
Useful columns for a working sheet include original URL, source, HTTP status, canonical URL, indexability, crawl discovery status, last known organic or referral visits, conversions or business value, page owner and proposed action. Avoid treating a URL as a confirmed orphan just because it appears in a sitemap but not in one crawler’s report.
How to prioritise the orphan list
A large site can produce hundreds or thousands of candidates. Sort by business relevance, not just URL count. Start with pages that are live and indexable, have impressions or visits, attract useful external links, support a current product or service, or contribute to a high-priority user journey.
For example, a retailer may find a current product detail page in its product feed and sitemap, but not in the crawl. If the product is available, in stock and commercially important, investigate why category or related-product pages do not link to it. A discontinued seasonal landing page with no visits, no links and no current purpose is a different case.
Also look for clusters. A set of location pages created from a CMS template may all be unlinked because a navigation module stopped including new locations. That points to a template or publishing-process issue, not a need to add one-off links to every URL.
Choose the right fix for each page
Add relevant internal links
Use this option when the page is useful, current and should be discoverable. Link from a relevant category, hub, product listing or supporting article. Use descriptive anchor text that tells readers what they will find, and make the link visible in the normal page experience. A link added only to an XML sitemap does not solve the lack of internal pathways for visitors.
Do not add links indiscriminately to a global footer or create a “miscellaneous pages” list just to clear the audit. A good link has a sensible relationship to its source page and helps someone move through the site.
Redirect or consolidate obsolete pages
If a page has been replaced, redirect it to the closest relevant successor where one genuinely exists. If several pages cover the same topic and one is the clear, useful destination, consolidate the content and redirect the retired URLs. Avoid sending unrelated old URLs to the homepage: that usually creates a poor user experience and does not explain the change.
When deciding between a canonical tag and a redirect for duplicate URLs, use the page relationship and intended user experience, not the fact that a URL is orphaned. Ryse SEO’s guide to canonical tags versus redirects explains the distinction.
Remove pages that have no continuing purpose
If a page is obsolete and has no suitable replacement, remove it deliberately. Return an appropriate not-found or gone status rather than leaving a thin page live simply because it is in a sitemap. Check for valuable external links, ongoing visits, legal or customer-service requirements and references from other channels before removal.
Update the sitemap and any internal references when a URL is retired. If an unwanted URL is indexed, investigate its source and indexation signals as well; the separate guide to investigating indexed but unwanted URLs is relevant here.
Keep intentional isolated pages out of the wrong fix queue
Some pages are intentionally outside the main site structure, such as short-lived campaign pages or account-specific destinations. Confirm the purpose with the page owner. If it should not appear in search, review access controls, robots directives and noindex handling as appropriate. Do not assume that adding a noindex is the right response to every orphan; it addresses search visibility, not whether users can find the page.
Prevent orphan pages from returning
Build checks into publishing and release processes. A new page should have an owner, an intended parent or linking route, a status, and a decision about whether it belongs in the sitemap. For bulk launches, test a sample of URLs and confirm they are linked from the correct category or hub before release.
For migrations and redesigns, map old pages to their new destinations and check that important content remains reachable after launch. A website migration and redesign SEO checklist can help make link structure part of release QA rather than a post-launch discovery.
Schedule a recurring comparison appropriate to the site’s publishing pace. Large sites with frequent catalogue changes may need automated checks; a smaller content programme may only need a periodic review and a release-time check. Track newly orphaned URLs, resolved candidates and the reason for each decision. The useful outcome is not a zero-orphan score at any cost. It is confidence that important pages have deliberate routes, while pages that should be retired or isolated are handled intentionally.
FAQ
Can a page be indexed if it has no internal links?
Yes. Search engines may discover it through a sitemap, external links or other sources. Lack of internal links does not by itself prove that a page is unindexed, but it can make discovery and site relationships less clear.
Does being in an XML sitemap mean a page is not orphaned?
No. A sitemap is a URL discovery and signalling mechanism, not an internal link from one page to another. A URL can be in a sitemap and still have no incoming links on the site.
Should every orphan page be linked from navigation?
No. Add links where they help users and fit the site’s structure. A relevant category, hub or contextual link is often more appropriate than putting every page in the main navigation.
How often should a large website be checked?
Set a cadence based on how often the site changes and how costly missed pages would be. Frequent product or location publishing may justify automated checks, while a stable editorial site may use a scheduled crawl and a check during each major release.
What if my crawler finds links that Google does not?
Check whether the links are present in rendered HTML, use crawlable link markup, and are not blocked or dependent on an interaction that prevents discovery. Compare crawler settings with browser rendering and Search Console evidence before deciding that a page is accessible to search engines.