How to detect WordPress on any website
The content management system that powers roughly 40% of the web.
By Mapree ·
Official siteWhat is WordPress?
WordPress is the single most-used CMS in the world, powering blogs, agency sites, e-commerce (via WooCommerce) and huge enterprise deployments. Its architecture revolves around plugins and themes loaded from predictable `/wp-content/` paths — which makes detection and enumeration easy.
WordPress was built on a simple premise: PHP-based templating plus a plugin/theme architecture that lets non-developers extend the system. Two decades later, that premise has produced the largest CMS ecosystem on the web. WordPress's plugin marketplace lists tens of thousands of plugins; its theme directory has more. The architecture of the site — how plugin assets are served from `/wp-content/plugins/<slug>/`, how themes live in `/wp-content/themes/<slug>/`, how `wp-includes/` serves core assets — is completely stable across versions, which makes detection and enumeration reliable. A WordPress site's plugin list often tells you more than its theme: WooCommerce means e-commerce; Elementor or Divi mean a page-builder-driven editorial experience; WPForms, Gravity Forms or Contact Form 7 tell you the form pipeline; Yoast or Rank Math is the SEO layer.
Why it matters to identify
On a WordPress site, the plugin list often matters more than the CMS itself. A single plugin can be responsible for page builders, checkout, forms, SEO, security or caching. Enumerating them turns a categorical 'WordPress' detection into an actionable tech breakdown.
A brief history of WordPress
WordPress started in 2003 as a fork of b2/cafelog. Its plugin system arrived in 2004 and has remained backwards-compatible for two decades. WooCommerce (the e-commerce plugin that dominates WordPress-based stores) was released in 2011. Gutenberg block editor replaced the classic TinyMCE editor in 2018 (WordPress 5.0). Full-Site Editing (FSE) with block themes arrived around 2022.
Ecosystem and common pairings
Common WordPress stacks: WooCommerce (e-commerce), Elementor (page builder), Yoast SEO, Advanced Custom Fields, Gravity Forms / WPForms, WP Rocket / W3 Total Cache, Wordfence / Sucuri (security), UpdraftPlus (backups). Hosting ranges from WP Engine / Kinsta / Pressable for managed installs to self-hosted on cPanel/VPS.
Detection signals we look at
Each signal alone is rarely conclusive; the detector cross-references all of them and weights by confidence. You can reproduce any of these checks yourself in Chrome DevTools.
<meta name="generator" content="WordPress
Default WordPress installs emit a generator tag with the version. Can be stripped by admins.
/wp-content/|/wp-includes/
Every WordPress asset is served from one of these paths. Almost impossible to hide on a working site.
x-pingback: https?://.*/xmlrpc\.php
WordPress advertises its pingback endpoint via this header.
wordpress_logged_in_|wp-settings-
Set after admin login. Present on editor/admin sessions.
/wp-login\.php|/wp-admin/
Admin entry points are identical across WordPress installs.
Versioning
What you typically see in production
WordPress in 2026 is still the dominant CMS by a wide margin, with W3Techs putting its share consistently around 43% of the public web. Detection is essentially trivial — `/wp-content/` and `/wp-includes/` paths are baked so deeply into the framework that no production WordPress site can hide them without breaking. The interesting questions are downstream: which theme, which plugins, what page builder, what e-commerce stack on top. A typical WordPress site loads 15-40 plugin asset paths during a single page render, each surfacing as a `/wp-content/plugins/<slug>/` URL in the Network tab. Enumerating them gives you the full plugin footprint by slug — Elementor, WooCommerce, Yoast SEO, WPForms, WP Rocket, Wordfence, Astra, MonsterInsights and so on, in a list that is more informative than the categorical 'this is WordPress' answer most public detectors stop at. Sourcemap Explorer does this enumeration automatically; the manual workflow is documented in the [find-wordpress-plugins-used-by-a-site](/how-to/find-wordpress-plugins-used-by-a-site) guide. Three common WordPress shapes you will encounter: (1) classic WordPress with PHP-rendered pages and a moderate plugin count, hosted on shared hosting or a managed WP host like WP Engine; (2) WordPress + WooCommerce e-commerce, with a heavier plugin payload (payment gateways, shipping integrations, product enhancers) and almost always a paid optimization plugin like WP Rocket; (3) headless WordPress, where the visible frontend is Next.js, Astro, or another JavaScript framework pulling from WordPress via WPGraphQL or the REST API — in this case `/wp-content/` does not appear on the visible page and the WordPress backend reveals itself only in the API requests the frontend makes. Multi-site WordPress installs (one WordPress install serving many subsites) are common in agency hosting and large enterprise. They look identical from the outside: same `/wp-content/themes/` paths, same `wp-includes/` core, same `wp_*` cookies. The same plugin enumeration techniques work; the only signal that this is multi-site is sometimes a `Server` header or a `wp-content/uploads/sites/<n>/` upload path leaking the site number.
Sites commonly running WordPress
- techcrunch.com
- thewaltdisneycompany.com
- sony.com (regional)
- vogue.com (regional)
- rollingstone.com
Often confused with
WordPress vs Headless WordPress
A Next.js or Astro frontend backed by WordPress via WPGraphQL won't show `/wp-content/` on the page. The backend reveals itself only in API calls — look for XHR/fetch requests to `/wp-json/wp/v2/` or `/graphql`. The visible site looks like a Next.js or Astro site; the CMS is invisible without inspecting the network tab.
WordPress vs Ghost, Medium, Substack
These are blog-focused competitors but have their own asset paths (`/ghost/assets/` for Ghost, the Medium-domain `cdn-images-1.medium.com` for Medium, Substack's distinctive content frame). The meta-generator value also differs.
WordPress vs Drupal
Both are PHP CMSes with similar surface conventions, but the asset paths give them away cleanly: WordPress uses `/wp-content/`, Drupal uses `/sites/default/files/`. The meta-generator value also differs.
FAQ
How do I find every plugin a WordPress site uses?
Enumerate `/wp-content/plugins/<slug>/` URLs in the Network tab. Sourcemap Explorer does this automatically and lists each slug on the Stack tab; the manual workflow is documented in [find-wordpress-plugins-used-by-a-site](/how-to/find-wordpress-plugins-used-by-a-site).
Can I tell if a WordPress plugin has a known vulnerability?
If you extract the slug and version from `?ver=` query parameters and correlate against the WordPress vulnerability database (Wordfence Intelligence, Patchstack, WPScan), yes. Casual detectors do not do this automatically; with the Sourcemap Explorer plugin enumeration plus a script against the Patchstack API you can build the per-site CVE exposure list in minutes.
How do I identify the active theme?
View Source and search for `/wp-content/themes/`; the first path that comes back is the active theme's asset URL. The theme slug between the slashes maps to wordpress.org/themes for free themes or the vendor's product page for premium themes. The full workflow is in [identify-a-wordpress-theme](/how-to/identify-a-wordpress-theme).
Is WordPress losing share?
By W3Techs measurements, no — WordPress's share of the web has been roughly flat at 42-44% for several years. The growth of headless setups (Next.js + headless WordPress) means more sites use WordPress as a backend without exposing the traditional fingerprints, which can make WordPress appear to be losing share on the visible side while staying strong as the underlying CMS.
How do I tell WordPress from a custom PHP site?
WordPress's signature is unmistakable: `/wp-content/`, `/wp-includes/`, `<meta name="generator" content="WordPress 6.x">`, `wordpress_*` cookies on logged-in sessions, the `/wp-json/` REST API endpoint. A custom PHP site has none of those.
Does WordPress detect work on multisite installs?
Yes. Multisite installs share the same `/wp-content/`, `/wp-includes/` and admin paths; only the `wp-content/uploads/sites/<n>/` upload path differs per subsite. From the outside the detection signature is identical.
How do you tell if a site is built with WordPress or Shopify?
Their fingerprints never overlap, so one look settles it. WordPress serves assets from `/wp-content/` and `/wp-includes/`, exposes a `/wp-json/` REST API, and ships a `<meta name="generator" content="WordPress ...">` tag — and if it sells, the store usually runs WooCommerce under `/wp-content/plugins/woocommerce/`. Shopify instead serves from `cdn.shopify.com` / `/cdn/shop/` and exposes a `window.Shopify` global. If you see `/wp-content/`, it's WordPress; if you see `cdn.shopify.com`, it's Shopify.
Related
See WordPress — with the exact version — on every site you visit.
Sourcemap Explorer runs these checks passively in the background. When the target library is bundled, you get the precise package.json-level version.