Does this execute JavaScript?

No. It only evaluates the initial HTML payload the fetch API returns.

Framework fingerprints plus low visible text relative to HTML size suggest partial SSR or streamed islands.

Can I compare rendered DOM?

Not here. Use headless Chrome, Puppeteer, or your crawl vendor for rendered versus raw diffs.

Will noscript save me?

The tool notes noscript text but does not treat it as a full SEO strategy. Prefer real HTML content.

Technical SEO

Live

JavaScript Rendering Checker

Compare rendered vs. raw HTML to find JS-blocked content.

URL

Compare raw HTML signals to detect client-side rendering issues.

X / Twitter LinkedIn Facebook

Start here · What is JavaScript rendering risk?

Crawlers often execute JavaScript now, but thin or delayed HTML still delays indexing and snippet quality.

This checker downloads HTML once through /api/fetch, strips script and style tags to measure visible text length, counts scripts, inspects noscript, detects common SPA root div patterns, guesses frameworks from fingerprints, and applies heuristics for server, hybrid, or client-rendered verdicts.

It is a triage screen—not a headless Chrome comparison. Pair it with on-page tests when stakes are high.

When to use this tool

SPA launches
Run before go-live to catch empty #root shells with almost no prerendered copy.
Marketing microsites
Lightweight landing pages should show substantive text in the first HTML response.
Vendor CMS reviews
Compare how different themes hydrate versus shipping meaningful H1 and body text upfront.
Debugging Indexing API gaps
When URLs lag in Search Console, confirm the fetch sees enough text before blaming links.

Examples

Walk through these with the form above — they are practice scenarios, not live data.

Healthy server-rendered page

Try this

Try a Wikipedia-style article URL with thousands of characters in body text.

What to look for

High visible text length, server-rendered badge, recommendation praises HTML copy presence.

Client-heavy bundle

Try this

Test a marketing SPA with a huge JS payload and empty root shell.

What to look for

Client-rendered verdict with guidance to add SSR, prerender, or static generation.

Short tutorial

Follow in order the first time you use the tool; later you can skip to the step you need.

Step 1 — Enter a public https URL
Use the canonical URL search engines fetch. Auth walls may error.
Step 2 — Click Check
Wait for /api/fetch to return HTML bytes and status.
Step 3 — Read verdict and recommendation
Green server-rendered is ideal for fast SEO signals. Amber hybrid means verify critical modules. Red client-rendered needs engineering.
Step 4 — Inspect metrics
Visible proportion, script counts, framework guess, and prerendered H1 explain why the verdict fired.
Step 5 — Cross-check with Mobile-Friendly and audits
Use Mobile-Friendly Checker or the Full Site Audit for complementary signals.

More detail

New here? Skim Start here first, then run one Examples scenario in the form above.

JavaScript Rendering Checker does one job: compare rendered vs. raw HTML to find JS-blocked content. It lives under Technical SEO on SEOToolkits, where the beginner idea is simple: Technical SEO keeps pages crawlable, indexable, fast enough, and understandable to search engines.

FAQ

Does this execute JavaScript?: No. It only evaluates the initial HTML payload the fetch API returns.
Why hybrid?: Framework fingerprints plus low visible text relative to HTML size suggest partial SSR or streamed islands.
Can I compare rendered DOM?: Not here. Use headless Chrome, Puppeteer, or your crawl vendor for rendered versus raw diffs.
Will noscript save me?: The tool notes noscript text but does not treat it as a full SEO strategy. Prefer real HTML content.