Initial HTML and rendered DOM are different evidence

Two captures answer two different questions

Initial HTML is the representation returned by the server before page scripts run. It can be recorded with status, headers, bytes, title, meta directives, canonical, headings, text, and links found in that response.

The rendered DOM is the document after a browser has parsed the response, loaded allowed resources, executed JavaScript, and applied client-side changes. It may add text and links, replace metadata, open a consent gate, or fail before the main content appears.

Why the difference matters

Google documents crawling, rendering, and indexing as separate stages. It parses the fetched response, can queue eligible 200 pages for rendering, and then processes the rendered HTML again. Rendering can take longer, and blocked or failed resources can change the result.

That does not mean every crawler behaves like Google. Google explicitly notes that not all bots run JavaScript. A clean server response therefore remains the most portable evidence available across search crawlers, link previewers, accessibility tools, monitors, and simple diagnostic clients.

Run a comparison that another person can reproduce

1. Record the exact public URL, timestamp, status, redirect chain, response headers, and raw initial HTML.
2. Open the same final URL in a fresh browser context without an authenticated session.
3. Wait for a stated event, such as network idle or a fixed application-ready marker, rather than an arbitrary screenshot delay.
4. Export or inspect the rendered DOM and record console or resource errors that affected it.
5. Compare stable fields: title, meta robots, canonical, language, H1, main text, crawlable href links, and structured data.
6. Repeat after the suspected fix with the same browser, viewport, consent state, and timing rule.

Differences that deserve attention first

A difference is not automatically an SEO defect. An interactive calculator can reasonably produce a result after input. The risk rises when the page's identity, core answer, navigation, or index controls depend on a script path that can fail or remain unavailable to the intended crawler.

• the initial HTML has no useful main text, but the DOM adds the entire answer;
• important links exist only after an interaction or failed API call;
• the canonical or robots directive changes after JavaScript;
• the server returns a generic shell or challenge while the browser later shows the page;
• the rendered DOM removes content that was present in the response;
• structured data describes content that never becomes visible to the user.

Do not turn user-agent switching into a content strategy

Google no longer recommends crawler-specific dynamic rendering as a long-term solution. Server-side rendering, static rendering, or hydration usually creates a simpler shared baseline for people and crawlers.

Serving materially different subject matter to a detected crawler also creates a cloaking risk. The useful target is equivalent content and meaning, even when an interactive browser adds controls or state around it.

What AnalyseSpider sees today

The crawler view records one bounded HTTP response and does not execute page JavaScript. Its “main content detectable” result therefore describes the delivered HTML, not the final browser DOM. This makes the result narrow but reproducible.

The crawler fixture contains a JavaScript-only link case so later tests can compare discovery from source HTML with discovery after rendering. No public result currently claims that a particular external crawler executed that script or indexed its target.

Report the difference plainly: “The initial HTML contains the title and canonical but no main answer. The rendered DOM adds 1,240 visible characters and six links after the application request succeeds.” Then verify the indexing state separately.