Your JavaScript-heavy site has two indexing problems. Only one of them is the one you've been worrying about.
The first is Googlebot's rendering queue. Google can execute JavaScript through headless Chromium. It doesn't happen inline with the crawl. Pages sit in a rendering queue for "several seconds or longer" before Google processes their JavaScript. For large sites, that delay compounds. The second problem is newer and worse: AI crawlers like GPTBot, ClaudeBot, and PerplexityBot can't execute JavaScript at all. They see your initial HTML response and nothing else. With AI search traffic growing 740% in 12 months, that's not a niche concern anymore.
Googlebot's Two-Queue Architecture
Google processes JavaScript pages in three distinct phases: crawl, render, index. The crawl phase fetches your HTML. The render phase executes JavaScript in a headless Chromium instance. The index phase evaluates the rendered content for search. Critically, rendering happens in a separate queue from crawling. Your page gets crawled, then waits, then gets rendered, then gets indexed.
Botify puts it well: if crawl budget is opening the envelope, render budget is reading the letter. You can have a healthy crawl rate and still suffer indexing gaps because Google's rendering capacity is the bottleneck.
This is why client-side React apps show 'Discovered, currently not indexed' in Search Console. They're not being ignored; they're stuck in rendering purgatory. Google found the URL, put it in the rendering queue, and hasn't gotten around to executing the JavaScript yet. For a 500-page marketing site, this might clear in hours. For a 2-million-page e-commerce catalog, the backlog is real.
The rendering queue also means Google is evaluating a snapshot of your JavaScript execution, not a live page. Content loaded via scroll events, user interactions, or delayed API calls won't exist in that snapshot. Shadow DOM content must render visibly. Lazy-loaded content below the fold may never enter the index at all.
AI Crawlers Don't Queue JavaScript—They Skip It
Googlebot's rendering delay is a performance problem. AI crawlers present a capability gap.
GPTBot, ClaudeBot, and PerplexityBot don't run a headless browser. They fetch your HTML, read it, and move on. If your content, structured data, or navigation depends on JavaScript execution, these crawlers see an empty shell. This isn't a queue delay they'll eventually work through. They will never see your client-rendered content.
This has a specific downstream effect worth calling out: structured data injected via JavaScript is invisible to AI crawlers. If your JSON-LD is rendered client-side, you lose not just AI search traffic but also the rich citation features that drive click-through from AI answer engines. Our AEO guide covers the optimization side, but none of that matters if the crawler can't read your markup in the first place.
Our read: the standard advice of 'Google can render JavaScript, so it's fine' was already incomplete. In 2026, it's actively misleading. You're optimizing for one crawler while being invisible to the fastest-growing traffic channel.
Framework Mistakes That Compound the Delay
Some JavaScript SEO problems are architectural. Others are just bugs. Search Engine Land documented a case where invalid dynamic routes using placeholder segments (like /::/) created thousands of URLs stuck in 'Discovered, currently not indexed.' The site was generating URLs that Google could find but couldn't meaningfully render.
A few patterns that consistently cause trouble:
Hash-based routing (#/products instead of /products) breaks URL discovery entirely. Google's documentation is explicit: use the History API. Hash fragments aren't sent to the server, so crawlers never see them as distinct URLs.
Missing server-side fallbacks for client-only state. If a URL returns a 200 but renders an empty page until JavaScript executes, Google queues it for rendering. AI crawlers index the empty page. SPAs need proper 404 handling or noindex directives for non-existent routes.
Client-side React apps driving up CPU usage and page load times. Search Engine Land's case study found that heavy JavaScript processing can exceed Google's Web Rendering Service capacity, causing rendering timeouts on pages that technically work fine in a browser.
These aren't edge cases. They're the default behavior of React SPAs built without search in mind.
Which Rendering Strategy for What
The fix isn't 'just use SSR.' It's picking the right rendering approach for each content type on your site.
Server-side rendering works best for content that changes frequently and needs fast indexing: product pages, news articles, dashboards with public data. The server delivers fully rendered HTML on every request. Both Googlebot and AI crawlers see complete content immediately. The tradeoff is server load and response time under traffic spikes. Next.js handles this well out of the box; it's the most common migration path for React SPAs with SEO problems.
Static site generation is the better choice for content that doesn't change often: blog posts, documentation, landing pages. Pages are pre-rendered at build time and served as static HTML. Zero rendering delay for any crawler. The constraint is that content updates require a rebuild and deploy.
Prerendering serves a pre-rendered HTML snapshot to crawlers while keeping the client-side experience for users. This solves the AI crawler problem without a full architectural migration. It's a pragmatic middle ground for teams that can't rewrite their frontend but need dual-channel visibility now.
Hybrid approaches mix these per route. Your marketing pages can be statically generated while your app shell stays client-rendered. Most modern frameworks (Next.js, Nuxt, SvelteKit) support this natively.
The Botify analysis makes a useful point about measurement: track full render time and browser-side JavaScript performance, not just server response time. Your TTFB can look healthy while your rendering ratio tells a different story. Calculate it by comparing what site search operators show for HTML-only content versus fully rendered content.
Three Checks That Matter
Fetch your key pages with JavaScript disabled. What do AI crawlers actually see? If the answer is a loading spinner and an empty <div id="root">, you have a problem no amount of content optimization will fix.
Check Search Console for 'Discovered, currently not indexed' patterns. If you see clusters of URLs stuck there, you're likely hitting rendering budget limits. Cross-reference with your JavaScript framework's routing to identify invalid dynamic routes or hash-based URLs.
Verify that structured data exists in the initial HTML response, not injected by JavaScript. This is the single highest-leverage fix for AI search visibility. Your JSON-LD needs to be in the server response, not in a useEffect hook.
The rendering gap between what browsers show and what crawlers index has existed since Googlebot started executing JavaScript. What's changed is that a growing share of search traffic now comes from systems that don't execute JavaScript at all, and won't. Building for both channels means building for the lowest common denominator: HTML that works before a single script tag fires.