Being visible in AI search does not start and end with a page looking correct in a browser. A product, service, or editorial page still needs a discoverable path before it can become a candidate for retrieval. A controlled crawl experiment published on August 19 suggests that internal links created only after JavaScript runs can be missed by many AI-facing crawlers.
This is not a new Google or OpenAI product announcement. It is an independent experiment on one site, and should be treated as a signal rather than a universal rule. Its practical value is that it challenges an assumption many teams make: if Google sees a page, every crawler that matters will see it too. For brands, the more useful question is whether critical discovery paths exist in the raw HTML response.
What the experiment actually tested
The test used a Brazilian business directory with roughly 2,400 pages. Within a 1,062-page hierarchy, 21 top-level sections were split into two groups. Child-page links in one group were present in the HTML returned by the server. In the other, equivalent links were added after page load with JavaScript. Sitemaps, breadcrumbs, and alternative discovery routes were deliberately removed, so a crawler had to follow the relevant internal links to reach lower-level pages.
According to the author’s server logs, tracked bots including GPTBot, ClaudeBot, Bingbot, PerplexityBot, and crawlers associated with Meta and Amazon traversed the HTML-linked sections but did not move beyond the JavaScript-only boundary. Google crawlers behaved differently: GoogleOther progressed sooner, while Googlebot reached only a small share of the JavaScript-linked pages. That does not prove every AI product behaves this way. It does make client-only internal linking a concrete discovery risk worth auditing.
The illustration isolates the mechanism behind the experiment. A link present in the first server response can be parsed immediately. A link that exists only after code runs depends on that crawler rendering the page. It is a Fark Studio illustration, not a product screen or a measurement result.
Why strong traditional SEO may not be enough
Google’s JavaScript SEO documentation separates crawling, rendering, and indexing. Googlebot can queue a URL for rendering and execute code with a modern Chromium environment. The same guidance still recommends server-side or pre-rendered HTML because it is useful for people, for speed, and for bots that do not run JavaScript. Google’s ability to render a page should therefore not be used as a proxy for every retrieval crawler’s behaviour.
The gap matters on sites where discovery is assembled in the browser. Category cards, related articles, project grids, service navigation, and product variations may all look complete to a visitor while leaving the server response thin. An AI retrieval system may then reach the page surface but fail to discover the deeper content. This is not a ranking penalty. It is a quieter failure mode: the page may never enter the candidate set when a relevant question is asked.
Who should care, and what remains unknown?
The risk is highest for ecommerce, multi-location services, publishers, tourism businesses, and B2B sites with large information architectures. Their valuable pages are often found through category paths, filters, related content, and in-app navigation rather than the primary menu. A site built with Next.js, React, or a headless CMS is not automatically at risk. The deciding factor is what the first HTML response contains, not the framework label.
What is known is limited to the experiment’s configuration and recorded bot requests. What is not known is whether every AI search product behaves the same way today, whether a missed link directly causes a traffic or revenue loss, or whether server-side rendering alone resolves every discovery problem. Sitemaps, external links, robots decisions, user-initiated browsing, and changing crawler behaviour can all alter the outcome. The responsible reading is not “all AI bots ignore JavaScript,” but “critical discovery paths should be tested instead of assumed.”
A practical technical SEO checklist for brands
1. Inspect the raw response. Check the highest-value category, service, project, and knowledge pages as the server first returns them, not only through the rendered browser. If critical <a href> links or primary copy are missing from that response, create a technical backlog item.
2. Map discovery paths. Starting from the home page, show how many steps separate users and crawlers from every important page. Flag routes that only appear after a filter, hover state, or client-side component activates. A sitemap is useful, but it should not replace meaningful internal links.
3. Prioritise commercial and editorial hubs. Rendering every interactive detail on the server may be unnecessary. Start with revenue-driving landing pages, category hubs, service explanations, product detail pages, and durable editorial content. Session-specific areas such as carts and personalisation deserve a separate decision.
4. Make bot access a business decision. robots.txt is not only an engineering file. Training, live retrieval, and user-initiated browsing bots can have different implications. Legal, content, and growth teams should record which access they allow and why.
5. Repeat the audit after change. A new theme, filter tool, experiment platform, or framework upgrade can change the raw output. Add source HTML, crawlable links, canonical, robots, sitemap, and relevant server-log checks to the release test set.
This workflow captures the operating sequence: create the content, inspect the server response, confirm the link exists in raw HTML, then observe real crawler access through logs. The dotted path represents the risk of discovery remaining client-side. It is a Fark Studio illustration.
Fark Studio view: this begins with information architecture
AI search makes the connection between technical SEO, corporate web design, and content production more visible. A page can be well written, yet its content system can restrict access to it when the links that lead there are absent from the initial response. The durable approach is to keep critical information paths intelligible on the server, then build rich interaction on top of that foundation.
If you want to review your brand’s technical discovery map for organic and AI search together, contact Fark Studio. The objective is not to open every bot without limits or rebuild an entire site. It is to prove which pages must be discoverable for which business outcomes, then invest accordingly.
Sources
Search Engine Land, “JavaScript links can make your pages invisible to AI search”, August 19, 2026.
Google Search Central, “Understand JavaScript SEO Basics”, updated March 4, 2026.
