How to Find What CMS a Website Uses

Knowing which content management system a site runs on is useful more often than you'd expect. It tells you what a competitor could do with their pages. It helps you judge whether a site is a realistic guest post or partnership target. It narrows down the cause of a technical SEO problem before you ask for server access. And agencies use it to scope a migration. You can often identify the platform in a minute by hand. This guide shows where to look, why some sites don't give up the answer, and when an automated detector helps.

Method 1: Check the generator meta tag#

Many platforms announce themselves. The HTML standard defines a generator meta name for "the identifier of the software that generated the page" (see MDN's list of standard meta names).

View the page source (Ctrl+U or Cmd+Option+U in most browsers) and search for generator:

<meta name="generator" content="WordPress 6.x">
<meta name="generator" content="Drupal 10 (https://www.drupal.org)">
<meta name="generator" content="Ghost 5.x">

Treat this as a strong hint, not proof. Security plugins and hardening guides often remove the tag, and page builders sometimes add their own generator tag alongside the CMS's.

Method 2: Look at asset paths#

The URLs of stylesheets, scripts and images often reveal the platform, even when the generator tag is gone. Search the source for these patterns:

Asset paths are hard to hide completely, because moving them means changing how the whole platform works. That makes them one of the more reliable signals.

Method 3: Check the HTTP response headers#

Headers sometimes name the platform or the software stack behind it. From a terminal:

curl -sI https://example.com/

Things to look for:

• X-Generator: Drupal commonly sends a header like X-Generator: Drupal 10 (https://www.drupal.org).
• X-Powered-By: often shows the language or framework (for example PHP/8.x or Express) rather than the CMS. A PHP value narrows the field but doesn't identify the CMS.
• Platform-specific headers: hosted platforms often add their own request ID or cache headers with the platform's name in them.
• Server: names the web server or CDN (nginx, Apache, cloudflare). It usually says nothing about the CMS.

Keep in mind that a CDN or reverse proxy in front of the site can strip or rewrite headers.

Method 4: Look at cookies#

Open your browser's developer tools, go to the Application or Storage panel, and look at the cookies the site sets:

• WordPress sets wordpress_test_cookie on its login page and wp-settings-* cookies for logged-in users.
• Shopify storefronts set cookies prefixed with _shopify_.
• Drupal session cookies typically start with SESS followed by a hash.
• laravel_session or XSRF-TOKEN points to a Laravel application, which may be a custom build rather than an off-the-shelf CMS.
• PHPSESSID only tells you the site uses PHP sessions.

Many cookies appear only after an action, such as adding to cart or visiting the login page, so a lack of cookies on the home page doesn't rule anything out.

Method 5: Check well-known URLs#

Some platforms expose predictable public URLs. Visiting public pages is fine, but don't try to log in or probe admin areas.

• /wp-json/: WordPress exposes its REST API here. A JSON response describing routes is a strong WordPress signal.
• /robots.txt: WordPress's default virtual robots.txt disallows /wp-admin/. Shopify and other platforms generate files with recognizable rules. You can read any site's file with the Robots.txt Checker.
• Sitemap URLs: WordPress core generates /wp-sitemap.xml, and popular SEO plugins produce files like /sitemap_index.xml. The Sitemap Checker shows you the structure.

A worked example#

Suppose you want to identify the platform behind example-store.com:

1. curl -sI https://example-store.com/ shows Server: cloudflare and no platform header. That tells you nothing yet, because a CDN sits in front.
2. The page source has no generator tag, but product images load from cdn.shopify.com.
3. The cookies include _shopify_y after you browse a product.
4. /robots.txt contains rules typical of Shopify storefronts.

Three independent signals point to the same answer, so you can be confident it's Shopify. Always look for at least two unrelated signals. One signal on its own is easy to misread. A WordPress blog on a subdomain, or a leftover file from an old platform, can send you in the wrong direction.

Why some sites can't be identified#

Manual checks and detectors both hit the same limits:

• Headless setups. The CMS stores content and serves it through an API, while a separate front end (often a JavaScript framework) renders the pages. Visitors never touch the CMS directly, so its fingerprints never reach the browser. You may identify the framework, such as Next.js from its __NEXT_DATA__ script, but not the CMS behind it.
• Deliberate hardening. Removed generator tags, renamed asset folders and stripped headers can hide a platform.
• Proxies and CDNs that rewrite headers and serve assets from their own domains.
• Custom builds. Many sites run on a framework (Laravel, Django, Rails) with no CMS at all.
• Client-side rendering. If the page content is built by JavaScript in the browser, the raw HTML may contain almost nothing to analyze.

When a site gives no signals, the honest answer is "unknown" or "custom," not a guess.

Using a CMS detector#

Checking one site by hand is easy. Checking fifty prospects for an outreach list isn't. Our CMS Detector automates the checks above. It matches open-source technology fingerprints against a page's HTML, response headers, cookies and script URLs, and reports the platform and other technologies it recognizes.

Two things to know about how it works:

• It doesn't run JavaScript. It analyzes the page as the server delivers it. That keeps it fast, but it can miss technologies that load only after scripts run, and it will see very little on fully client-rendered sites.
• It reports matches, not certainties. When a result matters, for example before quoting a migration, confirm it with one of the manual methods.

Putting it to use#

Once you know the platform, you can:

• Qualify outreach targets. A site on a common CMS with an active blog is often easier to publish on. Pair this with our guide on how to find guest post sites.
• Benchmark competitors. Knowing the stack helps explain their speed and structure. See how to improve website speed.
• Research a domain fully. Combine the platform with ownership and age data. See how to find who owns a domain and how to check domain age.