Short answer: Often not. The main public evidence says several AI crawlers read the HTML they are served and do not run JavaScript, so a page that is an empty div until a script fills it can look blank to them.
Googlebot is the exception: it renders JavaScript. The cheap fix is to send your real content in the first response, and you can check whether you need to in thirty seconds with curl.
Do AI crawlers run JavaScript?
The best public evidence we found is a December 2024 analysis by Vercel and MERJ. It reported no JavaScript execution from OpenAI's crawlers (including OAI-SearchBot and ChatGPT-User), from ClaudeBot, from Meta's crawler or from Bytespider. It did not show how PerplexityBot behaves.
Hold that loosely. It is one analysis, it is from late 2024, and no vendor guarantees either behavior. We reached the full write-up through a search summary rather than reading every page of it, so we state the finding and not the detail. Crawlers change. The honest position is that server-rendering is cheap insurance, not a proven requirement for every engine.
Google is different, and that is the trap
Google says it renders JavaScript with an evergreen Chromium, after a queue. So a client-rendered page can rank on Google and still be invisible to other crawlers. If your page ranks fine in Google, that tells you nothing about whether an AI crawler can read it.
What does a page that AI crawlers cannot read look like?
Open your page, choose View Source, and look at the body. A server-rendered page shows your headings and paragraphs in the markup. A client-rendered single-page app shows something like an empty div with an id of root, plus a script tag. A crawler that does not run the script gets the empty div.
View Source is not Inspect Element
Inspect Element shows the page after JavaScript has run, which is what your browser built. View Source shows what the server sent, which is what a non-JavaScript crawler gets. People check the wrong one all the time and conclude the page is fine.
There is a second, sneakier version. The header and footer are in the HTML, so the page does not look like an empty shell, but the article body is fetched by the browser after load. A rule that only looks for an empty mount point can pass that page while it is still empty of content. The only reliable check is whether your actual body text is in the served HTML.
How do I test my own page in thirty seconds?
Compare what the server sends with what you see in a browser. Pick a phrase from the page, ideally the headline, and search for it in the raw response.
# Is a phrase you can see in the browser present in the raw HTML?
curl -s https://example.com/pricing | grep -ci "your exact visible headline"
# Rough word count of the served HTML
curl -s https://example.com/pricing | sed -e 's/<[^>]*>/ /g' | wc -wZero matches, or a body that is only an empty div and scripts, confirms the problem. Run it on a few page types, not just the homepage. Marketing pages are often fine while the blog or docs are client-rendered.
Our audit rule aeo.content-server-rendered fails a page only when it has both an empty app shell (a known mount point with 3 words or fewer of visible text and at least one script) and fewer than 100 words in the served HTML. It deliberately does not fail a short page that is server-rendered. (AEO Toolkit skill source)
When does it matter, and when does it not?
It matters for any page you want cited: articles, documentation, product and pricing pages, about pages. It matters much less in three cases, and you should not spend a week on them.
- Logged-in screens: Dashboards and checkout are not meant to be cited. Nobody expects a crawler to read them.
- Interactive widgets on a rendered page: A calculator or chat bubble that is missing from the HTML is fine. The surrounding text is what counts.
- Google alone: If your only goal is ranking on Google, Googlebot renders JavaScript. Do not tell yourself the page is not indexed because of this finding. The concern is other engines and AI crawlers.
Check access before rendering
If a robots.txt rule or a CDN firewall blocks the bots, rendering is irrelevant because they never fetch the page. When nothing at all is being fetched, fix access first.
robots.txt for AI crawlersHow do I get my content into the first HTML response?
The goal is the same whatever your stack: the headline, the body text and your structured data should be in the HTML the server sends. At summary level:
List the pages that must be citable
Ask which pages you actually want cited. Everything else can stay client-rendered.
Pick the least invasive fix
If your framework supports server rendering and a page opted out, remove the opt-out. If the content is known at build time, generate it statically. For a Vite or Create React App single-page app with few public pages, prerender those routes at build time.
Fetch visible text on the server
Text loaded in a browser effect after the page mounts is invisible to a crawler that does not run scripts. Fetch it on the server and pass it down.
Render collapsed content into the markup
Tabs and accordions whose hidden panels only mount on click are empty to a crawler. Render every panel and hide it with CSS or a details element.
Re-run the curl test
Your headline and body text should now appear in the raw response. Spot-check a deep URL and a page with tabs, and confirm the page still behaves in a browser.
A coding agent is well suited to this, because the fix is specific to your framework. The skill behind this article can be installed into Claude Code and other agents so it runs the curl test, finds what is client-rendered, and proposes the change.
Full implementation guide for server renderingTo install the skills into your own agent, start here.
Install the AEO agent skillsThe skill's source is open if you want to read it first.
aeo-server-rendering on GitHubWhat goes wrong when people fix this?
- Stale snapshots: Prerendering at build time freezes the content. If it changes between builds, set a rebuild or revalidate schedule.
- Cloaking drift: A prerender service that serves bots different HTML from what users get can drift into cloaking if the content differs. Google lists dynamic rendering as a workaround, not a recommendation. Prefer rendering from the same code users get.
- Hydration mismatches: Server and client output that differ, through dates, random ids or window checks, cause warnings. Fix the mismatch. Do not suppress the warning and ship.
- Lazy text that waits for scroll: Below-the-fold text that only loads on scroll never loads for a crawler.
And keep the claim proportionate. Rendering your content makes it readable. It does not make an assistant cite it, and nobody can promise that. Our visibility tools check Perplexity only, so they cannot confirm that ChatGPT, Claude or Gemini now read a page that they could not before.
Common questions
Can ChatGPT read JavaScript-rendered pages?
The public evidence suggests not reliably. A December 2024 Vercel and MERJ analysis reported no JavaScript execution from OpenAI's crawlers, including OAI-SearchBot and ChatGPT-User. It is one analysis and OpenAI does not guarantee either behavior, so the safe approach is to put your content in the HTML the server sends.
Do I need server-side rendering for AI search?
For pages you want cited, it is cheap insurance, not a proven requirement for every engine. You can satisfy it with server rendering, static generation or build-time prerendering. Pages behind a login, and small interactive widgets, do not need it.
If my site ranks on Google, can AI crawlers read it?
Not necessarily. Google renders JavaScript with an evergreen Chromium, after a queue, so a client-rendered page can rank there. Other crawlers that read only the served HTML would see an empty shell. Ranking on Google tells you nothing about them.
How can I see what an AI crawler sees on my page?
Use View Source in a browser, not Inspect Element, or fetch the page with curl and search the raw response for your headline. If the text is missing and the body is only an empty div plus scripts, a crawler that does not run JavaScript sees nothing to cite.
Sources
Related guides
Want it done for you
Want this done and re-checked every month? Our monthly maintenance re-runs your buying questions in ChatGPT, Perplexity and Google, ships the fixes that keep you out of the answers, and reports what moved. Or run the free check on your site first at advancelabs.dev/tools/audit.
See how it works