The right starting point isn’t a page-by-page crawl, it’s an inventory of routes by their actual rendering mode, because Nuxt explicitly supports per-route rendering configuration (server-side rendering, client-side rendering, static generation, and hybrid rendering rules), and each mode carries a different SEO risk profile. Once you know which routes render how, you audit the higher-risk client-side routes first, verify against Google’s actual rendered output rather than your local dev environment, and remediate by converting genuinely high-value CSR routes to server-rendered or hybrid delivery where the audit shows an actual indexing gap.
Step 1: Build the rendering-mode inventory
Nuxt’s routing configuration allows rendering mode to be set per route (via route rules in recent Nuxt versions, or per-page configuration in older setups), which means a single application can legitimately mix SSR marketing pages, statically generated content pages, and CSR-heavy interactive routes (dashboards, account areas, search/filter interfaces) all in one codebase. Before auditing anything, get an explicit list of every route pattern and its configured rendering mode directly from the Nuxt config or route rules file, not from assumption. This matters because the SEO risk isn’t uniform across the app, it’s concentrated in whichever routes are actually client-rendered.
Step 2: Prioritize CSR routes for audit first
Routes rendered client-side carry meaningfully higher SEO risk than SSR or statically generated routes, because their content depends on Google’s rendering queue completing successfully rather than being present in the initial HTML response. Google has documented that JavaScript-rendered content goes through a two-phase process, initial crawling and indexing of the raw HTML, then a second rendering pass that can be delayed, and content that only appears after client-side JavaScript execution is entirely dependent on that second pass succeeding. SSR and static routes don’t carry this dependency at all, since the content is already present in the served HTML. That risk asymmetry is the reason to triage CSR routes first rather than auditing the whole site with equal priority.
Within the CSR route set, further prioritize by actual organic value, high-traffic or high-conversion-intent pages that are client-rendered deserve audit attention before low-value utility pages using the same rendering mode.
Step 3: Verify against Google’s actual rendered view, not local testing
The core reason rendering issues are often invisible during normal QA is that a developer’s local environment, staging server, or even a headless browser test typically doesn’t replicate Googlebot’s specific rendering constraints, resource budgets, or timing behavior. The only reliable verification is checking what Google itself renders and indexes for the route. Use URL Inspection in Search Console to view the actual rendered HTML Google produced for a given CSR route, and compare it directly against what a user’s browser renders for the same URL. A meaningful discrepancy, content present for the user but absent or incomplete in Google’s rendered view, is the concrete signal of an actual problem, as opposed to a theoretical one.
Do this per template type across the CSR route set, not just once on a sample page, since Nuxt applications frequently have several distinct component structures within the same broad rendering-mode category, and a rendering issue affecting one template pattern may not affect another even under the same rendering mode.
Hypothetically, consider a subscription-box company we’ll call “Site C” running a Nuxt.js storefront where the main product-listing routes are statically generated but the individual product-detail pages were built as client-side-rendered routes to support a highly interactive customization tool. If URL Inspection showed that a real browser rendered full product descriptions and pricing, but Google’s rendered HTML for the same URL came back with an empty description block, that specific template pattern, and only that one, would be the priority candidate for conversion to hybrid rendering, while the already-static listing pages wouldn’t need any change at all.
Step 4: Cross-check with Crawl Stats and indexing coverage
Search Console’s Crawl Stats report and Page Indexing report provide corroborating, aggregate evidence. A disproportionate share of CSR routes sitting in “Crawled – currently not indexed,” or unusually high response times specifically for CSR route patterns, supports the hypothesis that Google is struggling with or deprioritizing that rendering path. This isn’t a substitute for the per-template URL Inspection check in Step 3, but it’s a useful way to confirm the issue is systemic across a route type rather than isolated to one URL.
Step 5: Remediate based on what the audit actually found
Where the audit reveals a genuine indexing or content-visibility gap on a high-value CSR route, the direct remediation is converting that route to server-side rendering or Nuxt’s hybrid rendering approach, which serves fully rendered HTML on the initial response rather than relying on client-side hydration to populate content. This is a real, supported configuration change in Nuxt rather than a workaround, since the framework is explicitly built to support mixing rendering strategies by route.
Where the audit shows CSR routes performing fine (content present in Google’s rendered view, indexed normally), leave them as is, converting rendering modes carries real engineering cost and isn’t warranted without audit evidence of an actual problem. This is also why it’s worth being precise about which specific Nuxt version and rendering-mode behavior you’re relying on when planning remediation, since rendering-mode configuration syntax and defaults have evolved across Nuxt versions, and remediation guidance should be checked against your specific version’s current documentation rather than general framework assumptions.
The organizational piece
Rendering audits of this kind work best as a recurring practice tied to deploys, not a one-time project. Since Nuxt makes it straightforward for a route’s rendering mode to change during ordinary development (a route rule gets added or modified without anyone flagging it as an SEO-relevant change), the most durable fix is adding a lightweight check to the deployment or QA process that flags rendering-mode changes on existing indexed routes for SEO review, rather than relying on a periodic full-site re-audit to catch regressions after the fact.
