How to Check if a Website Uses WordPress (5 Methods That Actually Work)

WordPress is the most widely used CMS on the internet. According to W3Techs, it powers approximately 43% of all websites—everything from personal blogs to enterprise sites like TechCrunch and the White House. Whether you're doing competitive research, evaluating a potential client's site, or running a security audit, knowing whether a site runs WordPress is often the first question you need to answer.

The problem is that not every WordPress site looks like one. Security plugins strip identifying headers. Managed hosting providers remove telltale markers. Custom themes eliminate the default WordPress look entirely. Some sites use WordPress as a headless CMS, serving content through a completely separate frontend that shows no WordPress signatures at all.

This tutorial walks through five methods for detecting WordPress—from the simplest manual checks to automated API detection that catches sites the manual methods miss.

Method 1: Check /wp-admin and /wp-login.php URLs

The fastest manual check: append /wp-admin or /wp-login.php to the site's URL and see what happens.

Try it now. Pick any website and visit:

https://example.com/wp-admin
https://example.com/wp-login.php

If the site runs WordPress, you'll get one of three responses:

• The WordPress login page — unmistakable confirmation. You'll see the WordPress logo and a username/password form.
• A redirect to a custom login page — the site uses WordPress but has customized or relocated the login URL. Watch the URL bar; it might redirect to something like /login or /my-account.
• A 403 Forbidden response — the path exists but access is blocked. This is common on hardened WordPress sites. A 403 on /wp-admin is still a strong signal that WordPress is running underneath.

If you get a clean 404 Not Found, the site probably doesn't use WordPress—or has rewritten all WordPress paths at the server level, which is uncommon.

Method 2: View Page Source for wp-content/ and wp-includes/

Right-click anywhere on the page and select "View Page Source" (or press Ctrl+U / Cmd+U). Then search the source code for these strings:

• /wp-content/ — the directory where WordPress stores themes, plugins, and uploads
• /wp-includes/ — the directory containing WordPress core files like jQuery and other scripts
• wp-emoji-release.min.js — WordPress's emoji support script, loaded by default
• <meta name="generator" content="WordPress — the generator tag, if it hasn't been removed

Here's what WordPress asset URLs look like in practice:

<link rel="stylesheet" href="https://example.com/wp-content/themes/flavor/style.css">
<script src="https://example.com/wp-includes/js/jquery/jquery.min.js"></script>
<img src="https://example.com/wp-content/uploads/2026/03/hero-image.jpg">

The presence of /wp-content/ in any asset URL is a definitive WordPress indicator. Even sites that strip the generator tag and rename the login page almost always leave wp-content paths intact because changing them would break themes and plugins.

Limitation: This method fails for headless WordPress sites where content is fetched via the REST API (/wp-json/) and served through a separate frontend framework like Next.js or Gatsby. In that architecture, no wp-content or wp-includes paths appear in the HTML.

Method 3: Check HTTP Headers

Open your browser's Developer Tools (F12), go to the Network tab, reload the page, and click the first request (the HTML document). Check the response headers for WordPress signals:

• X-Powered-By: PHP/8.2 — WordPress is built on PHP, so this is a supporting indicator (though other PHP applications set this too)
• Link: <https://example.com/wp-json/>; rel="https://api.w.org/" — this is the WordPress REST API discovery header, and it's a definitive marker
• X-Pingback: https://example.com/xmlrpc.php — the WordPress pingback endpoint, enabled by default

You can also check headers from the command line:

curl -sI https://example.com | grep -i "x-powered-by\|x-pingback\|link.*wp-json"

The Link header containing wp-json is the most reliable of these three. WordPress adds it by default, and many site owners don't know it exists—so it survives security hardening that strips the generator tag and X-Powered-By header.

Method 4: Use a Browser Extension

Browser extensions like WhatRuns and Wappalyzer automate the HTML and header inspection described above. Install one, visit any website, and click the extension icon to see a list of detected technologies.

For WordPress detection specifically, these extensions check for:

• The <meta name="generator"> tag
• wp-content and wp-includes in asset URLs
• WordPress-specific JavaScript globals
• Cookie names like wordpress_logged_in_*
• HTTP headers containing WordPress markers

Extensions are convenient for one-off checks, but they have real limitations:

• No automation: You have to visit each site manually. You can't check a list of 500 URLs from a spreadsheet.
• Browser-only signals: Extensions only see what the browser sees—HTTP headers, HTML content, and JavaScript. They don't inspect DNS records or TLS certificates.
• Inconsistent results: Extensions run client-side, which means ad blockers, browser security settings, and content security policies can interfere with detection.
• No API access: You can't integrate extension results into your own tools, pipelines, or databases.

For a deeper look at how extensions compare to API-based detection, see our BuiltWith vs Wappalyzer vs DetectZeStack comparison, or check out our roundup of free BuiltWith alternatives for 2026.

Method 5: Use a Technology Detection API

For the most reliable WordPress detection—especially at scale—use a technology detection API. An API combines all the signals above (HTML patterns, HTTP headers, cookies) and adds layers that manual methods can't reach: DNS CNAME records and TLS certificate inspection.

Here's how to check if a site uses WordPress with the DetectZeStack API:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"

If the site uses WordPress, the response will include it in the technologies array:

{
  "url": "https://example.com",
  "domain": "example.com",
  "technologies": [
    {
      "name": "WordPress",
      "categories": ["CMS", "Blogs"],
      "confidence": 100,
      "cpe": "cpe:2.3:a:wordpress:wordpress:*:*:*:*:*:*:*:*"
    },
    {
      "name": "PHP",
      "categories": ["Programming languages"],
      "confidence": 100,
      "cpe": "cpe:2.3:a:php:php:*:*:*:*:*:*:*:*"
    },
    {
      "name": "MySQL",
      "categories": ["Databases"],
      "confidence": 100
    }
  ]
}

Along with WordPress itself, the API returns the full technology stack: hosting provider, CDN, analytics tools, JavaScript libraries, and security headers. The cpe field maps to the NIST National Vulnerability Database, which is useful if you're doing security auditing.

You can filter for just CMS results with jq:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
  | jq '.technologies[] | select(.categories[] | contains("CMS"))'

To check multiple sites at once, use the batch endpoint:

curl -s "https://detectzestack.p.rapidapi.com/analyze/batch" \
  -X POST \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["site1.com", "site2.com", "site3.com"]}'

For a full walkthrough of the API including Python and JavaScript examples, see Detect Any Website's Tech Stack With a Single API Call.

Edge Cases: When WordPress Hides

The five methods above will catch the vast majority of WordPress sites. But some configurations make detection harder. Here are the edge cases and how to handle them.

Headless WordPress

In a headless WordPress setup, WordPress serves as a content API (via the /wp-json/ REST API or WPGraphQL) while the frontend is built with React, Next.js, Gatsby, or another JavaScript framework. The visitor-facing site contains zero WordPress signatures—no wp-content paths, no generator tag, no WordPress cookies.

Manual detection methods 1 through 3 will all fail here because the WordPress instance typically lives on a separate subdomain (e.g., cms.example.com) that visitors never see. Browser extensions will detect the frontend framework (Next.js, Gatsby) but not the underlying CMS.

API-based detection has a better chance. DNS CNAME analysis can reveal if the backend subdomain points to a managed WordPress host, and page content analysis may catch references to the WordPress REST API in client-side JavaScript.

WP Engine and Managed WordPress Hosts

WP Engine, Kinsta, Flywheel, and other managed WordPress hosts strip headers that would normally identify WordPress. WP Engine in particular removes the X-Powered-By header and replaces the Server header with its own value.

However, these hosts leave other fingerprints. WP Engine adds an x-cache header specific to its caching infrastructure. The wp-content paths in HTML remain untouched. And DNS CNAME records often point to WP Engine's infrastructure (e.g., *.wpengine.com), which is a definitive indicator of WordPress.

Custom Themes That Hide WordPress

Some developers go to great lengths to obscure WordPress: removing the generator tag, renaming the login URL, disabling XML-RPC, and even rewriting wp-content paths to something generic like /assets/.

When you encounter this level of obfuscation, manual methods will fail. But the WordPress REST API is extremely difficult to disable entirely without breaking core functionality. Try visiting /wp-json/ directly:

curl -s https://example.com/wp-json/ | head -c 200

If you get a JSON response starting with {"name":"..., the site runs WordPress—regardless of how well the frontend is disguised.

WordPress Multisite

WordPress Multisite installations host multiple sites on one WordPress instance. Subdomains or subdirectory sites in a Multisite network share the same wp-content and wp-includes directories, so page source inspection works normally. The main difference is that individual subsites may have wildly different themes and designs, making visual identification unreliable.

Why API Detection Catches What Manual Methods Miss

Each manual method relies on a single signal: a URL path, an HTML pattern, or an HTTP header. If that signal is absent—stripped by a security plugin, overwritten by a CDN, or invisible in a headless architecture—the method fails.

API-based detection combines multiple signal layers:

The DNS and TLS layers are the key advantage. When a WordPress site is behind Cloudflare or another CDN (hiding the server header), using a security plugin (stripping the generator tag), and running a custom theme (no obvious visual cues), the DNS CNAME record still points to the managed WordPress host. That infrastructure-level signal is invisible to browser extensions and manual inspection, but it's exactly what API detection is designed to find.

For a deeper dive into how DNS-based detection works, see our guide on DNS-Based Technology Detection.

Which Method Should You Use?

It depends on your use case:

• Quick one-off check: Try /wp-admin first (Method 1), then view source and search for wp-content (Method 2). Takes 30 seconds.
• Checking a handful of sites: Use a browser extension (Method 4). Install once, click to check.
• Checking dozens or hundreds of sites: Use the API (Method 5). Automate with a script, check a whole spreadsheet in minutes. You can also integrate detection into AI agent workflows via MCP.
• Security audit where accuracy matters: Use the API (Method 5). The DNS and TLS layers catch what other methods miss, and the CPE identifiers in the response map directly to the NVD for vulnerability checking.
• Detecting hardened or headless WordPress: Use the API (Method 5) combined with a manual check of /wp-json/. If both come up empty, the site almost certainly doesn't use WordPress.

For broader CMS detection beyond just WordPress—including Shopify vs WooCommerce detection, Squarespace, Wix, Drupal, and more—see our complete guide: How to Detect What CMS a Website Uses.