JavaScript Rendering Audit: Raw vs Rendered

Rendering Check: Raw HTML vs Rendered DOM

When to use: Confirm what Googlebot sees after JavaScript runs, not just the initial server response.

Compare source code to the rendered DOM

Google fetches your raw HTML first, then renders the page with a headless browser before indexing. Because rendering is deferred and resource-intensive, it can lag behind crawling, so the rendered output is what ultimately matters for indexing.

Start by viewing the raw HTML response (the source the server returns) and noting what content, links, and metadata are present before any JavaScript executes. Then inspect the rendered DOM after scripts run and compare the two.

• [Page URL] audited
• Key body content present in raw HTML?
• Headings, copy, and product data present in the rendered DOM?
• Navigation and internal links present after render?
• Title, meta description, and canonical present after render?

Flag anything that appears only after JavaScript runs. That content depends entirely on successful rendering, so it carries the most risk. Document each gap between raw HTML and the rendered DOM as a finding to fix.

Crawlable Content & Links

When to use: Make sure primary content and navigation use real, crawlable links present in the DOM.

Use real links and DOM-present content

Search engines follow links through standard <a> elements with an href attribute that resolves to a real URL. Links triggered only by an onclick handler, a button, or a span are not reliably discovered, so important pages can go uncrawled.

Walk your key templates and confirm every navigational and contextual link is a true anchor with a crawlable href.

• Main navigation uses [a href] links
• Pagination and filters expose crawlable URLs
• Related and internal links are real anchors, not onclick
• Primary content renders into the DOM, not hidden behind interactions

Avoid relying on click events, infinite scroll without paginated URLs, or content that only loads after user actions Googlebot will not perform. If content needs a tap or scroll to appear, treat it as at risk and provide a crawlable path to it. Record which links and sections pass and which need a real href or DOM presence.

Indexability: Metadata After Render

When to use: Catch JS-injected noindex, canonical, or robots surprises that block or misdirect indexing.

Check rendered metadata, not just source

JavaScript can change indexing signals, but not always in the direction you expect. A noindex added by JavaScript can take effect; a noindex in the raw HTML that JavaScript later removes may not, because Google may skip rendering pages that start with noindex. A canonical set by JavaScript must match the one in the raw HTML.

For each template, inspect the rendered DOM and confirm the indexing signals match your intent.

• Robots meta in the rendered DOM: [index/noindex]
• Canonical tag present once and pointing to the intended URL
• No JavaScript swapping the canonical to a different URL
• Title and meta description resolve to the correct values after render
• Hreflang and structured data present where expected

JS-injected noindex or canonical changes are risky: Google may act on the raw value, the rendered value, or skip rendering entirely. Be especially careful with frameworks or tag managers that rewrite head elements. If a directive can change between raw and rendered states, treat it as a defect and set it server-side instead. Log each page's rendered directives and any mismatches.

Rendering Strategy: CSR vs SSR vs SSG

When to use: Choose a rendering approach that makes content reliably available to crawlers.

Pick a rendering strategy that favors crawlability

How you render decides how dependably content reaches search engines. Because Google's rendering is deferred, strategies that deliver content in the initial HTML reduce risk.

• Client-side rendering (CSR): the browser builds the page from JavaScript. Content depends fully on successful rendering, so it carries the most indexing risk.
• Server-side rendering (SSR): the server returns fully formed HTML on each request. Content, links, and metadata are present immediately.
• Static site generation (SSG) or prerendering: HTML is built ahead of time or served from a prerender layer, making content reliably available with strong performance.

For SEO-critical pages, prefer SSR, SSG, or prerendering so content is in the initial HTML. Reserve heavy CSR for areas behind authentication or low SEO value.

Document your current approach per template, the gaps it creates, and the target strategy.

• Template: [name]
• Current vs target rendering method

Performance Impact of JavaScript

When to use: Reduce JS weight and execution cost so pages render quickly for users and crawlers.

Trim JavaScript cost

Heavy JavaScript slows down rendering for users and adds to the work search engines must do to render your pages. Because rendering is resource-intensive, leaner pages render more dependably and load faster, which supports both experience and indexing.

Audit how much script each key template ships and what it blocks.

• Large or unused JavaScript bundles identified
• Render-blocking scripts deferred or split where possible
• Critical content not gated behind slow script execution
• Third-party scripts reviewed for weight and necessity
• Core Web Vitals reviewed on key templates

Favor code splitting, removing unused code, and loading non-critical scripts later so the main content appears quickly. Never block JavaScript or CSS files in robots.txt, since that prevents Google from rendering the page as users see it. Record bundle sizes, blocking resources, and the fixes you plan for each audited template.

Test & Monitor

When to use: Validate rendering with real tools and keep watch through Search Console over time.

Test the rendered page and monitor it

Verify your fixes against what Google actually renders. The URL Inspection tool in Search Console shows the rendered HTML and a screenshot of the crawled page, letting you confirm content, links, and metadata are present after rendering.

Run each key template through inspection and capture the results.

• URL Inspection rendered HTML contains main content
• Rendered screenshot shows the expected layout
• Navigation and internal links present in the rendered HTML
• Indexing directives correct in the rendered output
• No errors reported during rendering

Then move from one-off checks to ongoing monitoring.

• Track coverage and indexing reports in Search Console
• Re-inspect after major framework or template changes
• Watch for pages dropping out of the index

Log each tested URL [URL], its rendered status, and any follow-up needed so issues are caught early rather than after rankings slip.

Raw vs Rendered Audit Sheet (fill-in)

When to use: One row per page template: raw and rendered values for content, links, title, canonical, robots and status, plus console and hydration errors.

Raw vs rendered audit

Test one representative URL per template (home, category, product, article). Raw = the HTML your server returns. Rendered = what URL Inspection or the Rich Results Test shows after JavaScript runs.

Errors to log

• Console errors during render: [message, script file]
• Hydration errors: [framework warning, component, what changed between server and client HTML]
• Blocked resources: [JS or CSS files blocked by robots.txt]

Rule: if content or links appear only in the rendered column, the template depends on rendering. Server-side rendering or prerendering is the safer fix for pages that must rank.

Status & Soft 404 Checks

When to use: Make sure error pages in a single-page app return real errors, and that routing uses crawlable URLs.

Status checks

Single-page apps often show a "page not found" message with a 200 status. Google calls these soft 404s. Its JavaScript guide offers two fixes: redirect to a URL that returns a real 404, or add a noindex robots tag with JavaScript.

Completion check: every template's rows match or have a fix owner; retest date [date].

Worked Example (fictional recipe app)

When to use: A filled-in audit of an invented React recipe site, with the three gaps it found between raw and rendered HTML.

Worked example: Pantry & Plate

Example only. The company, people, URLs and figures are invented to show what a usable, filled-in version looks like.

Why row 3 mattered most

The template shipped noindex by default and JavaScript switched it to index after loading. In a browser everything looked fine. But Google may not render a page whose raw HTML says noindex, so the switch might never be seen. Removing the default fixed it.

Next step

Use Get Source Code of Webpage to see the raw HTML a crawler receives, then compare it with URL Inspection's rendered HTML. Run a website audit for status and metadata problems across templates, and check pages as you browse with the seotools.pro SEO Extension. If your team needs help moving key templates to server-side rendering, see our SEO & GEO services.