JavaScript SEO — What Googlebot and AI Crawlers Really See Without Rendering

Google has been rendering JavaScript for close to a decade, and well enough that the topic dropped off most teams' priority lists. It's coming back from a different direction. Vercel analyzed AI bot traffic on its own infrastructure — hundreds of millions of requests — and found that GPTBot, ClaudeBot and PerplexityBot fetch JavaScript files but never execute them. Content that only comes into being in the browser doesn't exist for ChatGPT, Claude or Perplexity. A React or Vue site can rank perfectly well in Google and be entirely absent from model answers at the same time — because all the AI engines see of it is an empty container and a loader.

Googlebot renders JavaScript — late and at its own cost. Most AI crawlers never render it at all: Vercel's study showed GPTBot, ClaudeBot and PerplexityBot fetch JS files but don't execute them. How to check in 5 minutes what bots really see, how CSR differs from SSR/SSG/ISR, and how to fix an SPA without rewriting the whole app.

Below I cover how Google actually processes JavaScript, how to check what bots see on a given page, and how to choose a rendering strategy (CSR/SSR/SSG/ISR) — without rewriting the whole application.

How Google processes JavaScript — three stages instead of one

For a plain HTML page the process is simple: Googlebot fetches the document and passes it to indexing. For a JavaScript-driven page there's a third, expensive stage — rendering:

Googlebot first fetches the raw HTML and indexes whatever it finds there. The page then enters the render queue — the Web Rendering Service, in practice an evergreen Chromium that executes JavaScript and builds the full DOM. Only that rendered HTML goes back to indexing. Google says the median wait is short, but the queue is shared and prioritized: on large sites the delay can grow to hours or even days. Rendering is also simply expensive — and it counts against your crawl budget, so a site that forces every page through a from-scratch render is throttling its own indexing.

In practice: even at Google, which can render, JavaScript-dependent content gets indexed later and less reliably than content present in the raw HTML.

AI crawlers don't execute JavaScript

Where Google built an entire infrastructure for rendering, the AI providers took the shortcut. Vercel's numbers leave little room for interpretation:

• GPTBot and OAI-SearchBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot — they fetch JS files but never execute them. They see only what the server returns in the first HTML response.
• Gemini uses Googlebot's infrastructure (WRS), so it's the only major player that gets rendered content.
• Bingbot (powering Copilot) claims limited rendering — in practice, don't rely on it.

For a classic SPA the arithmetic is simple: a React/Vue/Angular app that returns an empty div to bots and builds content client-side is invisible to AI search engines. The same applies to anything injected via JavaScript: meta tags, canonicals and Schema.org structured data — if the browser adds them, AI bots will never see them. And since models can't see the content, there's nothing to cite — your whole strategy for getting cited in ChatGPT starts with rendering.

CSR, SSR, SSG, ISR — which strategy to choose

The four rendering strategies differ in one thing: who builds the HTML, and when.

This is not an all-or-nothing choice. Modern frameworks (Next.js, Nuxt, Astro, SvelteKit) let you mix strategies per template: the blog as SSG, product pages as ISR, the cart as CSR. A sensible default split: public content you care about in search — HTML from the server; interactions — JavaScript. Hydration (attaching interactivity to ready HTML) doesn't hurt SEO as long as the HTML is complete before JavaScript kicks in.

The 5-minute test: what does the bot actually see

Rather than trust the framework's documentation, check it on your own site:

1. 1.Disable JavaScript in DevTools (Ctrl+Shift+P → "Disable JavaScript") and reload. What you see is the AI-bot version of your site. Missing content, prices, descriptions? You have a problem.
2. 2.Compare view-source with the DOM. "View page source" is the raw HTML (everyone sees it); the Elements tab is the DOM after JavaScript (mainly Google sees it — after rendering).
3. 3.Fetch the page like a bot. One terminal command shows whether a key phrase is in the server's first response:

# Is the offer title in the raw HTML?curl -s -A "GPTBot" https://yoursite.com/services | grep -i "service name"# How many characters of content does the server return without JS?curl -s https://yoursite.com/ | wc -c

1. 1.URL Inspection in Google Search Console. See the rendered HTML and a screenshot through Googlebot's eyes — differences against your browser are a warning sign. If the page looks fine in GSC but is empty in the no-JS test, it means: Google will cope, AI bots won't.

Seven common SPA mistakes

The same mistakes recur in audits — regularly enough to list from memory:

1. 1.Content only after interaction. Tabs, accordions and sections loaded on click don't exist for bots. Content should be in the DOM immediately (it can be visually collapsed).
2. 2.Infinite scroll without pagination. Bots don't scroll. Without classic links to further pages, products from "later screens" are unreachable.
3. 3.Client-side metadata. Title, description and canonical injected with JavaScript — AI bots won't see them, and Google may index the pre-swap version.
4. 4.Schema.org appended in the browser. Structured data must be in the server HTML — otherwise you lose the ~3× higher AI citability it provides.
5. 5.JS/CSS files blocked in robots.txt. Google can't render your page if you've blocked its resources. I cover the access audit in the post on AI crawlers and robots.txt.
6. 6.Lazy-loading without a fallback. Images and content loaded exclusively via scroll events (without native loading="lazy" or noscript) don't exist for bots.
7. 7.Soft 404s. The SPA returns status 200 for non-existent URLs and renders "not found" client-side. Bots index junk or — worse — duplicates.

Our case: Smart SPA Fallback at PozyczkoBank

We faced exactly this problem on the PozyczkoBank project: the site ran as an SPA, so for bots it was effectively empty. Instead of an expensive rewrite we deployed a Smart SPA Fallback architecture — bots and first visits get full, server-rendered HTML, while the user gets the same app as before once hydration completes. The result: content (including articles generated automatically by a Gemini pipeline) is indexable from the first request, with no change to the user experience.

The fix plan, step by step

1. 1.Inventory templates, not individual pages: home, category, product/service page, blog post, static page.
2. 2.Test each template without JavaScript (methods above) and label it: full content / partial / empty shell.
3. 3.Prioritize by revenue. Templates that earn money first: the offer, product pages, traffic-driving content.
4. 4.Pick a strategy per template: stable content → SSG, frequently changing → ISR/SSR, customer dashboard → stays CSR.
5. 5.Move metadata and schema to the server — title, description, canonical, JSON-LD in the first HTML response.
6. 6.Verify the result: URL Inspection in GSC, the curl test, and after a few weeks — crawl stats and server logs.
7. 7.Watch performance. SSR usually improves LCP, but hydration can wreck INP — after rollout check your Core Web Vitals.

---

I design rendering architectures for sites and apps that are fast for people and readable for bots, and I run rendering audits as part of technical SEO. Get in touch — the first step is checking what Google and AI crawlers really see on your site.

Worth reading next:

• AI crawlers — who scans your site and how to manage it
• AI Browsers and Agent Experience (AX) — can an agent use your site?
• Core Web Vitals — how to improve LCP, INP and CLS
• Crawl budget — how Google indexes a large site
• Schema.org structured data — the complete guide