Raw HTML and the Rendered DOM Tell Different Stories. You Need Both.

An SEO audit can inspect at least two versions of the same page.

The first is the response the server sent. The second is the DOM the browser built after JavaScript ran.

They might be nearly identical. They might also carry different headings, links, canonicals, robots directives, structured data, forms, and body copy.

A serious audit does not pick one and call it the real page. It compares them, and the finding is usually the difference.

What the initial response tells you

A source-level auditor makes an HTTP request and reads what comes back. That is still valuable, and the tools that do it are not obsolete.

The response tells you the status code, the redirects, the headers, whether robots directives and a canonical were present before any script ran, which links were immediately crawlable, and what body content existed without JavaScript.

A purely client-rendered application may return little more than a mounting element:

<div id="root"></div>

When an HTML parser reports that this response contains no heading and no body copy, it is not hallucinating. That content genuinely was not there yet. That is a real fact about what your server delivered, and it is exactly what a non-rendering crawler receives.

What the rendered DOM tells you

The browser adds the next layer. It fetches scripts, requests data, builds components, injects metadata, initializes forms, and attaches handlers.

That lets a browser-based audit see runtime content, JavaScript errors, failed requests, hydration behavior, client-injected JSON-LD, layout shifts, long tasks, accessibility problems in the finished DOM, and widgets that never initialized.

The rendered result is not automatically the correct one. It is a later stage of the same page.

Google processes both stages

This is where the usual framing gets it wrong, including our own earlier version of this article.

Google does not choose between the source and the rendered page. Its pipeline is crawl, then render, then index. Googlebot fetches the URL and parses the response first, extracting links and reading directives before any JavaScript executes. Eligible pages then go into a rendering queue, where Chromium runs the scripts and Google processes the rendered HTML as well. That queue can clear in seconds or take considerably longer.

One detail matters more than most people realize: Google does not click or scroll. Content that only appears after a user interaction may never reach the version Google indexes. Lazy-loaded content should load on viewport visibility, not on a scroll event.

So "it works in my browser" is not enough. And "Google renders JavaScript" is not a license to ship an empty document when the server could have sent something useful immediately.

The framework is not the diagnosis

React, Next.js, and Vue are not rendering strategies. A React app can be fully client-rendered, server-rendered, statically generated, or some hybrid. Next.js usually sends substantial HTML before hydration.

The question is never which framework is in the repo. It is what the server returned for this URL, and what changed after the scripts ran.

A parser can report a false problem, and a browser can hide a real one

If a page's H1 and JSON-LD are created by JavaScript, an HTML-only tool will report them missing and a browser-based tool will find them. Both are correct about the stage they inspected.

That does not automatically mean the site is broken. Google can process JavaScript-generated structured data once it exists in the rendered DOM. What the source report actually tells you is that those elements now depend on rendering succeeding, which is a dependency worth knowing about, not automatically a defect. It may be perfectly acceptable. It may also fail for a crawler that never runs scripts, during a runtime error, or when a third-party request times out.

The reverse trap is just as real. An auditor that scrolls the page, clicks controls, and waits out every background request can build a DOM that Google never receives. That tool will hand you a clean report on content Google cannot see.

For the record: DeepAudit does not scroll or click. It loads the page in Chromium, waits on a network-idle condition, and captures what is there. That is a deliberate choice, because Google does not interact with the page either. We would rather be limited in the same way our target is limited than produce a flattering DOM nobody else will ever build.

The difference is the finding

The most useful output is rarely the raw page or the rendered page on its own. It is what changed between them.

• Did the main body copy appear only after rendering?
• Did the canonical URL change?
• Did a second robots directive show up at runtime?
• Did the navigation disappear after hydration?
• Did structured data arrive only after a third-party request finished?
• Did the contact form exist in the browser but not in the response?

We measured exactly this gap across 368 small business websites. One in four omitted at least one answer-critical element from the initial HTML that was present after rendering. That study was built for this question, which is why we cite it here rather than borrowing a number from our general audit research.

A real example

We once chased product schema that some tools found and others did not.

The JSON-LD was injected by a third-party component after an asynchronous request completed. On some runs it entered the DOM before the audit's timeout. On others it did not. The markup was not wrong. Its availability was a race condition.

The fix was not to argue with the scanner. It was to move the JSON-LD into the server-rendered response so that its presence no longer depended on a component finishing in time.

Test all three versions

For any page that matters, look at three things:

1. The source response. View Source, not Inspect. Inspect shows the DOM after scripts have run.
2. The rendered page, with JavaScript enabled.
3. Google's own rendered result, via the URL Inspection tool in Search Console. That is the only view that tells you what Google actually built, and no third-party tool is Google.

In each one, search for the main heading, the body copy, the internal links, the canonical, the robots directives, the structured data, the contact details, and the conversion path.

When the versions disagree, do not just pick the one you like. Find out why.

An HTML-only audit can miss the entire application. A browser-only audit can miss how weak the document was before the application started.

Run the free audit if you want the rendered view. Then open View Source yourself and compare. The gap between those two is where the actual work is.