JavaScript SEO: what Google renders and AI crawlers may not

What does JavaScript SEO mean for your business?

JavaScript SEO is the work of making sure machines can read a page whose content depends on JavaScript, the code that runs in a visitor’s browser. For years that meant one machine: Google. Now it also means the bots behind ChatGPT, Claude and Perplexity, and that changes the risk.

A visitor opens your site and sees a finished page. Google runs the scripts too, so it usually sees much the same thing. The evidence on AI bots is incomplete and changing, but most of it says they read what your server sends first and stop there. On many sites that first answer is the whole page. On some it is a title and an empty box.

So a site can look fine to you, rank in Google and still hand an AI bot almost nothing to quote. Nothing on your screen warns you. You can check in two minutes with no tools.

What does Google do with JavaScript?

Google’s page “Understand JavaScript SEO Basics”, last updated March 4, 2026, describes three phases: crawling, rendering and indexing. Googlebot fetches the HTML and queues the page for rendering, which can take a few seconds or longer. Then “a headless Chromium renders the page and executes the JavaScript”, and Google uses the rendered HTML to index the page.

So Google renders, within limits its own documents state:

• Blocked files. “Google Search won’t render JavaScript from blocked files or on blocked pages.”
• Error codes and noindex. Rendering “might be skipped” on a page that does not answer with a 200 status, and Google may also skip it on a page with a noindex tag in its original code.
• File size. When crawling for Search, Googlebot reads “the first 2MB” of a supported file, and each script is fetched under the same limit (Googlebot page, last updated February 3, 2026).
• Clicks and scrolls. “Google Search does not interact with your page” (lazy-loading page, last updated December 10, 2025). Content that loads only after a click or a scroll can be missed.

The basics page also says “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”. And Google no longer recommends dynamic rendering, the trick of sending bots a prebuilt page and visitors the script-built one. Its page on the subject, last updated December 10, 2025, says it “was a workaround and not a long-term solution” and recommends “server-side rendering, static rendering, or hydration” instead.

Which AI bots run JavaScript, and how sure can anyone be?

The study most people cite is “The rise of the AI crawler”, published December 17, 2024 by Vercel with MERJ. It is Vercel’s own study, from traffic on nextjs.org and Vercel’s network over a few months, checked against two job-board sites built on different technology. It found that “none of the major AI crawlers currently render JavaScript”, naming the bots of OpenAI, Anthropic, Meta, ByteDance and Perplexity. The crawlers of OpenAI and Anthropic downloaded script files but did not run them. Gemini and Applebot rendered. The study is now nearly two years old.

Later tests are smaller, and each has its own limits:

• searchVIU, October 30, 2025. A maker of SEO software tested one fictional page. Gemini read a price added by JavaScript on a direct fetch, and Perplexity read it after the page was indexed. ChatGPT did not, and Claude reported no prices at all, even visible ones.
• Search Engine World, June 9, 2026. One site, one prompt per assistant, no repeats, on a page where only a script could show the real number. ChatGPT, Gemini, Claude and Perplexity all reported the decoy number in the HTML, though Perplexity’s chat also said it could not access the page. DeepSeek, ERNIE, Qwen, Kimi and Mistral reported the real number. It tested the live fetch that happens when a person hands an assistant a link, not background crawlers.
• Forge AI Bot Log, September 24, 2026. The maker of a bot-log plugin counted 30 days of server logs on one news site. ChatGPT-User made 37,045 page requests and fetched no script while loading a page. Claude-User made 10,028 and PerplexityBot 3,193, also with none. OAI-SearchBot made 1,738 and fetched 10. The counts go by bot name and were not checked against published addresses, and the author warns that “Fetching a script does not prove a bot ran it.”
• A developer on DEV Community, September 30, 2026. One site owner, checking requests against OpenAI’s published addresses, reports that OAI-SearchBot and GPTBot began rendering pages on September 25, and writes “It looks like rendering is only switched on for some sites”. This comes from that owner’s own sites, and the author found no announcement from OpenAI.
• A site owner on Substack, October 22, 2026. One small static site, 560 requests over two weeks, each checked against OpenAI’s published addresses. A headless browser came back about 32 minutes after OAI-SearchBot fetched the HTML and ran the page’s JavaScript. ChatGPT-User fetched HTML only.

Assistant by assistant:

Two claims go too far. “No AI crawler runs JavaScript” is one: Apple’s Applebot page, published September 4, 2026, says it “may render the content of your website within a browser”, and OpenAI’s crawlers may be changing. “AI bots see what visitors see” is the other: for the four assistants here, the tests of live fetches mostly point the opposite way. AI Overviews and AI Mode are a separate case: Google’s AI features page, last updated December 10, 2025, asks that a page be “indexed and eligible to be shown in Google Search with a snippet”, and that index uses rendered HTML.

Our suggestion: treat text that appears only after scripts run as text some AI bots may never see. For what each bot does, see our list of AI crawlers. For how each assistant finds pages, see our guide to LLM SEO.

How do you test a page in two minutes?

You need no JavaScript SEO tools for this, only a browser on a computer. Our suggestion: test your home page first, then your main service or product page, then your pricing page. Pick four or five plain words from the middle of the page, with no apostrophes or symbols, because HTML can store those as codes.

Read the page source

Right-click an empty part of the page and choose “View page source”. In Safari, first turn on “Show features for web developers” under Safari > Settings > Advanced. Press Control+F (Command+F on a Mac) and search for your words. Repeat with a price and with an FAQ answer.

• Pass: the words are there as ordinary page text, in paragraphs and headings.
• Look closer: the words appear only inside a script tag, as data your browser uses to build the page. We found no statement from any AI company on whether its bots read text there, so do not count it as a pass.
• Fail: the words are missing, and the file is mostly scripts around an empty box.

A fail often looks like this:

<body>
  <div id="root"></div>
  <script src="/assets/app.js"></script>
</body>

Turn JavaScript off

In Chrome, right-click the page and choose Inspect to open the developer tools. Press Control+Shift+P (Command+Shift+P on a Mac), type javascript, choose “Disable JavaScript” and reload. It stays off in that tab while the developer tools are open. In Safari, choose Safari > Settings > Security, clear “Enable JavaScript” and reload, then turn it back on.

A pass: your text, prices and menu still show. A fail: a blank page, a spinner or a message asking you to turn JavaScript on. If the page looks blank but the source has your words, trust the source: some pages hide text until a script reveals it.

The one-line version

If you are comfortable with a terminal:

curl -sL https://yourdomain.com/ | perl -0pe 's/<script.+?<\/script>//gis' | grep -ci "five plain words from your page"

It removes script tags, then counts the lines holding your words. A 0 means they are not in what the server sent as page text; 1 or more means they are. A firewall can answer this command differently from a browser, so compare a 0 with the page source.

These tests show what a bot that does not run JavaScript would get, not what any company’s bot did on your page. Google’s URL Inspection Tool and Rich Results Test answer another question: how Google crawls and renders a URL (its page “Fix Search-Related JavaScript Problems”, last updated December 18, 2025). A clean result there does not prove the first HTML holds your text.

Does server-side rendering matter for SEO and AI search?

For Google it is a recommendation, because Google renders pages built in the browser, within the limits above. For a bot that does not run JavaScript, it decides whether your text arrives at all. The terms below follow “Rendering on the web” on web.dev, last updated January 5, 2026.

Most sites mix these, which is why the test goes page by page. Scripts still have their place: the Vercel and MERJ study lists view counters, live chat widgets and social media feeds as things that can stay client-rendered.

Do WordPress, Shopify, Squarespace, Wix and Webflow send content in the first HTML?

Here is what each says in its own documents, read November 4, 2026. None of these statements covers every theme, app or piece of custom code added on top, so test your own page.

• WordPress. The Block Editor Handbook says a block’s markup is either “dynamically generated server-side upon request” or “statically generated during the save process”. The handbook speaks for blocks, not for every plugin.
• Shopify. Its theme documentation tells developers to “Render initial content with Liquid and HTML instead of client-side frameworks”. That is advice to theme builders, so it does not say what your theme and apps do.
• Squarespace. We found no statement on this in its help pages.
• Wix. Its SEO article, updated October 26, 2026, says “Every Wix site is built on server-side rendering”. That is Wix’s own statement.
• Webflow. Its developer docs say server-side rendering is on by default for code components and can be turned off per component. We found no direct statement about ordinary pages.

Our own scan of 32 sites, described below, rates no platform: sites on the same platform landed on different sides, and some platforms had only one site in it.

What should you ask a developer?

JavaScript SEO best practices come down to one request: put what a buyer needs in the first HTML. You do not need to know how. Copy this message, fill in your pages and send it.

Please check these pages: [home], [main service or product], [pricing], [FAQ].

For each page, tell me:

1. Is the main text in the HTML the server sends, before any script runs?
   Please send the curl output or a copy of the page source as proof.
2. Which parts load only after the page opens: prices, FAQ answers,
   reviews, product details, locations, menus?
3. Are the menu and internal links real <a href> links in that first HTML?
4. Is our structured data (JSON-LD) in that first HTML, or added by a
   tag manager or a script?
5. Do we send bots a different version from visitors (dynamic rendering)?
   If so, which bots get it? Are OAI-SearchBot, Claude-SearchBot and
   PerplexityBot on the list?
6. What would it take to move the parts from answers 2 to 4 into the
   first HTML? What would you do first, and why?
7. Can this check run after every release, so a redesign cannot undo it?

A good answer is specific and comes with proof, page by page. The fix may be one block on one template or a whole site moving to server rendering: only your developer can size it. If the answer is dynamic rendering, remember that Google calls it a workaround, and that a bot left off the list gets the script-built page.

Which parts hurt most when only JavaScript shows them?

• Main text. It is what an assistant quotes. Without it, a bot has a title, perhaps a menu, and nothing on what you sell.
• Links. Bots find your other pages through links. Google says it can only discover links that are real link elements with an href attribute, and that adding them with JavaScript is fine. A bot that does not run scripts never sees those, so deeper pages must be found some other way. The Vercel and MERJ study lists navigation among the things to server-render.
• Structured data. This is the known tag manager case. Google’s page “Generate Structured Data with JavaScript”, last updated December 10, 2025, gives the steps for adding JSON-LD through Google Tag Manager, and says Google can process structured data “available in the DOM when it renders the page”. A bot that does not run scripts never gets it, because the markup exists only after the tag manager runs. The Rich Results Test will not reveal this, since it renders. Search the page source for “application/ld+json”.
• Prices. A buyer’s “how much” needs a number. A price drawn by a script or a quote widget leaves a bot nothing to quote from your page. Google warns about this for its own Shopping crawls: “dynamically-generated markup can make Shopping crawls less frequent and less reliable, which can be an issue for fast-changing content like product availability and price”.
• FAQs. An answer hidden by styling until a click is still in the HTML. An answer fetched on click is not, and that applies to Google too, since it does not interact with the page. Search the page source for a line from a closed answer.

How common is thin first HTML on real business sites?

On November 4, 2026 we ran the MWY checker on 36 hand-picked websites: local businesses, online shops, software firms and blogs in seven countries. Four refused every request, so 32 were read. This is not a sample of the web. The item “Content is in the HTML” counts the words of main text, not menus or footers, in the raw HTML of the home page.

Among the sites we picked, thin first HTML was the exception. The other six are not six JavaScript cases, because the item counts words, not causes. One partial was a home page over the 1.5 MB the checker reads, with its text further down. One fail was a site that sent the checker to another address, where the first HTML held almost no text. A home page that is simply short lands in the same place.

A pass on the home page does not clear the rest of a site either. Two sites that passed here had FAQ content missing from the raw HTML: one had a FAQ heading whose questions were not there, the other a FAQ page with no readable words.

What the MWY checker does and does not test about JavaScript

The free AI visibility checker from MWY reads the HTML your server returns, without running JavaScript: the page you enter, usually the home page, and up to 7 inner pages, skipping anything your robots.txt closes to MWYGeoCheck. Its items read that HTML, so text, prices and schema that exist only after scripts run do not count, and schema added through a tag manager is not seen. You get your score, the score of each group and the 5 items that matter most in a few seconds, with no sign-up. If “Content is in the HTML” is among those 5, it shows the word count it found. Pro, which opens soon, shows all 24 items. The methodology page lists what the checker reads and how each item is weighted.

The checker cannot show what Google renders, so a page can fail here while doing well in Google. It does not watch any AI bot on your site or look inside any AI company’s index. Its word count cannot say why words are missing, or prove that one given price or answer is in the HTML: the page source test does that. And it does not promise that an assistant will name your business, because nobody outside those companies controls that. What can be checked is whether the words you want quoted are in the first answer your server gives.