SPA Sites Visible to Google But Invisible to AI

Googlebot, Bingbot, and Applebot adopted evergreen Chromium/Edge/WebKit rendering between 2019 and 2020 and officially support JavaScript execution. However, the official documentation for GPTBot, ClaudeBot, and PerplexityBot does not state whether JS is executed. SPA (CSR) content that isn't in the first-paint HTML is likely invisible to these AI crawlers.

Observation: An LP With Only ~28KB of HTML

We fetched the raw HTML returned by the server for a landing page built with a Japanese no-code SPA service. The response was only ~28KB, and the `<body>` was essentially empty — no copy, headings, images, or internal links. The content is rendered entirely on the client after JavaScript execution: a textbook CSR (Client-Side Rendering) setup.

Observed facts

•Initial server HTML is ~28KB with effectively zero visible body text
•Spoofing the Googlebot user agent returns the identical HTML — no Dynamic Rendering
•No JSON-LD structured data is implemented anywhere
•Only 6 URLs are registered in the sitemap (3 of which are form-related)

When this site is audited by CodeQuest.work SEO, content-side checks (body length, H1, internal links, image alt) all score near zero. The audit is technically correct, but it may diverge from how Google actually sees the page. Why does this divergence occur, and does the same divergence apply to AI crawlers? That's where this investigation begins.

The SEO Crawlers Have Already Evolved

'SPAs are bad for SEO' has been a popular notion since around 2015, but the major SEO crawlers have evolved significantly over the past five years. Aligning the official statements from the three vendors shows that JavaScript rendering is now effectively standard.

Googlebot: evergreen Chromium (since May 2019)

Google's official JavaScript SEO Basics states: "Google Search runs JavaScript with an evergreen version of Chromium." This is a two-stage indexing model — after crawl/fetch, a headless Chromium renders the page once resources are available.

Source: developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

Bingbot: Microsoft Edge = Chromium (since October 2019)

Bing's official blog: "By adopting Microsoft Edge, Bingbot will now render all web pages using the same underlying web platform technology already used today by Googlebot, Google Chrome, and other Chromium-based browsers." Effectively equivalent rendering power to Googlebot.

Source: blogs.bing.com/webmaster/october-2019/The-new-evergreen-Bingbot

Applebot: WebKit (Safari-compatible)

Apple's About Applebot states: "Applebot may render the content of your website within a browser. If JavaScript, CSS, and other resources are blocked via robots.txt, it may not be able to render the content properly." Renders via Safari-compatible WebKit for Apple Intelligence, Siri, and Spotlight.

Source: support.apple.com/en-us/119829

From a pure SEO (organic search) standpoint, SPAs can be read by the three major crawlers. The real problem lies one layer deeper.

AI Crawlers: 'Not Officially Stated'

We reviewed the official documentation for the major AI crawlers. None of them clearly state whether they execute JavaScript. The official position is neither 'we do' nor 'we don't' — it's simply absent.

Crawler	Purpose	Official JS execution statement
GPTBot	OpenAI model training	Not stated
OAI-SearchBot	ChatGPT Search indexing	Not stated
ChatGPT-User	Real-time fetch on user request	Not stated
ClaudeBot	Anthropic model training	Not stated
Claude-User	Fetch on Claude user request	Not stated
Claude-SearchBot	Claude search quality	Not stated
PerplexityBot	Perplexity search indexing	Not stated
Perplexity-User	Real-time on user query	Not stated

By contrast, each SEO crawler's documentation explicitly says it uses Chromium / Edge / WebKit to execute JavaScript. That only the AI crawlers omit this isn't coincidence — it reads more naturally as a structural choice.

Sources: OpenAI Bots / Anthropic Crawlers / Perplexity Crawlers

How to Interpret 'Not Stated'

Since it isn't officially stated, we can't conclude that JS is not executed. But assuming it is also lacks evidence. Let's separate facts from inference.

Facts (from official documentation)

•None of GPTBot, ClaudeBot, or PerplexityBot officially document their rendering engine
•Their User-Agent strings don't include browser version tokens like 'Chrome/W.X.Y.Z'
•Googlebot and Bingbot publicly announced 'we adopted Chromium/Edge to run JS' in 2019 — the opposite transparency posture

Inference (not assertion)

•Headless browsers cost tens of times more per request than plain HTML fetches. Running JS on every URL during large-scale training-data crawls isn't economically realistic
•User-request fetches (ChatGPT-User, Perplexity-User) are inherently real-time and may be more likely to render JS — but again, not officially stated
•If training crawlers did run JS, declaring it (as SEO crawlers did) would be operationally helpful — reduced error logs, easier WAF whitelisting. Not declaring it leans toward 'not running JS' as the more plausible reading

We don't conclude that AI crawlers don't execute JS. We treat it as: 'It isn't officially stated, and cost structure plus operational transparency signals lean toward no-JS.' Operationally, the safer choice is not to tolerate this uncertainty.

Google's Two-Stage Indexing Isn't a Full Rescue Either

The 'Googlebot will render it' argument has two caveats. Both are documented officially.

Caveat 1: Rendering happens 'when resources allow'

Google official: "Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript." Rendering is not immediate; it's queued. New pages get indexed slower; frequent updates don't propagate as expected.

Caveat 2: Dynamic Rendering was officially deprecated

Google official: "Dynamic rendering is a workaround and not a long-term solution for problems with JavaScript-generated content in search engines." The 2018-era approach of serving SSR HTML only to bots is now officially legacy. The modern solution is SSR / SSG / Hydration.

Source: developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering

Even Google's posture is 'we'll render and index, but not immediately.' For media sites publishing frequently, CSR means accepting that new articles may be indexed days or weeks late.

Three Ways to Check If Your Site Is 'Visible to AI'

You can verify what each crawler sees without specialized tools. Three checks in priority order.

Search Console 'URL Inspection' → 'Test Live URL'

The only official way to see Google's post-render HTML and screenshot. Compare 'HTML' tab (rendered output) and 'Screenshot' tab. If body content is missing from the screenshot, even Googlebot's second stage is failing.

Switch User-Agent with curl and compare HTML

Run `curl -A "Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)" https://example.com/` to get the same initial HTML an AI crawler would receive. If the body lacks visible text, non-JS crawlers very likely can't see it.

Use 'site:' search to observe actual snippets

Search `site:example.com` on Google and check whether snippets pull from body content. If snippets are filled by title/description only without body excerpts, Google likely struggled to access the rendered body.

Options: SSR / SSG / Hydration

Options for moving from CSR-only to 'visible to AI' as well. Dynamic Rendering is excluded since Google deprecated it.

Approach	Suited for	AI visibility
SSR (Server-Side Rendering)	Frequently updated or personalized media/apps	High
SSG (Static Site Generation)	LPs, blogs, documentation — moderate update frequency	High
Hydration (SSR + client rehydration)	Interactive apps that also need fast first paint	High
Prerendering	Minimal change on top of an existing SPA	Medium
Dynamic Rendering	Deprecated by Google. Don't adopt for new builds	Avoid

Modern stacks: Next.js App Router (SSR/SSG/ISR), Nuxt (SSR), Astro (SSG-first), SvelteKit (SSR). If rewriting an existing Vue/React SPA is too costly, prerendering the key pages — putting body content in the first-paint HTML — is the realistic compromise.

If you're using a no-code SPA service, its templates may be hard-locked to CSR with no user-facing rendering option. In that case, your remaining lever is usually requesting SSR/SSG support through the vendor's feedback channel.

How to Read CodeQuest.work SEO Audit for SPAs

CodeQuest.work SEO runs on Cloudflare Workers and audits the initial HTML directly — it does not execute JavaScript. This mirrors what Bingbot's first hop and (very likely) AI crawlers see.

How to read it as a signal

Body length, H1, internal links, image count all near zero → likely a CSR setup. If audit says 'everything is zero' on an SPA, the audit is technically correct but it's not what Google sees post-render
But that 'near-zero' visibility is exactly what AI crawlers, Bingbot stage one, OGP crawlers, and Twitter bots see. The low SEO score reflects real AIO/GEO risk, not a tool limitation
Even on CSR sites, you can still ship JSON-LD, meta description, and canonical in the initial HTML. These don't require leaving CSR, so they're the highest-priority minimum for AIO/GEO

Audit results should be read as 'signals,' not absolute benchmarks. The low score on an SPA is expected — but that same low score honestly reflects what AI crawlers can see. Reframe it that way and the next move becomes obvious.

Audit Your Site's Initial HTML

Enter a URL to audit the initial HTML (pre-JavaScript) across 45 items. If body, H1, and links score near zero, your site likely uses CSR and may be invisible to AI crawlers.

Written by

今井政和

SEO Director / Frontend Developer

SEO Director with 20+ years of web industry experience. Creator of CodeQuest.work SEO and the official WordPress plugin "ORECTIC SEO CHECK." Author of a book on web strategy inspired by Edo-era merchant principles.

@imai_director

FAQ

If SEO crawlers can run JS, isn't an SPA fine?▾

If your only goal is organic traffic from Google, Bing, and Apple, yes. But Google's two-stage indexing introduces multi-day delays for new pages. More importantly, the AI crawlers don't officially declare JS execution, so you likely lose citation opportunities from ChatGPT, Claude, and Perplexity. The difficulty of SPA design today is that the SEO risk and the AIO risk diverge in magnitude.

If AI crawlers don't officially say they don't run JS, could they actually run it?▾

Possibly — and we don't claim they definitely don't. But SEO crawlers publicly announced their Chromium/Edge/WebKit adoption, while AI crawlers haven't matched that transparency. Headless browsers also cost tens of times more per request than plain fetches, making JS execution economically hard to justify at training-crawl scale. The pragmatic call is: 'uncertain, but betting on no-JS is safer operationally.'

Why was Dynamic Rendering deprecated?▾

Google's documentation explicitly says: 'Dynamic rendering is a workaround and not a long-term solution.' Serving different HTML to bots versus users sits dangerously close to cloaking, the operational overhead is high, and SSR/Hydration provided a fundamental alternative. Don't adopt it for new builds, and migrate to SSR/SSG/prerendering if you currently rely on it.

What's the difference between prerendering and SSG?▾

Prerendering bolts onto an existing SPA: at build time you run a headless browser, snapshot the HTML, and serve those snapshots. Services like Prerender.io or custom Puppeteer pipelines are typical. SSG (Static Site Generation) is a framework-native feature in Next.js, Astro, etc., where HTML is generated at build time as part of the integrated rendering model. Prerendering = retrofit; SSG = first-class.

If migrating an existing SPA to SSR isn't worth the cost, what's the minimum?▾

While staying on CSR, you can still place three things in the initial HTML: (1) JSON-LD structured data (Article, Organization, BreadcrumbList, etc.), (2) basic meta tags — title, meta description, canonical, OGP, (3) robots.txt / sitemap.xml / llms.txt. None of these require JS rendering. Even without rendering body content, having this meta-layer information present in the initial HTML measurably changes AIO citation rates.

AI Search10 min

How to Optimize for AI Overview (AIO) | Practical Guide to Getting Cited

A practical guide to getting your site cited in Google AI Overview (AIO). Covers the four pillars — structured data, heading structure, direct answers, and E-E-A-T — plus how to audit with a free SEO tool.

AI Search6 min

How to Create llms.txt | Format and Deployment Guide for AI Search

Step-by-step guide to write and deploy llms.txt. Google officially states it's not required for its AI search; other vendors haven't made formal statements. A low-cost forward-looking measure for the AI search era.

SEO Lab10 min

Is llms.txt Really Unnecessary? | The Correct Reading of Google's Official Statement and Logical Gaps

Claims that 'llms.txt was unnecessary' are spreading. Google did officially say it's not needed — but only for its generative AI search. We analyze the correct reading of the statement, three logical gaps in the unnecessary argument, and contradictions like observed ChatGPT crawler access and Google deploying llms.txt on its own sites.