Many AI crawlers fetch raw HTML and do not execute JavaScript, so a website that builds its content client-side can be invisible to them even though it looks complete in a browser. You fix this by serving your important content in the initial HTML, through server-side rendering, static site generation, or prerendering, so that what the crawler receives already contains your content.
In short
- Many AI crawlers read the raw HTML and do not run JavaScript.
- A client-side rendered page can return a near-empty shell to those crawlers.
- Detect it by viewing the page source or fetching the raw HTML, not the rendered page.
- Fix it with server-side rendering, static generation, or prerendering so content is in the initial HTML.
Why is JavaScript rendering a problem for AI crawlers?
JavaScript rendering is a problem because many AI crawlers do not run JavaScript, and a client-side rendered site depends on JavaScript to build its content. When such a crawler requests the page, it receives the initial HTML the server sent, which for a client-only application can be a near-empty shell, and it never runs the scripts that would fill in the content.
The reason this is so easily missed is that browsers do run JavaScript, so the site looks perfect to anyone viewing it. The gap only appears for clients that read the raw HTML, which includes several major AI crawlers. Google's own crawler does render JavaScript, and AI Overviews draw on Google's index, so Google-based surfaces are less exposed, but the dedicated crawlers behind several AI assistants are not, which means a client-side rendered site can be largely invisible to them. This makes rendering one of the highest-leverage issues in LLM optimization, because fixing it can move content from invisible to retrievable across several AI surfaces at once.
How do you detect a rendering problem?
You detect a rendering problem by looking at the raw HTML your server returns, rather than the fully rendered page in your browser, and checking whether your actual content is present in it. If the content is missing from the raw HTML, crawlers that do not run JavaScript cannot see it.
A few methods reveal this. Viewing the page source, as opposed to inspecting the rendered DOM, shows roughly what a non-JavaScript crawler receives, so if your main content is absent from the source, that is the warning sign. Fetching the page with a tool that retrieves raw HTML without executing scripts shows the same thing more precisely. Disabling JavaScript in your browser and reloading the page approximates what such a crawler sees, and if the page is blank or missing its content, you have confirmed the issue. The practical test is simple: if your important text is not in the HTML before JavaScript runs, it needs to be, and the fixes below put it there.
What are the ways to fix it?
You fix a rendering problem by getting your content into the HTML the server returns, and there are a few established approaches depending on your setup. All of them share the same goal: the crawler receives the content without having to run JavaScript.
The main approaches are these. Server-side rendering generates the full HTML for each page on the server at request time, so the crawler receives complete content. Static site generation builds the HTML pages ahead of time, at build time, which is ideal for content that does not change on every request and serves complete HTML to every visitor. Prerendering generates static HTML snapshots of pages, often used to add server-rendered output to an otherwise client-side application without rebuilding it entirely. Each of these ensures the important content is present in the initial response. The right choice depends on your stack and how dynamic your content is, but for content you want AI systems to find, any approach that puts the content in the initial HTML solves the core problem.
What should you prioritize when fixing rendering?
You should prioritize getting your most important, visibility-relevant content into the initial HTML first, since that is what determines whether AI systems can see it. Not every part of a site needs the same treatment, so focus where it matters.
A sensible order helps. Start with the pages you most want cited in AI answers, your key content, product, and resource pages, and ensure their main text is server-rendered or prerendered. Confirm the fix by re-checking the raw HTML and watching for AI crawler activity in your server logs, covered in how AI crawlers work. Interactive features that genuinely require client-side JavaScript can remain so, as long as the core readable content, the text an engine would extract, is in the initial HTML. The aim is not to eliminate JavaScript but to ensure the content you want retrieved does not depend on it. Once content is reliably in the initial HTML, the rest of LLM optimization, structure, entities, and the content and presence work in AEO and GEO, can actually take effect.