JavaScript SEO Audit: Rendering, Hydration, and Crawlability in 2026

Google indexes JavaScript-heavy sites using a two-pass process. In the first pass, Googlebot crawls the raw HTML and queues any JavaScript resources it discovers. The second pass, which can be delayed by days or weeks, renders the page in a headless Chromium instance and indexes the fully rendered DOM. Content that requires JavaScript to render may not appear in the index for an extended period, if it appears at all.

This two-pass architecture has not changed substantially since Google announced it in 2018, but the stakes have risen. With AI Overviews and LLM retrieval systems now relying on clean, structured content, pages that depend heavily on client-side rendering are at a structural disadvantage. A 2025 study by SEW Data found that JavaScript-rendered pages were 3.2 times more likely to be classified as "Crawled but not indexed" compared to server-rendered equivalents [1].

The first step in a JS SEO audit is understanding the rendering strategy your site uses. The three major approaches carry different SEO implications:

• Server-side rendering (SSR). The server generates the full HTML for each request. Content is immediately available in the raw HTML response. This is the safest approach for SEO and the recommended default for any site where organic search traffic is a primary channel.
• Static site generation (SSG). HTML is pre-built at build time and served as static files. This offers the same SEO advantages as SSR with better performance. The trade-off is that content updates require a rebuild.
• Client-side rendering (CSR). The server delivers a minimal HTML shell, and JavaScript executes in the browser to fetch and render content. This is the most SEO-vulnerable approach. Content may not be available in the initial HTML, and the rendering queue can cause arbitrary delays before Google indexes the page.
• Progressive hydration and partial prerendering. Frameworks like Next.js and Nuxt have introduced hybrid approaches that statically render critical content while hydrating interactive components on the client. These strategies offer a strong compromise between performance and crawlability.

For every template on your site, verify what content is present in the raw HTML response versus what requires JavaScript to appear. Use curl with a desktop user agent or curl with Googlebot's user agent to fetch the raw HTML. Compare the output against a fully rendered screenshot or DOM dump.

Create an inventory of content elements and classify them as:

• Present in raw HTML. This is the safest category. Content will be indexed regardless of JavaScript execution.
• Injected by JavaScript on initial load. Content fetched from an API or rendered by a framework on page load. This content is indexable but depends on successful JavaScript execution during Google's second pass.
• Available only after user interaction. Content hidden behind tabs, accordions, or "load more" buttons that depend on JavaScript event handlers. This content may not be indexed unless it is present in the initial HTML payload.

Google's Martin Splitt has stated that Googlebot does not click buttons or scroll to trigger lazy-loaded content. If content is not present in the rendered DOM after the initial page load, it is effectively invisible to Google's indexer [2].

Verify that all JavaScript files required for rendering are accessible to Googlebot. The most common JS SEO failure is a JavaScript resource that is blocked by robots.txt. Even if the HTML page is crawlable, if the JavaScript file that renders the content is disallowed in robots.txt, Google cannot execute it and will index only the empty HTML shell.

Check your robots.txt file for any Disallow rules that match .js files or JavaScript delivery paths. If you are using a CDN for JavaScript assets, verify that the CDN does not block Googlebot's user agent.

Also verify that JavaScript files are not blocked by a noindex HTTP header or by requiring authentication. Any resource that returns a 401 or 403 status code for Googlebot's IP range will prevent rendering.

Client-side rendered applications often use JavaScript-based routing (React Router, Vue Router) instead of standard <a> tags. Googlebot can discover JavaScript-based navigation links when the framework renders them as <a> elements in the DOM, but it may not discover links that are generated by click handlers attached to non-anchor elements.

Audit your internal link structure by rendering each page and searching the DOM for <a href="..."> elements. Any navigation path that does not produce a visible <a> tag with an href attribute in the rendered DOM is unlikely to be discovered. If your site uses a JavaScript framework for client-side routing, verify that all route changes produce observable <a> elements.

Structured data must be present in the rendered DOM for Google to detect it. If you inject JSON-LD via JavaScript after the page loads, the structured data will be available in the rendered DOM. However, if the JavaScript fails during Google's rendering pass, the structured data is lost.

The safest approach is to include JSON-LD in the server-rendered HTML. If that is not possible, ensure the JavaScript that injects structured data is simple, well-tested, and does not depend on asynchronous API calls that could fail. Google's 2025 documentation on JavaScript SEO recommends that structured data be present in the initial server response whenever practical [3].

Single-page applications are prone to "soft 404" errors. When a user navigates to a URL that does not correspond to a real resource, the SPA router may serve the app shell with an empty content area and a 200 status code instead of returning a proper 404 status code. Googlebot interprets a 200 status with no meaningful content as a soft 404, which can mark the page as low quality.

Use a crawler with JavaScript rendering enabled and check every page that returns a 200 status code for empty or placeholder content. Pages with no visible text, no structured data, and no meaningful content should return a 404 or 410 status. Alternatively, configure your SPA router to return a 404 status code from the server for undefined routes.

Run a JavaScript SEO audit quarterly if your site relies on client-side rendering for any portion of its content. Focus the audit on the six areas above: rendering strategy, content availability, resource accessibility, link discovery, structured data placement, and soft 404 prevention. Track the "JS content parity score" (percentage of pages whose rendered DOM content matches the intended design) as your primary health metric. If the score drops below 80 percent, investigate which JavaScript dependencies are failing during Google's rendering pass and either server-render the affected content or simplify the rendering pipeline. The JavaScript ecosystem evolves rapidly, but the audit principles of content availability and resource accessibility remain constant.

---

References

1. SEW Data. (2025). "JavaScript SEO Indexation Study: CSR vs. SSR Index Rates." SEW Data Research.
2. Splitt, M. (2025). "How Googlebot Handles JavaScript: The Two-Pass Indexing Process." Google Search Central Office Hours.
3. Google. (2025). "JavaScript SEO Best Practices." Google Search Central Documentation.