How to Detect the CMS a Website Uses (5 Free Methods)

You can usually tell what a website is built with in under a minute, without any special tools, because most sites announce it without meaning to. Every page a browser loads carries small tells: a meta tag here, a script URL there, a cookie name, a folder path. Read a few of them and the content management system behind the site becomes obvious. WordPress, Shopify, Squarespace, Wix and the rest each leave a recognizable trail.

This guide walks through five free methods to detect the CMS a website uses, from reading the page source by hand to using a checker that does it for you. For each one I will be clear about what it can see and what it cannot. Detection is not magic, and a few setups hide well. I will also show the angle that matters most if you do this for prospecting: the absent stack is the signal. What a business does not run often tells you more than what it does.

Why bother detecting a website’s CMS at all#

There are good reasons to know what a site runs. If you build websites, a dated CMS tells you whether a rebuild is an easy conversation. If you sell a plugin or theme, finding sites on the matching platform is your whole targeting strategy. If you run an agency, the stack is a fast read on how a business operates and where it is weak.

That last case is the one this guide keeps returning to, because it changes how you read the results. A curious developer wants to know what is present. An agency prospecting for clients wants to know what is missing. Same methods, very different reading.

Method 1: View the page source#

The oldest method is still one of the best. Right-click any page and choose View Page Source, or press Ctrl+U (Cmd+Option+U on a Mac). You are now looking at the raw HTML the server sent, and it is full of tells.

The meta generator tag#

Many content management systems stamp a <meta name="generator"> tag into the page head. It is the single most direct giveaway. WordPress writes something like content="WordPress 6.5". Drupal, Joomla and many others do the same. Use your browser’s find (Ctrl+F) inside the source and search for the word “generator”. If it is there, you often have the CMS and sometimes the exact version in one line.

Not every site exposes it. Some platforms omit it, and some site owners strip it deliberately for tidiness or security. Its absence does not mean a CMS is absent. It just means this particular tell is not available, and you move to the next one.

Telltale file paths#

Even without a generator tag, the asset paths in the source are revealing. A few patterns are worth memorizing.

• WordPress loads assets from /wp-content/ and /wp-includes/. If you see wp-content anywhere in the source, you are almost certainly looking at WordPress.
• Shopify serves its assets from cdn.shopify.com. That domain in a script or image URL is a reliable Shopify fingerprint.
• Squarespace references squarespace.com and static1.squarespace.com, and tends to include Static.SQUARESPACE_CONTEXT in inline script.
• Wix loads from static.parastorage.com and wix.com domains and leaves clear Wix markers in the markup.

Theme and template hints#

The source frequently names the theme or template too. WordPress exposes a theme directory under /wp-content/themes/your-theme-name/, telling you not just that it is WordPress but which theme is doing the work. Page builders show up the same way: an Elementor site carries elementor classes and stylesheet names throughout the markup.

What view source cannot reach is anything the server decides on its own and never sends to the browser. A site rendered entirely server-side with the tells stripped out can look anonymous. That is the honest ceiling of this method, and it is why we have four more.

Method 2: HTTP headers and cookies#

Before the HTML even arrives, the server sends response headers, and those carry their own fingerprints. You do not need a separate tool to read them. Open your browser’s developer tools (F12 or right-click then Inspect), go to the Network tab, reload the page, and click the first request, usually the document itself. The Headers panel shows everything the server returned.

Headers worth reading#

• x-powered-by sometimes names the underlying technology outright, such as PHP or a specific framework. It is not always present, and it can be spoofed, but when it is there it is a strong hint.
• server can name the web server (nginx, Apache) and occasionally more. On its own it does not identify a CMS, but it adds context.
• Platform-specific headers appear on some hosts. Certain platforms add their own custom headers that effectively brand the response.

Cookies as fingerprints#

Cookies are often more telling than headers. In the same developer tools, the Application tab (or Storage tab, depending on the browser) lists the cookies a site set. The names are the giveaway. WordPress sets cookies prefixed with wordpress_ and wp-. Many ecommerce and CRM tools set distinctively named cookies the moment a page loads. Reading cookie names is a quick, reliable way to spot tools that do not advertise themselves in the HTML.

The limitation mirrors method one. Headers can be stripped or rewritten by a proxy or CDN, and cookies only appear for tools that actually set them. So headers and cookies are excellent corroboration, not a guarantee.

Method 3: robots.txt and sitemap fingerprints#

Two files almost every site exposes can confirm a platform on their own. Add /robots.txt to the root domain and look at what it disallows and where it points its sitemap. Then open the sitemap it names.

The patterns are distinctive. WordPress commonly exposes a wp-sitemap.xml and disallows paths like /wp-admin/ in robots.txt. Shopify sites reveal themselves through /sitemap.xml entries and URL patterns built around /collections/ and /products/. Other platforms have their own characteristic sitemap names and disallowed paths.

Because these files are meant for crawlers, they are public by design and rarely locked down, which makes them a dependable cross-check. They will not reveal client-side tools like analytics or chat widgets, since those are not part of site structure. But for confirming the core CMS or ecommerce platform, robots.txt and the sitemap are a quick, high-signal look.

Method 4: Browser extensions and online checkers#

If you would rather not read source by hand, dedicated detectors do the reading for you, and several are genuinely good. They have spent years building fingerprint libraries far larger than anything you would assemble manually, and for listing what a site runs they are hard to beat. The short version: tools like Wappalyzer identify the CMS the moment you click, and database tools surface lists of sites by platform. Free tiers handle single-site reads; bulk use generally costs money.

Since picking between them is its own decision, this guide keeps the tool roundup brief. For a side-by-side of the detectors and where each one fits, see the companion comparison of BuiltWith and Wappalyzer alternatives, which covers the free tiers and the paid lines honestly.

The honest caveat is the same across all of them: they detect what is detectable. They are outstanding at reading client-side fingerprints, the code served to the browser, and they hit the same wall everyone does on server-side or custom stacks.

This is also where a gap-first approach differs. Most checkers answer “what is present” beautifully. If your job is prospecting, you also want “what is absent” surfaced and scored, because the missing CRM or missing pixel is the pitch. That reading is exactly what Website Technology Checker is built around, and it is the lens the rest of this guide uses.

Method 5: URL structure and admin paths#

The shape of a site’s URLs is a fingerprint in its own right, and you can read it just by clicking around.

• WordPress exposes its login at /wp-admin/ and /wp-login.php. You do not need to log in; the page simply existing in that recognizable form is the tell.
• Shopify organizes its storefront around /collections/ for category pages and /products/ for individual items. That structure is a near-certain Shopify signal.
• Other platforms have their own conventions, from characteristic admin paths to predictable content directories.

Browsing the public structure is low effort and quick to confirm a hunch from the earlier methods. Be sensible about it: looking at public pages and the standard shape of URLs is ordinary browsing. Do not try doors that are not meant for you. The point is to read the public structure, not to test access.

When detection fails (and it sometimes does)#

No method, manual or automated, sees everything. It is worth knowing the situations where detection legitimately comes up short, so you read a blank result correctly.

• Custom builds. A bespoke site with no off-the-shelf CMS has no standard fingerprints to find. There is nothing to detect because there is no known platform under it.
• Headless frontends. Increasingly, sites run a CMS purely as a backend and render the frontend with a separate framework. The visitor sees the framework, not the CMS, so the content system can be effectively invisible from the outside.
• Aggressive caching and proxies. A CDN or reverse proxy can strip identifying headers, rewrite responses and serve flattened HTML that hides the origin. The site loads fine while giving very little away.

The right response to all three is honesty. When the tells are not there, the correct conclusion is “not detected”, which is different from “not present”. A good detector says so rather than guessing. Overclaiming a clean result is worse than admitting the limit, especially if you are about to act on it in a sales conversation.

The agency lens: the absent stack is the signal#

Here is the shift that turns CMS detection from trivia into a prospecting tool. Once you can read what a site runs, start paying attention to what it does not. For an agency, each gap maps to a service you sell.

• No pixel. A business running ads with no Meta pixel or Google tag is spending money it cannot measure. That is a paid-media management pitch with the problem already proven.
• No chat widget. A service business with no chat or messaging on the site is leaking inbound interest. That is a conversion or customer-experience pitch.
• No CRM. A lead-generating site with no detectable CRM is probably handling enquiries in an inbox. That is an automation and systems pitch.
• No booking tool. An appointment-based business with no online scheduling is taking bookings by phone. That is a clear, concrete improvement you can offer.

WordPress plus no CRM is an automation pitch waiting to happen. Shopify with no email marketing platform is an obvious flows-and-retention conversation. The detected stack qualifies the lead; the gaps tell you what to say. That is the difference between knowing what a site is built with and knowing why that matters for your next outreach.

It also scales. Detect the stack across a list of prospects, sort by the gaps, and you have a segmented, prioritized outreach list where every entry comes with a reason to call. That is the whole value of reading detection through an agency lens rather than a developer’s.

Putting the methods together#

For a single site, you rarely need all five methods. A fast routine: open the page source and search for “generator” and “wp-content”. If that does not settle it, read the response headers and cookie names in developer tools, cross-check with /robots.txt and the sitemap, and glance at the URL structure to confirm. Within a minute or two you will know the CMS and most of the surrounding stack, and where detection is solid versus guessing. For many sites at once, the manual approach does not scale and you lean on tools, ideally one that surfaces the gaps and not just the inventory.

The bottom line#

Finding out what CMS a website uses is genuinely easy. The meta generator tag, asset paths like wp-content, response headers, cookie names, robots.txt and sitemap patterns, and the shape of the URLs all give it away, and free checkers like Wappalyzer, BuiltWith and WhatCMS do the reading for you. The only real limits are custom builds, headless frontends and aggressive proxies, where the honest move is to say “not detected” rather than pretend.

If you do this for prospecting, read the results the agency way: let the detected stack qualify the lead and let the gaps write the pitch. Website Technology Checker is built for exactly that. Join the waitlist and we will email you the moment it is live, free at launch.