SSR Checker

How it works

1. Fetch the URL twice in parallel, without executing JavaScript: once with a desktop Chrome user agent, once with the Googlebot user agent
2. Follow redirects (max 5) and record the final URL, HTTP status, time to first byte and response headers (server, CDN, cache status)
3. Parse the raw HTML: title, meta description, canonical, lang, robots directives, H1s, <a href> links, images, JSON-LD types, meta refresh
4. Strip scripts, styles, noscript, templates and SVG, then count the words of visible text — what a first-wave crawler indexes
5. Detect the stack from markup markers: __NEXT_DATA__ / self.__next_f (Next.js), __NUXT_DATA__ (Nuxt), __remixContext, ng-version + ng-server-context (Angular), astro-island, SvelteKit, Qwik, CMS generators, and empty <div id="root"> / <div id="app"> shells
6. Compare the two responses: a 403/429 for Googlebot means bots are blocked; far more text for Googlebot means dynamic rendering
7. Score 0–100 from content (up to 40), non-empty app container, title, H1, links, canonical, JSON-LD, lang and script weight; verdict: server-rendered, partially rendered or client-rendered

About server-side rendering and SEO

Server-side rendering (SSR) means the HTML your server returns already contains the page — headings, text, product data, links. Client-side rendering (CSR) means the server returns a near-empty shell and the browser assembles the page by running JavaScript. Both look identical to a person with a modern browser. They look completely different to anything that reads the HTML without executing scripts: the first wave of Google's crawler, Bing, link previews on Slack, WhatsApp and LinkedIn, most AI crawlers and answer engines, and a large share of SEO tools.

Google does run JavaScript, but in a second, deferred pass that depends on crawl budget and can lag the first fetch by hours or days. A CSR page therefore gets indexed later, with its links discovered later, and any hiccup in the rendering pipeline — a blocked script, a timeout, an API that needs a cookie — leaves the page indexed as the empty shell it shipped. Frameworks like Next.js, Nuxt, Remix, SvelteKit, Astro and Angular exist to solve this by rendering on the server first and then hydrating in the browser; this checker tells you whether that is actually what your production deployment does.

The tool reads the raw HTML, so it can answer the question a rendered screenshot cannot: what is in the document before any script runs? It counts the words of visible text, checks that the application container (#root, #app, #__next, #__nuxt) is not empty, verifies the head elements that need to be in the initial HTML — title, meta description, canonical, lang — and reads the rendering mode from the markers the frameworks leave behind, such as Next.js' __NEXT_DATA__ with its gssp/gsp flags or the React Server Components payload in self.__next_f.

Fetching as Googlebot alongside a normal browser adds two things a single request cannot show. If the bot gets a 403 or 429 while the browser gets the page, a WAF or bot-protection rule is blocking crawlers — a surprisingly common cause of pages that will not index. If the bot gets substantially more text than the browser, the site uses dynamic rendering or a prerender service for crawlers, which is legitimate but must be kept in sync with the real page. Everything happens in memory on our side: the page HTML is analysed and discarded, and only the derived numbers plus a 500-character text sample are returned.

Frequently asked questions

How do I know if my site is server-side rendered?

Paste the URL here. If the HTML already contains your headings, text and links — the checker shows hundreds of words, a non-empty app container and a filled title — the page is server-rendered or statically generated. If it shows a handful of words and an empty #root or #app, the content is built by JavaScript in the browser. You can confirm manually by viewing the page source (not the DevTools inspector, which shows the rendered DOM) or by disabling JavaScript.

Does the checker execute JavaScript?

No, on purpose. It shows what the server sends, which is exactly what first-wave crawlers, link-preview bots, most AI fetchers and many SEO tools see. Google's Rich Results Test and URL Inspection in Search Console show the rendered result after JavaScript; use both views together: this one to know what ships, Google's to know what it renders.

What does 'partially rendered' mean?

The HTML contains a shell with some content — often a header, footer and navigation from the server, while the main content (a product list, an article body, search results) is fetched and drawn by JavaScript after load. It is also the verdict for a Next.js getStaticProps page served as a fallback shell, or for pages where the visible text is tiny relative to the script payload. Check which content is missing from the text sample and move it into the initial HTML.

Why does Googlebot get a different result than the browser?

Three usual reasons. A WAF or bot-protection rule blocks the Googlebot user agent (HTTP 403/429/503) — real Googlebot also verifies by IP, but a UA-based block is a strong hint. A dynamic-rendering setup (Rendertron, Prerender.io, a CDN worker) serves pre-rendered HTML to crawlers only. Or the site personalises by user agent and language. The first needs fixing; the second is fine as long as both versions carry the same content; the third is worth checking for cloaking risk.

Is a client-rendered page always bad for SEO?

Not always, but it is always slower and riskier. Google will usually render and index it eventually; Bing and most other engines, social previews and AI crawlers will not. For pages that need to rank or be shared — landing pages, product pages, articles — the content should be in the initial HTML. Behind-login dashboards and app screens that never need indexing can stay client-rendered.

Which frameworks and platforms does it recognise?

Next.js (App Router vs Pages Router, and getServerSideProps vs getStaticProps), Nuxt 2 and 3, Remix, React Router 7, Gatsby, Astro, Docusaurus, SvelteKit, SolidStart, Qwik, Angular (with or without SSR), plain React and Vue apps by their mount point, and the usual server-rendered platforms: WordPress, Shopify, Wix, Webflow, Squarespace, Framer, HubSpot, Drupal, Joomla, Ghost, Magento, Hugo, Jekyll, Eleventy and the Turkish e-commerce platforms Ticimax, IdeaSoft and T-Soft. Anything else is judged purely on its HTML content.

Is the URL or page content stored?

No. The page is fetched into memory, analysed and discarded; the endpoint sets no-store, keeps no log of URLs, and only answers requests coming from insighthackerz.com. What you see on this page — counts, headers, a 500-character text sample — is everything that leaves the server.