Raw vs. Rendered HTML Checker

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
Report a bug

Found something broken in Render Gap? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
 
 
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
 
12
 
1,840
 
 
 
Links
 
0
 
57
 
 
 
 
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
 
     
  1. 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.
    2.  
  2. 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.
    3.  
  3. 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.
    4.  
  4. Open the individual checks below the table for the specific JS-SEO
            issues, grouped Problems → Worth fixing → Notes → Passing.
    5.  
  5. 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).
    6.  
 
 
 
     
     
     
 
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.

People also explore
ToolSEO Incident SimulatorToolGoogle Index CheckerToolCanonicalization CheckerArticleJavaScript SEOArticlePage Indexed Without ContentArticleTechnical SEO
 
 
 
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.
 
     
  
  
 
 
 
 
      
 
Common issues & how to fix them
 
     
  •  Warning Initial document head closes unexpectedly early Fix: Fix the malformed head markup so metadata stays inside one valid <head> element in the initial HTML. 
  •  Error Title is missing Fix: Add one concise, unique <title> to the initial HTML that names the page’s primary topic. 
  •  Warning Title changes after rendering Fix: Make the server and rendered <title> values identical unless the client-side change is deliberately required. 
  •  Error Title appears only after JavaScript Fix: Emit the final <title> in the initial HTML instead of relying on JavaScript to insert it. 
  •  Warning Meta description is missing Fix: Add a page-specific meta description to the initial HTML that accurately summarizes the content. 
  •  Warning Meta description changes after rendering Fix: Align the initial and rendered meta descriptions so crawlers receive one consistent summary. 
  •  Error Initial and rendered canonicals conflict Fix: Choose the preferred absolute URL and make the initial and rendered canonical tags point to it. 
  •  Error JavaScript overwrites the canonical Fix: Keep one canonical in the initial HTML and stop client code from replacing it after render. 
  •  Warning Canonical exists only after rendering Fix: Move the canonical tag into the initial HTML instead of adding it only after JavaScript runs. 
  •  Error JavaScript removes noindex Fix: Remove noindex from the initial server response when the page should be indexed; do not rely on JavaScript to undo it. 
  •  Warning JavaScript adds noindex Fix: Stop client code from adding noindex to pages that should remain indexable. 
  •  Error Noindex remains after rendering Fix: Remove the noindex directive from both initial and rendered HTML when the page should be indexed. 
  •  Warning Nofollow remains after rendering Fix: Remove nofollow when crawlers should follow the page’s links, or scope it only to links that require it. 
  •  Warning hreflang appears only after rendering Fix: Emit every hreflang annotation in the initial HTML or HTTP headers instead of adding it only with JavaScript. 
  •  Warning hreflang changes after rendering Fix: Make the initial and rendered hreflang sets identical, reciprocal, and pointed at the intended locale URLs. 
  •  Error Important content appears only after rendering Fix: Server-render or statically generate the important copy so it exists in the initial HTML. 
  •  Warning Substantial content is added after rendering Fix: Move the essential JavaScript-added copy into initial HTML and leave only nonessential enhancements to the client. 
  •  Warning Important links appear only after rendering Fix: Expose important destinations as ordinary <a href> links in the initial HTML. 
  •  Error Rendered links are not crawlable URLs Fix: Replace onclick, javascript:, or button navigation with crawlable <a href> URLs. 
  •  Warning Rendered images lack alt attributes Fix: Add concise alt text to meaningful rendered images and empty alt attributes to decorative ones. 
  •  Error Robots.txt blocks rendering resources Fix: Allow Googlebot to fetch the blocked JavaScript, CSS, or data resources required to render the page. 
  •  Warning Rendering produces console errors Fix: Fix the named client-side exception and confirm essential content still renders on a cold load. 
  •  Warning Rendering has failed resource requests Fix: Restore, correctly route, or remove each failed resource request required by the rendered output. 
  •  Warning Important content is hidden in the rendered DOM Fix: Make the important DOM content visibly available by default or through an accessible expandable control. 
  •  Warning Important content requires interaction Fix: Put the full content in the loaded DOM or give it a crawlable URL instead of requiring a click or scroll. 
  •  Error Rendered page looks like a soft 404 Fix: Return 404/410 for a missing page, or replace the thin error-like body with substantive content at the 200 URL. 
  •  Warning JavaScript redirects the page Fix: Replace the JavaScript redirect with an appropriate server-side 3xx response to the final URL. 
  •  Information Structured data is absent Fix: Add accurate JSON-LD for the page’s primary supported entity when structured data is appropriate. 
  •  Warning Structured data appears only after rendering Fix: Emit the validated JSON-LD in initial HTML instead of inserting it only after JavaScript runs. 
  •  Information Page depends on a WebSocket during render Fix: Render essential content without requiring an open WebSocket, and provide a resilient HTTP or server-rendered fallback. 
  •  Warning Viewport meta tag is missing Fix: Add <meta name="viewport" content="width=device-width, initial-scale=1"> to the initial head. 
  •  Error Critical content depends on client rendering Fix: Server-render or prerender the title, H1, links, and primary content in the initial HTML. 
  •  Warning Page relies on hash routing Fix: Switch the router to history-mode paths that the server can resolve without a URL fragment. 
  •  Warning Title element is outside the HTML head Fix: Move the title into the document head and keep exactly one non-empty title value there. 
  •  Warning Canonical element is outside the HTML head Fix: Move the intended canonical link into the document head and remove body-level canonical declarations. 
  •  Warning Initial HTML contains conflicting canonicals Fix: Emit one canonical URL in the initial HTML instead of relying on JavaScript to repair conflicting declarations. 
    •