Click depth and orphan pages

By Matt Kerr·Published 16 September 2026

Two findings in your audit sound like the same complaint about the same problem. One says pages sit too many clicks from the homepage. The other says nothing links to a page at all. They come from one check, they are measured in different ways, and only one of them is withheld when the crawl was too partial to support it.

Docket's index.depth check is registered as "Click depth and orphans" and can emit three findings:

• Deep pages — index.deep_pages, at LOW. Indexable pages whose recorded depth is 4 or more.
• Orphan pages — index.orphan_pages, at MEDIUM. Sitemap URLs with no internal link pointing at them.
• Orphans not checked — index.orphans_unchecked, a NOTICE flagged as a tool limitation. The orphan question could not be answered on this crawl, so it is not answered.

That third one is the reason the check is worth reading about rather than merely acting on. A zero there would mean blind, not clean.

What "clicks from the homepage" actually counts

The depth on a page is the level at which the crawler first put that URL into its queue. The crawl walks outward a level at a time, so the number is the shortest path along links the crawler followed from where it started.

Three things follow, and none of them matches the phrase in the finding's title.

It is measured from the start URL, not from your homepage. Point Docket at a section and that section is depth zero; everything under it counts from there. The engine keeps a separate flag recording whether the page it is calling the homepage really is the site root, and that flag exists because a finding once announced a whole site was deindexed when the only page fetched was a single product page carrying a noindex. Any finding whose wording says "homepage" inherits that caution, this one included.

It counts links Docket could see. A menu assembled in the browser is not in the delivered HTML, so a crawler reading the HTML finds no links in it. Pages reachable in one click through that menu are then reached, if at all, by some longer route through a footer or a body link — and their depth is the length of that longer route. The number is real; what it measures is your link graph as served, which on a client-rendered site is not your link graph as used.

It is capped before it is measured. The default click-depth limit is 5. Links discovered beyond it are not fetched; they are recorded as URLs the crawl skipped. So on a default run the deep list can only contain pages at the threshold or at the ceiling, and a genuinely buried page — the one this finding is supposed to be about — never appears in it, because it was never fetched. If you want the real distribution, raise the limit or remove it with -d 0, which means no limit rather than no links.

The gate this check applies to one half and not the other

Said plainly, because it is our own asymmetry and you should know about it before you weigh the LOW finding.

The engine has a property that decides whether link-graph claims are defensible from a given crawl. Its own documentation says it governs "inlink counts, orphan status and click depth". One of the conditions inside it was added after a crawl of a site whose navigation is built by JavaScript produced, in the words of the code, "a meaningless click-depth model" alongside a list of pages wrongly called orphans.

The orphan half of index.depth consults that property. The depth half does not read it at all. So on a site whose navigation never reaches the HTML, the orphan claim is correctly withheld and the deep-pages list is printed anyway — with depths produced by the same unreadable link graph that caused the orphan claim to be withheld. Treat a deep-pages list on such a site as a statement about what Docket could crawl, not about your structure. If your report also carries a finding about navigation that needs JavaScript, that is the signal: how to fix navigation that needs JavaScript covers what to do about the cause.

What Docket will call an orphan

Narrower than the phrase suggests, and worth reading as a list of conditions that must all hold. A page is reported as an orphan when it was crawled and answered cleanly, it is HTML, it is not excluded by a noindex directive, its URL appears in your sitemap, the crawl recorded no internal link pointing at it, and it is not the page being treated as the homepage.

The sitemap condition is the one that surprises people. A page nothing links to and nothing declares is not reported here — it is not reported anywhere, because a crawler starting from your homepage and following links has no way to reach it and no way to know it exists. If you publish no sitemap at all, index.orphan_pages cannot fire under any circumstances. The finding's own detail text is accurate about this: "These pages appear in the sitemap but nothing on the site links to them." The gloss that gets repeated elsewhere — any page with no inbound internal links — is a wider claim than the code makes, and a wider claim than a crawl can support.

The fix attached to it is deliberately two-sided: "Link to each from a relevant parent or hub page — or remove it if it is obsolete." Orphans are frequently correct. A page that nothing links to because nothing should link to it any more is a deletion, not a linking job.

When the orphan answer is withheld, and why that is the useful part

"Nothing links to this page" is a claim about your entire site, and you cannot make it from pages you never fetched. The URLs left unfetched are exactly the ones whose outbound links are unknown — they are the only candidates for carrying the missing link.

So the check requires that the crawl left nothing meaningful behind: the number of skipped URLs must be no more than 5, or 25% of the pages crawled, whichever is larger. A handful of stragglers does not invalidate a link graph. Past that line, Docket emits the notice instead, and the notice deliberately does not quote how many orphans it would have reported — that list is precisely what the crawl cannot support, and printing it would hand you a number to act on while claiming not to. What it quotes instead is how many URLs were never fetched.

This behaviour was bought with a wrong answer. Measured on a London gelateria on 14 August 2026, at a cap of 25 pages: 15 of those pages were reported as orphans, while the crawl's own log recorded 20 further URLs discovered and never fetched. Roughly two-fifths of the link graph had not been looked at, and the pages that would have carried the links were sitting in the queue. The gate in place at the time passed the crawl, because it fell back to a 20% coverage floor — a defensible bar for "does a privacy page exist anywhere on this site?", since a URL seen and never fetched still answers that, and the wrong bar entirely for "does anything link here?".

That distinction survives in the code as two separate properties, and the looser one was left alone on purpose. Presence can be established from a list of URLs. Absence of an inlink cannot.

The remedy names one limit; there are three

The notice tells you to re-run without a page limit, using -n 0, or to raise the limit past the number of URLs the site declares. That is right about the most common cause and incomplete about the rest. URLs land in the skipped list for three reasons: the page budget ran out, the click-depth budget rejected the link, or the frontier grew past several times the page budget.

Only the first is what -n 0 addresses. On a site deeper than the default limit, the depth budget alone can push enough URLs into the skipped list to withhold the orphan finding, and no page limit you choose will change that. If the notice persists after an uncapped run, lift the other ceiling too:

docket audit https://example.com -n 0 -d 0

Both zeros mean "no limit on this dimension", not "no pages" and not "no links" — a distinction that once cost a whole-site preset its crawl, and is now the documented convention on both flags.

What the LOW severity is telling you

Deep pages are reported at LOW, below orphans at MEDIUM, and that ordering is a judgement rather than a measurement. The finding's detail says buried pages "get crawled less often and are read as less important", and that "anything commercially valuable should be within three clicks". No citation is attached to that finding, unlike others in the same file which carry a link to the documentation they rest on. Read it as a rule of thumb the check encodes, not as a published threshold anyone has verified for your site.

The practical reading is narrower and safer: depth is a proxy for how much internal linking a page receives, and internal linking is a thing you control directly. If a page matters and sits far from everything, the fix is the same either way — a link from a hub or a related- content block, which is the finding's own advice. Internal link equity, measured covers the distribution behind that proxy, which is the more useful view once you have more than a handful of pages.

Reading the list you were given

The deep list arrives sorted deepest first, which is the order to work in. It is capped at 25 URLs in the report, with the true total kept separately — so a short list is not necessarily a short problem, and the report says how many it is showing of how many.

Work orphans before depth. An orphan in your sitemap is a page you told search engines about and then left unreachable by anything else, which is a contradiction you can resolve in one edit. A deep page is a ranking of your own structure against a threshold, on a number whose ceiling you set when you started the crawl. And if neither finding appears but the notice does, nothing has been ruled out: re-run with both limits lifted before concluding your link graph is clean. Whether a page is indexed at all is a different question with a different answer — is your page actually indexed? covers how to check that directly.

One note on why this page exists. We have not measured how many people ask this question, and nothing here should be read as a claim that an audience for it was counted. It exists because the check exists, its two halves are easy to confuse, and one of them applies a crawl-quality gate the other does not. Engine source read on 16 September 2026.

Download Docket

Common questions

How many clicks from the homepage is too many?

Docket reports a page at four clicks or more, at its lowest severity, and the finding's own wording suggests keeping anything commercially valuable within three. That is a rule of thumb the check encodes rather than a published threshold, and no citation is attached to it. The number is also capped by your crawl settings before it is capped by your site.

Does Docket measure click depth from my homepage?

It measures depth from the URL you started the crawl at. If you audit a section URL, that section is depth zero and everything is counted from there. The engine tracks separately whether the page it treats as the homepage is really the site root, because findings worded around the homepage can otherwise be wrong.

Why does my audit say orphan pages could not be checked?

Because too many URLs the crawl discovered were never fetched, and those are exactly the pages that might carry the missing links. Docket withholds the orphan claim rather than reporting a count nobody should act on, and it tells you how many URLs were missed instead. Re-run with no page limit, and if the notice persists, lift the click-depth limit too.

Will Docket find an orphan page that is not in my sitemap?

No. The orphan finding requires the URL to appear in your sitemap as well as having no internal links pointing at it. If you publish no sitemap, this finding cannot fire at all. A page that nothing links to and nothing declares is also a page a link-following crawler has no way to reach.

Are orphan pages always a problem?

No, and the fix text says so: link to each from a relevant parent or hub page, or remove it if it is obsolete. A page nothing links to because nothing should link to it any more is a deletion. What is not defensible is leaving it in the sitemap, which tells search engines the page matters while the rest of the site says it does not.