On March 4, 2026, Google removed the “Design for accessibility” warning from its official JavaScript SEO documentation, labeling the advice as outdated. For many web developers, this signaled that JavaScript rendering is now standard and that AI crawler JS issues are a thing of the past. The reality, however, presents a sharp paradox.
While Google’s Web Rendering Service (WRS) successfully executes complex modern JavaScript syntax, the most extensive public measurement to date found zero JavaScript execution across major AI crawlers. Your site may be fully visible to Google, but to the bots powering AI search answers, it is effectively a skeleton. This disconnect highlights why understanding client-side rendering SEO is no longer just a technical detail—it is a critical visibility gap. We need to distinguish between what a search engine can do and what a generative engine actually does, because the former does not guarantee the latter. The decision of what content gets indexed is often made by the initial HTML, not the rendering capability of the crawler.
Inside the two-wave crawl: how Googlebot handles JavaScript
Google’s search infrastructure operates in three distinct stages: crawling, rendering, and indexing. To understand where dynamic content AI systems might stumble, it helps to visualize the first two stages as a two-wave process. The initial wave consists of a standard HTTP request where the server sends the raw HTML response. At this point, no scripts run; the browser remains static. The second wave is the rendering phase, where the WRS picks up the URL from a queue and executes the code. This separation is critical because the initial HTML must contain all structural signals—links, titles, and meta tags—before JavaScript has a chance to alter the page.
When the WRS activates, it utilizes an evergreen, headless Chromium instance. This environment is not a simplified or outdated browser; it is a fully modern engine that supports the latest JavaScript standards. Features such as ES6+, async/await, Promises, and the Fetch API function exactly as they would in a desktop browser. This capability resolves many historical concerns about client-side rendering SEO, ensuring that complex interactive features do not prevent Google from understanding the page content.
However, technical capability does not equate to immediate availability. Two constraints limit this process. First, there is a strict 2 MB ceiling on any individual fetched resource. If a JavaScript bundle or image exceeds this size, the excess bytes are discarded, potentially leaving the page incomplete. Second, the timing is asynchronous and variable. While a small site might see rendering within seconds, larger or lower-priority domains can face delays ranging from hours to weeks. Understanding that the rendering queue is a finite resource, not an instant processor, is essential for setting realistic expectations regarding how quickly changes appear in search results.
The blind spot: why AI crawlers ignore client-side rendering
The assumption that your site is fully visible to all major bots is dangerously outdated. While Google’s WRS handles complex JavaScript with precision, the most extensive public measurement to date reveals a stark disconnect in how other AI agents interact with your content. For anyone focused on AI crawler JS issues, this gap represents the single biggest risk to visibility in the emerging AI search ecosystem.
The data from 500 million fetches
In December 2024, Vercel and MERJ released an analysis that fundamentally changed how we understand bot access JS. Their research examined over 500 million fetches by GPTBot and other major AI crawlers. The conclusion was unambiguous: none of the major AI crawlers currently render JavaScript. This is not a minor technicality; it is a structural limitation in how these systems ingest information. If your content relies on client-side rendering SEO strategies to display text, AI bots see a skeleton, not a story. The data proves that being indexable by Google does not guarantee you are visible to the engines generating AI answers.
Who is leaving pages empty?
The study covered the specific crawlers powering the current AI landscape, including GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Bytespider, and Meta-ExternalAgent. Interestingly, some of these bots do download JavaScript files, but they do not execute them. In 11.50% of requests, ChatGPT crawlers downloaded JS files without running them. Claude crawlers showed an even higher download rate at 23.84%, yet still performed zero execution. This behavior confirms that these bots are simple HTTP clients, not browser-based renderers. No vendor has officially documented JavaScript execution for these agents, but the empirical data from the analysis is the closest thing to a definitive answer we have today.
A real-world warning from a Vue.js SPA
Consider the case of a Vue.js single-page application with no server-side rendering. To Google, this site appears perfectly normal; its Web Rendering Service fills in the blanks. But for AI crawlers, the initial HTML is essentially empty. This site had no verified GPTBot fetches that resulted in indexed content and had zero visibility in ChatGPT Search. The dynamic content AI users expect to find is simply missing from the bot’s perspective. This case study serves as a clear reminder: your technical stack must prioritize what the server sends, not what the browser eventually builds. For dynamic content AI systems to cite, the information must be present in the first byte of the response, not in a script that never runs.
Rendering strategies for AI visibility: CSR vs SSR vs SSG
The choice of rendering method determines whether your content exists in the initial HTML or waits for JavaScript execution. Given that current AI crawlers generally do not execute JavaScript, this distinction is the primary driver of AI visibility.
The technical landscape
To understand the risk, we must distinguish how each strategy delivers content. Client-Side Rendering (CSR) sends a minimal HTML shell to the browser, relying on JavaScript to populate the content. Server-Side Rendering (SSR) generates the full HTML on the server for every request. Static Site Generation (SSG) pre-renders HTML at build time, serving it as a static file. Dynamic Rendering serves pre-rendered HTML only to detected bots, while serving the standard CSR shell to humans.
The following table compares these approaches specifically regarding their compatibility with AI crawlers, rather than just traditional search engine optimization.
| Strategy | Initial HTML Content | AI Crawler Compatibility | Best Use Case |
|---|---|---|---|
| CSR | Minimal (Empty Div) | Low (High Risk) | Highly interactive apps |
| SSR | Complete HTML | High | Dynamic content requiring real-time data |
| SSG | Complete HTML | High (Static) | Content-heavy sites, blogs |
| Dynamic | Complete (Bots Only) | Medium (Maintenance) | Migrating legacy SPAs |
Why CSR is a liability
When an AI crawler requests a page using CSR, it receives an empty div. Since these bots do not execute the JavaScript needed to populate that div, they see a blank page. This creates a direct conflict with the goal of dynamic content AI visibility. Even if the site is fully indexed by Google, it remains invisible to the bots powering generative search answers. Relying on CSR for core content is a structural vulnerability that no meta tag or llms.txt file can overcome.
Recommended approach
For content-heavy sites, SSG is the default recommendation. It provides the highest reliability because the HTML is fully formed and static, requiring no server resources per request. For applications requiring dynamic data, such as user-specific dashboards or e-commerce product pages, SSR is the preferred solution. It ensures the initial HTML response contains complete content, guaranteeing that any crawler receives the necessary data without executing JavaScript.
We advise against using Dynamic Rendering as a new-build strategy. It is a migration workaround for legacy Single Page Applications. It requires manually maintaining a list of bot user agents, which is error-prone and difficult to keep current as new AI crawlers emerge. While it solves the immediate problem, the maintenance burden of tracking new bot user agents makes it unsustainable for long-term bot access JS management. Build with SSR or SSG to eliminate the dependency on bot detection logic entirely.
Audit your site: verifying what AI bots actually see
To understand the AI crawler JS issues affecting your visibility, start by verifying exactly what these bots receive. The most reliable method for seeing the rendered HTML Google sees is the URL Inspection Tool in Search Console, which displays the specific content and screenshot from the last crawl.
Disabling JavaScript in a local browser is outdated advice and does not accurately reflect how Google’s Web Rendering Service operates. Instead, use Screaming Frog to simulate an AI crawl by switching the user agent to GPTBot or PerplexityBot. Compare the resulting HTML against the Googlebot view; if the content differs, you have identified a rendering gap that directly impacts your client-side rendering SEO performance in generative search.
Bot access and llms.txt
When structuring your site for these tools, remember that standard bot access rules still apply. While llms.txt is an emerging standard for guiding AI agents, the underlying infrastructure for non-Google bots remains basic. Current best practice dictates assuming no JavaScript execution from these sources. This assumption ensures that your critical content, including structured data and links, is present in the initial HTTP response, regardless of the crawler’s capabilities.
FAQs: JavaScript, AI crawlers, and visibility
Does Google render JavaScript for all pages?
Yes, but the process is asynchronous. When Googlebot first visits a URL, it captures the raw HTML. Only if that page is deemed important enough is it placed in a queue for the Web Rendering Service to execute the code. Queueing is not the same as successful rendering. For smaller domains or sites with high crawl frequency, the delay between the initial fetch and the rendered state can range from hours to weeks. During that window, the page is effectively invisible to the indexing pipeline, making initial HTML content critical.
Do I need to avoid JavaScript for good rankings?
No. JavaScript remains the standard for interactive elements and user experience. However, for SEO, you must ensure critical content—such as body text, navigation links, and meta tags—is present in the initial HTML. If you rely on client-side rendering to inject these elements, you risk losing them during the initial crawl phase. The safest approach is to use Server-Side Rendering or Static Site Generation for your core content, reserving client-side logic for non-critical interactions.
Can I inject JSON-LD via JavaScript?
Technically, yes, for Google. If the rendering phase completes successfully, the injected structured data is processed. However, this strategy fails for AI crawlers like GPTBot or PerplexityBot, which do not execute JavaScript. To guarantee that your structured data is visible to both traditional search engines and AI assistants, place your JSON-LD directly in the initial HTML response. This ensures the data is available regardless of the crawler’s capabilities.
The question of whether Google can render JavaScript is no longer the central concern; the real challenge lies in understanding who else can. While Google’s Web Rendering Service executes complex scripts with high fidelity, the most extensive public data indicates that major AI crawlers often treat client-side content as invisible. This means the initial HTML determines your visibility, not the rendering capabilities of the visiting bot. As AI search gains weight, the gap between Google’s robust infrastructure and the simpler approaches of other crawlers is likely to widen. For 2026, treating initial HTML completeness as a non-negotiable baseline is the most prudent path forward. The landscape of crawler infrastructure remains in flux, but the fundamental principle of accessibility through static markup will likely endure, regardless of how bot behavior evolves in the coming years.
