Can SI crawlers see JavaScript-rendered content?

Most major SI crawlers cannot see JavaScript-rendered content; bots such as GPTBot, ClaudeBot and PerplexityBot read the raw HTML the server sends and never see the content that builds later in the browser. The Vercel and MERJ analysis published in December 2024, based on real crawler traffic, concluded that none of the major SI crawlers execute JavaScript. These bots sometimes download JavaScript files, but they do not run them. As of mid-2026, none of these companies has publicly documented adding JavaScript rendering to their crawlers. The exception is Google’s products such as Gemini and AI Overviews, which benefit from the rendering infrastructure Googlebot has used for years. This means a page that ranks well in Google can be an empty shell to ChatGPT, Claude or Perplexity. In this guide, we look at how bots see pages differently from browsers, how you can test your pages and which content components are most at risk.

How do SI crawlers see a page differently from a browser?

SI crawlers see a page as it was before the browser executed JavaScript and built the content, in other words as the HTML the server sent in its first response. When a user opens a page, the browser loads the HTML, then runs the JavaScript files, fetches data from APIs and places the product description, reviews or price on the page. The user ends up seeing a complete page. A bot that does not execute JavaScript sees only the first step of this process.

In client-side rendered single-page applications, that first step is often little more than an almost empty frame: a menu, an empty container and a series of script tags. The headline, body copy, product information and even structured data are never recorded by the bot, because they are created after the script runs. Because Googlebot can queue and process these pages for rendering, no problem may appear on the Google side. This is why the problem is usually noticed late; teams see that everything looks fine in Search Console, while the page never appears among ChatGPT’s or Perplexity’s sources.

Which bots execute JavaScript and which do not?

Among SI-related bots, the main crawlers that render JavaScript are Googlebot and Applebot; the SI companies’ own crawlers make do with raw HTML. The Vercel and MERJ analysis found that GPTBot downloaded JavaScript files in about 11.5 percent of its requests and ClaudeBot in about 23.8 percent, but neither executed those files. This shows that the files are collected as content, but the page is not rendered.

The status in the table is based on the late-2024 analysis and documentation published by these companies up to mid-2026. One of these companies may add rendering in the future, but for now the safe assumption is that critical content needs to be in the raw HTML. Microsoft Copilot relies on Bing’s infrastructure and therefore on Bing’s rendering capacity, so it is useful to check separately how Bing sees the page through Bing Webmaster Tools.

How do you test what your page shows in raw HTML?

The fastest way to test what a page shows in raw HTML is to view the page source and search for a sentence from the main content. The elements panel in the browser’s developer tools shows the page after JavaScript has run, so it is misleading for this test. The page source shows the server’s first response and is much closer to what bots see.

For a more thorough test, the following steps can be followed:

1. Check the page source: Search for a sentence from the product description, the price and a review. If you cannot find them, that content is being built on the client side.
2. Open the page with JavaScript disabled: Disable JavaScript in the browser settings and reload the page. What you see is close to what bots see.
3. Send a request from the command line with a bot identity: Use a tool such as curl to fetch the page with the GPTBot or OAI-SearchBot user agent and check whether the content is in the response. This test also shows whether some servers respond differently to bots.
4. Search for structured data separately: Search the raw HTML for “application/ld+json” and confirm that product, price and review information sits in that block.
5. Test by template: Test one example from each template, such as the homepage, category, product, blog and help pages; problems are usually concentrated in specific templates.

Which content components are most at risk?

The content components most at risk are the sections loaded after the page loads, through an API call or user interaction. Even when a page’s main template is built on the server, it is very common for some critical components to be added later on the client side. This leaves the most valuable information missing even though most of the page is visible.

In practice, the risky components encountered most often are:

• Third-party review widgets: Product reviews and ratings are often loaded with JavaScript from an external service; the strongest social proof is missing from the raw HTML.
• Tab and accordion content: If technical specifications or FAQs load only when a user clicks a tab, the bot does not see this content.
• Dynamic price and stock information: Fetching the price or stock status from an API after the page loads causes bots to see the product without a price.
• Lists loaded with infinite scroll: On category pages, products that appear after the first screen are not discovered by bots if there is no pagination link.
• Personalised content blocks: Recommendation areas that change per user are usually built on the client side and appear empty to bots.

Is structured data added through a tag manager visible?

Structured data added through a tag manager is not visible to bots that do not execute JavaScript. Many brands add product, FAQ or organisation markup to pages through tools such as Google Tag Manager because it requires no development resources. Because Googlebot can read this markup during rendering, everything looks correct in Google’s testing tools. But because the same markup is not in the raw HTML, it does not exist for GPTBot, ClaudeBot or PerplexityBot. The lasting fix is to generate structured data on the server side as part of the page template.

How do you choose between SSR, pre-rendering and hybrid approaches?

The right approach is chosen based on the site’s technical infrastructure, how often content changes and development resources; the shared goal is for critical content to be in the first HTML response. Server-side rendering (SSR) builds the complete page on the server for every request and is the most reliable method for frequently changing information such as price and stock. Frameworks such as Next.js, Nuxt and Angular support this approach natively.

Static generation or pre-rendering means building pages as HTML in advance and serving them, and it is an efficient solution for content that changes infrequently, such as blog posts, guides and category descriptions. If a full architectural change is not possible, a hybrid approach can be adopted: the page skeleton, headline, main copy, price and structured data are generated on the server, while filters and interactive components remain on the client side. Dynamic rendering solutions that show bots different content from users can be used as a temporary bridge, but because the two versions risk drifting apart over time, they should not be seen as a long-term solution. Whichever method is chosen, the content shown to bots and to users must be the same.

How is the impact of a rendering fix measured?

The impact of a rendering fix is measured first by how often bots visit the fixed pages in server logs, and then by whether these pages begin to appear as sources in SI answers. Once the fix goes live, the first signal is search-focused bots such as OAI-SearchBot and PerplexityBot returning to these pages. The second signal is the pages beginning to be cited in SI answers for relevant queries.

In the technical audit stage of its GEO consulting process, Webtures applies template-based raw HTML tests as a standard step and uses them to uncover the rendering issues behind pages that are visible in Google but not cited on other SI platforms. When the questions these pages target are tracked before and after the fix with a GEO tool such as Brantial, the impact of a technical change on visibility in ChatGPT, Perplexity and Claude answers can be compared concretely. This comparison also makes prioritisation easier for the development team, since data can show which template’s fix brings the greatest visibility gain.