What CMS Does This Website Use? 8 Checks for Any Site
Abhay Khant
Jan 1, 1970 • 7 min read
What CMS Does This Website Use? How to Check Any Site
- View-source asset paths identify most CMSs on sight: wp-content means WordPress
- The generator meta tag often declares the platform outright
- Builder platforms like Wix, Squarespace, and Webflow betray themselves through their static-asset domains rather than directory structures
- A site's wp-json endpoint confirms WordPress in one request
The quick answer to "what cms does this website use"
You can answer what cms does this website use for most sites in under two minutes without installing anything. Right-click, choose View Page Source, then search for the platform signatures below. It takes one click more than loading the page. Asset paths are the fastest tell because nearly every CMS organizes uploads and scripts into recognizable directories. This article is the CMS-focused companion to the complete website technology detection workflow, which covers the broader stack beyond the content management layer.
Per-platform signatures at a glance
| Platform | Strongest signal | Confirming signals |
|---|---|---|
| WordPress | /wp-content/ asset paths | Generator meta, /wp-json/ endpoint, wp-settings- cookies |
| Shopify | Assets from cdn.shopify.com | /collections/ URLs, Shopify.shop JS variable |
| Wix | Assets from static.wixstatic.com | Wix-specific JS objects in source |
| Squarespace | Assets from static1.squarespace.com | Squarespace globals, template names in CSS paths |
| Webflow | Assets from assets.website-files.com | data-wf-page attributes, w- prefixed classes |
| Drupal | /sites/default/files paths | drupal-settings-json, generator meta |
| Joomla | /media/ vendor paths | /components/com_ URLs, generator meta |
| Ghost | /content/images/ paths | Ghost SDK markers in source |
One strong signal plus one confirming signal is the standard before you state a conclusion. A single match can be coincidence; two independent matches rarely are.
The 30-second checks, in order
Response headers come first in practice even though they need developer tools: open the Network tab, select the document request, and read the Server and X-Powered-By headers, which often name the backend before you touch the source at all.
Check the generator meta tag first
In the page source, look for <meta name="generator">. As [MDN's meta element documentation](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta) notes, this tag exists precisely to declare the software that generated the page. Many sites strip it for security hardening, but plenty leave it in, sometimes with a version number attached.
Search the source for asset directories
Use your browser's find-in-page on the source view and search for each signature path from the table. The first hit usually settles the question. Uploads, themes, and scripts all live inside these directories, so even a single image URL reveals the platform.
Confirm WordPress with one request
If the evidence points at WordPress, the [WordPress REST API](https://developer.wordpress.org/rest-api/) settles it definitively: append /wp-json/ to the domain and a JSON response naming the site appears. Hardened sites disable this route, so an error response is not proof against WordPress, but a success response is proof of it. The wp-settings- cookies listed in the table work as a fallback: they appear in DevTools under the Application tab once you browse a WordPress site logged-in or not.
A worked example with real output
We ran the two strongest checks against techcrunch.com while writing this guide (verified August 2026), and both signals agreed. Notably, no generator meta tag appeared in the source, which shows why relying on any single signal fails: the asset paths carried the identification alone.
- Asset paths: the page source contains multiple
wp-content/uploads/image URLs, the classic WordPress directory - REST probe: requesting
/wp-json/on the domain returned HTTP 200, meaning the WordPress REST API is live and answering
Two independent signals, one conclusion: WordPress. The whole check took under a minute with nothing but view-source and a browser address bar. That is the standard of proof worth holding every detection to, and it works the same way on any site you are curious about.
Builder platforms hide differently
Wix, Squarespace, and Webflow sites rarely expose directory structures because everything loads from the vendor's own domains. That actually makes them easier to spot: check where the stylesheets and images come from. A stylesheet pulled from a squarespace or wixstatic domain answers the question instantly. These platforms also lock URL structures, which shows up in the address bar itself.
Each vendor documents its platform openly, which helps verification: the [Shopify developer documentation](https://shopify.dev/docs) describes the theme architecture behind those cdn.shopify.com assets, [Squarespace's developer docs](https://developers.squarespace.com/) cover its template structure, and [Webflow's platform docs](https://developers.webflow.com/) explain the site-files hosting its exports use. Matching what you observe against the vendor's own documentation turns a hunch into a verified identification.
Shopify sits between the two worlds: stores run on custom domains but every asset call goes back to cdn.shopify.com, and product URLs follow the collections-and-products pattern regardless of branding.
The self-hosted long tail: Drupal, Joomla, Ghost
Self-hosted CMSs beyond WordPress follow the same directory conventions, just with their own names. [Drupal's documentation](https://www.drupal.org/docs) describes its /sites/ directory structure, which survives into production URLs as /sites/default/files. Joomla deployments commonly expose /media/ and component paths that the [Joomla documentation](https://docs.joomla.org/) catalogs; note that Joomla 3 sites may still show the older /media/jui/ layout, which version 4 restructured. Ghost sites serve uploads from /content/images/ as shown in the [Ghost docs](https://ghost.org/docs/). The pattern generalizes: every CMS documents its own directory layout, and those layouts leak into public asset URLs whether the operator intends it or not.
When a site hides its CMS
Hardened sites rename asset directories, strip generator tags, and disable API routes specifically to defeat these checks; as [MDN notes on server identification](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server), minimizing exposed implementation details is a recognized hardening practice. When every direct signal comes up empty, indirect signals still help: the [sitemap protocol](https://www.sitemaps.org/protocol.html) files at robots.txt and sitemap.xml often retain platform-shaped paths even after cosmetic hardening, and hosting fingerprints from an IP lookup narrow the platform family (managed hosting platforms show up in IP and TLS fingerprints). Sometimes the honest conclusion is that the CMS is not publicly determinable, and pretending otherwise helps nobody.
Why people ask this question
The motive shapes how deep to dig. Competitor research wants the platform to estimate costs and flexibility. Job applicants want to know which skills a role actually touches. Site owners migrating want to know what they are moving away from. Security researchers document exposed versions responsibly. In every case the manual checks above answer the question faster than signing up for a scanner, and the roundup of the best tools to detect website technologies covers when automated scanning earns its keep instead.
Common detection mistakes to avoid
| Mistake | Why it misleads | Better approach |
|---|---|---|
| Trusting one signal | Asset paths can survive platform migrations for years | Require two independent signals |
| Reading old tutorials' paths | Platforms rename directories across major versions | Check current docs, not stale lists |
| Assuming absence means custom | Hardening strips signals; hidden is not handmade | Try indirect signals before concluding |
| Confusing CDN with CMS | A Cloudflare header says nothing about the origin platform | Separate edge findings from origin findings (see the detection workflow) |
The migration trap catches the most people: sites move platforms and leave old asset URLs behind in cached pages, older posts, and third-party embeds. A wp-content URL on an otherwise un-WordPress-looking site deserves suspicion rather than instant verdicts.
Checking any site's CMS from here on
To find what cms does this website use: open the source, read the generator tag, search for signature asset paths, and confirm with a second signal such as the wp-json endpoint or an asset domain. Builder platforms reveal themselves through their static-asset domains, hardened sites resist politely, and the whole check costs nothing but a minute of attention. Bookmark this guide as your cms detector reference for the next site that catches your curiosity.
