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

The short, honest answer for 2026 goes like this: Google can render JavaScript, but it does so late and at its own cost — and most AI crawlers don't do it at all. Vercel's study of hundreds of millions of requests showed that GPTBot, ClaudeBot and PerplexityBot fetch JavaScript files but never execute them. If the key content of your site is built only in the browser, then for ChatGPT, Claude and Perplexity that content does not exist. In an era where more and more research starts with a question to a model, an "empty HTML shell" has stopped being a purely technical problem — it's a business visibility problem.

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.

This guide shows how bots really process JavaScript, how to check in 5 minutes what they see on your site, and how to pick 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.

The practical takeaway: even in the "friendly" Google scenario, JavaScript-dependent content gets indexed later and less reliably than content present in the raw HTML.

AI crawlers don't execute JavaScript — and that won't change soon

Here the theory from Google's docs ends and the new reality begins. Vercel analyzed AI bot traffic across its infrastructure (hundreds of millions of requests a month) and the conclusions are unambiguous:

• 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.

The consequences are brutal for classic SPAs: 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.

The good news: it's 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 sane default split for 2026: any 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

You don't have to take anyone's word for it — check:

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

Audits show the same problems over and over — the same seven sins:

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

Proof you can solve this without throwing the app away is 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
• 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