New React site. Carefully crafted design, fluid animations, flawless UX. Weeks pass and Google has indexed three pages. Maybe four. Everything else is a black hole.
It's a common situation, more than people realize. JavaScript SEO remains one of the most underestimated areas of technical optimization, and in 2026 it's becoming even more critical with the arrival of AI crawlers.
The core problem
Google doesn't read web pages the way a normal user does. The browser loads the page, runs JavaScript, builds the DOM, and a few milliseconds later shows the content. Googlebot, however, works in two separate phases: first it crawls the raw HTML, then it queues the page for rendering (when resources are available).
This queue can be long. Very long.
The data is clear: rendering JavaScript content requires Google approximately nine times longer than static HTML. For lightweight JS pages we're talking minutes; for complex SPAs it can easily stretch to days. Sometimes weeks.
In the meantime, the content simply doesn't exist for Google.
Single Page Applications: a double-edged sword
SPAs have revolutionized frontend development. The user experience is incomparable: instant navigation, no reloads, fluid interactions. But from an SEO perspective they're a minefield.
The reason is structural. An SPA loads a practically empty HTML shell — often little more than <div id="app"></div> — and then JavaScript builds everything else. Navigation, content, internal links: all generated client-side.
Crawlers see that empty shell. End of story.
Or rather, they would only see that without the right countermeasures.
Server-Side Rendering: the mainstream solution
Server-Side Rendering (SSR) flips the approach. Instead of sending the browser an empty HTML with JavaScript instructions, the server generates the complete HTML and sends it already ready. The browser receives readable content, and so do crawlers.
Modern frameworks have made SSR accessible:
- Next.js for React
- Nuxt for Vue
- SvelteKit for Svelte
With these tools you no longer have to choose between user experience and indexability.
The mechanism works like this:
- Request — the user (or Googlebot) requests a page
- Server rendering — the server executes JavaScript and generates the complete HTML
- Delivery — the HTML arrives at the client already populated with content
- Hydration — JavaScript "reanimates" the page to make it interactive
Hydration is the key step. The page arrives static but functional, then the framework attaches and adds interactivity. The user notices nothing, and Google receives complete HTML to index immediately.
Svelte and SvelteKit
Svelte deserves special mention. Unlike React and Vue, Svelte compiles components into vanilla JavaScript during the build, eliminating framework overhead at runtime. This translates to lighter bundles and faster rendering times.
SvelteKit, the official meta-framework, offers SSR out of the box with minimal configuration. It also supports static generation (SSG) for sites that don't require dynamic content — ideal for blogs and landing pages where SEO is the priority.
Svelte's lightness also benefits crawl budget: leaner pages mean faster rendering on Google's side.
Pre-rendering: the pragmatic alternative
A full migration to SSR isn't always possible. Legacy projects, limited budgets, teams without meta-framework experience: the reasons are many.
Pre-rendering offers a middle ground. Services like Prerender.io intercept bot requests and serve them a pre-generated static HTML version. Regular users continue receiving the standard SPA.
It's a stopgap solution, certainly, but one that works — and for many projects represents the right compromise between effort and results.
One important caveat: Google doesn't like cloaking, i.e. showing different content to users and bots. Pre-rendering is accepted because the content is identical; only the delivery method changes. If the pre-rendered version diverges from the user version, the risk of a penalty is real.
The details that make the difference
Beyond the rendering strategy, there are technical aspects that often get overlooked.
Internal links
Links must be genuine <a> tags with an href attribute. It sounds obvious, but there are dozens of sites with navigation built entirely on onClick handlers and programmatic routing. The user navigates without issue, but Google doesn't see those connections.
Wrong:
<div onClick={() => goto('/products')}>Products</div>
Correct:
<a href="/products">Products</a>
All modern frameworks (Next, Nuxt, SvelteKit) provide Link components that generate correct <a> tags. Using them is essential.
Metadata
Title, description, canonical: these tags must be present in the initial HTML, not injected via JavaScript after rendering. With SSR this isn't an issue. With a client-side SPA, libraries like react-helmet, vue-meta or svelte-head handle meta tags — but they must be configured for server-side rendering.
XML sitemap
For JavaScript-heavy sites, the sitemap becomes essential. Relying on internal link discovery isn't enough. A complete, automatically updated sitemap covering all dynamic pages makes the difference between partial indexing and full coverage.
Structured data
Schema.org can be injected via JavaScript — Google recognizes it. But the same principle applies as for metadata: rendering it server-side eliminates variables and reduces the risk of it not being read.
How to diagnose a problem
Before intervening, you need a diagnosis. Useful tools:
The URL Inspection Tool in Search Console shows exactly what Google sees: crawled HTML, rendered HTML, screenshot. If content is missing from the rendered version, the problem is identified.
The Rich Results Test validates structured data after JavaScript rendering.
Lighthouse identifies performance bottlenecks that slow rendering and therefore indexing.
A quick test: open the page in Chrome, disable JavaScript (DevTools → Settings → Debugger → Disable JavaScript), reload. What appears is roughly what Googlebot sees on its first pass.
The AI factor: 2026 and beyond
There's a new element to consider. It's no longer just Google and Bing crawling the web. ChatGPT, Perplexity and other AI systems are building their own indexes. And their crawlers often have limited or zero JavaScript rendering capabilities.
A site that relies entirely on client-side rendering cuts itself off from a growing slice of visibility — the kind that brings traffic from AI responses, citations and generated snippets.
Clean, accessible HTML has never been more strategically important.
When JavaScript SEO isn't a problem
A traditional CMS site with a few scripts for animations or interactive forms probably has no issue. JavaScript SEO becomes critical when the main content depends on script execution.
WordPress blog with a few plugins? No alarm. Shopify e-commerce? Handled by the platform. React/Vue/Svelte dashboard that needs to rank on Google? That's where you need to act.
Operational checklist
- Diagnosis — use the URL Inspection Tool in Search Console to verify whether Google sees the content
- Rendering — for SPAs, implement SSR with Next.js, Nuxt or SvelteKit, or evaluate pre-rendering
- Internal links — verify all links use genuine
<a href>tags, not onClick handlers - Metadata — verify that title, description and canonical are in the initial HTML
- Sitemap — generate and maintain an up-to-date XML sitemap covering all dynamic pages
- Structured data — test structured data with the Rich Results Test
- Monitoring — periodically check crawl budget in Search Console