JavaScript SEO Audit Template

Rendering Check: Raw HTML vs Rendered DOM

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

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

Catch JS-injected noindex, canonical, or robots surprises that block or misdirect indexing.

Check rendered metadata, not just source

Indexing directives are read from the rendered HTML, so JavaScript that injects or changes them can quietly affect how a page is indexed. A clean source can still ship a noindex or wrong canonical once scripts run.

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 because Google may act on the rendered value. 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

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

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

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.

Can Google index content that is rendered with JavaScript?

Yes. Google can execute JavaScript and index content that appears in the rendered DOM. However, rendering is deferred and resource-intensive, so it may happen later than crawling. Anything that only appears after JavaScript runs depends on successful rendering, which is why server-rendered or prerendered HTML is more dependable for SEO-critical content.

What is the difference between raw HTML and the rendered DOM?

Raw HTML is the initial response your server returns before any JavaScript runs. The rendered DOM is the page after scripts have executed and modified it. Googlebot fetches the raw HTML, then renders the page, and indexes what it sees in the rendered output. Auditing means comparing both so you know what content actually reaches the index.

Why do my links need to be real anchor tags?

Search engines discover and follow URLs through standard anchor elements that include an href pointing to a real URL. Links that work only through an onclick handler, a button, or a span are not reliably crawled, so the pages behind them may never be found. Always expose important navigation and content links as true crawlable anchors in the DOM.

Why would JavaScript-injected noindex or canonical tags be a problem?

Google reads indexing directives from the rendered HTML, so a directive added or changed by JavaScript can take effect even if the source looks fine. A script that injects noindex or rewrites the canonical to the wrong URL can de-index or misdirect a page. Setting these signals server-side avoids surprises between the raw and rendered states.

Which rendering strategy is best for SEO?

For SEO-critical pages, prefer server-side rendering, static generation, or prerendering so that content, links, and metadata are present in the initial HTML and do not depend on the browser building the page. Client-side rendering is riskier because content relies fully on rendering. Reserve heavy client-side rendering for low-SEO-value or authenticated areas.

How do I confirm what Googlebot actually renders?

Use the URL Inspection tool in Google Search Console. It shows the rendered HTML and a screenshot of how Google crawled the page, so you can verify that content, internal links, and indexing directives are present after rendering. Also make sure robots.txt does not block JavaScript or CSS, and re-inspect pages after template or framework changes.