How JS rendering affects what AI can read
Guide · SEO / AEO / GEO · 4 min read · last verified 2026-07-27
JavaScript rendering is the step where a browser executes a page's scripts to build the content a person actually sees. Many modern websites ship a nearly empty HTML shell and let JavaScript assemble the headlines, product details, and pricing tables in the visitor's browser after the page loads. That works for people. It does not reliably work for AI systems: many of the crawlers that read the web to build AI answers fetch the raw HTML of a page and move on without executing any JavaScript. Content that only exists after scripts run can be invisible to them — which means the version of your site that answer engines read may be far thinner than the one your buyers see.
This is one of the few AI visibility problems that is purely technical, fully diagnosable from your own desk, and fixable without writing a single new sentence of content.
Every page exists in two versions
When a browser loads a page built with a client-side framework, two documents exist in sequence. The first is the raw HTML response — what the server actually sends over the network. The second is the rendered DOM — what exists after the browser has executed the JavaScript, fetched data from APIs, and assembled the final page. On a fully server-rendered site the two are nearly identical. On a heavily client-rendered site the first version can be close to empty: a root element, some script tags, and none of the words you wrote.
Humans only ever see the second version, so teams rarely notice the gap. Crawlers are not so forgiving. Executing JavaScript at crawl scale is expensive, so any system reading millions of pages has a strong incentive to take the raw HTML and move on.
What AI crawlers actually do
Here honesty matters more than tidiness. Crawler behaviour is not uniform: some systems fetch raw HTML only, some render a subset of pages, and some rely on search indexes that did the rendering separately. The behaviour differs between engines, between crawl types within one engine, and it changes over time without notice. Anyone quoting a precise figure for how many AI crawlers execute JavaScript is guessing.
What you can rely on is the asymmetry. If your content exists in the raw HTML, every crawler can read it — the ones that render and the ones that do not. If your content exists only after JavaScript runs, you are betting on each crawler's rendering behaviour, which varies and changes. Raw HTML is the safe baseline; everything else is exposure you accept knowingly or not.
Three checks you can run today
The diagnosis takes minutes and requires no tooling beyond a browser.
First, the view-source test. Open a page that matters — your homepage, your pricing page, a definition page — and use the browser's view-source function. This shows raw HTML, not the rendered DOM. Search within it for an exact sentence that matters to you: your product definition, an integration name, a plan limit. If the sentence is there, that content is visible to non-rendering crawlers. If the source is mostly script tags and the sentence is absent, it is not.
Second, compare raw HTML to the rendered page from the command line:
curl -s https://www.example.com/pricing -o raw.html
grep -i "your key sentence here" raw.html
If the phrase appears in the browser but not in the curl output, the words are being assembled client-side.
Third, disable JavaScript in your browser's settings and reload the page. What you see now is a fair approximation of what a non-rendering crawler sees. An empty white page is a clear verdict.
Run the checks on the pages tied to your most important buyer questions first, not on the site in general — the blog may be fine while the pricing page is invisible, or the reverse.
What server rendering and prerendering change
If the checks fail, the fixes all move content from the second version of the page into the first.
Server-side rendering generates the full HTML on the server for every request, so the raw response contains the real content and JavaScript only adds interactivity afterward. Static generation does the same work at build time, producing complete HTML files ahead of any request — a strong fit for content pages that change on publish, not per visitor. Prerendering serves a pre-built HTML snapshot, sometimes selectively to crawler user agents, when rebuilding the whole stack is not practical — it works, but selective serving adds a moving part that needs monitoring. Most modern frameworks also support hybrid modes, where marketing and documentation routes are server-rendered while the application behind the login stays client-side. That split matches how visibility actually works: the logged-in app was never going to be read by crawlers anyway, and the public pages are the citation surface — the same logic that decides whether a help center is readable at all.
The goal in every variant is one sentence long: the words you want quoted must exist in the initial HTML response.
Verify the fix changed anything
A rendering fix is an ideal candidate for honest measurement, because it has a clean before and after. Record what answer engines currently say about your company and your category before shipping the change — this is exactly what a locked baseline is for, and it is the part of the loop a platform like Magrios automates with scheduled re-scans against a fixed benchmark. Then re-check after the change has been live long enough for crawlers to revisit, and compare. Answers move for many reasons, so a single shift proves little — but content that was invisible becoming visible is the kind of change that can plausibly show up, and measuring it beats asserting it.