Updated April 2026

JavaScript SEO: How Google Handles JS Sites

Check your JS site for indexing issuesAnalyze My Site

Google can render JavaScript, but it does so in a two-wave process: first it crawls the raw HTML, then it queues the page for rendering (executing the JS) which can take anywhere from hours to weeks. This delay means content that only appears after JS execution may not be indexed promptly. For most modern JS frameworks using server-side rendering, this is a non-issue. For client-side-only apps, it can cause serious indexing problems.

The Two-Wave Crawling Problem

When Googlebot visits a JavaScript-heavy page, it first sees the initial HTML. If that HTML contains meaningful content, Google indexes it immediately. It then schedules the page for JavaScript rendering, which happens in a second crawl wave using a headless Chromium browser. The gap between wave one and wave two can be days. New content published on a JS site may not appear in search results for significantly longer than on a traditional server-rendered site.

Server-Side Rendering vs Client-Side Rendering

Server-side rendering (SSR) generates the full HTML on the server before sending it to the browser. Googlebot sees the complete content in the first crawl wave. Client-side rendering (CSR) sends a near-empty HTML shell and builds the page in the browser using JavaScript. Googlebot must wait for the rendering queue to see the actual content. For SEO, SSR is strongly preferred. Next.js, Nuxt, SvelteKit, and Astro all support SSR out of the box.

Static Site Generation

Static site generation (SSG) pre-renders all pages at build time as plain HTML. This is the best option for SEO: Googlebot sees full content immediately, no JS rendering required, and pages load faster. The limitation is that dynamic content (user-specific data, real-time prices) cannot be statically generated. A hybrid approach - SSG for public pages, CSR for authenticated/dynamic sections - gives you the best of both worlds.

Common JavaScript SEO Problems and Fixes

Meta tags not in initial HTML: If your title, description, and canonical tags are injected by JavaScript after page load, Google sees the wrong meta data in wave one. Fix: include all meta tags in the server-rendered HTML. In React, use Next.js metadata or React Helmet with SSR. In Vue/Nuxt, use useHead.

Internal links built by JavaScript: Links that are rendered by JS rather than in the initial HTML may not be discovered in the first crawl wave, creating crawl gaps. Fix: render navigation and internal links in server-side HTML. This is particularly important for your main navigation and any links between key pages.

Infinite scroll pagination: Content loaded as the user scrolls is not seen by Googlebot. Fix: implement paginated URLs (/page/2, /page/3) and link between them, in addition to or instead of infinite scroll. Google needs discrete URLs to crawl each section of content.

JS errors blocking rendering: A single JavaScript error can prevent the entire page from rendering. Use Google Search Console URL Inspection and click "Test Live URL" to see what Google actually renders for your pages. Compare this to what users see.

How to Check if Google Is Rendering Your JS

In Google Search Console, open URL Inspection for any page on your site. Click "Test Live URL" at the top right. This runs a real-time render and shows you the screenshot of what Googlebot sees, the rendered HTML, and any JavaScript errors. If the rendered screenshot shows a blank page or missing content, you have a JS rendering problem that is hurting your indexing.

Find JS indexing issues in your sitemap

Free analysis in 60 seconds

Analyze My Site Free