Detect the technologies behind any site — CMS (WordPress, Shopify, Wix…), JavaScript frameworks, analytics, CDNs and server — straight from the homepage. Great for sizing up competitors.
⚡ Interactive demo — sample data
This sample site is a WordPress build with a common front-end library, a tag manager and an edge layer in front of it.
CMS / Generator: WordPressLooks good
JavaScript: jQuery detectedLooks good
Analytics: Google Tag Manager detectedLooks good
CDN / edge: Cloudflare signals detectedLooks good
Server header: exposes detailed software name — consider hiding itWarning
Detect the technologies behind any site — CMS (WordPress, Shopify, Wix…), JavaScript frameworks, analytics, CDNs and server — straight from the homepage. Great for sizing up competitors.
How it works
Enter the website URL
Paste any public homepage and run the check. We fetch the page and read both its HTML and the response headers the server returns — the two places a site's underlying technology leaves fingerprints.
Review the detected stack
You get a grouped list of what we found: the CMS or site generator, JavaScript frameworks and libraries, analytics and tag tools, CDN signals, and the web server and any powered-by header. Each entry shows what category it falls under.
Use it to size up a site
Compare a competitor's stack to yours, confirm your own site is shipping what you expect, or scope a migration or audit. Re-run any URL to see how the building blocks differ across sites.
What we check
CMS / site generator — Reads the page's generator meta tag and known markup fingerprints to identify the content management system or builder behind the site — for example WordPress, Shopify, Wix, Squarespace, Webflow, Drupal or Joomla. This is usually the single most telling fact about how a site is built.
JavaScript frameworks & libraries — Looks for signatures of front-end frameworks and libraries such as React, Vue, Angular, Next.js, jQuery and Bootstrap. These reveal how interactive the front end is and how the site is likely rendered and maintained.
Analytics & tag tools — Detects common measurement and tag-management signatures in the page, such as tag managers and analytics snippets. It tells you whether and roughly how a site is tracking its visitors and marketing.
CDN & performance signals — Picks up signs that a content delivery network or edge layer is in front of the site. A CDN affects how fast and how reliably content is served and is a common part of a modern, scaled stack.
Web server & powered-by — Reads the server response header and any x-powered-by header the site exposes, which can name the underlying web server or application platform. Many sites hide these, so a blank here simply means the server isn't advertising them.
UI & utility libraries — Surfaces front-end utilities like CSS frameworks and icon sets (for example Tailwind, Bootstrap or icon libraries) that show up in the page source. These hint at the design system and developer tooling in use.
Common issues we catch
A near-empty result on a big-name site — Some sites strip generator tags, hide server headers and bundle their code so signatures don't appear in plain HTML. A short result doesn't mean a simple site — it can mean the team deliberately removed the fingerprints this kind of check relies on.
Detection reads the homepage, not the whole site — The check inspects the page you give it. A site can run different technology on its blog, store or app subdomains than on its homepage, so one URL is a snapshot of that page rather than a guaranteed map of the entire property.
A revealing server or powered-by header — Servers that advertise their exact software and version in headers hand attackers a head start on known vulnerabilities. Finding a detailed powered-by or server header on your own site is a quiet security hygiene flag worth tidying up.
Frameworks that render after load — Heavily client-rendered sites build much of their markup with JavaScript after the first response. Some signatures still appear in the initial HTML, but a check that reads the first response will naturally see less of a script-built page than a server-rendered one.
Stale tools still loading on the page — Old analytics snippets, abandoned chat widgets and retired marketing pixels often stay in the page long after they're needed. Spotting them in the stack is a prompt to remove dead weight that's still costing requests on every visit.
Shared fingerprints across platforms — Some signals — a common JavaScript library, a popular CSS framework — appear on sites built many different ways. They tell you a library is present, not that the whole site is built around it, so read individual entries rather than assuming one defines the architecture.
A CDN masking the true origin — When an edge or CDN layer fronts a site, the headers you see can describe the edge rather than the origin server behind it. That's useful to know, but it means the server header may not reflect the actual application platform.
Where this matters
WordPress, Drupal & Joomla — Traditional content management systems leave clear footprints in markup paths and generator tags. Identifying them tells you how content is managed and what plugin ecosystem and update cadence a site is likely working with.
Shopify, Wix, Squarespace & Webflow — Hosted site builders and commerce platforms have distinctive asset domains and markup. Recognising them tells you a site is on a managed platform with that platform's constraints, themes and app marketplace.
React, Vue, Angular & Next.js — Modern JavaScript frameworks signal a component-based, often app-like front end. Spotting them tells you how interactive a site is and how it's likely built, rendered and maintained by its development team.
Analytics & tag managers — Measurement and tag-management snippets reveal how a site tracks visitors and deploys marketing tags. Their presence — or absence — is a quick read on how data-driven a site's marketing operation is.
CDNs & edge layers — Edge and delivery layers in front of a site point to a performance- and scale-minded setup. They influence load speed and reliability and are a common ingredient in stacks built to handle real traffic.
Frequently asked questions
How does the tool detect a website's technology?
It fetches the homepage and reads two things: the page's HTML — including the generator meta tag and known markup fingerprints — and the server's response headers. Many technologies leave recognisable signatures in one or both, and the tool groups what it finds into categories like CMS, framework and server.
Why does it sometimes find very little?
Some sites deliberately strip generator tags, hide server headers and bundle their code so the usual fingerprints don't appear in plain HTML. Heavily script-rendered sites also expose less in the first response. A short result reflects how little the site advertises, not how simple it is.
Can I use this to check a competitor?
Yes — that's one of the most common uses. Pointing it at a competitor's homepage shows you the CMS, frameworks, analytics and delivery layer they're built on, which is useful for sizing up their setup, scoping a comparable project or spotting tools you might be missing.
Does it scan the whole website?
No, it inspects the single page you give it, usually the homepage. A site can run different technology on its blog, store or app subdomains, so the result is an accurate snapshot of that page rather than a guaranteed map of every section of the site.
Is detecting another site's stack allowed?
Yes. The tool only reads information the site already sends publicly to every visitor's browser — the page HTML and response headers. It doesn't probe, log in or attempt anything a normal page load wouldn't, so it's the same data your own browser receives.
What does the server or powered-by header tell me?
When present, it can name the underlying web server or application platform. On your own site, a header that exposes exact software and versions is worth tightening up, since it gives anyone probing for known vulnerabilities a useful head start.
Why don't all the JavaScript frameworks show up?
Front-end frameworks that build markup after the first response may leave only partial signatures in the initial HTML the tool reads. Some signals still appear, but a script-rendered site will naturally surface fewer than a server-rendered one — absence here isn't proof a framework isn't used.
Can knowing the stack help my SEO or performance?
Indirectly, yes. Knowing the platform tells you its typical strengths and limits, what slows it down, and where fixes live. Spotting stale analytics, unused widgets or a heavy framework gives you concrete things to trim, which feeds straight into speed and page-experience work.
This is one of several free SEO tools from Custom Web Audits.
For a complete, prioritized analysis of your whole website,
run a full audit.