Checking JavaScript Rendering: What Google and AI Crawlers Actually See

The Two-Minute Test: What Does the Delivered HTML Contain?

The test requires no tool, only Chrome. It shows the HTML that the server delivers before JavaScript has changed anything. This is exactly the version every crawler sees first, and many never see any other.

1. Open the page in Chrome.

2. Right-click on the page, select Inspect, switch to the Network tab and click the Doc filter.

3. Reload the page, click the page name on the left and open the Response tab on the right.

4. Use CTRL+F (Mac: CMD+F) to search for something important: the main heading, a service description, a price, an FAQ answer.

If the searched text appears, it is present in the delivered HTML. If it is missing despite being visible in the browser, it was inserted afterwards via JavaScript.

For an even quicker check: CTRL+U opens the page source and shows the same raw HTML.

The Catch: The Elements Tab Shows Something Different

A common mistake occurs immediately after clicking "Inspect". The Elements tab does not show the delivered HTML but the finished DOM after JavaScript has run. Everything is always present there. For the purposes of this check, only the Response in the Network tab or the page source counts.

One further note on context: the test shows what the server sends to your own browser. If a website delivers different content to bots, or if a firewall blocks certain crawlers, this will not be apparent here. More on that below.

What JavaScript Rendering Means

Rendering is the step in which code becomes a finished page. The browser loads HTML, CSS and JavaScript, executes the scripts and builds the DOM from them — the structure that ultimately appears on screen.

On a traditional website, this step is unremarkable. The HTML from the server already contains headings, text and links. JavaScript adds at most a menu or a slider.

On many modern websites, the opposite is true. The server sends an almost empty shell with a reference to a JavaScript bundle. Only the script then fetches the content via an API and writes it into the page. In the source code, this looks roughly like:

<body>\n <div id="root"></div>\n <script src="/assets/app.4f2a.js"></script>\n</body>

There are therefore two versions of every page:

• Raw HTML: what the server delivers as a response.

• Rendered HTML: what is present in the browser after JavaScript has executed.

Users always see the second version. A crawler only sees it if it brings its own browser and executes JavaScript. This consumes processing time, and that is precisely why many bots skip this step.

CSR, SSR, SSG: Where Content Is Assembled

Whether a page includes content in its raw HTML depends on where it is assembled. This is described by the rendering model.

Client-Side Rendering (CSR) means: the page is assembled in the visitor's browser — on the client. The server delivers only the empty shell and the script. This is the default mode of classic single-page applications built with React, Vue or Angular. CSR is therefore the cause of exactly the problem the test above reveals.

Frameworks such as Next.js, Nuxt or SvelteKit support SSR and SSG out of the box. Importantly, a modern framework alone is no guarantee. Even in a server-rendered page, any content that a component fetches from an API after loading will be absent from the HTML.

CSR is therefore not inherently wrong. For everything behind a login, visibility is irrelevant. It becomes critical for pages that need to be found and cited.

How Google Handles JavaScript

According to its own documentation, Google processes JavaScript pages in three phases:

1. Crawling: Googlebot fetches the URL, reads the raw HTML and collects the links from href attributes.

2. Rendering: Pages with status code 200 enter a render queue. Once resources are available, a headless Chromium executes the JavaScript.

3. Indexing: Google indexes the rendered HTML and sends the links found there back into the crawl queue.

This works reliably in most cases. Nevertheless, the detour via rendering has weaknesses that SEOs should be aware of:

• Time delay: According to Google, a page often spends only seconds in the queue, but it can take longer. Content and links that only exist after rendering are discovered correspondingly later.

• No interaction: Google does not scroll or click. Content that only loads after a user action is not seen by Google.

• Error pages: For status codes other than 200, Google may skip rendering.

• noindex in the initial HTML: If Google encounters a noindex tag there, rendering may also be skipped. A script that removes the tag afterwards never gets a chance to run.

• Blocked resources: JavaScript files blocked via robots.txt are not executed by Google.

There is also the simple matter of failure. If a script breaks or an API responds too slowly, the page remains empty for Google while everything looks fine in your own browser.

Google itself draws a clear conclusion from this. Server-side rendering or prerendering remains a good idea, its documentation states: it makes websites faster for users and crawlers, and not all bots can execute JavaScript.

At least it is possible to check what Google has received. The URL Inspection tool in Search Console shows the rendered HTML along with a screenshot under View Crawled Page. The Rich Results Test does the same for any URL.

AI Crawlers: No JavaScript, No Second Pass

For most AI crawlers, the rendering stage is currently absent entirely. They fetch the raw HTML and work with whatever is in it. There is no queue for a later second pass.

The most important source of data is an analysis by Vercel and MERJ from December 2024. It evaluated access logs across the Vercel network, including 569 million requests from GPTBot and 370 million from Claude in a single month. The finding: none of the major AI crawlers renders JavaScript. ChatGPT and Claude do download JavaScript files (11.5% and 23.84% of their requests respectively), but do not execute them.

Little has changed since then. Search Engine Journal still lists GPTBot, ClaudeBot, PerplexityBot and CCBot as crawlers without JavaScript rendering as of April 2026. Glenn Gabe demonstrated in a case study in August 2025 what this means in practice: ChatGPT, Perplexity and Claude were simply unable to find client-side rendered content on a website.

Direct Page Retrieval Also Reads Only Raw HTML

An interesting test by Andre Alpar from June 2026 is worth noting. He gave twelve AI assistants a URL in the chat. The raw HTML contained an incorrect value; the correct one was only inserted via JavaScript.

ChatGPT, Claude, Gemini, Perplexity, Meta AI and Microsoft Copilot all returned the value from the raw HTML. Only DeepSeek, ERNIE, Qwen, Kimi and Mistral returned the correct value. Gemini was particularly surprising, reading only the raw HTML despite Google's rendering infrastructure.

The test is a snapshot with one website and one prompt per assistant. It does, however, fit the broader picture.

Why Blanket Statements Still Fall Short

"AI ignores JavaScript entirely" is a claim one often encounters. It is not quite that simple:

• Google's AI answers in search are built on the search index, which does include rendered content. The live retrieval in the Gemini chat, however, behaved differently in the test.

• Agentic browsers such as ChatGPT Atlas or Perplexity Comet are real browsers and see the finished page. They operate for an individual user, however, and do not build an index.

• Data in the HTML can be received even if it is not visibly rendered. Vercel notes that language models can, for example, read embedded JSON from the initial server response.

• Providers change their systems without announcement. What applies today may be outdated in six months.

In practice, this means: AI crawlers very likely have problems with JavaScript content, but in any individual case one cannot be certain. Assuming the worst case puts you in the right position for all systems.

The Real Problem: No Search Console for AI Crawlers

Google provides a control mechanism. URL Inspection shows in black and white what HTML Google has after rendering. For ChatGPT, Claude or Perplexity, nothing comparable exists. No provider shows website owners what its crawler actually saw at a given URL. Glenn Gabe called for exactly this as early as 2025, under the heading "AI Search Console".

Simply asking the chatbot is only partially helpful. In Alpar's test, Perplexity claimed in the chat that it could not reach the page. According to the server log, its own crawler had already fetched it with status code 200 at that point. Self-reports from assistants are not a measurement.

What remains are checks that replicate crawler behaviour:

• Check the raw HTML: The two-minute test above is the most important check. Whatever is missing there is very likely also missing for AI crawlers.

• Disable JavaScript in the browser: In Chrome DevTools, open the command menu with CTRL+SHIFT+P, type "Disable JavaScript" and reload the page. Whatever is still visible works without JavaScript.

• Fetch via curl: The command fetches the page without a browser and with a bot's user agent. This also reveals whether a firewall or CDN treats bots differently from visitors.

• Crawl without rendering: SEO crawlers such as Screaming Frog can crawl a website once without and once with JavaScript rendering. The comparison shows, across the entire site, which content and links only exist in the rendered version.

• Analyse server logs: Logs show which AI bots are fetching which URLs and what status codes they receive. It is the only place where the actual behaviour of bots becomes visible.

curl -s -A "GPTBot" https://www.example.com/page | grep -i "searched text"

If the command returns no output, the searched text is not present in the delivered HTML. One limitation remains: IP-level blocks are not detected by curl, as the request originates from your own machine.

Common Pitfalls

It is not only pure single-page applications that are affected. On traditionally built websites too, individual pieces of content can quietly disappear from the HTML. The most common cases:

• Content behind clicks: Tabs, accordions or "Show more" buttons that fetch their text from the server only on click. Content that is present in the HTML but merely collapsed via CSS is not a problem.

• Lazy loading on scroll: Infinite scroll and text blocks that only load as the user scrolls down.

• Structured data via Tag Manager: Google can process JSON-LD inserted via JavaScript. Crawlers without rendering never see it.

• Title, description and canonical via JavaScript: Google adopts the rendered values. Everyone else sees the placeholder from the shell — often the same title for every URL.

• Internal links without href: Navigation that relies solely on click events. Google only follows genuine links with an href attribute.

• Embedded widgets: Reviews, prices, availability information or job listings from third-party providers loaded via script.

• Error pages in SPAs: The router displays "Page not found" but the server responds with status code 200. The result is soft 404 errors.

Structured data and meta information inserted via JavaScript are particularly insidious. Google usually processes them correctly, so nothing appears amiss in Search Console. The problem only becomes apparent when content is missing from AI responses.

What to Do Now

For SEOs, this results in a manageable list:

1. Test page types: Check one URL per template — homepage, category, product or service page, and guide. For each, look for the H1, key body text, price, FAQ, internal links and JSON-LD.

2. Move critical content into the HTML: Main content, title, description, canonical, navigation, internal links and structured data all belong in the server response.

3. Use JavaScript for enhancements: Counters, chat widgets, personalisation and interactive elements can continue to be assembled in the browser. Vercel recommends the same approach.

4. Clarify the rendering model with development: Plan for SSR or SSG for all indexable page types. For existing SPAs, prerendering can bridge the gap until a full migration.

5. Check regularly: Re-test after every relaunch, every template change and every new tracking or consent setup.

The last point is most often overlooked in practice. Rendering problems rarely arise at launch; they emerge months later through an inconspicuous change in the frontend. The check therefore needs to be a fixed task with a named owner in every technical audit.

Conclusion

Looking at the raw HTML takes two minutes and answers a question that was long relevant only for Google: does the content arrive without JavaScript?

For Google, JavaScript is a detour with risks. For most AI crawlers, it is currently a dead end. And unlike with Google, there is no tool there to flag problems.

The conclusion is the same one Google has recommended for years: everything that needs to be found and cited belongs in the HTML the server delivers. Anyone who ensures this does not need to bet on which crawler will gain which capabilities and when.

Sources

• Understand the JavaScript SEO basics, Google Search Central, as of 4 March 2026

• Fix lazy-loaded content, Google Search Central, as of 10 December 2025

• The rise of the AI crawler, Vercel and MERJ, 17 December 2024

• AI Search and JavaScript Rendering, Glenn Gabe, 11 August 2025

• The Technical SEO Audit Needs A New Layer, Slobodan Manic in Search Engine Journal, 27 April 2026

• Do AI Assistants Actually Render Your JavaScript when Grounding?, Andre Alpar at Search Engine World, 9 June 2026