Free tool
SSR checker: is this page server-side or client-side rendered?
Paste a URL to test whether it ships real content in its raw HTML (server-side rendering) or an empty shell for JavaScript to fill in later (client-side rendering). Checks the markup directly — no headless browser, no render.
What this SSR test checks
- Empty framework root elements — Checks #root, #app, #__next, #__nuxt and other common mount points for React, Vue, Angular, Next.js and Nuxt apps to see if they already contain text.
- Noscript fallback warnings — "Enable JavaScript to run this app" is the most direct signal a page ships — checked verbatim.
- Text-to-HTML ratio — How much of the page is visible text versus markup and script, as a secondary signal.
- Framework fingerprint — Detects Next.js, Nuxt, Gatsby, Remix, Angular, SvelteKit and Create React App markers in the raw HTML.
This is a markup heuristic against a single fetch, not a rendered comparison — it trades some accuracy for being free and instant. The full FAQLens scan runs a real browser render and diffs it against the raw fetch for a definitive answer.
SSR vs CSR questions
What is the difference between server-side rendering (SSR) and client-side rendering (CSR)?
Server-side rendering sends a browser or crawler complete HTML with the page content already in it. Client-side rendering sends a mostly empty HTML shell plus a JavaScript bundle, and the content is built in the browser after the JavaScript runs. A crawler that does not execute JavaScript sees the full page with SSR and an empty shell with CSR.
How does this SSR checker work?
It fetches the page once and reads the raw HTML, the same way a search engine or AI crawler receives it. It looks for known signs of client-side rendering — an empty React, Vue or Angular mount point, a noscript warning telling visitors to enable JavaScript, a low ratio of visible text to page size, and known framework markers — and reports each one individually rather than a single score.
Is this the same as opening dev tools and disabling JavaScript?
It checks the same underlying fact — what is present in the HTML before any script runs — but from the server side, in about a second, with no browser needed. It is a heuristic based on markup patterns, not a rendered comparison, so it can be wrong on an unusual page; the verdict says so when the signals do not agree strongly enough.
Why would a website not be server-side rendered?
Most single-page apps built with plain React, Vue or Angular (via create-react-app, Vite, or the Angular CLI, without an SSR framework layered on top) render entirely in the browser by default. Frameworks like Next.js, Nuxt, SvelteKit, Remix and Gatsby can render on the server or at build time, but a page inside one of them can still ship client-rendered if it opts out — which is why this checks the actual markup rather than assuming from the framework name.
Does client-side rendering hurt SEO and AI visibility?
Googlebot runs a full rendering pass, so a client-rendered page can still be indexed by Google. Most AI crawlers do not: GPTBot, ClaudeBot, PerplexityBot and OAI-SearchBot all fetch JavaScript files without executing them, so content that only exists after client-side rendering is invisible to them. A page can rank in Google and still be blank to ChatGPT.
Rendering mode is the precondition. Answering buyer questions is the product.
FAQLens tests every buyer-critical question against the text an AI can actually extract from your page, and drafts the wording for what is missing.