JavaScript SEO: How Google Renders Your Single-Page App

Googlebot uses an evergreen version of Chromium to render JavaScript. Rendering happens in a second wave after the initial crawl. The initial crawl fetches the HTML and queues the URL for rendering. The rendering wave pulls the URL out of the queue, runs the JavaScript, and captures the resulting DOM. Depending on crawl budget and rendering queue depth, the gap between the two waves ranges from hours (for high-priority sites) to weeks (for large low-authority sites).

The implication: any content that only appears after JavaScript execution is invisible to Google during the initial crawl. For competitive queries where indexation speed matters, that gap is a ranking disadvantage. Sites that render server-side deliver the full content on the first crawl and skip the wait.

The rendering wave is also incomplete. Not every crawled URL gets rendered - Google's system prioritizes URLs based on internal signals. Low-authority pages may sit in the queue indefinitely. If your pages depend on rendering to become indexable, some fraction of them may never be indexed at all.

Server-side rendering (SSR) returns fully rendered HTML on every request. It scales for dynamic personalized content but requires infrastructure per request. Static site generation (SSG) pre-renders HTML at build time and serves it from a CDN. It is faster and cheaper but requires a rebuild for content changes. Client-side rendering (CSR) returns an empty shell and lets the browser build the page.

For SEO, the ranking is SSG > SSR > CSR. SSG is fastest to first paint, cheapest to serve, and always fully indexable. SSR is nearly as good but has higher server costs and slightly slower TTFB. CSR is a disadvantage for indexation, ranking, and Core Web Vitals - it should be used only for authenticated app UI, not for public content.

Modern frameworks (Next.js, Nuxt, SvelteKit, TanStack Start, Remix, Astro) let you mix strategies per route. Public pages should default to SSG or SSR. Interactive widgets inside those pages can be CSR-hydrated. This hybrid approach gives you SEO-friendly initial paint plus rich client-side interactivity.

A single-page app that uses hash-based routing (/#/about, /#/products) is invisible to Google below the home page. Everything after the # is a URL fragment that Google ignores. Your entire site collapses to a single URL from Google's perspective.

The fix is the History API. React Router, Vue Router, Svelte's SvelteKit router, and every modern framework support clean URLs via History pushState. Migrate hash routes to clean routes as a first-priority technical SEO project - the effort is small and the traffic impact is dramatic.

After migrating, verify with URL Inspection in GSC that every route is now indexable. Add each route to your sitemap. Add internal links between routes. The full-site indexation curve typically shows visible movement within four to eight weeks of the migration.

The single most useful tool for debugging JavaScript SEO is URL Inspection's 'Test Live URL' function. Paste a URL, click Test Live URL, and wait for Google to render it in real time. Once complete, click 'View Tested Page' → HTML tab. You see exactly the HTML Google saw after JavaScript execution.

If your main content is missing from that HTML, you have a rendering problem. Common causes: a slow API call that did not resolve before Google's render timeout, JavaScript that throws an error under Googlebot's user agent, content that depends on user interaction (click a button to reveal), content behind a login wall.

Fix the rendering problem before doing anything else. No amount of internal linking, backlinking, or content quality will save a page whose content Google cannot see. Rendering issues are the P0 of JavaScript SEO.

Dynamic rendering (serving a pre-rendered version to Googlebot while serving JavaScript to users) was Google's official workaround for JavaScript-heavy sites from 2018 to 2022. Google has since deprecated it as a recommendation and advised sites to move to SSR or SSG instead.

Dynamic rendering still works. Google will not penalize you for using it. But it is fragile - drift between the pre-rendered version and the JavaScript version creates content mismatch that Google can detect, and detection can lead to cloaking penalties.

If you inherited a site with dynamic rendering, plan a migration to SSR or SSG. The engineering cost is a fraction of maintaining dynamic rendering long-term, and the ongoing operational burden disappears.

React sites should default to Next.js or Remix for public content. Create React App (CSR-only) is a bad choice for SEO in 2026 and Meta itself has deprecated CRA. TanStack Start is a newer alternative with strong SSR and file-based routing.

Vue sites should default to Nuxt. Vite + vue-router without Nuxt is CSR-only unless you add manual SSR configuration, which is more work than adopting Nuxt from the start.

Svelte sites should default to SvelteKit. Svelte itself is a compiler and does not include routing or SSR; SvelteKit provides both. Vanilla Svelte with a client-side router is CSR-only.

Before shipping any JavaScript-heavy site to production, run a five-item checklist. First, curl -A 'Mozilla/5.0 (compatible; Googlebot/2.1)' each key URL and inspect the raw HTML. Main content should be present. Second, use URL Inspection's Test Live URL on the same URLs and inspect the rendered HTML. Both should show the content.

Third, disable JavaScript in Chrome DevTools and reload each key URL. If the page is blank, you have SSR gaps. Fourth, run Lighthouse in a private window on each key URL and check the SEO score. Any score below 90 needs investigation.

Fifth, submit each key URL via URL Inspection's Request Indexing button. Wait a week and confirm each is indexed via a 'site:yourdomain.com/path' Google search. Only after all five checks pass should you consider the site SEO-ready.