JavaScript rendering and AI crawlers: what gets read

Some crawlers run the JavaScript on your pages and some may not, and for most AI crawlers the honest answer is that nobody outside the company knows. As of October 2026, Google and Bing document that they render JavaScript. Apple says its crawler "may render" pages. Common Crawl says it does not execute JavaScript at all. OpenAI, Anthropic, Perplexity, Amazon and Meta say nothing either way on their crawler pages.

That gap matters if your website builds its content in the browser. On such a site, the first response from the server is a nearly empty page, and the text, prices and links only appear after scripts run. A crawler that renders sees the finished page. A crawler that does not sees the empty one.

You cannot settle the question for vendors that have not answered it. You can remove the risk: make sure the content you want read is in the HTML your server sends first.

What rendering means

A browser first receives an HTML file from the server. If that file contains the full text of the page, the content is there for anyone who fetches it. Many modern sites work differently: the HTML is a thin frame, and JavaScript then builds the page on the visitor's device. Google's documentation describes it this way: "On some websites, JavaScript loads additional content when the page is open in a browser. This is called client-side rendering."

Rendering is the step where a crawler runs those scripts, the way a browser would, to see the finished page. It costs time and computing power, so not every crawler does it. Single-page applications are the usual case; our article on single-page applications and GEO looks at those frameworks in more depth.

What each operator documents

This table shows what each company's own crawler documentation says about JavaScript as of October 2026. The crawler names are explained in our guide to AI crawlers and robots.txt.

How Google renders JavaScript

Google has rendered JavaScript for years and documents the process in detail. Its JavaScript SEO basics page says it "processes JavaScript web apps in three main phases": crawling, rendering and indexing. Rendering is queued. "The page may stay on this queue for a few seconds, but it can take longer than that."

The details that trip sites up are all in Google's own documentation:

• Rendering is not guaranteed. "Google typically renders pages in order to index them, however rendering is not guaranteed."
• Blocked files are not rendered. "Google Search won't render JavaScript from blocked files or on blocked pages." If your robots.txt disallows the script files, Google cannot build the page.
• Only the rendered HTML counts. "If the content isn't visible in the rendered HTML, Google won't be able to index it."
• Links must be real links. "Google can only discover your links if they are <a> HTML elements with an href attribute."
• A noindex tag cannot be removed with a script. When Google sees the tag, "it may skip rendering and JavaScript execution."

Google does not describe a separate rendering process for AI Overviews or AI Mode. It says a page must be indexed and eligible to appear in Search with a snippet to be shown as a supporting link in those features, and its guide to optimizing for generative AI search says "Google is able to process content within JavaScript as long as it isn't blocked."

What Bing and Apple say

Microsoft Copilot draws on the Bing index, so Bing's rendering is what matters there. Bing renders, yet its webmaster guidelines list hiding critical content behind client-side rendering among the things to avoid, and warn: "Content that cannot be reliably rendered may not be indexed or selected for grounding results." Grounding is the step where an AI system pulls web content to support its answer. Our guide to Bing Webmaster Tools and IndexNow covers the Microsoft side.

Apple's Applebot page is more cautious. It says the crawler "may render" a page, and that if JavaScript, CSS and other resources are blocked in robots.txt, "it may not be able to render the content properly." Apple's advice is to make every resource a user needs available to the crawler, or to "make sure that the website renders cleanly, even if all of the resources are not available."

The operators that say nothing

The crawler pages published by OpenAI, Anthropic, Perplexity, Amazon and Meta list each bot's name, purpose and robots.txt behavior. None of them states whether the bot executes JavaScript. That is the whole of what can be said from first-party sources.

You will find confident claims online in both directions. Treat them as observations, not vendor facts. A user-agent string that mentions a browser engine is not a vendor statement that the bot renders pages.

The one thing OpenAI does say is general. Among the reasons ChatGPT may fail to use a site, it lists: "Lack of access: The model may not be able to obtain relevant information from a given website due to technical issues, paywalls or preferences set via robots.txt." It does not say whether JavaScript is one of those technical issues.

Why server-rendered HTML is the low-risk choice

If the answer is unknown for several of the crawlers you care about, the safe design is one where the answer does not matter. Content that is already in the first HTML response can be read by a crawler that renders and by one that does not.

This is not a rule any AI vendor has published, so do not treat it as a requirement or expect it to produce citations. It is a way to remove a possible point of failure. Google gives the same reasoning for its own crawler: "Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."

On the last row, Google's dynamic rendering page is now titled "Dynamic rendering as a workaround" and says: "we recommend that you use server-side rendering, static rendering, or hydration as a solution." It also notes the weak point for other crawlers. A dynamic rendering setup only helps the bots it recognizes, and serving bots "completely different content" from users "can be considered cloaking."

Whether your site does server-side or static rendering is a question for your developer, and it is worth asking before a rebuild, not after. If a redesign is coming, add it to the plan in our guide to protecting AI visibility during a redesign or migration.

How to see what a non-rendering fetcher gets

You do not need developer tools for a first check. You need the raw HTML, before any script has run.

1. Pick three pages that matter: a service or product page, your pricing or contact page and one article.
2. On each, copy a sentence from the middle of the main content, and note one important fact such as a price, a phone number or your address.
3. In a desktop browser, open the page, right-click and choose View Page Source. This shows the HTML the server sent, not the finished page.
4. Search the source (Ctrl+F or Cmd+F) for your sentence and your fact.
5. If both are there, a non-rendering fetcher can read them. If the source is mostly script references and your sentence is missing, the content depends on JavaScript.

If you are comfortable in a terminal, this command does the same thing in one line. It prints the matching line if the sentence is in the raw HTML and prints nothing if it is not.

curl -s https://www.example.com/page | grep -i "a sentence from the page"

No AI vendor prescribes this test. It works because a plain HTTP request returns the server's HTML without running scripts. For Google's view, use the tools Google names: "use the Rich Results Test or the URL Inspection Tool and look at the rendered HTML."

One caution. This test shows what your server sends to you. If a firewall treats bots differently from browsers, a crawler may get something else entirely, which is the subject of our guide to CDNs and firewalls blocking AI crawlers.

What to look for in the raw HTML

These checks sit alongside the other items in our technical foundations of GEO.

What this does not tell you

Passing the test means a crawler can read your content. It does not mean an AI assistant will use it, cite it or recommend you. No vendor publishes a rule that connects rendering method to being chosen as a source, and Google has not said that server-side rendering improves inclusion in AI Overviews or AI Mode specifically.

It also does not tell you which bots visited or what they received. That takes log data, and a way to tell real bots from imitations. See our guide to verifying AI bots in your server logs.

Conclusion

Google and Bing render JavaScript and say so. Apple says its crawler may. Common Crawl says it does not. OpenAI, Anthropic, Perplexity, Amazon and Meta have not documented the point as of October 2026, and guessing on their behalf is how sites end up with bad advice. The practical answer is to stop depending on the unknown: put the content you want read in the HTML your server sends, and confirm it with View Source. If you want someone to check how your site looks to a fetcher that does not run scripts, request a free GEO audit. More guides are in our GEO and AEO Guide.

Frequently asked questions