Technical SEO / AEO
JavaScript Rendering SEO Risk Checker
Paste your page's full HTML source (View Page Source / Ctrl+U output) to see exactly what a non-JavaScript-executing crawler can see — including every AI answer engine crawler — versus what only show up after your framework hydrate the page.
Use "View Page Source" (Ctrl+U), not the DevTools Elements panel — Elements shows the DOM AFTER JavaScript already run, defeat the whole purpose of this check. Nothing get sent anywhere except our server for this one-time analysis.
What this tool checks
Googlebot eventually will execute JavaScript, but only in a second, resource-budgeted rendering wave that can lag by days or kena skip entirely on a low-crawl-budget site. Most other crawlers that matter today — Bingbot at reduced scale, and almost every AI crawler (GPTBot, ClaudeBot, PerplexityBot, CCBot) and social-preview bot (Twitterbot, facebookexternalhit, LinkedInBot) — never execute JavaScript at all one. 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 after your JS framework hydrate the page.
How the analysis works
The pasted HTML get 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" read straight from the parsed markup. A framework that inject these via JavaScript (common React/Vue router pattern) will show as missing here — exactly how a non-rendering crawler sees it.
Body copy vs. document size
Script, style, and noscript content get stripped out, then the remaining visible text measured against the total document size. A page that mostly got <script> bundle wrapping 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 — get located and their inner text measured. Empty root container plus near-empty body is strong evidence the whole page built client-side after load.
noscript fallback quality
The <noscript> block get checked for real fallback content versus a generic "please enable JavaScript" message, because that block literally the only thing a non-JS-executing visitor or crawler will ever see besides the raw HTML.
Which crawlers really execute JavaScript
This is the real reason why static, server-visible SEO signals still matter in 2026 — most crawlers that decide AI-answer citations and social previews never run a script at all one.
| Googlebot | Deferred | Executes JavaScript, but only in a second, resource-budgeted rendering wave — indexing of JS-only content can lag by days or kena skip on crawl-budget-constrained sites. |
| Bingbot | Limited | Renders JavaScript at smaller scale and tighter budget than Google. Static content the safer bet lah. |
| GPTBot / ChatGPT-User (OpenAI) | No | Fetches raw HTML only. Content that appears only after JavaScript run invisible to it — directly affect whether ChatGPT can cite your page. |
| ClaudeBot (Anthropic) | No | Fetches raw HTML only, same limitation as other AI crawlers — directly affect whether Claude can cite your page. |
| PerplexityBot | No | Fetches raw HTML only — this directly affect 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) 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 lah. Server-side rendering (SSR) and static generation (SSG) output your title, meta tags, H1, and body copy direct into the HTML response, so this tool will read them as present, and the framework root container will have real text instead of empty shell. This tool specifically flag client-side-only rendering (CSR), where the initial HTML response is a near-empty shell that only fill in after a JavaScript bundle download and run.
Why "View Page Source" matter more than the DevTools Elements panel here?
The Elements panel show the live DOM after your browser already execute every script — always look complete, even on a pure CSR site, because your browser just rendered it. "View Page Source" (or a plain curl/wget fetch) show the actual bytes a non-rendering crawler receives, before any JavaScript run. That the only view that match what GPTBot, ClaudeBot, Twitterbot, and most SEO crawlers really see.
Does Google really cannot see my JavaScript-rendered content properly?
Googlebot generally do render JavaScript, but on a delayed, separate rendering wave with a real resource budget — Google itself document indexing lag and occasional render failures for JS-heavy pages. For content you need indexed reliably and fast, and for every AI-answer or social-preview crawler that don't render JavaScript at all, static HTML presence is what really guarantee visibility.
Does this tool store or share my pasted HTML?
Your pasted HTML get 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 not stored beyond that request.