A 41-day experiment found GPTBot, ClaudeBot, and 6 other AI crawlers found zero JS-linked pages. Even Google's indexing crawler only reached 2%.
"Google renders JavaScript" has been the standard reassurance about client-side navigation for years. Vinicius Stanula, an SEO director at LOCOMOTIVE, ran a 41-day controlled experiment to check whether that reassurance still covers the crawlers that actually matter now, and the results are more lopsided than the premise suggested. GPTBot, ClaudeBot, Bingbot, PerplexityBot, Meta's crawler, and Amazon's crawler found zero of the JavaScript-linked pages. Google's own indexing crawler, Googlebot, found only 2%.
How the test was built
Stanula split a 2,400-page site (a Brazilian business classification directory he owns) into two groups across its 21 top-level sections. Eleven sections had every child link hard-coded directly in the HTML. The other ten had every child link, at every level, injected by JavaScript after the page loaded, with the raw HTML showing an empty div where the links would eventually appear. To keep the signal clean, he disabled the sitemap, removed breadcrumbs, and removed internal hierarchy panels, so the only way into a JavaScript-group page was for a bot to render its parent's JavaScript and follow the link that got injected. A hit on one of those pages is unambiguous proof that a crawler executed the script.
The scorecard
After 27 days, the numbers split cleanly into two categories: crawlers that rendered JavaScript, and crawlers that didn't.
GPTBot, ClaudeBot, Bingbot's indexing pass, OAI-SearchBot, Meta-ExternalAgent, Amazonbot, and ChatGPT-User all crawled the HTML-linked group thoroughly, in most cases hundreds of pages deep, and then hit a wall at the JavaScript boundary. GPTBot crawled all 748 HTML hierarchy pages on day one and reached exactly zero JavaScript-linked ones. ClaudeBot did the same the next day. Bingbot recrawled the ten JavaScript section pages on 18 separate days over three weeks and never once followed an injected link into a division page (it did eventually reach three pages, but the crawl pattern points to a different discovery path rather than actual rendering). PerplexityBot barely moved at all, staying on the homepage and robots.txt for the entire 27-day window.
Only Google's crawler stack rendered anything, and even that comes with a catch worth sitting with. Google runs two separate crawlers here: Googlebot, which builds the actual search index, and GoogleOther, a separate crawler with a different job. GoogleOther reached 48% of the JavaScript group. Googlebot, the one that determines whether a page can show up in Google Search at all, reached 2%. Counting GoogleOther's coverage as proof that "Google sees it" is exactly the mistake Stanula flags: raw crawl logs will make a site look far more discoverable than it actually is if every Google user agent gets lumped into one bucket.
What real user requests could and couldn't reach
The most concrete finding in the study isn't about crawl training data at all. ChatGPT-User, the agent that fetches a page in real time when someone asks ChatGPT a direct question, pulled real queries to dozens of HTML-linked pages during the test window. It reached zero of the JavaScript-linked ones. That means the pages a person was actively trying to reach through a live ChatGPT conversation were exactly the pages that conversation couldn't get to. This isn't a hypothetical training-data gap that resolves itself eventually. It's a live request failing right now.
Fixing it later is harder than not breaking it in the first place
Twenty-seven days in, Stanula converted every JavaScript link back to hard-coded HTML and watched what happened next, with nothing else about the pages changed. GPTBot swept every previously blocked section within two days, picking up 250 pages in under three hours. Bingbot followed within a week, adding 212 pages. Meta-ExternalAgent joined by day 41.
Two crawlers didn't recover cleanly. Amazonbot had already finished its crawl and left the site six days before the fix went live, so its coverage stayed at zero regardless of what changed afterward. ClaudeBot kept recrawling the site for the rest of the study, but only pages it already knew about; whatever map of the site it built on its first pass, it never went back to update that map with the newly discoverable pages, even while it kept hitting the site hundreds of times.
Google, the only crawler that had actually rendered any JavaScript in Phase 1, was the slowest to respond to the fix. By day 41, Googlebot had visited exactly one page in the converted sections. GoogleOther had visited none. Stanula's read: a brand-new site's aggressive first-visit crawl budget gets spent once, and getting Google to come back and re-evaluate a site it already crawled once is a harder ask than getting a first look in the first place.
The honest limits of one experiment
This was one site, one niche, a 41-day window, and a fresh domain with zero external links pointing at the buried pages, and Stanula says so directly rather than generalizing past what the data supports. An established site with a real backlink profile and stronger trust signals might see Googlebot invest more in rendering than it did here. What doesn't come with that caveat is the non-Google side of the results: eight separate crawlers failed to execute the JavaScript and follow the injected links across every crawl burst and every recrawl cycle of the study, with no exceptions and no partial credit.
Where this differs from what's already on this blog
This blog has already covered internal linking as a Google crawl-budget and priority signal, citing John Mueller's point that a deliberate internal link structure tells Google which pages matter most. That post is entirely about how Googlebot uses the links it can already see. This is a different, earlier question: whether a link exists at all from the perspective of a crawler that doesn't execute JavaScript in the first place. A perfectly prioritized internal link graph does nothing for GPTBot or ClaudeBot if the links themselves only materialize after a script runs. The fix Stanula recommends, server-side rendering for navigation specifically (not every widget on a page, just the links that move a crawler from one page to the next), is a prerequisite that sits underneath any internal-linking strategy, not a replacement for one.
A backlink pointing at a page that no AI crawler can reach is competing with the same blind spot from the outside: the link exists, but nothing indexing for AI answers can find what it points to if the destination site's own internal architecture never lets the crawler in.
