Why JavaScript Websites Are Invisible to AI Search Engines

If your website renders entirely client-side, it is practically invisible to most AI search engines. AI crawlers such as GPTBot (ChatGPT), ClaudeBot and PerplexityBot only fetch the raw HTML and do not execute any JavaScript. If your site only builds its content in the browser, those crawlers see an empty shell. In this article you will read why client side rendering is an SEO problem, why you can still show up in Google at the same time, and why server-side rendering (SSR) or static site generation (SSG) is the structural fix.

What exactly is client-side rendering?

Client-side rendering means the server sends an almost empty HTML page and JavaScript only builds the real content once it reaches the browser. The visitor first gets a bare skeleton, after which scripts load in the text, headings and links. Many single-page applications (SPAs), built with frameworks that assemble everything in the browser, work this way by default.

To a human opening the page, this is invisible: the script runs in a fraction of a second and you see a complete page. The difference lies in what an automated visitor gets. A crawler that fetches the page but does not run JavaScript is stuck on that empty skeleton. That gap between raw HTML and rendered HTML is the same Achilles heel we describe in JavaScript SEO: why Google sometimes cannot see your content, but with AI search engines the impact is harsher.

Why do AI crawlers not see my JavaScript content?

Because the major AI crawlers do not run JavaScript. They request your page, read the HTML the server returns directly, and stop there. Anything that only appears through JavaScript simply does not exist for them.

Research by Vercel into the behaviour of AI crawlers shows this clearly: none of the major AI crawlers render JavaScript. That applies to OpenAI’s bots (including GPTBot and OAI-SearchBot), to Anthropic’s ClaudeBot and to PerplexityBot. According to that same research, some of those crawlers do download your JavaScript files, but they never execute them. The result is the same: client-side rendered content never arrives.

In practice this means your product descriptions, your service pages, your case studies and your answers to frequently asked questions stay invisible to the model a potential customer is consulting. If someone asks ChatGPT or Perplexity for a supplier like you, you simply cannot be included, because the AI was never able to read your content. This is exactly the kind of technical blocker that generative engine optimization sets out to remove.

But I do rank in Google, so how is that possible?

Those two go together perfectly well, and that is precisely what makes the problem so treacherous. Googlebot is one of the few crawlers that does render JavaScript. It fetches your page, executes your scripts in a separate step, and then indexes the rendered content. A client-side site can therefore achieve solid rankings in the classic Google results.

The AI crawlers from OpenAI, Anthropic and Perplexity skip that rendering step. That creates a gap: the same page Google fully understands is a blank sheet to ChatGPT and Perplexity. So your conclusion cannot be “we rank in Google, so we are fine”. The right question is whether your content is already in the raw HTML, because that is the only version every crawler is guaranteed to see.

Note one nuance: within Google the centre of gravity is shifting too. Features such as AI overviews lean on what Googlebot can fetch, but the generative answers outside Google, in standalone AI tools, depend entirely on your raw HTML. Anyone who keeps steering on Google alone misses the part of the market that now does its research in a chat interface.

How do I check whether my site has this problem?

The quickest test takes you half a minute. Open your page, click “view page source” (the view-source, not the inspector), and search for your most important text, your H1 and your service description. If that text is not literally there, it is probably only loaded client-side and the AI crawlers do not see it.

A few additional checks:

• Compare raw and rendered HTML. If the view-source mostly shows an empty skeleton and a few script tags while the visible page is full of content, you are rendering client-side.
• Temporarily disable JavaScript in your browser settings and reload the page. If an empty or half-empty page is all that remains, an AI crawler experiences exactly the same thing.
• Look page by page, not just at your homepage. Often the difference sits precisely in the deeper service and product pages that are supposed to bring in your leads.

If you want to dig deeper into how crawlers fetch your pages and which content does or does not come through, it helps to look at your website architecture and SEO as a whole, because rendering rarely stands on its own.

How do I fix client-side rendering?

The structural fix is to stop building your most important content in the browser and instead prepare it on the server or at build time. There are roughly two routes for that.

Server-side rendering (SSR). The server assembles the full page and sends ready-made HTML to both the visitor and the crawler. No extra rendering step is needed, so nothing can go wrong in a bot’s browser. This suits sites with content that changes often or differs per user.

Static site generation (SSG). Here your pages are converted into static HTML files during the build. Every visitor, human or crawler, gets the complete page immediately. This is ideal for content that does not change by the second, such as service pages, knowledge articles and case studies, exactly the pages that matter for B2B visibility.

Both deliver the same result for AI crawlers: your content sits in the raw HTML and is therefore readable without a single line of JavaScript having to run. A pleasant side benefit is speed. Less client-side JavaScript usually means a faster first render, which also helps your Core Web Vitals. Which approach and which platform fit best depends on your situation: the volume of content, how often it changes, and how your team works. A headless CMS setup can support SSR or SSG well, but it is not a requirement. On our page about website development you can read how we make that choice case by case.

Do I have to rebuild my entire site now?

Not right away, and certainly not in a panic. Start with the pages that make money: your service pages, your most important landing pages and the content you want to be found for. If those are the ones sitting in the raw HTML, you have already covered the biggest risk. An interactive dashboard behind a login can happily stay client-side, because no AI crawler is looking for it there.

If you are planning a bigger intervention or a new site anyway, take rendering along from the start as a design choice rather than a repair afterwards. Do it during a website migration and you kill two birds with one stone: you protect your existing visibility and you make your content readable for AI engines straight away. Our stance is level-headed: steer on leads and revenue, not on an endless technical checklist. A page nobody visits and that produces no leads does not need to be rebuilt first.

To see how all of this fits into a broader build approach, read our guide to having a B2B website built.

The short summary

Client-side rendering only makes your content appear in the browser, and the major AI crawlers (GPTBot, ClaudeBot, PerplexityBot) do not run JavaScript. As a result you can rank comfortably in Google and be completely absent from ChatGPT, Claude and Perplexity. The fix is to put your most important content in the raw HTML through server-side rendering or static site generation, starting with the pages that generate leads. That way humans, search engines and AI all read the same complete page.

Want to know whether your site is visible to AI search engines and what a sensible rendering approach looks like in your case? Book your free intake and we will look together at where you stand today.