A fetch-and-parse crawler does one thing with your HTML: it scans the response body for href attributes and queues the URLs it finds. It does not build a DOM and it does not wait for client-side rendering [14]. A menu entry that only becomes a URL after a client-side router runs gives that scan nothing to queue, and the destination is never requested, whatever is on it [13]. It looks fine in your browser, which is the part that makes it expensive to catch [21].
Search Engine Land's accounting is worth checking before you carry its numbers anywhere. The HTML group is given as 748 pages and the JavaScript group as 293, which sums to 1,041 against the 1,062 hierarchy pages the split is said to cover [15]. The 21-page gap matches the 21 top-level sections exactly, so the section landing pages are the likely residual [15]. Less tidy: Googlebot's phase-one coverage is reported as seven of 348 pages tracked in the JavaScript group, a group described elsewhere in the same write-up as 293 pages [20]. Someone changed a denominator mid-report. So read the ratios as directional. GPTBot's roughly 250 recovered pages is about 85% of a 293-page group [16], Bingbot's 212 about 72% [17], Googlebot's seven about 2% of its own larger denominator [18].
The zero is the load-bearing figure, and it is a figure about a specific setup. Sitemaps, breadcrumbs and every other discovery route were disabled, so each JavaScript section had exactly one way in [3]. For that zero to transfer to your site, the sections you care about would have to be single-pathed in the same way: no sitemap entry, no in-body cross-links from pages a crawler already has. The design isolates the navigation channel, which is what makes it a clean measurement and also what caps it. If you ship a complete sitemap, this result says your navigation contributes nothing to discovery, not that your pages are unreachable.
The phase-two split is what I would take to a review. GPTBot shows no renderer anywhere in these results and still came back within about two days of the markup changing [11]. Googlebot has a renderer, got further into the scripted hierarchy than any other crawler, and had found one converted page after 41 days [6][12]. Rendering capability and recrawl latency are separate properties of a crawler, and a plan that leans on the first is exposed to the second.
Adoption cost is low where the fix is markup: an anchor with a real href instead of a button with a handler, plus server-side rendering or prerendering wherever the framework injects navigation after load [14]. It gets expensive when the nav itself is fetched client-side after mount, because then the fix is a rendering-strategy change and not a component edit. My rule in this context is that navigation belongs in the server response and JavaScript decorates it. The report is careful on this point too: scripted navigation is not incompatible with discovery, it just cannot be the only path [19].
