How to Tell What CMS a Website Is Using

Want to know which content management system is running a website? In most cases you can find out in under a minute without any special access. The quickest method is to open the page source and look for a generator meta tag, which many systems print outright — but there is a stack of equally reliable fallbacks: telltale URL paths like /wp-content/, distinctive login pages, HTTP headers, cookies and free detection tools. This guide walks through every signal, from the one-glance check to the harder cases like headless CMS, so you can name the platform with confidence.

This is a focused companion to how to find out what a website is built with; here we zero in on the content management layer specifically.

Why identify the CMS behind a site?

Knowing the CMS is one of the most useful single facts about a website, because the platform shapes nearly everything else. Agencies and freelancers qualify leads and scope projects — a redesign quote depends heavily on whether a site runs WordPress, a proprietary builder or a custom stack. Developers evaluate how a competitor built their product and what migrating or maintaining it would involve. Marketers and SEOs want to know what they are working with before recommending plugins, schema or performance fixes. And security-minded researchers note that an outdated, well-known CMS install is a far larger attack surface than a hardened or bespoke one. Because most content management systems leave clear fingerprints, all of these questions are answerable from the outside.

The fastest check: the generator meta tag

The single quickest tell lives in the page source. Right-click any page, choose View Source (or press Ctrl+U / Cmd+Option+U), and search the HTML for the word generator. Many content management systems insert a line like:

<meta name="generator" content="WordPress 6.5.2" />

Drupal, Joomla, TYPO3, Ghost and others emit their own versions of this tag, frequently including the version number. It is the closest thing to the CMS announcing itself. The catch is that the tag can be removed — security plugins and cautious developers strip it deliberately — so its presence is conclusive but its absence tells you nothing. When the generator tag is missing, you simply move on to the other signals, of which there are plenty.

URL paths and login pages

Even with the generator tag stripped, most platforms betray themselves through the paths they use for assets, content and administration. These are baked into how the software works and are far harder to hide completely:

• WordPress loads themes and plugins from /wp-content/, exposes a REST API at /wp-json/, and puts its login at /wp-login.php (admin dashboard at /wp-admin).
• Drupal serves files from /sites/default/files/ and /core/, uses /node/123 style content URLs, and often exposes a Drupal.settings JavaScript object.
• Joomla keeps its admin at /administrator/, uses index.php?option=com_... component URLs, and sets a long hexadecimal session cookie.
• TYPO3 uses a /typo3/ backend path and /typo3conf/ and /fileadmin/ asset paths.
• Ghost serves a /ghost/ admin route and a /content/images/ media path, and emits a Ghost generator tag.

Trying a likely login path is a classic move: appending /wp-login.php or /administrator/ to a domain and getting a recognisable login screen is a near-instant confirmation.

A comparison of common CMS fingerprints

It helps to see the signatures side by side. The table below lists the most reliable single tells for the platforms you will meet most often.

CMS	Asset / path tells	Other signals
WordPress	/wp-content/, /wp-includes/, /wp-json/	wp-login.php, generator "WordPress", wordpress_* cookies
Drupal	/core/, /sites/default/files/, /node/	Drupal.settings object, X-Generator: Drupal header, X-Drupal-Cache
Joomla	/administrator/, /media/jui/, index.php?option=com_	generator "Joomla", long hex session cookie
TYPO3	/typo3/, /typo3conf/, /fileadmin/	generator "TYPO3 CMS"
Ghost	/ghost/, /content/images/	generator "Ghost", /members/ API
Squarespace	static1.squarespace.com assets	Server: Squarespace header, generator "Squarespace"
Wix	static.wixstatic.com, static.parastorage.com	X-Wix-* headers, generator "Wix.com"
Webflow	assets-global.website-files.com	data-wf-page/data-wf-site attributes, generator "Webflow"
Shopify	cdn.shopify.com, /cdn/shop/	window.Shopify, x-shopify-stage header

A single matching row usually settles the question. For the two platforms you will encounter most, it is worth knowing the deeper details, which is why each has its own guide: how to tell if a website is built with WordPress and, for hosted site builders, how to tell what website builder a site uses.

WordPress is the most likely answer

When you do not yet have a signal, the statistical base rate is worth remembering. According to W3Techs, WordPress powers around 43% of all websites and holds more than 60% of the CMS market among sites whose CMS is known. In practice that means that if a site looks content-driven — a blog, a brochure site, a news outlet, a small-business site — WordPress is the single most probable platform before you check anything. That does not excuse guessing; it just means the /wp-content/ and /wp-json/ checks are the highest-yield first move. If those come back empty, you have meaningfully narrowed the field and can work through the rest of the table. Once you have confirmed WordPress, the natural next step is to identify its theme and plugins, covered in how to identify a WordPress theme and its plugins.

Reading HTTP headers and cookies

The response headers and cookies are a trustworthy layer because they come straight from the server and a theme cannot style them away. Open DevTools (F12), go to the Network tab, reload the page, and click the first (document) request to read its response headers. Useful CMS tells include:

• X-Generator: Drupal 10 — Drupal sometimes states itself in a header.
• X-Drupal-Cache and X-Drupal-Dynamic-Cache — Drupal's page cache headers.
• X-Powered-By — occasionally names the platform or its language.
• Cookies — wordpress_logged_in_* and wp-settings-* for WordPress, a long hexadecimal Joomla session cookie, SESS<hash> for Drupal.

You can fetch headers without a browser using curl -I https://example.com, which prints the response headers for quick inspection. Headers are especially valuable when the visible markup has been cleaned up, because server-level fingerprints are easy to overlook and hard to remove entirely.

Free tools that answer it instantly

You do not have to read source by hand. Several free tools recognise hundreds of platforms from exactly the signals above:

• Wappalyzer — a browser extension (and website) that reports the CMS, frameworks, analytics and more for the current page.
• BuiltWith — a web app and extension that profiles a domain's full technology stack, with historical data on paid plans.
• WhatCMS — a focused detector that takes a URL and names the content management system, often with a version guess.
• View Source and DevTools — the manual tools behind all of the above, and the way to verify what an automated detector claims.
• StackOptic — a full website audit that reports the CMS alongside hosting, performance, SEO and security in one pass, so you see the platform in context rather than in isolation.

Automated tools are fast and convenient, but they are reading the same fingerprints you can read yourself; when accuracy matters, confirm a tool's verdict against the raw signals.

The hard case: headless and decoupled CMS

The trickiest sites to identify are headless (or decoupled) builds. In this architecture the CMS — for example Contentful, Sanity, Strapi, Prismic or a headless configuration of WordPress — stores and serves content through an API, but does not render the pages. A separate front-end framework such as Next.js, Nuxt or Astro fetches that content and builds the HTML. The result is a site with no traditional CMS markup: no /wp-content/ paths, no generator tag, none of the usual tells, because the visible app is custom JavaScript.

To detect a headless setup, change where you look:

1. Watch the Network tab for API requests to a content backend — calls to *.contentful.com, *.sanity.io, a GraphQL endpoint, or a site's own /wp-json/ consumed by a separate front end.
2. Identify the front-end framework first (see how to check what JavaScript libraries a website uses); a Next.js or Nuxt app serving editorial content is a strong hint that some headless CMS sits behind it.
3. Probe admin endpoints — a headless WordPress still answers at /wp-json/ and /wp-admin, even if the public site looks nothing like WordPress.

Headless detection is inherently less certain than spotting a classic install, and sometimes the honest answer is "a custom front end backed by an unidentified content API."

Common mistakes when identifying a CMS

A few errors recur. Treating a missing generator tag as proof of a custom build is the big one — plenty of WordPress and Drupal sites strip it, so absence is not evidence. Confusing the CMS with the hosting or the builder: a site on a generic host or fronted by Cloudflare can run any CMS underneath, and a CDN's headers tell you nothing about the platform. Mistaking an embedded widget for the platform — a content site might embed a single hosted form or store widget without being built on that platform. And stopping at the first clue: one signal can mislead, so corroborate the generator tag with a path, a header or a cookie before you commit.

How accurate is CMS detection?

For mainstream, self-hosted content management systems, detection is highly reliable. WordPress, Drupal, Joomla and the major hosted builders emit distinctive paths, headers, cookies and markup that are difficult to disguise completely, so triangulating two or three signals yields a confident answer. Accuracy falls for headless builds (where you must read API traffic instead of markup), for hardened installs that deliberately strip identifying signals, and for fully bespoke systems that match no public signature. The dependable rule is the same one that governs all technology detection: never rest on a single clue, and let the server-level signals — paths, headers and cookies — settle disputes when the visible markup has been cleaned up.

The fast, reliable workflow

1. View Source and search for a generator meta tag.
2. Look for signature paths — /wp-content/, /sites/default/, /administrator/, /typo3/.
3. Try a login path (/wp-login.php, /administrator/) for instant confirmation.
4. Read the headers and cookies in the Network tab or with curl -I.
5. Run a detector (Wappalyzer, BuiltWith, WhatCMS) and verify its verdict.
6. For headless sites, watch the Network tab for content-API calls and identify the front-end framework.

Go deeper

• The complete approach: how to find out what a website is built with.
• The most common answer in depth: how to tell if a website is built with WordPress.
• Hosted builders, not self-hosted CMS: how to tell what website builder a site uses.
• Going further on WordPress: how to identify a WordPress theme and its plugins.

Want the CMS, framework, hosting and full stack in one pass? Analyse any website with StackOptic — one report, free, no sign-up.