JavaScript SEO

Long definition

For a search engine to index content, it has to see the content in HTML. Plain server-rendered pages give that immediately. JavaScript-heavy sites — React, Vue, Angular, Svelte — often ship a near-empty HTML shell and build the page in the browser. Googlebot can execute JavaScript via the Web Rendering Service, but rendering costs more than parsing static HTML, takes longer, and isn't guaranteed to complete on every fetch.

The four common rendering strategies:

• Static HTML / pre-rendered — built at deploy time, served directly. Best crawler experience, fastest, most reliable.
• Server-side rendering (SSR) — HTML generated on each request on the server, JS hydrated in the browser. Crawlers see complete HTML; users get interactivity after hydration.
• Client-side rendering (CSR) — server returns a near-empty shell, browser fetches data and builds the DOM. Googlebot has to render to see anything; other crawlers (most AI bots, social previews, niche search engines) often don't render.
• Hydration — modern hybrid: SSR initial paint plus client-side interactivity. Best of both if done right; broken if hydration mismatches the rendered HTML.

The rule of thumb: if a crawler that doesn't execute JS can read your page, you're safe. That includes Googlebot's first wave (the parse pass before WRS), Bingbot historically, GPTBot, ClaudeBot, PerplexityBot, social link previews, and the long tail of niche search engines and link checkers.

Common JavaScript SEO failures:

• Routes that only exist after JS executes — single-page apps using pushState without server-side route handlers return the same HTML for every URL.
• Critical content blocked behind interactions — "load more" buttons, tab switches, infinite scroll without proper pagination links.
• Lazy-loading without loading="lazy" — homemade observers may not trigger for headless rendering.
• Hydration mismatches — server renders one thing, client renders another, Google indexes whichever it sees first.
• Indexable error states — a JS routing failure that renders an empty page with HTTP 200 → soft 404.

The fix in most cases is SSR or static generation. Tools like Next.js, Nuxt, SvelteKit, Astro, and Remix make this the default. For legacy CSR apps, a dynamic rendering proxy (serve pre-rendered HTML to bots, JS to users) is a transitional pattern Google still tolerates but no longer recommends. See Google's JavaScript SEO basics.

Common misconceptions

• "Googlebot renders JavaScript like Chrome, so SSR is unnecessary." It does render via an evergreen Chromium-based WRS, but rendering is queued, takes longer, and is best-effort. SSR is faster, more reliable, and works for the many other crawlers that don't render at all.
• "AI search engines render JavaScript." Most don't. GPTBot, ClaudeBot, PerplexityBot, and Common Crawl primarily fetch the raw HTML response. If your content lives only in the rendered DOM, AI overviews won't cite you.
• "Dynamic rendering is the recommended fix." Google deprecated the explicit recommendation in 2022. It still works as a transition pattern, but new builds should aim for SSR or pre-rendering.
• "If a page works in Chrome it works for Googlebot." Browser users wait for full hydration; Googlebot has time and resource limits. A page that takes 8 seconds to fully render in DevTools may be indexed in its half-loaded state.