Is Your React Website Invisible to AI Search? How to Check in 30 Seconds

If your website was built as a single-page application, there is a good chance that large parts of the web cannot read it. Not because it is blocked, and not because it is slow, but because the HTML your server sends contains no content at all.

What actually gets sent to a crawler

A client-rendered app ships a near-empty HTML shell plus a JavaScript bundle. The browser downloads the bundle, runs it, and builds the page. A human sees a complete site and assumes that is what everyone gets.

A crawler that does not execute JavaScript sees the shell. Typically that is a couple of hundred bytes containing <div id="root"></div> and a script tag. No headings, no copy, no links.

Which crawlers run JavaScript?

Googlebot does, which is why sites like this can still rank in Google. Rendering happens in a second pass and can lag the initial crawl, but it happens.

The AI answer engines are a different story. GPTBot, ClaudeBot, PerplexityBot and CCBot fetch raw HTML. So do most link preview generators, which is why a client-rendered site often produces a blank card when shared on LinkedIn, Slack or WhatsApp — the same root cause, showing up somewhere more visible.

The 30-second test

Right-click your homepage and choose View Page Source. Do not use Inspect Element — the inspector shows the live DOM after JavaScript has run, which is exactly the difference you are trying to measure.

Search that source for a sentence you can see on the page. If it is not there, neither is it there for any crawler that does not run a browser. Repeat on a deep page, such as a service or product page, because those are usually the ones you most want quoted.

What we found on our own site

We ran this on digova.ca and every route returned zero words of body content. The per-page titles, meta descriptions and structured data were all injected by JavaScript too, so those were invisible as well.

After adding a prerender step to the build, the same URLs served 350 to 730 words of real HTML each, with their titles, canonicals and JSON-LD present in the first response. Nothing about the visible site changed. The difference was entirely in what a machine receives before any JavaScript runs.

Prerendering, server-side rendering, or a rewrite?

There are three common routes, and the right one depends on how much your content changes.

• Prerendering at build time. Render each route to static HTML during the build. Best for marketing sites and portfolios where content changes on deploy. No server runtime required, and it works on plain shared hosting.
• Server-side rendering. Render each request on the server. Right when content is dynamic or personalised. Needs a Node runtime and more operational care.
• Static site generation with a framework. Astro, Next.js or similar, if you are prepared to rebuild rather than retrofit.

For most small business sites, prerendering is the pragmatic answer. It is a build step rather than an architecture change, and it produces exactly what crawlers want.

One thing to watch after you fix it

Prerendered pages are static files with hashed asset names that change on every deploy. Make sure your host serves a missing asset as a genuine 404 rather than falling back to your index page — a fallback returns HTTP 200 with HTML under a .js URL, which browsers and CDNs will cache and then refuse to execute. We have written about that failure mode because we hit it ourselves.

Digova builds and rebuilds websites for businesses across Toronto and the GTA, including performance and search work on existing sites.