Client-side JavaScript rendering, where content is built up in the browser after the initial page load rather than delivered as complete HTML from the server, has been a workable pattern for years because major search engines eventually learned to execute JavaScript when crawling. Independent research and crawler-traffic analysis suggest AI crawlers largely haven't caught up. That makes this a genuinely different, and currently more restrictive, constraint than traditional SEO has had to account for.
What the available evidence suggests
Analysis of real AI crawler traffic, including research published by infrastructure providers who can observe crawler behavior directly, has found that major AI crawlers, including those associated with leading AI search and chat products, generally do not execute JavaScript. They read the initial HTML response and nothing more. This is a meaningfully different situation from Google's crawler, which has supported JavaScript rendering for years. If this pattern holds (and multiple independent sources point the same direction), content that only exists after client-side JavaScript executes may simply be invisible to a real and fast-growing share of AI-driven traffic.
Why this specifically matters for GEO
If an AI crawler can't see your product details, pricing, FAQ content, or article text because it only exists after JavaScript runs, none of the AEO or GEO practices covered elsewhere on this blog (structuring for extraction, adding schema markup) matter, because the crawler never sees the content in the first place. This is a foundational, upstream problem that has to be solved before anything else on this list has a chance to work.
What actually solves this
Server-side rendering, or a server-rendered fallback
Rendering the initial HTML response on the server, so meaningful content is present in the raw HTML before any JavaScript executes, is the most direct fix. Modern frameworks generally support this as a configuration choice rather than a full rewrite, so for most sites it's an addressable problem rather than a fundamental architecture change.
Static generation for content that doesn't need to be dynamic
For content that doesn't need real-time interactivity (blog posts, product pages, FAQ pages), generating fully static HTML at build time sidesteps the rendering question entirely. There's no client-side rendering step for a crawler to miss.
Checking what a non-JavaScript-executing crawler actually sees
The most direct way to verify this is checking the raw HTML response your server sends, before any JavaScript runs, and confirming that your actual content (not just a loading shell or empty container) is present in it. If the raw response is mostly empty divs waiting for JavaScript to fill them, that's the specific gap worth closing.
This isn't a reason to avoid JavaScript entirely
Interactive features, dynamic UI, and client-side functionality all remain valuable and don't need to disappear. The specific issue is that your content (the information you want found, read, and cited) needs to exist in the initial server response rather than depending entirely on client-side rendering. A site can have rich interactivity and still deliver its core content server-rendered.
How we approach this
We build content-bearing pages with server-side rendering or static generation as a default, so the content that matters for AEO and GEO is present in the initial HTML response whether or not a given crawler executes JavaScript. Everything else in an organic strategy depends on that foundation.