Technical SEO / AEO
JavaScript Rendering SEO Risk Checker
Paste a page's full HTML source (View Page Source / Ctrl+U output) to see exactly what a non-JavaScript-executing crawler sees — including every AI answer engine crawler — versus what only shows up after your framework hydrates the page.
Use "View Page Source" (Ctrl+U), not the DevTools Elements panel — Elements shows the DOM AFTER JavaScript has already run, which defeats the point of this check. Nothing is sent anywhere except our server for this one-time analysis.
What this tool checks
Googlebot eventually executes JavaScript, but only in a second, resource-budgeted rendering wave that can lag by days or get skipped entirely on a low-crawl-budget site. Most other crawlers that matter today — Bingbot at reduced scale, and virtually every AI crawler (GPTBot, ClaudeBot, PerplexityBot, CCBot) and social-preview bot (Twitterbot, facebookexternalhit, LinkedInBot) — never execute JavaScript at all. This tool parses your pasted static HTML with a real DOM parser and reports whether your title, meta description, canonical tag, H1, structured data, and actual body copy exist in that static markup, or only appear once your JS framework hydrates the page.
How the analysis works
The pasted HTML is parsed into a real DOM (not a naive regex scan), then checked against the exact signals a non-rendering crawler would use to understand and index the page.
Static SEO tag presence
Title, meta description, and rel="canonical" are read straight from the parsed markup. A framework that injects these via JavaScript (a common React/Vue router pattern) will show them as missing here — exactly as a non-rendering crawler would see it.
Body copy vs. document size
Script, style, and noscript content is stripped out, then the remaining visible text is measured against the total document size. A page that is mostly a <script> bundle wrapped around a near-empty body is the classic client-side-rendering (CSR) signature.
Framework root-container detection
Common SPA mount points — #root, #app, #__next, #__nuxt, #___gatsby, #svelte, Angular's ng-version, React's data-reactroot — are located and their inner text is measured. An empty root container plus a near-empty body is strong evidence the entire page is built client-side after load.
noscript fallback quality
The <noscript> block is checked for real fallback content versus a generic "please enable JavaScript" message, since that block is literally the only thing a non-JS-executing visitor or crawler will ever see besides the raw HTML.
Which crawlers actually execute JavaScript
This is the real reason static, server-visible SEO signals still matter in 2026 — most of the crawlers that decide AI-answer citations and social previews never run a script at all.
| Googlebot | Deferred | Executes JavaScript, but only in a second, resource-budgeted rendering wave — indexing of JS-only content can lag by days or be skipped on crawl-budget-constrained sites. |
| Bingbot | Limited | Renders JavaScript at a smaller scale and tighter budget than Google. Static content is the safer bet. |
| GPTBot / ChatGPT-User (OpenAI) | No | Fetches raw HTML only. Content that appears only after JavaScript runs is invisible to it — directly affecting whether ChatGPT can cite your page. |
| ClaudeBot (Anthropic) | No | Fetches raw HTML only, same limitation as other AI crawlers — directly affects whether Claude can cite your page. |
| PerplexityBot | No | Fetches raw HTML only — this directly affects AI-answer citation eligibility in Perplexity. |
| CCBot (Common Crawl) | No | Feeds numerous AI training datasets; crawls raw HTML only, no JavaScript execution. |
| facebookexternalhit / Twitterbot / LinkedInBot | No | Social link previews (Facebook, Twitter/X, LinkedIn) are built entirely from static meta tags fetched with no JavaScript execution. |
| Most SEO / backlink crawlers | No | Most SEO/backlink crawlers (Ahrefs, Semrush and similar) parse raw HTML only, for speed and cost reasons. |
Frequently asked questions
My site uses Next.js/Nuxt with server-side rendering — will this flag it as risky?
No. Server-side rendering (SSR) and static generation (SSG) output your title, meta tags, H1, and body copy directly into the HTML response, so this tool will read them as present, and the framework root container will contain real text instead of an empty shell. This tool specifically flags client-side-only rendering (CSR), where the initial HTML response is a near-empty shell that only fills in after a JavaScript bundle downloads and runs.
Why does "View Page Source" matter more than the DevTools Elements panel here?
The Elements panel shows the live DOM after your browser has already executed every script — it always looks complete, even on a pure CSR site, because your browser just rendered it. "View Page Source" (or a plain curl/wget fetch) shows the actual bytes a non-rendering crawler receives, before any JavaScript runs. That is the only view that matches what GPTBot, ClaudeBot, Twitterbot, and most SEO crawlers actually see.
Does Google really not see my JavaScript-rendered content properly?
Googlebot generally does render JavaScript, but on a delayed, separate rendering wave with a real resource budget — Google itself has documented indexing lag and occasional render failures for JS-heavy pages. For content you need indexed reliably and quickly, and for every AI-answer or social-preview crawler that does not render JavaScript at all, static HTML presence is what actually guarantees visibility.
Does this tool store or share my pasted HTML?
Your pasted HTML is sent once, over HTTPS, to our server to run this one-time parsing and analysis (needed to keep the DOM-parsing logic consistent and not exposed as copyable client code), and is not stored beyond that request.