JavaScript Rendering & SEO
How Google actually indexes JavaScript
DeepAudit AI is a real browser SEO audit and JavaScript SEO scanner that reproduces Google's two-pass index. See exactly what gets indexed on the first pass, what depends on the render budget, and which routes are at risk before Search Console flags them.
Free. No signup. 60 seconds per URL.
JavaScript SEO has its own physics
The internet is no longer a collection of static HTML files. Most production sites built in the last decade run on a JavaScript framework — React, Vue, Angular, Svelte, Solid — and ship some or all of their content client-side.
That changes how search engines index content in ways that classic SEO checklists do not capture. A site can pass every traditional audit and still rank poorly because its real content never makes it into Google's index.
And Google is now the forgiving case. The crawlers behind ChatGPT, Claude, and Perplexity fetch your page but do not run JavaScript at all, so client-rendered content is simply invisible to them. In our AI Visibility Study of 368 small business sites, 1 in 4 hid answer-critical content from non-rendering AI crawlers. JavaScript rendering is no longer just a Google problem.
The mechanism is Google's two-pass index. The first pass reads your initial HTML response and indexes whatever metadata and content it finds.
The second pass queues the page for full rendering and re-indexes the post-JavaScript DOM. Both passes are real, but they happen on different timelines and under different constraints.
The second pass runs on a render budget — a dynamically allocated time window that pages either finish inside or fail. Pages that fail the budget rank only on whatever the first-pass HTML happened to contain, which for most JavaScript apps is an empty shell.
Architecting for both passes is what separates JavaScript SEO from classic SEO. SSR and SSG put real content in the first-pass index. Bundle-size discipline, hydration timing, and dynamic-import boundaries determine whether the second pass finishes inside the render budget.
The DeepAudit AI real browser SEO audit measures both passes for any URL and surfaces which pages are at risk before Search Console reports anomalies weeks later.
JavaScript SEO Foundations
Six concepts that determine whether your JS app ranks
These are the technical ideas every engineer and SEO lead working on a JavaScript app needs internalized. The two-pass index is the foundation. The render budget is the constraint. SSR, SSG, CSR, and hybrid rendering are the architectural choices that determine which side of the budget each route lands on.
The next panel covers how DeepAudit AI measures these concepts in practice — render-budget instrumentation, rendering-strategy detection, and the specific failure modes each concept maps to.
The two-pass index, in detail
Pass one fires the moment Googlebot fetches your URL. It reads the raw HTML response, discovers <a href> links for crawl expansion, and indexes whatever metadata and content the response contains. Pass two queues the page for rendering — typically minutes to days later — and executes JavaScript in a real Chromium instance. The rendered DOM is then re-indexed, replacing the first-pass content if the second pass succeeded. If second pass fails or runs past the render budget, the first-pass content is what ranks.
Render budget is a moving target
Google does not publish a fixed render-budget number. It is a function of crawl priority, domain authority, historical render success, page complexity, and overall load on the rendering pipeline. In practice, modest pages reliably finish under two to three seconds; complex pages with heavy hydration, large bundles, and runtime data fetches commonly run past the threshold. The audit measures your pages against a conservative budget so you know which routes are at risk before Search Console reports anomalies.
SSR is the highest-leverage SEO move for JS apps
Server-side rendering produces real HTML on the first pass. The two-pass schedule still runs, but indexable content is in the index from the moment the page is crawled. There is no render-budget dependency for the foundational content. SSR also tends to improve LCP (real content paints faster than JS-driven content) and gives Google a stable cache of the page for future re-crawls. Frameworks: Next.js, Nuxt, SvelteKit, Remix, Astro all offer first-class SSR.
SSG is faster and cheaper when content is stable
Static site generation produces HTML at build time and serves it from CDN. Rendering cost on request is zero. Indexability is identical to SSR for the first pass. The tradeoff is freshness: content updates require a rebuild and redeploy. For marketing pages, blog posts, documentation, and product catalogs that change daily-or-less, SSG is materially better than SSR. ISR (incremental static regeneration) is the Next.js hybrid that gets most of SSG's speed with SSR-like freshness.
CSR is structurally bad for SEO content pages
Client-side rendering means the server returns an empty shell and the framework renders content in the browser. Indexing depends entirely on the second pass and the render budget. Crawl rates drop, indexing delays measure in weeks, and any hydration error or render-budget overrun results in the empty-shell content being what ranks. CSR is appropriate only for authenticated apps where SEO does not matter; for content pages, the migration to SSR or SSG is one of the highest-ROI SEO investments available.
Hybrid rendering is the modern default
Most production JS apps mix strategies. Marketing pages and blog content statically generated. Product pages with frequent inventory changes server-rendered. Authenticated dashboards client-rendered. Next.js, Astro, and similar frameworks support per-route rendering decisions. The audit identifies which routes are SSR, SSG, or CSR by inspecting the initial HTML response per route and recommends the right strategy per page based on content freshness, traffic, and SEO importance.
How Detection Works
Two-pass instrumentation in a real browser
DeepAudit AI runs every audit through a headless Chromium instance — the same browser engine Googlebot uses. The first observation is the raw HTML response from your server, captured before any JavaScript executes. That snapshot represents what Google's first-pass index sees: every <title>, every <meta>, every <a href>, every <script type="application/ld+json"> already present, plus all body content that arrived as HTML.
The second observation is the post-hydration DOM, captured after JavaScript has executed and the network has settled. We measure the gap between first contentful paint and DOM settlement to estimate render-budget risk.
Routes whose hydration completes well under the budget are safe; routes whose hydration finishes late are flagged.
We also detect hydration mismatches by structurally diffing the initial HTML against the post-hydration DOM — any major divergence is a signal that the server render is being replaced by the client render, which has indexing implications because Google may have cached the server version.
Rendering-strategy detection compares the initial HTML response per route against the post-hydration DOM. Routes whose initial HTML contains the real content are SSR or SSG. Routes whose initial HTML is an empty shell are CSR. Routes that include placeholder content swapped out during hydration are flagged as transitional.
The deep scan crawls up to fifty routes from your sitemap and gives you a per-route rendering-strategy report, so you can identify the specific pages where migrating from CSR to SSR or SSG would unlock the most ranking gain.
Every audit also runs the full Core Web Vitals audit.
LCP, CLS, and INP are measured under conditions matching Google's field data, with attention to the rendering-related causes — large JavaScript bundles inflating LCP, hydration cost inflating INP, dynamic content shifts inflating CLS. The structured-data validator runs on both the initial HTML and the post-hydration DOM, so JSON-LD that exists only after JavaScript execution is flagged as first-pass-invisible.
See how Google actually indexes your JavaScript app
DeepAudit AI runs the full real browser SEO audit, JavaScript SEO scanner, and Core Web Vitals audit in one pass. Two-pass diff, render-budget measurement, rendering-strategy detection per route, and a downloadable PDF report. No signup, 60 seconds.
Launch Free SEO AuditFAQ
JavaScript SEO questions, answered
What is Google's two-pass index?
Google indexes JavaScript apps in two passes. The first pass reads the initial HTML response from the server and discovers links and metadata. The second pass executes JavaScript on a render budget and re-indexes whatever the rendered DOM contains. Pages that exceed the budget — slow JS, hydration errors, large bundles — never get their second-pass content indexed and rank only on whatever the first-pass HTML happened to contain.
What is the render budget and how do I measure it?
The render budget is the time Googlebot allocates to executing JavaScript before giving up on a page. It is not a publicly fixed number; it is a function of resource priority, crawl health, and historical render success. In practice, pages whose hydration finishes in under two to three seconds are reliably indexed; pages that take longer are at material risk. Our JavaScript SEO scanner measures the gap between first contentful paint and DOM settlement to flag at-risk routes.
Is server-side rendering always better than client-side rendering for SEO?
For content pages, yes. SSR or static generation produces real HTML on the first pass, so Google indexes the content without depending on the render budget. CSR works for authenticated apps where SEO does not matter — dashboards, internal tools, single-customer portals — but is a structural liability for any page meant to rank. The audit tells you which routes need to migrate to SSR or SSG most urgently.
What is the difference between SSR, SSG, and ISR?
SSR (server-side rendering) generates HTML per request on the server, so every page load runs through the framework's render path with fresh data. SSG (static site generation) generates HTML at build time, so requests are served from cache or CDN. ISR (incremental static regeneration) is a Next.js hybrid: pages are statically generated but revalidated on a schedule. All three produce real HTML on the first pass. The right choice depends on data freshness needs and traffic patterns.
Does Googlebot run all JavaScript?
Yes, but on the second-pass schedule and with constraints. Googlebot uses a recent Chromium that supports modern JavaScript features. Network requests, fetch calls, and dynamic imports all run. The catches are timing — render budget can cut execution short — and certain APIs that are unavailable or behave differently from a standard browser session, including some autoplay, user-gesture-gated APIs, and certain storage APIs.
What is hydration and why does it affect SEO?
Hydration is the process where a JavaScript framework attaches event handlers and state to server-rendered HTML, turning a static page into an interactive app. It matters for SEO because hydration mismatches — where the server-rendered HTML differs from the client render — can cause the framework to replace the server output. Google may have already cached the server version. The result: snippets and indexed content show fallback values that no longer match the live page.
How do I know if my JavaScript app is being indexed correctly?
Three signals. Search Console's URL Inspection tool shows the indexed snapshot — compare it to the live rendered DOM. Search Console's Coverage report flags discovered-not-indexed and rendered-no-content pages. The DeepAudit AI real browser SEO audit reproduces both passes locally and gives you the diff in 60 seconds, including which routes are at render-budget risk and which are CSR-only.
What about Core Web Vitals for JavaScript apps?
Core Web Vitals are tightly coupled with rendering strategy. SSR and SSG help LCP because real content paints before JavaScript executes. Hydration cost hurts INP because the page is unresponsive while React, Vue, or Angular is mounting. CLS suffers when images render without explicit dimensions and dynamic content shifts the layout. Every Core Web Vitals audit run by DeepAudit AI captures these signals under field conditions.
Related
Apply the foundation to your stack
The two-pass index is universal. The remediation depends on which framework you ship.
Technical SEO is one slice of our digital marketing services. See all services.
React SEO Audit
React-specific failure modes: react-helmet timing, useEffect-set metadata, hydration mismatches, and the Next.js / Vite tradeoffs that determine which side of the render budget each route lands on.
- react-helmet pitfalls
- SSR vs SSG vs CSR guidance
- React Router crawl gotchas
SPA SEO Audit
Framework-agnostic detection across React, Vue, Angular, Svelte, and Solid. Same diff engine, same render-budget instrumentation, framework-specific remediation guidance in the report.
- Framework fingerprinting
- Hash routing detection
- Sitemap drift checks
Get Started
Diagnose your rendering
Drop in any URL. DeepAudit AI runs the real browser SEO audit, JavaScript SEO scanner, and Core Web Vitals audit. You get the two-pass diff, the rendering strategy per route, the render-budget risk assessment, and remediation paths specific to whatever framework powers your app.