Guide

Click depth in SEO: what it is and why it matters

Click depth and crawl depth in SEO: what each term means, why depth over four hops gets flagged, and how to flatten a site so more of it gets crawled.

By Sunny Patel · Updated 2026-09-20

Click depth counts the clicks it takes to reach a page from your homepage, following normal internal navigation. It follows the shortest internal link path a crawler can find, not every path that happens to exist. A page linked directly from the homepage sits at depth one. A page linked from that page sits at depth two. Depth keeps increasing with each further hop, and fewer crawlers and visitors ever reach a page the deeper it sits. Each additional hop loses some share of both crawl budget and human patience, which is why click depth in SEO counts as a structural signal, not a cosmetic one.

Crawl depth vs click depth

The two terms describe related but distinct counts, and mixing them up leads to confusing conversations with a developer or an SEO tool vendor. Crawl depth is a setting a crawler applies to itself: how many link hops it is configured to follow out from wherever it started, whether that is a homepage, a sitemap entry, or any other seed URL. It is a property of the crawl, not of the site. A crawler configured with a crawl depth limit of three will simply stop following links past that point, regardless of how the site's own navigation is structured. Click depth is different: it is a property of the site itself, counting the hops a real visitor needs from the homepage to reach a given page by clicking through normal navigation.

The two diverge for a specific reason: a crawler rarely starts every fetch from the homepage the way a visitor does. A sitemap.xml file can hand a crawler a direct link to a page buried ten navigation hops deep, so that page gets crawled at a shallow crawl depth even though its click depth from the homepage is still ten. An external backlink pointing straight at a deep page has the same effect: the crawler can reach it in one hop from that link, while a visitor arriving at the homepage still has to click through the full chain. Pagination causes the opposite kind of mismatch. A crawler configured to follow every "next page" link will keep walking a paginated archive well past where a real visitor gives up, so crawl depth and click depth can disagree sharply on exactly the pages a site relies on pagination to surface.

sitemap.digital reports click depth specifically, calculated with the breadth first search described above: the shortest chain of internal links back to the crawl root, over the real link graph the crawl builds, not a crawler configuration setting and not a guess from folder depth in the URL. That is a deliberate choice. Click depth is what decides whether a page competes fairly for attention and crawl allowance under normal browsing and normal link-following, which is the outcome this tool exists to check.

Why sitemap.digital flags depth greater than four

Four is not an arbitrary round number. Site architecture guidance has converged for years on keeping any page a visitor cares about within three or four clicks of the homepage, because that is roughly where both attention and crawl allowance taper off in practice. A widely cited version of this convention comes from Ahrefs' guide to website structure, which recommends a flat hierarchy that keeps important pages only a few clicks from the homepage (Ahrefs, website structure). Google's own documentation on managing crawl budget for large sites makes a related point from the crawler's side: pages that are hard to reach through a site's internal links compete poorly for a finite crawl allowance, and low value or hard to reach URLs can crowd out the pages that matter (Google Search Central, large site crawl budget). sitemap.digital's depth greater than four rule sits directly on top of that convention: it is the same three to four click guidance, applied automatically to every page a scan finds, with no judgement call left to make.

Click depth is a symptom of a wider decision, not a standalone setting: it is the outcome of how a site's architecture distributes hub and spoke links across the whole hierarchy, not something fixed page by page.

Depth and discoverability for AI crawlers

AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot do not have infinite patience for any one domain. Cloudflare Radar's ongoing tracking of AI crawler and AI referrer traffic has repeatedly shown these bots behaving differently from a full search index crawl: they fetch a narrower slice of a site instead of attempting to enumerate every page (Cloudflare Radar, AI insights). That is Cloudflare's observed pattern, not a measurement sitemap.digital makes itself. The practical effect is straightforward: an AI crawler tends to prioritise pages that are easy to reach from a site's main structure, then spends whatever budget remains on the rest. A page buried five or six clicks deep competes for a shrinking slice of that budget against every other deep page on the site. That makes it far less likely to be read, indexed by the AI system's own cache, or ever surfaced in an answer.

Depth versus discoverability for human visitors

The same logic applies to people. A visitor who lands on your homepage rarely clicks through more than three or four links before giving up or going back to search instead. Content buried deep in a category structure effectively becomes invisible to normal browsing even when it sits only a handful of clicks away. A specific product page nested inside several layers of subcategories, or a help article buried under a support hub, a sub category, and a topic page, are common examples. Both a person and a crawler are running the same underlying calculation: how many hops is this worth, given everything else competing for the same click.

Common causes of deep pages

Deep pages rarely happen on purpose. They accumulate as a side effect of how a site grows. A category tree that adds a new subcategory every time the product range expands, instead of linking new products from an existing hub, pushes everything underneath one layer deeper each time. Paginated listings do the same thing in a subtler way: a product or article that only appears on page fourteen of a paginated archive can sit many hops from the homepage even though the archive itself is only one click away, because reaching page fourteen means following the next page link thirteen times first. Faceted navigation on ecommerce and directory style sites multiplies this further, since each filter combination can spawn its own URL nested under the last one. A support or documentation section that grows by adding topic pages under existing subcategories, instead of linking new articles from the section hub, produces the same drift. None of these causes are mistakes exactly. They are just what happens when a hierarchy grows without anyone checking what it does to the shortest path into its oldest or newest content.

A page can also carry zero inbound links at all, not merely a long path to it, which is a related but distinct problem. Read the orphan pages guide for how sitemap.digital flags that case separately from depth, and why a page with no path in at all needs a different fix than a page that is simply too many hops deep.

A site migration or redesign is one of the fastest ways to push a whole section deeper overnight, since the new navigation rarely preserves the old hop count on purpose. The site migration SEO checklist covers checking depth as part of a before-and-after scan comparison.

A worked depth example

The table below illustrates, for a single example page, how flattening a hierarchy moves it from depth five down to depth two. It is a worked example to show the mechanism, not a measurement from any real site.

The article itself never moves on disk in this illustrative example. What changes is the shortest path a crawler or visitor can take to reach it. Adding one contextual link from the support hub straight to the article removes three intermediate layers from the shortest path, taking it from depth five, flagged as deep, to depth two, comfortably inside the threshold.

Flattening in practice

Flattening a site rarely means deleting the subcategories and topic pages altogether, and it rarely means a full redesign either. It means adding a shorter path alongside the existing one, so the shortest path sitemap.digital or any crawler finds is the short one. A few tactics do most of the work.

A hub page linking directly to its most important child pages, instead of relying on a visitor to drill down through every intermediate category, is usually the single highest leverage fix. This is the fix behind the worked example above: one link from the support hub straight to the article did the entire job. A homepage section or featured block highlighting cornerstone guides or key product pages puts them at depth one regardless of how deep they sit in the folder structure, which matters most for the handful of pages a site earns most of its revenue or citations from. Contextual links from within body content, pointing from a related article straight to a deep page, add a second path that can beat a long one through navigation alone, and they tend to be the cheapest to add since they do not require touching a template. Main navigation and footer links that surface a site's most important sections, not only its top level categories, work the same way, though they carry more design cost since they change what every visitor sees on every page.

Paginated and faceted sections need a slightly different fix: do not rely on the page-by-page or filter-by-filter chain to eventually reach older or narrower content. Link directly to the specific pages worth keeping shallow from a hub, a sitemap style index page, or a related content block instead. That gives the page a second, short path that does not depend on anyone clicking through twelve pages of pagination first.

A rescan is the fastest way to confirm a fix actually worked, rather than assuming a new link shortened the path when some other page still offers a shorter one. A page recorded at depth five on one scan, then linked from a hub page before the next scan, would show up in sitemap.digital's scan history and diff view with a negative depthDelta as an illustrative before and after: the page moving from flagged to clear between the two scans. That is the same mechanism the worked example above shows. The content does not change. The shortest path to it does.

Depth checks alongside the rest of a site's structure

Click depth rarely tells the whole story on its own. A page can trip the deep page flag while also carrying broken outbound links, missing structured data, or a low AI readiness score for reasons that have nothing to do with how many hops it sits from the homepage. Treat depth as one signal in a wider structural read of a scan rather than the only one worth fixing. The internal links for AI guide covers how the underlying link graph that depth is calculated from gets built in the first place, and why that same graph decides which pages an AI crawler ever reads at all.

Frequently asked questions