TLDlive

What CMS Does a Website Use? Six Ways to Tell

Every content management system leaves traces in the HTML, the response headers and the file paths it serves. This guide shows the manual checks that work in a minute, how reliable each one is, and how a detector automates them.

Why people ask this question

Developers ask it before a redesign or a migration. Agencies ask it while qualifying a lead. Domain investors ask it when judging whether an expired name once hosted a real business. Security teams ask it because an unpatched plugin ecosystem is a different risk from a hosted store builder. In every case the goal is the same: infer, from public signals only, which platform produced the page.

Nothing here requires special access. A web server must send the browser everything the browser needs, so the platform's fingerprints are unavoidably visible. The skill is knowing which fingerprints are strong, which are weak, and which can be faked.

Method 1: read the generator meta tag

Open the page source (Ctrl+U or Cmd+Option+U) and search for generator. Many systems announce themselves with <meta name="generator" content="...">, a convention documented on the MDN page for the meta element. WordPress usually prints its version, Joomla prints "Joomla! - Open Source Content Management", Ghost prints "Ghost" with a version, and several site builders print their own name.

This is the easiest check and also the weakest. The tag is optional, security plugins remove it routinely, and anyone can write a false value. Treat a generator tag as a hint to confirm, never as proof.

Method 2: look at asset and file paths

Platforms keep files in predictable places. Search the source for these path fragments:

PlatformTypical path or host in the HTMLStrength
WordPress/wp-content/, /wp-includes/, wp-emoji-release.min.jsStrong; survives hiding the generator tag
Drupal/sites/default/files/, /core/misc/drupal.jsStrong
Joomla/media/system/js/, /templates/ with a com_ component in URLsMedium
Shopifycdn.shopify.com, /cdn/shop/, a global named ShopifyStrong
Wixstatic.parastorage.com, static.wixstatic.comStrong
Squarespacestatic1.squarespace.com, Static.SQUARESPACE_CONTEXTStrong
WebflowA data-wf-site attribute on the html element, assets on a website-files hostStrong
Magento/static/frontend/, /media/catalog/Medium

Strength here means resistance to cosmetic change. A site that proxies its images through its own domain can hide a CDN host, but it cannot easily hide the way its theme JavaScript is organised.

Method 3: probe well-known URLs

Some systems expose endpoints that exist on every installation. Visit them in a new tab or fetch them with curl:

  • /wp-json/ returns the WordPress REST API index, and /wp-login.php is the default login page.
  • /products.json on a Shopify storefront lists products in many stores, and /cart.js returns the cart as JSON.
  • /user/login and /CHANGELOG.txt are Drupal conventions, though newer versions no longer ship the changelog file in the same place.
  • /administrator/ is the default Joomla back end.
  • /ghost/ opens the Ghost admin.

Be a considerate visitor. One request per URL is fine; scanning a site for admin paths can trip a web application firewall and is poor manners on sites you do not own. Also note that administrators often block or move these paths, so a missing endpoint proves little.

Method 4: read the HTTP response headers

Headers are sent before the page body and some systems add their own. In DevTools open the Network tab, reload, click the first document request and read the response headers. From a terminal, curl -sI https://example.com prints them. Useful signals:

  • X-Powered-By may name PHP, ASP.NET or Next.js. It is informational and frequently removed.
  • X-Generator is set by Drupal in many versions.
  • X-Wix-Request-Id appears on Wix-hosted pages.
  • Server names the web server, such as nginx or Apache, or a CDN such as Cloudflare, which tells you about hosting rather than the CMS.
  • Link headers with rel="https://api.w.org/" point to the WordPress REST API.

Header semantics are defined in RFC 9110. Remember that a CDN in front of the site can overwrite or hide headers from the origin, which is why headers alone often identify the hosting layer instead of the application. See the guide to Cloudflare and CDN detection for that case.

Method 5: check JavaScript globals and the DOM

Open the DevTools console and type the name of a suspected global. Shopify returning an object means a Shopify theme. jQuery.fn.jquery prints the jQuery version. window.__NEXT_DATA__ exists on Next.js pages that use the Pages Router, which is covered in the guide to detecting Next.js and React. This method is precise because the globals exist for the platform's own scripts, but it needs a live browser, so it cannot be done from a plain HTTP fetch.

Class names and data attributes also help. A body class that begins with wp- or woocommerce suggests WordPress and its store plugin. Element IDs such as __next suggest Next.js, and data-reactroot was the marker of older server-rendered React.

Method 6: use a detector

Doing five checks by hand for every site does not scale. Detectors encode the same clues as a catalogue of patterns, each with a confidence score, then combine them. They also follow implications: if Shopify is detected, the page also runs on a hosted commerce platform, so the "ecommerce" category follows without a separate rule.

TLDlive Lens is a browser extension that runs this logic locally in the tab you are looking at. It reads response headers, meta tags, script and link URLs, a capped sample of the HTML, cookie names, selected JavaScript globals and DOM selectors, matches them against its catalogue, and shows the technologies and a guessed site purpose in the popup. Detection runs in your browser; nothing needs to be uploaded for the popup to work. Sharing anonymous, domain-level observations is optional and off until you opt in, as described in the privacy policy.

When enough people opt in, those observations feed the technology statistics on /technologies. For a single name you have not visited, the domain checker at /check shows what TLDlive knows about its registration and DNS.

Where detection goes wrong

  • Headless and decoupled sites. A WordPress back end feeding a Next.js front end serves a Next.js page. The visitor sees the front end only, so the manual methods report the framework, not the CMS.
  • Reverse proxies and path rewriting. A site can serve its platform behind another domain or rewrite /wp-content/ to a custom directory.
  • Migrations. Leftover files from the old platform can remain in the HTML long after a migration.
  • Lookalike signals. A plugin that imitates a generator tag, or a theme that copies another platform's markup, produces false positives.
  • Versions. A version string is the first thing hardened sites remove, so "unknown version" is normal and not a sign of a failed check.

The practical rule is to require two independent signals, for instance a path and a global, before you write down a conclusion. Detectors that give a confidence number are doing the same thing: a lone weak match scores low, and several agreeing matches score high.

A five-minute routine

  1. Search the source for generator, wp-content, cdn.shopify.com, parastorage and _next.
  2. Read the response headers of the first document request.
  3. Try the one well-known URL that matches your leading guess.
  4. Confirm with a JavaScript global or a body class.
  5. Record the evidence next to the conclusion, with the date, because sites change.

If the goal is domain research rather than curiosity, pair the result with registration data: a site built on a hosted builder that was registered last week tells a different story from a ten-year-old self-hosted installation. The guide to what newly registered domains run explains how TLDlive analyses that at scale.

Sources

Frequently asked questions

What is the fastest way to see what CMS a website uses?

View the page source and search for the words generator, wp-content, cdn.shopify.com and parastorage. Those four searches identify most WordPress, Shopify and Wix sites within a minute. A detector extension does the same checks automatically.

Can a website hide its CMS?

It can hide the easy clues, such as the generator tag and version numbers, and it can proxy assets. It cannot hide everything, because the browser needs scripts, styles and markup that follow the platform's structure. Hiding reduces confidence rather than removing it.

Is it legal to check what a website is built with?

Reading the public HTML and headers that a server sends to every visitor is normal web use. Avoid aggressive scanning of private paths, and do not try to log in or exploit anything you find. This is general information, not legal advice.

Why does a tool say Next.js when I expected WordPress?

Many modern sites use WordPress only as a headless content back end. The page you see is produced by a separate front end, so a detector reports the front-end framework. Look for the WordPress REST API on a sibling hostname to confirm the back end.