How can I tell what CMS a website is built on?

Check the page source for known file paths (/wp-content/ means WordPress), a generator meta tag, script URLs pointing at a platform's CDN, or platform-specific cookie names — usually one of these settles it within a minute.

Can a website hide what CMS it's using?

To a real degree, yes — a headless architecture, a white-labeled agency platform, or a site that deliberately strips identifying signals can genuinely defeat manual detection. In those cases, cookies and response headers are the usual tiebreaker.

Why does knowing a site's CMS matter for SEO?

Technical SEO advice differs by platform — a canonical tag issue on WordPress is often a plugin conflict, while the same issue on a custom-built site is a code-level bug. Identifying the platform correctly is usually the first real step in diagnosing someone else's technical SEO problem.

Is there a free tool to detect a website's CMS?

Yes — a dedicated detector checks HTML, scripts, cookies, and headers together in one pass, catching platforms a quick manual look might miss, especially less common ones.

What CMS Is This Website Using? Free Technology Detector

Q: Why doesn't a site show a generator meta tag?

Some platforms don't add one by design, and others (like WordPress with certain security plugins) strip it deliberately. Its absence is inconclusive, not proof the site is custom-built.

Why you'd even want to know

Three genuinely different situations lead people to this question. A developer scoping a competitor rebuild wants to know what stack they're dealing with before quoting a timeline. A marketer evaluating an agency's past work wants to confirm a claimed "custom-built" site isn't actually a template. And plenty of people are just curious after seeing a site with a distinctive layout and wanting to build something similar. All three cases have the same answer: the CMS almost always leaves fingerprints in the page's own HTML, and reading them doesn't require anything more invasive than viewing source.

The signals that actually give it away

The generator meta tag — many platforms (WordPress, Wix, Squarespace) add <meta name="generator"> naming themselves directly. This is the single most reliable signal when it's present, though many sites strip it deliberately.
File and folder paths — /wp-content/ means WordPress, immediately and unambiguously. /sites/default/files/ means Drupal. Path conventions are baked into how each platform serves assets and are far harder to hide than a meta tag.
Script and stylesheet URLs — a script loaded from cdn.shopify.com means Shopify, full stop, regardless of what the rest of the page looks like.
Cookie names — platforms often set a distinctively-named cookie (wordpress_logged_in_, _shopify_s) even on pages with no other visible signal.
HTTP response headers — a X-Powered-By or platform-specific header can confirm a guess even when the HTML itself has been scrubbed clean.

Two platforms, two completely different fingerprints

A WordPress site's page source typically carries several of these signals at once:

<meta name="generator" content="WordPress 6.6">
<link rel="stylesheet" href="/wp-content/themes/astra/style.css">
<script src="/wp-includes/js/jquery/jquery.min.js"></script>

Any one of these alone would be a strong signal; together, there's no real ambiguity. A Shopify store looks completely different, but is just as identifiable once you know what to look for:

<script src="https://cdn.shopify.com/shopifycloud/shopify/assets/storefront.js"></script>
<link rel="canonical" href="https://example.myshopify.com/products/trail-runner-x2">
<meta name="shopify-checkout-api-token" content="...">

Neither of these required checking cookies or headers — the HTML alone settled it. That's true for the large majority of sites; the harder cases are custom-built platforms or heavily white-labeled setups that deliberately strip every obvious signal, which is where cookies and headers become the tiebreaker.

Paste a URL into CheckSEO's Website Technology Detector to see the CMS, framework, analytics, and hosting clues a page's HTML actually reveals — no signup.

Open the Website Technology Detector

Ways to check, from fastest to most thorough

View page source and search for known paths

Right-click → View Page Source (not just Inspect, which shows the rendered DOM after JavaScript runs), then search for wp-content, shopify, drupal, or similar. Fix: this alone resolves the majority of sites in under a minute.

Check the generator meta tag specifically

Search the page source for name="generator" — present on many platforms, absent by design on others (WordPress sites with certain security plugins strip it deliberately). Fix: treat its absence as inconclusive, not as proof of a custom build.

Look at cookie names in DevTools

Open the Application (Chrome) or Storage (Firefox) tab and check the cookie list — platform-specific cookie names often survive even when every other signal has been scrubbed. Fix: use this as a tiebreaker when the HTML alone is ambiguous.

Check response headers

Some platforms and hosting providers add identifying headers even when the page content itself gives nothing away. Fix: fetch the page's raw headers (curl -I, or a browser's network tab) rather than just reading rendered HTML.

Run a dedicated detector for anything still unclear

A tool that checks all of the above signals at once — HTML, scripts, cookies, headers — in a single pass catches cases a manual five-minute check would miss, especially on sites using less common platforms. Fix: use a detector as the fallback, not the only step, once manual checks come back inconclusive.

Why some sites are genuinely hard to identify

A handful of situations defeat every signal above by design, not by accident. A fully custom-built site on a headless architecture (a Next.js or similar frontend pulling content from an API) has no CMS-specific paths in its HTML at all, because there is no traditional CMS serving the page directly — the actual content system might be entirely invisible from the rendered output. Heavily white-labeled agency platforms deliberately strip every identifying trace as a selling point to their own clients. And a site that's migrated platforms recently can carry stale signals — leftover cookies or cached headers from the old stack — that point to the wrong answer entirely. In all three cases, the honest answer is "not reliably determinable from the outside," which is a legitimate finding, not a failed check.

What this has to do with SEO

Beyond curiosity, knowing a site's CMS changes what technical SEO advice actually applies. A canonical tag issue on WordPress is usually a plugin conflict (two SEO plugins fighting over the same tag); the same issue on a custom Next.js build is a code-level bug in how metadata gets generated. Recommending "check your Yoast settings" to a site that isn't running WordPress at all wastes everyone's time — identifying the platform correctly is usually the first real step in diagnosing a technical SEO problem someone else built, not just an idle curiosity.

Check any site now

CheckSEO's Website Technology Detector reads a page's HTML for CMS, framework, analytics, and hosting signals in one pass, so you're not manually cross-referencing file paths and meta tags by hand.

How to Check What CMS Any Website Is Running On