What CMS Does This Website Use? How to Check Any Site
· 11 min read
Find what CMS any website uses in under 2 minutes with 8 free view-source signatures covering WordPress, Shopify, Wix, Squarespace, Webflow, and Drupal.
- View-source asset paths identify most CMSs on sight: wp-content means WordPress
- WordPress runs 40.7% of all websites and 58.9% of the known-CMS market per W3Techs, August 2026; those are two different denominators
- Builder platforms like Wix, Squarespace, and Webflow betray themselves through their static-asset domains rather than directory structures
- A 401 or 403 on the wp-json endpoint means the route was locked down by its owner
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. Asset paths are the fastest tell because nearly every CMS organizes uploads and scripts into recognizable directories. WordPress alone accounts for 40.7% of all websites and a 58.9% share of the CMS market in the W3Techs survey updated August 30, 2026, which is why its signatures dominate this list. This article is the CMS-focused companion to the complete website technology detection workflow, and the companion piece on how technology detection works shows how scanners do the same checks automatically.
Prefer to watch? This two-minute walkthrough from the ToolSura YouTube channel runs the same checks against a live site, view-source signatures and all, using nothing but a browser:
Which CMSs are you actually looking at?
Knowing the odds sharpens every guess. WordPress powers 40.7% of all websites, which is a 58.9% share of the CMS market, per W3Techs as of August 2026. Those two percentages use different denominators, so keep them straight: one divides by every site on the relevant web, the other only by sites running a CMS that W3Techs can identify. Conflating them is the single most common error in CMS statistics.
The rest of the field is far smaller. Shopify runs 5.3% of all websites and 7.7% of the CMS market, Wix sits at 4.2% and 6.1%, Squarespace at 2.5% and 3.5%, Joomla at 1.1% and 1.7%, and Drupal at 0.7% and 1.0%, with Ghost at 0.1% on both counts. Another 30.9% of websites use none of the content management systems W3Techs monitors. A random site is thus more likely WordPress than every other platform combined.
One methodology note: W3Techs updates its reports daily, counts what it calls the relevant web using publicly available sources such as Tranco, Google, Microsoft, and ipinfo.io, and detects platforms by searching for the same patterns you will check by hand below: generator meta tags, HTTP headers, and URL structure.
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 | First-party /cdn/shop/ paths or legacy cdn.shopify.com/s/files/ assets | /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 cdn.prod.website-files.com (newer) or assets.website-files.com (legacy) | 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.
Two rows changed shape recently. Webflow's own site now serves images from cdn.prod.website-files.com, while older sites still load assets from the legacy assets.website-files.com domain, so treat either as a hit. Shopify stores are split the same way: the live storefront allbirds.com, observed August 2026, pulls files from the first-party path /cdn/shop/files/ on its own domain alongside legacy cdn.shopify.com/s/files/1/.../files/ URLs, whose numeric store ID is visible right in the path.
The 30-second checks, in order
- Read response headers (Server, X-Powered-By)
- Check the generator meta tag
- Scan asset paths for platform directories
- Probe the /wp-json/ REST route on WordPress suspects
- Inspect cookies for platform prefixes
- Note which CDN serves the assets
- Study URL patterns such as /collections/ or /wp-content/
- Fall back to indirect signals when a site hides its stack
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. The two headers carry different weight. MDN lists Server as a standard header defined in RFC 9110, while MDN documents X-Powered-By as a non-standard header for identifying the application or framework that generated the response, not part of any current specification.
Can a site fake these? Yes, and MDN says the payoff is limited: a header with fine-grained implementation details may make known vulnerabilities easier to detect, yet obscuring it is of debatable value because fingerprinting server software is possible via other means. The deeper mechanics, including X-Powered-By patterns, are covered in technology fingerprinting for developers.
Check the generator meta tag first
In the page source, look for <meta name="generator">. As MDN's standard metadata names documentation notes, generator is a spec-standard name whose value is the identifier of the software that generated the page. Many sites strip it for security hardening, but plenty leave it in, sometimes with a version number attached. WordPress 7.1, released August 19, 2026, is the current release, and version 7 overall runs on 58.6% of WordPress sites per W3Techs version data, so generator tags commonly read WordPress 7.x this year.
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. Version strings map to the current releases: WordPress 7.1, Joomla 6.1.3 with 5.4.8 maintained in parallel, Drupal 11.4.6 under security coverage until June 2027, and Ghost 6.x.
Confirm WordPress with one request
If the evidence points at WordPress, the REST API discovery mechanism settles it: append /wp-json/ to the domain and a JSON response naming the site appears. The same documentation specifies a Link header with rel="https://api.w.org/" that stock installs emit, plus the fallback form ?rest_route=/ for sites without pretty permalinks. Clients, the docs state, are advised to handle both forms. Paste what you get back into the JSON formatter to read the site name and namespaces cleanly.
Failures have a documented cause. Hardened sites deny unauthenticated access through the rest_authentication_errors filter, available since WordPress 4.4.0: when the filter returns a WP_Error, access is denied, which is the official mechanism behind the 401 and 403 responses you will meet in the wild. 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 logged-in fallback: they appear in DevTools under the Application tab only after you sign in.
A WordPress console check when the source is scrubbed
Sometimes the source gives you nothing and the console still talks. The wp-emoji.js source in WordPress core reads a settings object named window._wpemojiSettings, leading underscore included, sets window.wp.emoji, and depends on the global window.twemoji. A default install shows all three, so typing any of the names into DevTools on a suspect gives a third confirming signal. This marker is WordPress-only; we claim nothing about console globals for other platforms.
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 to hold every detection to, and it works the same way on any site.
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 describes the theme architecture behind those cdn.shopify.com assets, Squarespace's developer docs cover its template structure, and Webflow's platform docs 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 asset calls split between the first-party /cdn/shop/ path and legacy cdn.shopify.com/s/files/ URLs, 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 sites commonly expose /sites/default/files in their asset URLs, and current production releases sit at 11.4.6, which drupal.org describes as ready for production use with security coverage until June 2027. Joomla deployments expose /media/ and /components/com_ paths, with older Joomla 3 sites still showing the legacy /media/jui/ layout; the Joomla project site offers 6.1.3 as the latest stable release with 5.4.8 maintained in parallel.
Ghost sites serve uploads from /content/images/ in observed default setups, a pattern that persists across the current 6.x releases listed on the Ghost GitHub releases page. 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, minimizing exposed implementation details is a recognized hardening practice. When every direct signal comes up empty, indirect signals still help: the sitemap protocol 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 platforms show up in IP and TLS fingerprints, which an SSL certificate check surfaces). Sometimes the honest conclusion is that the CMS is not publicly determinable, and pretending otherwise helps nobody.
A missing signal is not proof of a custom build. It usually means someone hardened the site, migrated it, or built on a platform outside the 30.9% with no monitored CMS. Check the migration trap in the mistakes table before you conclude anything.
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 and asset domains across versions, as Webflow's cdn.prod migration shows | Check current behavior, 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) |
| Trusting a faked Server header at face value | Obscuring it is of debatable value because fingerprinting works by other means, per MDN | Treat headers as one vote, never the verdict |
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. Remember the odds: WordPress holds 58.9% of the CMS market per W3Techs, so it is the rational first guess, yet 30.9% of sites run no monitored CMS at all. 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, and read how detection tools do it automatically when you need to scan at scale.
Written by
Abhay Khant
Abhay Khant is the founder of ToolSura, a privacy-first developer tools platform. Writes about client-side architecture, AI tooling, and the open web.