SERP.tools

CMS & Tech Stack Detector — See What Any Website Is Built On

Enter any URL to detect the CMS, JavaScript framework, analytics tools, CDN, and hosting. Every detection shows the exact signal that gave it away — no black box.

Enter any URL above to detect its CMS, JS framework, analytics, CDN, and hosting.

Works with any publicly accessible URL. Results include the evidence that triggered each detection.

How CMS Detection Works

Every CMS and framework leaves traces in the HTML it generates. Our detector fetches the page source from the server — the same HTML a search engine crawler sees — and runs it through a fingerprint engine that checks seven categories of signal:

Signals checked per URL

  • 1. Meta generator tag — <meta name="generator"> in the page head. Most CMSes set this by default. WordPress, Ghost, Joomla, and Drupal all expose version numbers here.
  • 2. HTTP response headers — server-added headers like X-Powered-By, X-Shopid, or X-Ghost-Cache-Status. Often the most reliable signal.
  • 3. HTML body patterns — path patterns like /wp-content/ in stylesheet links, or Nuxt's id="__nuxt" root element.
  • 4. Script src URLs — platform CDN domains in <script src="..."> attributes. Shopify loads from cdn.shopify.com, Framer from framerusercontent.com.

 

  • 5. JavaScript globals — inline script blocks often expose platform globals. Next.js writes __NEXT_DATA__ directly into the HTML; Wix injects wixBiSession.
  • 6. Cookies — response cookies in the Set-Cookie header. Drupal session cookies follow the pattern SESS[32 hex chars]; Shopify sets _shopify_y.
  • 7. URL patterns — some platforms are detectable from the URL alone. A *.myshopify.com domain is 100% Shopify; *.blogspot.com is always Blogger.
Static analysis only. This tool analyses the raw HTML returned by the server — the same source code you see in "View Source". It does not execute JavaScript. Technologies that only reveal themselves after JS runs (dynamically created globals, lazy-loaded scripts) may not be detected. Single-page applications with minimal server-rendered HTML will show lower confidence results.

What We Detect — 24 CMS Platforms + Stack

Our fingerprint database covers the platforms that power over 97% of all CMS-using websites. The remaining 3% are fragmented across hundreds of minor regional builders — and the ~41% of websites with no detectable CMS at all are custom-built or plain static HTML by design.

Platform Category % of all websites Primary signal
WordPress CMS 41.9% Meta generator + /wp-content/ paths
Shopify CMS 4.9% x-shopid header + cdn.shopify.com scripts
Wix CMS 4.1% Meta generator + parastorage.com CDN
Squarespace CMS 2.4% server: Squarespace header
Joomla CMS 1.5% Meta generator + Joomla JS global
Webflow CMS 0.9% Meta generator + Webflow global
Drupal CMS 0.8% Meta generator + X-Drupal-Cache header
Blogger CMS 0.5% Meta generator + blogspot.com URL
Next.js Framework 0.5% __NEXT_DATA__ in HTML
Magento CMS 0.4% mage-cache cookies + js/mage scripts
GoDaddy Website Builder CMS 0.4% Meta generator
Framer CMS 0.3% framerusercontent.com CDN
TYPO3 CMS 0.3% Meta generator + typo3conf/ paths
Ghost CMS 0.2% Meta generator + X-Ghost-Cache-Status
HubSpot CMS CMS 0.2% x-hs-hub-id header
Nuxt.js Framework 0.2% id='__nuxt' div + /_nuxt/ scripts
Astro Framework 0.1% Meta generator + astro-island elements
Gatsby Framework 0.1% Meta generator + ___gatsby div
Hugo Framework 0.1% Meta generator
SvelteKit Framework 0.1% data-sveltekit-preload + /_app/ scripts
Craft CMS CMS <0.1% X-Powered-By: Craft CMS header
Contentful CMS <0.1% x-contentful-request-id header
Sanity CMS <0.1% x-sanity-shard header
Strapi CMS <0.1% X-Powered-By: Strapi header

Market share data from W3Techs, May 2026.

Beyond CMS platforms, the detector also identifies analytics tools (Google Analytics 4, Google Tag Manager, Hotjar, Plausible), CDN providers (Cloudflare, Fastly), and hosting platforms (Vercel, Netlify, WP Engine) from response headers and script patterns.

Why We Show the Evidence

Every other free CMS detector is a black box — it tells you "WordPress" and gives you a confidence percentage with no explanation. We show the exact signal that triggered each detection: "Meta generator: 'WordPress 6.5.3'", "HTTP header x-pingback: /xmlrpc.php", "Script src: wp-content/themes/...".

This matters for SEO and security audits. If you're a consultant reviewing a client's site, you need to know why the tool reached its conclusion — and whether the signals are intentional or accidental leaks. A site exposing its WordPress version via meta generator is also exposing it to attackers scanning for vulnerable versions.

If you're trying to hide your tech stack, the evidence list tells you exactly what to suppress. The HTTP headers panel shows every response header, making it easy to identify unnecessary information disclosure.

🔍 Transparent detection

Every result shows which signal triggered it. No guessing why the tool reached its conclusion.

🛡️ Security insight

Version numbers exposed via generator tags are also visible to attackers. Know what you're leaking.

📡 Raw headers

Every HTTP response header is displayed in full — useful for debugging CDN configuration and server setup.

Related Tools

Robots.txt Validator

Check if this CMS is accidentally blocking crawlers or AI bots.

AI Bot Access Tester

Is this CMS blocking GPTBot, Claudebot, or Google-Extended?

Bulk Indexability Checker

Audit individual pages from this CMS for indexability issues.

Frequently Asked Questions

Why didn't you detect my CMS?
Several things can prevent detection. Security plugins (Wordfence on WordPress, Cloudflare Bot Management) suppress generator tags and custom headers. Headless setups decouple the CMS from the rendered HTML entirely. Sites that heavily restrict bot traffic may return a CAPTCHA page instead of the real HTML. Our tool relies on static HTML signals only — if a site removes all traces of its stack from the source, it is genuinely undetectable without browser-level execution.
What's the difference between High, Medium, and Low confidence?
High confidence (70%+) means at least two independent signals matched — for example, both a meta generator tag and a platform-specific HTTP header. Medium confidence (40–69%) means one strong signal matched, such as a generator tag alone or a platform-specific cookie. Low confidence (<40%) means only weak signals were found, like a script URL pattern that could appear on multiple platforms. The evidence list shows exactly which signals triggered the result.
Why does my WordPress site also show React or Vue?
WordPress is a PHP CMS, but its themes and plugins can load React (used by the Gutenberg block editor) or Vue components. Showing both is correct — the CMS and its front-end rendering framework are two separate things. Headless WordPress setups explicitly use WordPress as a backend API while rendering the frontend in Next.js, Gatsby, or another React framework.
Is this the same as Wappalyzer or BuiltWith?
Similar concept, different approach. Our key differentiator is showing the evidence that triggered each detection — the specific header, HTML pattern, or script that gave it away — which no other free tool does. We cover 20+ CMS platforms and 10+ frameworks, analytics, and CDN providers. BuiltWith and Wappalyzer cover far more technologies (2,500+) but don't explain their reasoning.
Can you detect headless CMS setups?
Partially. Headless CMSes like Contentful, Sanity, and Strapi only leave signals when their API or CDN is used to serve assets directly. If the frontend is built with Next.js pulling from Contentful's API and the assets are self-hosted, there may be no detectable Contentful signal in the HTML. We detect what's visible in the static page response — if the CMS is fully decoupled, it will not appear in results.
Why does it show 'JS global' in the evidence?
Some technologies write global JavaScript variables into the page source as inline script blocks. We parse those inline scripts from the static HTML to find globals like window.__NEXT_DATA__ (Next.js) or window.Shopify (Shopify). Globals created dynamically after JavaScript execution (not present in the raw source) cannot be detected without a headless browser — we note this in results when it's relevant.