Find out whether your content is in the raw HTML or only appears after JavaScript runs. Search engines and AI crawlers that don’t fully execute JS may miss client-side content — this flags pages at risk and explains the fix.
⚡ Interactive demo — sample data
Only 38 words are in the raw HTML — this sample page leans on JavaScript to render its content.
Text crawlers see without JS — 38 words in the raw HTMLIssue
Client-side app shell — Detected (Next.js): empty mount node, content injected by JSWarning
Framework fingerprint — /_next/ markers found in the HTML
Verdict — most content renders via JavaScript; non-rendering and many AI crawlers may see little. Consider server-side rendering or pre-rendering.Issue
Find out whether your content is in the raw HTML or only appears after JavaScript runs. Search engines and AI crawlers that don’t fully execute JS may miss client-side content — this flags pages at risk and explains the fix.
How it works
Enter your page URL
Paste any public URL and run the check. We fetch the page's raw HTML exactly as it arrives from your server — before any JavaScript runs — which is the same starting point every crawler sees on its first pass.
We measure what's in the raw HTML
We strip out scripts, styles and noscript, then count the actual readable words left in the body. We also count your JavaScript files and look for tell-tale single-page-app shells — an empty <div id="root"> / app / __next / __nuxt, or framework fingerprints like /_next/, data-reactroot and ng-version.
Read the verdict and decide on a fix
If there's little text and a heavy app shell, the page leans on JavaScript to render — content crawlers that don't run JS may miss it. We flag the risk and point you to the fixes: server-side rendering, static generation, pre-rendering or dynamic rendering. Note: this is a fast heuristic on the raw HTML — we do not execute JavaScript here. The full JS-rendered comparison is part of the paid audit.
What we check
Text visible without JavaScript — Counts the readable words present in the raw HTML body before any script runs. A near-empty body (under ~100 words) is a strong sign content is injected client-side and may be invisible to non-rendering crawlers.
JavaScript file count — Tallies external <script src> files and inline scripts. A large bundle (roughly 8+ external scripts) alongside thin HTML text suggests the page assembles its content in the browser rather than shipping it ready-made.
Client-side app shell — Looks for an empty mount point — <div id="root">, app, __next or __nuxt with nothing inside — which is the hallmark of a single-page app that paints content only after JavaScript executes.
Framework fingerprints — Detects React (data-reactroot), Next.js (/_next/), Angular (ng-version), Nuxt/Vue (__nuxt) and Vue (data-v-) markers in the HTML, so you know which stack is driving the rendering behavior.
Crawler-visibility verdict — Combines the signals into a plain-English call: either your main content is already in the raw HTML (crawlers see it without JS), or the page renders most content with JavaScript and is at risk with engines and AI crawlers that don't fully execute it.
Raw-HTML heuristic, not a full render — This check reads the HTML your server sends and does NOT run JavaScript — it's an honest, $0 first look. It tells you whether content is present pre-render, not whether a JS-capable crawler could eventually render it. The full executed-render comparison lives in the paid audit.
Common issues we catch
Empty root div, content painted by JavaScript — A React/Vue/Angular app ships <div id="root"></div> and builds everything inside it in the browser. The raw HTML has almost no text, so a crawler that doesn't render JS sees a blank page where your content should be.
Looks full in the browser, empty in view-source — The classic trap: the page is rich and complete on screen because your browser ran the JavaScript. View-source (the raw HTML) tells a different story. What crawlers and many AI bots fetch is the view-source version, not the rendered one.
Googlebot renders JS, but many other crawlers don't — Google can render JavaScript, but it happens in a deferred second wave that can delay indexing — and Bing, social-preview scrapers and a large share of AI crawlers fetch the raw HTML only. Relying on client-side rendering bets your visibility on every crawler being as capable as Google.
AI crawlers often miss JS-only content — The crawlers feeding ChatGPT, Claude, Perplexity and Gemini frequently grab raw HTML and don't execute heavy client-side JavaScript. If your content only exists after render, you can be effectively invisible in AI answers even while ranking fine in Google.
Critical content (title, copy, links) injected late — Even on a mostly-static page, key elements — the H1, body copy, or internal links built by JS — may be absent from the raw HTML. Crawlers can miss exactly the parts that carry your ranking and discovery signals.
Hydration mismatch hiding content — An SSR/SSG app can ship correct HTML and then a JavaScript hydration error wipes or fails to attach part of the page. Users still see it (or a flash of it), but the intended content path is broken — a subtle issue a raw-HTML look can hint at when text is thinner than expected.
Lazy-loaded content below the fold — Infinite-scroll feeds, tabbed panels and 'load more' sections often aren't in the initial HTML at all. They appear only on user interaction or scroll, so a crawler taking a single raw snapshot never sees them — pre-render or link to them directly.
Where this matters
React, Vue & Angular (SPAs) — Pure client-side single-page apps render into an empty mount node, so the raw HTML is mostly an app shell. Without server-side rendering or pre-rendering, their content is the most at-risk for crawlers that don't execute JavaScript.
Next.js & Nuxt — These frameworks can do server-side rendering or static generation — which puts content in the raw HTML — but can also be configured for pure client-side rendering. We surface the /_next/ and __nuxt fingerprints so you can confirm which mode a given page is actually using.
Google, Bing & social scrapers — Google renders JavaScript in a second pass that can delay indexing; Bing and social-preview scrapers (the bots that build link cards) largely read raw HTML only. Content that's missing pre-render is missing for them until — and unless — a render happens.
AI crawlers (ChatGPT, Claude, Perplexity, Gemini) — Many AI crawlers fetch raw HTML and skip heavy JavaScript execution. If your content only materializes after render, you risk being absent from AI answers even when traditional search still finds you.
Frequently asked questions
What does this checker actually do?
It fetches your page's raw HTML — the version your server sends before any JavaScript runs — and measures how much readable content is already there. It also flags single-page-app shells and framework fingerprints. It's a fast, free heuristic; it does not execute JavaScript, so it shows what a non-rendering crawler sees on first fetch.
Why does it matter if my content needs JavaScript to show?
Some crawlers don't run JavaScript, and others (like Google) run it in a delayed second wave. If your content only appears after JS executes, raw-HTML crawlers — including many AI bots, Bing and social scrapers — may see a near-empty page. That can cost you indexing, rich previews and AI-answer visibility.
Doesn't Google render JavaScript anyway?
Yes, Googlebot can render JavaScript — but in a separate, deferred pass that can slow indexing, and it isn't guaranteed for every page. Other crawlers and AI bots often don't render at all. Putting content in the raw HTML removes that dependency and gets you reliably seen by everyone.
What is an 'app shell' and why is an empty one a problem?
An app shell is the minimal HTML a single-page app ships — usually an empty <div id="root"> or similar — into which JavaScript later injects all the real content. If a crawler doesn't run that JavaScript, it sees the empty shell and none of your content.
How do I fix a JavaScript-rendering problem?
Get your content into the HTML before it reaches the crawler. The main options are server-side rendering (SSR — the server builds the HTML per request), static generation (SSG — pages pre-built at deploy time), pre-rendering (serving a cached rendered snapshot), or dynamic rendering (serving rendered HTML specifically to bots). SSR and SSG are the most robust.
Why does my page look full in the browser but the tool reports few words?
Your browser ran the page's JavaScript and built the content, so it looks complete. This tool measures the raw HTML before JS runs — the same thing a non-rendering crawler fetches. The gap between the two is exactly the content at risk of being invisible to those crawlers.
Will fixing this guarantee my page gets rendered correctly by crawlers?
It removes the biggest risk. Putting content in the raw HTML means crawlers don't have to render anything to see it. This tool can't confirm a successful JavaScript render — it only reads raw HTML. The full executed-render comparison, which checks what content appears after JS runs, is part of our paid audit.
Is some JavaScript on a page always bad for SEO?
No. JavaScript is fine — the issue is relying on it for your core content and links. Interactive widgets, analytics and enhancements can load via JS without harm, as long as your important text, headings and internal links are present in the raw HTML before any script runs.
This is one of several free SEO tools from Custom Web Audits.
For a complete, prioritized analysis of your whole website,
run a full audit.
