Guide 05 · Evidence review
Do AI crawlers run JavaScript? Can ChatGPT read it?
Generally not. Retrieval crawlers fetch your HTML and parse it; they do not execute the scripts on the page. Googlebot does render JavaScript, which is why a site can rank perfectly well in classic search and be invisible to the engines that answer questions.
This is the only item on the whole GEO evidence list that is binary. Everything else shifts your odds. This one decides whether you are in the running.
Google’s AI optimization guide says Google can process content in JavaScript as long as it is not blocked, and asks you to follow its JavaScript SEO best practices. That is Googlebot. The retrieval crawlers behind ChatGPT, Perplexity and Claude are a different case, which is what this page is about.
Why do the crawlers behave differently?
Rendering is expensive. To execute a page’s JavaScript a crawler has to run a real browser engine, wait for network requests to settle, and hold that page in memory while it does — orders of magnitude more cost per URL than reading the HTML the server sent. Google absorbed that cost over years because its whole business is the index.
A retrieval crawler working against a live question has a different constraint: it is fetching a handful of pages while a user waits. Speed is the requirement. So the pragmatic assumption — treat retrieval crawlers as HTML parsers, not browsers — matches both the incentives and the reported behaviour.
No engine publishes a rendering guarantee in either direction, and behaviour can change without an announcement. What I would not do is bet a product’s visibility on an undocumented capability. Check your own raw HTML — that answer is specific to you and it does not expire when a crawler changes.
How do you check your own site?
Two minutes, no tools. Fetch the page as a crawler would and look for your own words in what comes back:
curl -sA "OAI-SearchBot" https://yoursite.com/your-page/ | grep -c "a distinctive sentence from your page"A count of zero means the sentence is not in the HTML your server sent. It is being written into the page by JavaScript after the fact, and a crawler that does not run that JavaScript never sees it.
Without a terminal: open the page, right-click, View page source — the raw document, not the inspector — and use your browser’s find. The inspector shows the DOM after scripts have run, which is exactly the view a retrieval crawler does not get. This is the single most common way people convince themselves their content is fine.
Or let the free retrievability check do it: give it your wordpress.org slug and it reports how many words of text are in the HTML each crawler actually receives.
Is this a problem for WordPress sites?
Usually not, and that is worth saying plainly rather than manufacturing alarm. WordPress renders on the server by default. PHP assembles the HTML, the HTML goes out, the content is in it. A standard theme with standard posts is in the clear.
The exceptions are specific and worth knowing by name:
| Setup | Where the content lives | Risk |
|---|---|---|
| Standard theme, standard posts | Server-rendered HTML | None |
| Block themes and page builders | Server-rendered HTML | None |
| Tabs and accordions | In the HTML, hidden by CSS | Low |
| Infinite scroll, “load more” | Fetched by script on demand | High past the first batch |
| Review, pricing or comparison widgets | Third-party script | High |
| Headless WordPress with a JS front end | Rendered client-side | Total, unless SSR is on |
The pattern is not “WordPress or not”. It is whether the specific thing you want quoted arrived in the response or was fetched afterwards. Hidden-by-CSS is fine — the text is in the document. Fetched-by-script is not.
The widget row is the one that catches plugin companies. A pricing table pulled in from a third-party script, or a feature comparison rendered by a review plugin, is precisely the content you would most want an engine to quote, and it is precisely the content most likely to be absent from the HTML.
What if you find your content is client-rendered?
Put the text in the server response. That is the entire fix, and there are three ordinary ways to get there.
Render it server-side. For headless setups this means turning on SSR or static generation in the front-end framework. It is the real fix and usually a configuration change rather than a rewrite.
Write the important part into the HTML anyway. If a widget renders your pricing, put the same numbers in an ordinary paragraph above or below it. Slightly redundant for a human reader; the difference between existing and not for a crawler. This is the cheapest option and it is often enough.
Do not reach for prerendering services first. Serving a different, pre-rendered document to crawlers than to humans is a fragile arrangement, it needs maintaining, and you would be introducing it to solve a problem that a paragraph of plain HTML usually solves.
Is JavaScript the only thing that breaks the fetch?
No, and the others are more common. The same logic — total, invisible in a content audit — covers an expired TLS certificate, a WAF or CDN rule refusing unfamiliar user agents, and a robots.txt line that blocked retrieval crawlers along with the training ones.
This site was invisible to every retrieval crawler for 152 days on a lapsed certificate while its content was perfectly fine. Check all four together — they take the same two minutes, and any one of them makes the rest of your work irrelevant. The full diagnostic is here.
What this page cannot tell you
No engine documents its rendering behaviour, so “generally do not execute JavaScript” is drawn from reported behaviour and from the economics, not from a published specification. It could change tomorrow and nobody would announce it.
That is exactly why the recommendation here is a check you run on your own site rather than a fact to memorise. “Is my text in my HTML” has a definite answer, it is yours, and it stays true regardless of what any crawler decides to do next.
And fixing this does not get you cited. It gets you eligible. Retrievability is necessary and nowhere near sufficient — this site has been fully retrievable for weeks and is cited in none of the twenty-four prompts it tracks. I publish that count either way.
Related: what a retrieval crawler is, and how it differs from a training crawler.
How this was made: figures come from our own runs in the engines’ public interfaces or from the studies named above. Drafted with an AI assistant (Claude) and reviewed by Alauddin Chowdhury. Method and AI use.
Want the check run for you?
Send me your wordpress.org slug. I will fetch your pages as each retrieval crawler and tell you what arrives — certificate, robots rules, live response code, and how much of your content is in the HTML they receive. Free, no call, usually within a day.