Why a website built only in JavaScript is invisible to AI, and how to tell if yours is

Which AI crawlers can’t read JavaScript?

The best measurement comes from Vercel, a web hosting company, and its research partner MERJ. Studying crawler traffic across Vercel’s network, they found that none of the major AI crawlers ran JavaScript. That covers OpenAI’s three crawlers (OAI-SearchBot, ChatGPT-User and GPTBot), Anthropic’s ClaudeBot, PerplexityBot, and the crawlers from Meta and ByteDance (Vercel and MERJ, The rise of the AI crawler, 17 Dec 2024).

ChatGPT’s and Claude’s crawlers downloaded script files and never ran them. In Vercel’s words: “They can’t read client-side rendered content.” Two crawlers did run scripts: Google’s, which Gemini shares, and Apple’s AppleBot (Vercel and MERJ).

That study is from late 2024, and the crawler pages from OpenAI, Anthropic and Perplexity still don’t say whether their crawlers run JavaScript (OpenAI, Overview of OpenAI crawlers; Anthropic, Does Anthropic crawl data from the web?; Perplexity, Perplexity crawlers). Until one of them says otherwise, we build for crawlers that don’t run scripts.

Why can Google read my site when ChatGPT can’t?

Google crawls a page, then queues it for rendering: a browser with no screen opens the page and runs its JavaScript, and Google indexes the result. Google says a page “may stay on this queue for a few seconds, but it can take longer than that” (Google Search Central, Understand JavaScript SEO basics, 4 Mar 2026).

Mostly, it works. In an earlier study on nextjs.org, published in July 2024, Vercel and MERJ found Google rendered every HTML page it crawled, half of them within 10 seconds and the slowest 1 in 100 after about 18 hours (Vercel and MERJ, How Google handles JavaScript throughout the indexing process, 31 Jul 2024).

It has limits. Google Search doesn’t click or scroll on your page, so text that loads only after a visitor acts stays unseen (Google Search Central, Fix lazy-loaded website content, 10 Dec 2025). And Google itself calls server-side rendering or pre-rendering “still a great idea”, partly because “not all bots can run JavaScript” (Google Search Central, Understand JavaScript SEO basics).

So a good Google ranking shows that Google can read your page. The crawlers Vercel tested for ChatGPT, Claude and Perplexity read the raw file.

How does a website end up with empty HTML?

Google calls the pattern the app shell model, where “the initial HTML does not contain the actual content” and JavaScript adds it afterwards (Google Search Central). It’s how a single-page app works: the browser gets one nearly empty file and a script, and the script draws every page.

The starter template for React apps made with Vite, a popular build tool, shows it. The visible part of the page is one empty box, <div id="root"></div>, and a script, and nothing else (Vite, React starter template, index.html). The older Create React App template adds one line: “You need to enable JavaScript to run this app.” (Create React App, starter template, index.html). If your page’s code looks like that, a crawler that can’t run scripts gets the title and little else.

Site builders vary, and they change. Lovable, an AI app builder, says it pre-renders its older React and Vite apps for verified search and AI crawlers, and renders apps made since 13 May 2026 on the server (Lovable Documentation, Optimize your app for SEO and AI search). A custom-coded site may have neither, so test the page itself, whatever built it.

How can I tell if my website is affected?

You need Chrome on a computer and about a minute.

1. Open the page that matters most, such as your main service page. Pick three or four words a customer needs, like a service name or the areas you cover. Skip apostrophes, because the code can store punctuation differently.

2. Press Ctrl+U on Windows, or ⌘+Option+U on a Mac. A new tab opens with the page’s HTML, the file your server sends (Chrome Help, Chrome keyboard shortcuts). That file is what Vercel found the ChatGPT, Claude and Perplexity crawlers read.

3. Press Ctrl+F, or ⌘+F on a Mac, and type your phrase. If Chrome finds it, those crawlers can read it. If it finds nothing, a script adds that text after the page loads.

4. To see the whole page their way, go back to it and open Developer Tools with F12, or ⌘+Option+I on a Mac. Press Ctrl+Shift+P (⌘+Shift+P on a Mac), type “javascript”, choose Disable JavaScript, press Enter, and reload the page. JavaScript stays off in that tab until you close Developer Tools (Chrome DevTools, Disable JavaScript).

What the result means

• Your words are all there. Crawlers can read the page, so work through the other causes in our guide to why AI assistants don’t recommend your business.
• You see a blank page, a loading spinner, or only the menu and footer. A crawler that can’t run scripts has nothing to quote, so fix this first.
• The heading is there, but prices, service details or reviews are missing. A script draws those parts. Move the ones customers ask about into the HTML.

One case this test misses: some platforms send crawlers a separate, pre-rendered copy, and Lovable says outside checks still get “the regular single-page app” (Lovable Documentation). If your platform says it does this, ask it how to view the copy crawlers get.

How do you fix a JavaScript-only website?

The aim is a server that sends every word. Scripts can still add extras: Vercel suggests keeping them for “non-essential dynamic elements” such as live chat widgets and social media feeds (Vercel and MERJ).

There are three standard ways to get there, defined in Google’s web.dev guide (Addy Osmani and Jason Miller, Rendering on the Web, web.dev, updated 5 Jan 2026). Each is a job for whoever built your site.

• Server-side rendering builds the full HTML on the server each time someone asks for a page. It suits pages that change by the minute, such as stock levels.
• Static rendering builds every page as a finished HTML file ahead of time. Most business sites change their services and prices a few times a year, so this is where we’d start.
• Pre-rendering runs your existing app once, when the site is built, and saves each page as HTML. It’s the least rework for a site that’s already a single-page app.

Avoid serving one version to people and another to bots. Google calls that dynamic rendering, “a workaround and not a long-term solution”, and recommends server-side rendering, static rendering or hydration instead (Google Search Central, Dynamic rendering as a workaround, 10 Dec 2025).

When the fix is live, run the test again on each key page. Every phrase a customer needs should turn up in the code. That’s how we build every site.