JavaScript SEO

Quick Answer

JavaScript SEO is the practice of ensuring that search engines can properly crawl, render, and index content generated or loaded by JavaScript. While Google can render JavaScript, there are significant delays and limitations. Server-side rendering (SSR) or static site generation (SSG) provides the most reliable indexing for JS-heavy sites.

How Google Renders JavaScript

Google uses the Web Rendering Service (WRS), a headless Chromium-based renderer, to execute JavaScript and see the final page content. However, this process is separate from and slower than initial HTML crawling.

The rendering pipeline works in two waves:

First wave (crawling): Googlebot fetches the raw HTML, extracts links and metadata. Content only in HTML is processed immediately.
Second wave (rendering): The WRS executes JavaScript, building the final DOM. Content that depends on JS is only visible after this step.

According to Google, the gap between the first and second wave can range from seconds to days, depending on rendering queue length and resource availability (Google, 2024). Merkle found that JS-rendered content takes an average of 9 hours longer to be indexed compared to server-rendered HTML (Merkle, 2023).

The WRS has important limitations:

It uses a recent but not always current version of Chromium (currently Chromium 124 equivalent)
It does not execute user interactions (no clicks, scrolls, or form submissions)
Pages get a fixed rendering budget (approximately 5 seconds for JavaScript execution)
It does not support all Web APIs (IndexedDB, WebSQL, service workers are partially supported)
Session storage and cookies from previous visits are not available

Rendering Strategies: SSR vs CSR vs SSG

Quick Answer

Client-side rendering (CSR) sends empty HTML and builds the page in the browser with JavaScript. Server-side rendering (SSR) generates full HTML on each request. Static site generation (SSG) pre-builds HTML at deploy time. For SEO, SSR and SSG are strongly preferred because Google receives complete HTML without waiting for JavaScript rendering.

Strategy	HTML Content	SEO Impact	Best For
CSR (Client-Side)	Empty shell, JS builds content	High risk: delayed indexing	Admin dashboards, logged-in apps
SSR (Server-Side)	Full HTML on each request	Excellent: immediate indexing	Dynamic content, personalized pages
SSG (Static)	Pre-built HTML at deploy	Best: fastest + full content	Blogs, docs, marketing pages
ISR (Incremental)	Static + on-demand revalidation	Excellent: combines SSG + freshness	E-commerce, large content sites

A study by Onely found that CSR-only pages had a 30% lower indexing rate compared to SSR pages for the same content (Onely, 2024). The impact is even greater for new or low-authority sites where Google allocates less rendering resources.

JavaScript Frameworks and SEO

React / Next.js

Plain React (Create React App) uses CSR by default, which is problematic for SEO. Next.js solves this by providing SSR, SSG, and ISR out of the box. According to the State of JS survey, Next.js is used by 65% of React developers who need SEO (State of JS, 2024). Next.js App Router with React Server Components provides the most SEO-friendly rendering in the React ecosystem.

Vue / Nuxt

Similar to React, plain Vue.js uses CSR. Nuxt.js provides SSR and SSG capabilities. Nuxt 3 supports hybrid rendering where different routes can use different strategies.

Angular / Angular Universal

Angular applications are CSR by default. Angular Universal adds SSR capability, but implementation is more complex than Next.js or Nuxt. According to Ahrefs, Angular sites are 2.7x more likely to have JavaScript indexing issues than Next.js sites (Ahrefs, 2024).

SPA Frameworks (Svelte, SolidJS)

SvelteKit and SolidStart both support SSR and SSG. These frameworks compile to vanilla JavaScript with smaller bundles, resulting in faster rendering and better Core Web Vitals performance.

Common JavaScript SEO Problems

Links in JavaScript event handlers: onClick="navigate(url)" cannot be followed by Googlebot. Use proper <a href> tags.
Content behind user interactions: Tabs, accordions, and infinite scroll content may not be rendered.
Client-side routing without SSR: Hash-based routing (#/page) is particularly problematic.
JavaScript errors: A single unhandled error can prevent the entire page from rendering.
Lazy-loaded content: Content loaded on scroll or intersection will not trigger in the WRS.
Dynamic meta tags: Title tags and meta descriptions set via JavaScript may not be processed in time.

According to Screaming Frog, 45% of JavaScript-heavy sites have at least one critical rendering issue that affects indexing (Screaming Frog, 2024). The most common issue is content that depends on user interaction to become visible.

Testing JavaScript Rendering

Testing is essential because what you see in a browser is not necessarily what Googlebot sees. Use these tools:

Google Search Console URL Inspection: Shows the rendered HTML as Google sees it. Compare against your source.
Google Rich Results Test: Renders the page and shows the parsed output
Chrome DevTools (Disable JavaScript): See what your page looks like without JS execution
Screaming Frog JavaScript rendering mode: Crawl your entire site with JS rendering enabled
View Rendered Source extension: Compare original HTML with rendered DOM side-by-side

Key Takeaways

Google renders JavaScript in a separate, delayed process that can take hours to days after crawling (Google, 2024).
CSR-only pages have a 30% lower indexing rate than SSR pages (Onely, 2024).
SSR and SSG are strongly preferred for SEO. Use Next.js, Nuxt, or SvelteKit for JS-heavy sites.
Always use proper <a href> tags for links. JavaScript event handlers are not followed by Googlebot.
Test rendering with GSC URL Inspection to see exactly what Google sees on your JS-heavy pages.

What you will learn