Deep or Lost? Mastering Your Site Structure, Internal Linking, and Orphan Pages

How to Find and Fix Orphan Pages Without Flattening Your Site

Site structure is the way navigation and internal links connect your pages. An orphan page has no crawlable internal link from another page within the audited site. A deep page is different: it is linked, but it takes several internal link steps to reach.

Google’s link best practices say every page you care about should have a link from at least one other page, while also stating that there is no magical ideal number of links. The familiar “three-click rule” is therefore a useful warning sign at most, not a Google requirement or a universal ranking threshold.

This guide shows you how to build a complete URL inventory, separate true orphan pages from false positives, decide which pages deserve stronger links, and verify that your changes worked without stuffing every URL into the main menu.

What Poor Site Structure Actually Changes

Discovery

Search engines discover many URLs by following links. A page with no crawlable internal links is harder to discover through the site itself. It may still be known through an XML sitemap, an external link, a previous crawl, or another source, so “orphaned” does not automatically mean “not indexed.” The reverse is also true: adding an internal link does not guarantee indexing.

Context and relative importance

Internal links help explain how pages relate to one another. The source page, surrounding text, anchor text, and wider pattern of links all provide context. A page that is linked prominently from relevant hubs will usually be easier for users and crawlers to understand than one that appears only in an old footer or a disconnected archive.

User journeys

Visitors should not need to know an exact URL or use site search to reach an important service, product, article, or policy page. Clear categories, contextual links, breadcrumbs, and pagination give people several understandable routes through the site. Site search can help, but it is not a replacement for navigable structure.

Content governance

A structure audit also exposes pages that no longer have an owner or purpose: expired campaigns, duplicate categories, forgotten tag pages, discontinued products, and old landing pages. The right fix is not always “add a link.” Some pages should be consolidated, redirected, excluded from search, or removed after their value and dependencies have been checked.

Use These Signals Instead of a Single Click-Depth Rule

Click depth is useful, but only when interpreted alongside page purpose, internal inlinks (links from other pages on the same site), crawlability, and business importance. ScanMySEO recommends treating depth as a prioritisation signal rather than a pass-or-fail SEO rule.

Separate four different problems

• Orphaned: The audit found no crawlable internal link to the URL within the defined crawl scope.
• Underlinked: The page has an internal link, but only from a weak, irrelevant, hard-to-reach, or purely templated location.
• Deep: The page is reachable, but requires more internal link steps than its importance appears to justify.
• Interaction-dependent: The page appears only after a search, filter, button press, or JavaScript interaction that may not expose a normal crawlable link.

These conditions need different fixes. A genuinely orphaned service page may need a relevant hub link. A deep legal archive may be perfectly acceptable. A product hidden behind a “Load more” button may need crawlable pagination rather than a sitewide menu link.

Make the link itself crawlable

For important navigation, use a real anchor element with an href value and descriptive link text:

<a href="/services/technical-seo-audit">technical SEO audit service</a>

JavaScript can insert links, but the rendered result should still be a normal anchor with an href. Google explains that its crawlers generally do not “click” buttons to reveal more URLs, which is especially relevant to pagination, “Load more” controls, and infinite scroll.

Use a layered structure

• Primary navigation: Reserve it for the major routes most visitors need, not every indexable URL.
• Category or hub pages: Group related services, products, locations, or articles and provide a clear route to their child pages.
• Contextual links: Link from relevant copy at the point where the destination genuinely helps the reader.
• Breadcrumbs: Show the page’s place in the hierarchy and offer links back to parent levels. See the ScanMySEO guide to adding useful HTML breadcrumbs.
• Pagination: Ensure items beyond the first screen or category page remain reachable through crawlable links.
• XML sitemap: Maintain an inventory of preferred URLs—the canonical versions you want treated as primary—that search engines should know about.

Treat the XML sitemap as an inventory, not a substitute for links

A sitemap can help search engines discover URLs that are otherwise hard to find, but it does not create a user journey or prove that a page belongs in your site structure. Google describes sitemap submission as a hint rather than a guarantee of crawling or indexing. Keep the sitemap aligned with the canonical URLs you actually want to retain and make eligible to appear in search. For implementation details, use the ScanMySEO guide to building and maintaining an XML sitemap alongside Google’s sitemap documentation.

Do not flatten the whole site

Making every page one click from the homepage usually creates a different problem: crowded menus, repetitive sitewide links, and less meaningful prioritisation. Important pages should have clear, reasonably direct routes. Lower-priority archives, historic resources, and specialist detail pages can sit deeper when that matches how people use the site.

Plan large ecommerce and faceted sites separately

Filters, sorting options, calendars, internal search results, and parameter combinations can create very large numbers of URLs. Decide which combinations deserve stable, indexable landing pages before exposing them through crawlable navigation. The goal is not to link every possible URL; it is to make the valuable, canonical set easy to reach while controlling low-value variations.

Audit, Decide, Fix, and Verify

1. Define the audit scope

Choose the preferred protocol and hostname—for example, the HTTPS www or non-www version—decide whether subdomains or language versions are included, and identify the page types that are supposed to be public and indexable. Record the crawl start URL and settings so the comparison is repeatable. A page can look orphaned simply because the crawler was not allowed to enter the part of the site that links to it.

2. Build a URL inventory from more than one source

A normal crawl discovers pages by following links, so it cannot prove that it has found URLs with no links. Compare its output with other inventories:

• Crawl data: URLs reachable from the selected start page, plus their internal inlinks and click depth.
• XML sitemaps: URLs your site declares as preferred for discovery.
• CMS or database exports: Pages the platform believes exist, including unpublished, archived, or disconnected records where available.
• Google Analytics 4: Landing pages and visited pages that may have been reached through bookmarks, campaigns, external links, or old navigation.
• Google Search Console: URLs Google knows about through the Page indexing and performance reports.
• Server logs or backlink exports: Optional evidence of URLs requested by search crawlers or reached from other websites.

The Search Console Links report can help you inspect internally linked pages, but Google states that it is a sample rather than a complete list. Do not use it as your only orphan-page test.

3. Compare the source sets

• In the sitemap or CMS, but absent from the crawl: A strong orphan or inaccessible-page candidate.
• In Analytics or Search Console, but absent from the crawl: Possibly an old URL, an externally discovered page, a campaign landing page, an alternate URL, or a genuine orphan.
• In the crawl, but absent from the sitemap: Not automatically a problem. The page may be intentionally excluded from the sitemap, newly published, non-canonical, or not intended for indexing.
• Present in every source but still deep: Usually a prioritisation question rather than a discovery failure.

4. Verify every candidate before changing it

For each suspected orphan or deep page, answer these questions:

• Does the URL return the expected status, or does it redirect, error, or behave like a soft 404—a missing-looking page that still returns a success status?
• Is it the canonical version, or is another URL preferred?
• Is it indexable, blocked from crawling, or intentionally excluded from search?
• Does a link exist in the source or rendered HTML, and is it a crawlable <a href> link?
• Is the link present on mobile as well as desktop?
• Does the page still serve a user or business need?
• Is it duplicate, expired, legally required, account-only, campaign-specific, or otherwise intentionally separate?

Google’s Page indexing report guidance explicitly notes that “not indexed” is not necessarily bad; the reason and the page’s intended role matter.

5. Choose the right outcome

1. Keep and strengthen: The page is useful, current, canonical, and intended for discovery. Link it from a relevant hub, related page, breadcrumb trail, or navigation path.
2. Keep but do not promote for search: The page is useful to a limited audience but is not intended as a search landing page. Preserve the user route it needs and apply the appropriate indexing controls rather than adding artificial SEO links.
3. Consolidate: The page overlaps a stronger URL. Merge valuable content and links into the preferred page, then use the appropriate redirect where the old URL has a clear replacement.
4. Remove: The page has no continuing purpose and no important dependencies. Check traffic, conversions, backlinks, campaigns, legal obligations, and internal references before removal.

6. Add the smallest useful set of links

Place links where a person would reasonably need the destination. A service page may belong on a services hub and in a related guide. A product may need a category route and crawlable pagination. A location page may need a regional hub. Avoid adding every orphan to the homepage, header, or footer simply to change a crawler score.

Link directly to the final canonical URL, use concise descriptive anchor text, and fix broken or redirecting internal targets at the same time. Where many pages share the same problem, a template or component change is usually more reliable than editing individual pages one by one.

7. Re-crawl and verify the result

• Repeat the crawl with the same scope and start URL.
• Confirm that intended pages now have at least one relevant internal inlink.
• Check whether priority pages have a more appropriate depth, without forcing every page to the same level.
• Inspect the rendered HTML when JavaScript is involved.
• Confirm that links resolve to live, canonical destinations without unnecessary redirects.
• Keep the XML sitemap aligned with the retained canonical URLs.
• Test desktop and mobile navigation, including keyboard access to menus and links.
• Monitor Search Console and Analytics over time, but do not assume every later traffic or ranking change was caused by the internal-link update.

What to Fix First—and What Not to Do

Prioritise in this order

1. Valuable public pages with zero internal inlinks: Core services, products, locations, conversion pages, and important guidance that should be discoverable.
2. Canonical sitemap URLs that the crawl cannot reach: These often reveal template, pagination, or navigation gaps.
3. Important pages with only one weak route: For example, a page linked only from an archive, old footer, or unrelated page.
4. Broken, redirecting, or non-canonical internal links: Correct the route before adding more links to it.
5. Low-value legacy and parameter URLs: Decide whether to consolidate, control, or remove them rather than promoting them.

Avoid these common mistakes

• Treating three clicks as a universal rule: Depth should reflect importance and site type, not an arbitrary number.
• Calling every sitemap-only URL an SEO problem: First decide whether the URL is current, canonical, useful, and intended for search.
• Assuming zero Analytics traffic means zero value: New, seasonal, legal, support, and low-volume conversion pages may still matter.
• Adding every URL to the main menu or footer: This creates clutter and removes meaningful prioritisation.
• Relying on one tool: A crawler finds reachable URLs; an orphan audit requires a second inventory.
• Linking to redirects or duplicate variants: Point internal links to the preferred final URL.
• Ignoring crawl scope: Login walls, robots.txt rules, subdomains, JavaScript, and crawl limits can all create false positives.
• Deleting first and investigating later: Check backlinks, campaigns, conversions, integrations, and legal dependencies before removal.

Worked Example: A Category Template Creates Sitemap-Only Products

Before

An ecommerce category displays 24 products and uses a “Load more” button for the rest. The button updates the page, but the additional products are not exposed through crawlable links or paginated URLs. Those product pages still appear in the XML sitemap and receive occasional visits from adverts and old bookmarks.

Diagnosis

A homepage-led crawl finds the category and its first 24 products, but not the remaining product URLs. Comparing the crawl with the sitemap and Analytics reveals the missing set. These pages are not necessarily low quality or deliberately hidden; the category template has failed to provide a crawlable route.

Fix

The retailer adds crawlable paginated category pages, keeps each retained product in the relevant category, and ensures that the product cards use normal anchor links. Breadcrumbs connect products back to their category. Selected high-priority products also receive contextual links from relevant buying guides, while discontinued products are reviewed separately rather than linked indiscriminately.

Verification

A repeat crawl now reaches the intended product set through the category path. Sample URLs show real internal inlinks in the rendered HTML, the links resolve directly to canonical product pages, and the sitemap contains only retained URLs. Search Console and Analytics are then monitored for discovery and user behaviour, without promising a particular traffic or ranking outcome.

The Practical Rule for Site Structure

Give important pages clear, crawlable links from relevant places. Do not force every URL to the same depth, and do not preserve or promote pages merely because they exist in a report.

1. Define which pages are meant to be public, useful, canonical, and indexable.
2. Compare a crawl with at least one independent URL inventory.
3. Verify suspected orphan pages before changing or removing them.
4. Choose the right outcome: strengthen, retain with controls, consolidate, or remove.
5. Re-crawl with the same scope and monitor the result over time.

Site structure is not a one-off clean-up. New templates, migrations, product changes, navigation redesigns, and content pruning can all create new gaps, so repeat the comparison after significant releases and as the site grows.

Quick Reference: What Each Data Source Can Tell You

Data-source limits

• Site crawl: Shows what is reachable from the chosen start point under the chosen settings. It cannot discover a true orphan unless that URL is supplied from another source.
• XML sitemap: Shows URLs the site declares for discovery. It does not prove that those URLs are internally linked, crawled, indexed, or valuable.
• CMS or database: Shows records the platform knows about. It may include drafts, archives, duplicates, and pages that should not be public.
• Google Analytics 4: Shows pages that recorded visits. It cannot list pages with no measured visits, and tracking gaps can create omissions.
• Search Console Page indexing: Shows indexing states for URLs Google knows about. It is not a complete inventory of every possible site URL.
• Search Console Links: Provides a sample of links Google has found, not a comprehensive internal-link graph.
• Server logs: Show requested URLs and crawler activity. A request does not prove that a page is valuable, canonical, or indexed.

Final validation checklist

• The page has a continuing user or business purpose.
• The URL returns the intended status and is the preferred canonical version.
• The page is intended to be public and indexable.
• At least one relevant page contains a crawlable internal link to it.
• The anchor text explains the destination without keyword stuffing.
• The route works in rendered desktop and mobile navigation.
• Pagination and interactive controls do not hide important URLs behind buttons alone.
• The XML sitemap reflects the retained canonical URL set.
• The repeat crawl uses the same scope as the baseline.
• Success is judged by better discovery and clearer user routes, not by an assumed ranking guarantee.