SEO

JavaScript rendering parity check

Use when a JavaScript site indexes oddly and you need to know what is missing before render.

js-rendering-parity-check.md

Download .md

You are comparing raw HTML against rendered HTML to find content that depends on JavaScript. You are not debugging application code.

Raw HTML, as served: {{RAW_HTML}}
Rendered HTML, after JavaScript runs: {{RENDERED_HTML}}
Framework and rendering mode: {{FRAMEWORK}}
Elements that must be crawlable: {{KEY_ELEMENTS}}

Output five numbered sections.

1. Parity table: Element | Present in {{RAW_HTML}}? | Present in {{RENDERED_HTML}}? | Verdict (Safe / At risk / Missing) | Consequence. Cover every item in {{KEY_ELEMENTS}} plus title, canonical, meta robots, H1, body copy, main navigation and pagination.
2. Links that exist only after rendering, each with the pattern responsible: click handler, button, hash route, infinite scroll, tab or accordion.
3. Root cause, read against {{FRAMEWORK}} and its rendering mode.
4. Fix options, ranked, each naming the change (server render, static generation, prerender, moving the tag into the served document) and what it costs the team.
5. Checks to run once the fix ships.

Constraints:
- Judge only what is in the two pastes. If something is absent from both, write "absent from both, not a rendering issue".
- Do not state timings for when a crawler renders a page. Say only whether the content depends on JavaScript.
- Quote the exact tag or line as evidence behind every Missing verdict.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{RAW_HTML}}
{{RENDERED_HTML}}
{{FRAMEWORK}}
{{KEY_ELEMENTS}}

Getting a better result

Take the raw HTML from a plain fetch, not from the browser inspector, which shows you the rendered DOM.
Test a template page and a deep page, since routing problems only show on the second.
Watch section 2 closely - links behind click handlers are the usual reason deep pages never get found.

Questions about this prompt

When is this the right check rather than a crawl?

When a JavaScript site indexes strangely: pages in the index with no body copy, deep pages never discovered, titles that do not match what you wrote. A crawl reports what one tool saw. This compares two documents you supply for the same URL, which is what settles whether the content depends on JavaScript.

What do I need before running it?

Raw HTML taken from a plain fetch or view-source, the rendered HTML after scripts run, the framework and its rendering mode, and a list of elements that must be crawlable. Take the raw copy from curl rather than the browser inspector, which shows you the rendered DOM under a misleading label.

What comes back?

A parity table covering title, canonical, meta robots, H1, body copy, navigation and pagination, then links that exist only after rendering, a root cause read against your framework, ranked fixes with their cost, and post-fix checks. Section two is the one to read first: links behind click handlers are why deep pages go undiscovered.

What goes wrong most often?

Testing the homepage or one template page only. Routing problems show up on the second click, so a deep page has to be in the sample. The other costly error is pasting inspector output as the raw document, which reports perfect parity and sends you looking for the problem somewhere else entirely.