Raw vs. Rendered HTML Checker

Q: Is a JavaScript-inserted canonical or noindex respected by Google?

Google may skip rendering after it sees noindex in the initial HTML, so JavaScript cannot reliably remove that directive later; rendered-only noindex can also be used. For canonicals, JavaScript may add one when the initial HTML has none, and setting the same value is okay. Changing it to a different value or leaving multiple values creates risky competing input.

Free, no signup. Open the page in a browser and it looks complete; Google sees raw HTML first, then runs JavaScript and looks again — and those two views don't always agree. Test a public URL through the bounded rendering service to find where they diverge, with a side-by-side raw-vs-rendered diff.

Built by Patrick Stox

Free, no sign-up. The page is rendered in headless Chrome only when the initial HTML looks incomplete — most server-rendered sites never need it.

Checks run from our server; we fetch the URL you enter and don't keep the results. Reports are kept 7 days so you can share a link to the result. Anonymous aggregate stats feed our research posts; domains are counted once via an anonymized hash and never stored in the clear. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback

Sample report

Say you test a product page whose server response is essentially an empty container — the real content is painted in by a client-side framework. The initial HTML the tool fetches looks like this:

<div id="root"></div>
<script src="/assets/app.4f2c.js"></script>

…and the tool returns a verdict, a field comparison, and a flagged check:

Illustrative example — a live check renders the page in headless Chrome via this site's Browser Rendering binding, which this static page can't invoke; the verdict shape and thresholds shown match the real tool

Key content is missing until JavaScript runs

React · rendered in 4.2s · probed 0 expanders

Initial HTML what Googlebot reads first

Rendered DOM after JavaScript runs

Title

—

changedTrail Runner GTX — Waterproof Running Shoe

Words

1,840

Links

Error

Body content only appears after rendering

The initial HTML has 12 words; the rendered DOM has 1,840. Almost all of the page’s content and its 57 internal links depend on successful JavaScript rendering and are absent from the initial response.

The red verdict is the headline — nothing meaningful is in the server HTML at all, before JavaScript runs. See what each verdict color means ↓.
Title, words, and links all flip from empty to populated — the split table shows Googlebot's first read (12 words, 0 links) versus the rendered DOM (1,840 words, 57 links), which is the classic client-side-rendering render gap, not a partial one.
The fix is server-rendering, not just faster JavaScript — pre-rendering or SSR ships the title, copy, and links in the initial HTML so Google's first pass already sees them. More on this trade-off in JavaScript SEO.

Two less-obvious render gaps to test

1. Content arrives after an arbitrary timer or slow dependency.

<main id="product"></main>
<script>
  setTimeout(async () => {
    const product = await fetch('/api/product/42').then(r => r.json());
    document.querySelector('#product').textContent = product.description;
  }, 8000);
</script>

There is no universal five-second Google rendering cutoff. The practical problem is that important copy now depends on an eight-second timer, a second request, and successful JavaScript execution. A bounded renderer may capture the empty state, while a different run may capture the completed state. Test repeatedly, inspect runtime errors, and move essential content into the initial HTML rather than tuning the timer.

2. Correct signals occur after the fetched response prefix.

<!-- 2,180,000 bytes of inline application state appear first -->
<link rel="canonical" href="https://example.com/products/trail-runner">
<main>Product copy, structured data, and internal links...</main>

Google documents an approximately 2 MB fetch limit for supported non-PDF files. If oversized inline state pushes the canonical, main copy, structured data, or links beyond that boundary, those signals can be correct in View Source and still fall outside what Googlebot fetched. This tool treats truncated acquisition as not evaluated, not as proof that a missing signal does not exist. Reduce the response and keep critical markup early.

How to use it

Paste the full URL of the page you want to test into the box — the exact page, not just the homepage. A JavaScript-heavy template page is the most revealing.
Clear the anti-abuse check (Turnstile) and press Test page. The tool fetches the raw HTML first; if that looks like an empty shell, it renders the page in headless Chrome. Rendering, when it happens, takes roughly 10–20 seconds.
Read the coloured verdict at the top, then scan the Initial HTML vs Rendered DOM table for rows flagged changed — those are the fields JavaScript altered.
Open the individual checks below the table for the specific JS-SEO issues, grouped Problems → Worth fixing → Notes → Passing.
Switch to the Raw vs rendered diff tab to see line-by-line what JavaScript added or removed, and use Copy share link to save a report (kept 7 days).

What this is checking

The render gap

Google can process JavaScript in a rendering phase after crawling. Content that appears only after rendering depends on that phase and is absent from the initial response; this comparison does not predict discovery or indexing timing.

The most restrictive rule wins

If a noindex appears in either the raw or rendered HTML, Google may use it — and an initial-HTML noindex may cause Google to skip rendering, so JavaScript cannot reliably undo it.

Canonicals are conditional

JavaScript may add a canonical when the raw HTML has none, or keep the same value. A different or additional value creates competing canonical input.

Checks based on the JavaScript SEO guide on Ahrefs. Confirm findings in Search Console.

What the results mean

The verdict banner rolls the whole test into one of three levels:

Good (green) — the initial HTML already carries the important content and tags; JavaScript adds little or nothing that matters for indexing.
Warning (amber) — the page works but leans on rendering more than it should, e.g. some content or links only appear after JavaScript, or a tag differs between the two versions in a non-fatal way.
Problem (red) — something that can keep the page or its content out of search: an empty shell, a rendered-only noindex, a canonical conflict, or blocked resources.

Each individual check carries a severity badge:

Error — a real indexing risk to fix.
Warning — worth fixing; a fragility or inefficiency, not a hard block.
Information — a note or observation (framework detected, minor difference).
Pass — this aspect is healthy.

In the comparison table, a row tinted amber with a changed flag means that field—title, meta description, canonical, robots, word count, links, H1s, images without alt, structured-data blocks, or hreflang—is not the same in the initial HTML as in the rendered DOM.

How it works

A small Worker endpoint fetches your page’s raw HTML and its robots.txt. Only when that initial HTML looks incomplete does it render the page in headless Chrome (behind a cost ledger; a skipped render means the raw heuristic found substantial content, not that SSR or parity was proved). It returns both HTML versions to your browser.

Everything analytical then runs client-side. Each HTML version is parsed with an inert DOMParser (scripts in the fetched HTML never execute), reduced to a snapshot of the fields that matter, and run through roughly fifteen calibrated JS-SEO checks. The tool detects the framework, builds the verdict, and produces the line-by-line raw-vs-rendered diff you see in the second tab. No sign-in, and reports are stored for seven days only for sharing.

Features

Side-by-side Initial HTML vs Rendered DOM table across ten fields, with every JavaScript-driven change flagged.
Around fifteen calibrated JS-SEO checks grouped by severity (Problems, Worth fixing, Notes, Passing), each with a plain-English summary and evidence.
A line-by-line raw-vs-rendered diff — green lines exist only after JavaScript runs; red lines were dropped from the rendered DOM.
Framework detection (React, Vue, Angular, and others) shown in the verdict meta line.
Renders in headless Chrome only when the raw-content heuristic requests it, and reports whether a render happened, was skipped without claiming SSR parity, or was unavailable.
Robots-aware: flags when robots.txt blocks the JavaScript or CSS Google needs to render the page.
Shareable reports kept for seven days; no sign-up, nothing stored beyond that.

Limitations

This is a fast, directional check — not Google’s renderer. Its headless Chrome is not the exact evergreen build Google uses, timing and network conditions differ, and it renders one page at a time. It will not click through complex interactions beyond probing common content expanders, and very large pages are truncated for analysis. When the initial HTML already looks complete, no render runs, so there is nothing to diff. For any finding that affects whether a URL is actually indexed, confirm it in Google Search Console’s URL Inspection tool, which runs Google’s own renderer on your verified property.

Frequently asked questions

What is the render gap in JavaScript SEO?

The render gap is the difference between what a page contains in its raw, server-delivered HTML and what it contains after the browser runs JavaScript and builds the final DOM. Google can process JavaScript in a rendering phase after crawling. Anything that appears only after JavaScript runs depends on successful rendering and is absent from the initial response. This tool measures that dependency; it does not predict when Google will discover or index the content.

Does Google actually render JavaScript?

Yes. Google renders pages with an evergreen Chromium, so client-side content can be indexed. Rendering is a separate processing phaseTurning HTML, CSS, and JavaScript into the final visual page and DOM., and blocked resources or JavaScript errors can prevent content from appearing in rendered HTML. Google Search does not interact with a page to load content, so content that requires an interaction must already be present in rendered HTML to be available. Putting critical content and tags in the server response removes that rendering dependency.

Why does this tool sometimes not render my page?

Headless Chrome runs only when a bounded heuristic says the initial HTML looks incomplete. Substantial raw titles, links, and body text can make the tool skip rendering, but that does not prove the framework is server-rendered or that JavaScript would add nothing. A skipped run gives an initial-HTML analysis without a rendered parity comparison.

Is a JavaScript-inserted canonical or noindex respected by Google?

Google may skip rendering after it sees noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. in the initial HTML, so JavaScript cannot reliably remove that directive later; rendered-only noindex can also be used. For canonicals, JavaScript may add one when the initial HTML has none, and setting the same value is okay. Changing it to a different value or leaving multiple values creates risky competing input.

Is this the same as Google Search Console’s URL Inspection tool?

No, and it is not meant to replace it. This is a fast, directional comparison. Search Console’s URL Inspection toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate "Test live URL" mode fetches the current version. provides Google-specific crawl, indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and live-test evidence for a verified property, but neither tool guarantees how a URL will be processed on a later crawl.

Next stepXML Sitemap Generator — generate the corrected version.

Feature requests for Render Gap

Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.

Loading…

➕ Request a feature

New requests are reviewed before they appear here.

Where this tool helps

Common use cases

Compare raw and rendered HTML

See which links, metadata, directives, and content appear only after JavaScript runs.

Diagnose a JavaScript SEO problem

Review calibrated checks for changed canonicals, noindex, robots blocking, link loss, and soft-404 signals.

Identify the rendering strategy

Use the observed HTML differences to classify the page as server-rendered, prerendered, client-rendered, or hybrid.

Verify a rendering fix

Rerun the page after deployment and confirm that important search signals are present in the intended HTML state.

Watch the full workflow

Raw vs. Rendered HTML Checker walkthrough

Read the transcript