How to Check What CMS a Website Uses: 6 Methods, 30 Seconds (2026)

Most people install a browser extension, glance at a badge, and call it done. That single-tool habit is exactly why so many “CMS reports” are wrong the moment a site runs anything more complex than a stock WordPress theme.

Why the CMS Is the First Thing Worth Detecting

A content management system is the fastest tell you’ll get about how a company operates online, long before you dig into its frontend framework, hosting, or analytics stack.

What a CMS actually reveals about a company

The platform choice signals budget, technical maturity, and priorities. A company running WordPress with a page builder is usually optimizing for speed of publishing over engineering purity. A company running a headless setup with a custom frontend is usually investing in a dedicated engineering team. Shopify or BigCommerce tells you e-commerce is core to the business model, not a bolted-on feature.

Need company tech stack data?

Search companies by technology, industry, size, and location.

Search Companies →

Who checks a site’s CMS and why (sales, recruiters, agencies, investors)

Sales teams use CMS detection to qualify leads before a call (a prospect on an outdated CMS is a different pitch than one on a modern stack). Recruiters and job seekers use it to gauge whether a company’s engineering culture matches what they want. Agencies use it to scope migration or redesign work. Investors and analysts use it as one input into how a company is scaling its digital presence.

CMS detection as the entry point to the whole stack

The CMS is rarely the whole picture, it is the first layer. Once you know the platform, you can usually infer the hosting pattern, the likely plugin ecosystem, and where to look next. Our guide on what tech stack a website uses walks through that fuller process, and if you are evaluating a potential employer rather than a prospect, how to research a company’s tech stack before applying covers the job-seeker angle specifically.

Method 1: Read the Page Source (Free, 30 Seconds, No Tools)

Before opening any tool, open view-source. It is free, it requires no install, and on a large share of sites it answers the question outright.

The meta name=”generator” tag and where it leaks

Many CMS platforms, and especially WordPress themes and plugins, still emit a <meta name="generator" content="..."> tag in the <head>. Right-click, view page source (not just inspect element, since some CMS markers only appear in the raw HTML response), and search for “generator.” If it’s there, you likely have your answer in one line.

Tell-tale file paths: /wp-content/, /sites/default/, cdn.shopify.com

Even when the generator tag is stripped, asset paths usually aren’t. Search the page source for these patterns:

/wp-content/ or /wp-includes/ points to WordPress
/sites/default/files/ points to Drupal
cdn.shopify.com or /cdn/shop/ points to Shopify
/typo3conf/ points to TYPO3
static.wixstatic.com points to Wix

Class-name and script signatures that fingerprint a platform

Beyond file paths, look at class names and inline script variables. WordPress themes often carry classes like wp-block- or elementor-. Squarespace injects Squarespace. namespaced JavaScript objects. These are the same category of clue that browser extensions automate, you’re just doing it manually and faster.

Why view-source beats extensions for a fast first read

View-source shows you the actual HTML the server sent, before any extension’s heuristics run on top of it. It costs nothing, works in any browser without permissions, and gives you the raw evidence rather than a tool’s interpretation of that evidence. This is the same signature-hunting approach we detail more broadly in what tech stack a website uses, just narrowed to CMS-specific markers.

Signal	WordPress	Drupal	Shopify	Wix
Generator meta tag	Often present	Sometimes present	Rarely present	Rarely present
Distinct file path	/wp-content/	/sites/default/	cdn.shopify.com	static.wixstatic.com
Class naming pattern	wp-block-, elementor-	region-, node–	shopify-section-	wixui-
Survives a CDN in front	Usually	Usually	Usually	Usually

Method 2: Inspect HTTP Response Headers

If the page source comes up empty, the response headers are the next place to look, and they’re just as fast to check.

Reading X-Powered-By, X-Generator, and Set-Cookie names

Some servers still return an X-Powered-By header naming the underlying platform or language. A few CMS platforms go further with an X-Generator or similar custom header. Even when both are absent, the Set-Cookie header often names session cookies tied to a specific platform.

Platform cookies (wordpress_, Shopify _shopify_, Wix hs)

Cookie names are one of the more reliable CMS signals because they’re functional, not decorative, so platforms rarely bother stripping them.

Platform	Common cookie prefix	Notes
WordPress	wordpress_, wp-	Especially visible on login or admin pages
Shopify	_shopify_, cart	Present on nearly every storefront page
Wix	hs, svSession	svSession is close to universal on Wix sites
Squarespace	crumb, ss_cvr	Present on most Squarespace pages

How to pull headers with DevTools, curl, or an online header checker

Three ways to see the raw headers, in order of speed:

Open browser DevTools, go to the Network tab, reload, and click the top document request
Run curl -I https://example.com from a terminal for a clean, tool-free header dump
Use a free online header checker if you don’t have terminal access

Shopify is a good site to practice on, because its header and cookie signatures are some of the most consistent in the industry. Our breakdown of companies using Shopify walks through exactly what a confirmed Shopify fingerprint looks like in practice, which is a useful reference point before you go hunting on a site where the answer is less obvious.

Method 3: Browser Extensions and Detection Tools

Once you’ve exhausted the free manual checks, a dedicated detection tool will usually get you the rest of the way, provided you understand what it is and is not built to catch.

What Wappalyzer and BuiltWith detect and their blind spots

Wappalyzer and BuiltWith both work by matching a site’s HTML, headers, and script signatures against a library of known patterns, the same categories of evidence covered in Method 1 and Method 2, just automated and cross-referenced against a larger database than any one person maintains manually. Their blind spots show up in the same places: heavily customized themes, CDNs that strip identifying headers, and headless setups where the CMS never touches the rendered page at all.

Extension vs. lookup-service: when each is right

A browser extension is right when you’re already on the page and want an instant read. A lookup-service (paste in a URL, get a report) is right when you don’t want to visit the site yourself, or when you want a historical record of what a site was running previously.

Cross-checking two tools before you trust either

Because both tools rely on pattern libraries that lag behind new platform releases, a single tool’s “no CMS detected” result is not proof that no CMS exists. Run a second tool before accepting a negative result. If you want a fuller sense of where each falls short and what else is available, see our Wappalyzer alternatives roundup, and if cost is a factor, BuiltWith pricing explained breaks down what you actually get at each tier.

Tool type	Best for	Main limitation
Browser extension	One-off checks while browsing	Misses headless and CDN-masked sites
Lookup service	Checking sites you’re not visiting	Report freshness depends on last crawl
Manual (source + headers)	Verifying a tool’s result	Slower, requires knowing what to search for

When Manual Checks Aren’t Enough

A single manual lookup is fine for one site. It stops being fine the moment you need CMS data on a list of fifty, five hundred, or five thousand domains.

The limits of one-off manual lookups

View-source and header checks don’t scale. They also don’t produce a record you can filter, sort, or revisit later, which matters if CMS detection is feeding a sales list, a research project, or ongoing competitive tracking rather than a single curiosity check.

When you need CMS data for a whole list of domains, not one site

If you’re qualifying a prospect list, building a target list of companies on a specific platform, or auditing a portfolio of client sites, you need a dataset, not a browser tab. That’s a different tool category than the extensions covered in Method 3, and it’s worth knowing the cheaper options exist before you assume you need an enterprise contract. Our guide to the 7 best BuiltWith alternatives covers exactly this gap.

Building a repeatable, verifiable detection process

Whatever tool you land on, the process should be repeatable: same signal set, same verification step, every time, so results from different runs are comparable rather than dependent on which extension happened to be installed that day.

Method 5: Bulk CMS Detection Across Many Sites

Scaling from one domain to many changes the workflow entirely, and it’s worth understanding the shift before you commit to a tool.

From one domain to a filtered list by CMS

Instead of asking “what CMS does this one site run,” bulk detection asks “which of these ten thousand domains run WordPress” or “show me every site on this list that switched to Shopify in the last year.” That’s a filtering and segmentation problem, not a single lookup.

Using technographic datasets instead of manual view-source

Technographic datasets are built by crawling and fingerprinting sites at scale, then storing the result so you can query it instead of re-detecting it live every time. This is the same category of data BuiltWith sells access to, and the 7 best BuiltWith alternatives piece compares pricing and coverage across the field.

Turning “runs WordPress” or “runs Shopify” into a target list

Once you have a filtered list by CMS, the next step is usually monitoring it over time rather than pulling a static snapshot once. Our guide on building a competitive intelligence dashboard using tech stack data covers how to turn a one-time bulk export into an ongoing watch list.

Method 4: When Detection Fails (Headless, Custom, and Masked Sites)

Sometimes every signal comes back empty, and that absence is itself informative if you know how to read it.

Headless CMS and JAMstack setups that hide the backend

A growing share of sites use a headless CMS (content managed in a system like Contentful or Sanity, then rendered through a separate frontend framework). Because the CMS never generates the HTML directly, none of the markers from Method 1 or Method 2 will exist. There is nothing to detect on the frontend, because the frontend and the content system are two separate applications talking over an API.

How CDNs and reverse proxies (Cloudflare) strip signatures

A CDN or reverse proxy sitting in front of the origin server can also strip or rewrite headers before they ever reach the browser. Cloudflare, for example, can be configured to remove server-identifying headers as part of a hardening setup, which means a header-based check can come back clean even when a very ordinary CMS is running behind it.

Confirming a custom or in-house build when no signature appears

When Methods 1 through 3 all return nothing, and there’s no headless CMS evidence either, you’re likely looking at a fully custom, in-house build. That’s a legitimate answer, not a detection failure, and it’s itself a useful data point about a company’s engineering investment.

Cross-referencing the frontend framework as a clue

Even without a visible CMS, the frontend framework is usually still detectable, and it narrows the possibilities. A site built on React is more likely to be paired with a headless CMS than a traditional one. Our breakdown of companies using React in 2026 is a useful reference for what that pairing tends to look like in practice, and for treating a detected framework as a clue toward the backend rather than the full answer on its own.

Method 6: Verifying Your Answer With Layered Signals

The single most reliable habit in CMS detection isn’t any one method, it’s refusing to stop at the first signal you find.

The layered-signal method (source + headers + tool + framework)

Treat each method in this guide as one input, not a final answer. A confirmed CMS should show up in at least two independent places: the page source and the headers, or a tool’s result and a manual spot-check. When two unrelated signals agree, your confidence should go up substantially. When only one signal fires, treat it as a lead, not a conclusion.

Handling conflicting results between tools

When Wappalyzer and BuiltWith disagree, or when a tool’s result contradicts what you saw in view-source, don’t average the two. Go back to the raw evidence (page source and headers) and let that break the tie, since tools are inferring from the same evidence you can inspect directly.

Documenting confidence level, not just a platform name

If you’re recording CMS data for later use, record how you got there, not just the platform name. “Confirmed via generator tag and cookie” is a different quality of data than “Wappalyzer said so,” and that distinction matters if the data ever needs to be re-verified. This layered approach is the same principle behind our full tech stack detection guide, applied specifically to the CMS layer.

Putting CMS Detection to Work

CMS detection is rarely the end goal, it’s the first concrete fact in a larger picture you’re building about a company.

For job seekers and engineers evaluating an employer

If you’re weighing an offer, the CMS and the stack around it tell you something about the engineering culture you’d be joining. Our guide to researching a company’s tech stack before applying picks up from here.

For sales and agencies qualifying prospects by platform

If you’re qualifying leads or scoping a migration, CMS detection is the first filter, and the layered verification method above is what keeps that filter accurate instead of just fast.

Next steps: mapping the rest of the stack

Once the CMS is confirmed, the natural next step is mapping the hosting, analytics, and frontend layers around it. That’s the fuller process we cover in what tech stack a website uses.

Frequently Asked Questions

How can I check what CMS a website uses for free? View-source and HTTP header inspection (Methods 1 and 2) are both free and require no account or install. Between the two, they catch the majority of standard CMS deployments.

What is the fastest way to tell if a site runs WordPress? Search view-source for /wp-content/ or /wp-includes/, or check for a WordPress-prefixed cookie in the response headers. Either usually resolves the question in under thirty seconds.

Why does Wappalyzer or BuiltWith sometimes fail to detect a CMS? Both tools rely on pattern libraries that need to recognize a platform’s known signatures. Headless CMS setups, aggressive CDN header stripping, and heavily customized themes can all produce a false negative, which is why cross-checking with a manual method matters.

Can you detect a headless or custom-built CMS? Not directly in most cases, since a headless CMS doesn’t touch the rendered page. You can narrow it down by identifying the frontend framework and treating the absence of any traditional CMS signature as its own piece of evidence.

How do I check the CMS of many websites at once? Manual methods don’t scale past a handful of sites. For lists beyond that, a bulk technographic dataset or lookup service, covered in Method 5, is the practical option.

Does a CDN like Cloudflare hide which CMS a site uses? It can. A CDN or reverse proxy configured to strip server-identifying headers will hide the Method 2 signal specifically, though page source markers (Method 1) often still come through since they live in the HTML itself, not the headers.

Is checking a website’s CMS legal? Reading publicly served HTML and headers that a server sends to any visitor, including the response headers, is standard browsing behavior. It’s the same information your browser already receives to render the page.

The Bottom Line

No single method in this guide is bulletproof on its own, and that’s the actual takeaway. Page source and headers are free and fast but can be stripped. Extensions and lookup tools are convenient but run on lagging pattern libraries. The reliable answer comes from layering two or more of these six methods and trusting agreement between independent signals over any single tool’s badge.