In short. A site's engine is given away by the traces a CMS leaves in the page code and server responses: the generator meta tag, characteristic paths (/wp-content/ for WordPress, /sites/default/ for Drupal), classes and comments in the HTML, and response headers (X-Powered-By, cookies like PHPSESSID or laravel_session). The fastest way is to run the address through an automatic detector that checks dozens of such signals in one pass. Note: some sites deliberately hide the traces or are hand-built — then the engine can't be identified, and that's a normal result, not an error. Below is which signals to look at and how to check.
Why know a site's engine at all
- Choosing a platform. See what the sites you like are built on, to pick an engine for your own.
- Competitive research. Understand a competitor's stack: a custom engine, a boxed CMS, or a website builder — these mean different budgets and capabilities.
- Security. An outdated version of a popular CMS is a known set of vulnerabilities. Identifying the engine makes it easier to gauge the risk — yours or a contractor's.
- Assessment before buying/support. Before taking a site on for changes, it helps to know what you're diving into.
Which traces reveal a CMS
An engine is like handwriting: even with the nameplate removed, the characteristic paths, file names, and headers remain. Wiping every trace is hard, so most mass-market sites are identified by a combination of signals.
1. The generator meta tag
Many CMSs sign their name honestly in the <head>:
<meta name="generator" content="WordPress 6.5">
<meta name="generator" content="Joomla! - Open Source Content Management">The most direct signal — but it's often removed for security, so its absence disproves nothing.
2. Characteristic paths and files
Open the page source (Ctrl+U) and look for static-asset paths — they give away the engine most reliably:
| CMS / platform | Characteristic traces |
|---|---|
| WordPress | /wp-content/, /wp-includes/, /wp-json/, login at /wp-admin |
| Joomla | /media/jui/, /components/, /administrator |
| Drupal | /sites/default/, /core/, header X-Generator: Drupal |
| Shopify | cdn.shopify.com, /cdn/shop/, X-ShopId header |
| Wix / Squarespace | static.wixstatic.com, squarespace.com asset hosts |
| Magento / OpenCart | /skin/frontend/, catalog/view/ |
3. Response headers and cookies
Servers often reveal the stack in headers: X-Powered-By, X-Generator, plus session cookies (PHPSESSID, laravel_session). You can view the headers without setting anything via the HTTP header check — it also shows the web server (nginx/Apache/IIS). More on what to read in headers is in the response-headers breakdown.
4. An automatic detector
All the checks above are done in one pass by the technology detector: it gathers the generator, paths, headers, cookies, and JS libraries and reports the likely CMS, web server, analytics, and frameworks. Faster than scrolling the source by hand, and it doesn't miss the small stuff.
When the engine can't be identified
This is a normal situation, not a tool failure:
- Traces deliberately wiped. The
generatorremoved, paths renamed, headers hidden — solid defense against automatic vulnerability scanning. - A custom engine or framework. A site on Laravel, Django, or Next.js without a boxed CMS won't "detect as a CMS" — because there isn't one.
- Headless and static. Content is served via an API and the frontend is built statically — the traces of a classic CMS may not be on the pages at all.
If the engine isn't identified, that's an answer too: you're looking at either a carefully locked-down site or a custom build. Both say more about the level of development than the label "WordPress."
Frequently asked questions
The detector says WordPress, but the owner says it's custom. Who's right?
Look at the specific traces. If /wp-content/ and /wp-json/ are there, it's WordPress, even with a custom theme on top. The reverse happens too: a single signal (say jQuery, which WordPress also uses) is not a CMS but a coincidence. Trust the combination of paths and headers, not one marker.
Why hide what engine a site runs on?
For security. Knowing the exact CMS and its version, an attacker immediately picks known vulnerabilities. So removing generator, hiding the version, and stripping extra headers is standard hardening. If it's your site, check that it isn't revealing too much via the security scanner.
Can the CMS tell me a site is vulnerable?
Indirectly. The fact "it's WordPress" decides nothing — the danger is an outdated version with unpatched holes. After identifying the engine you look at the version and update dates; for your own site it's safer to keep it under regular scanning than to rely on obscurity.
Checklist to remember
- The engine is given away by: the
generatormeta, paths (/wp-content/,/sites/default/), headers, and cookies. - One signal isn't a diagnosis; trust the combination of paths and headers.
- An auto-detector checks dozens of signals per pass — faster than a manual search.
- Not identified means the traces are wiped or the engine is custom. That's an answer too.
- Check your own site for over-disclosure (version, headers) with a security scanner.