The World Wide Web is piled up with an array of websites, each powered by a different content management system. Among these, WordPress stands as a dominant force, driving a substantial share of websites worldwide with its user-friendly interface and versatile features. Amidst this vast online ecosystem, distinguishing whether a specific website is built on WordPress or another platform can sometimes prove to be a genuinely tricky task, especially once a developer has stripped out the obvious signals and customized the front end heavily. This ambiguity often arises from the diverse customization options available to website owners and developers, a heavily modified WordPress site can look nothing like the default install most people picture when they think of the platform. Equipped with the right tools and a bit of methodical checking, though, it’s possible to unravel the mystery and accurately identify WordPress-powered websites in nearly every case.
This matters beyond idle curiosity. Developers use it for competitive research, agencies use it during a client pitch to understand what they’d be inheriting, and site owners use it to sanity-check what a contractor actually delivered. Here’s a rundown of the most reliable, and a few less reliable, methods to figure it out.
Methods for Recognising a WordPress Website
1. Check the Footer for a “Powered By WordPress” Watermark
One of the easiest methods is checking the footer section for a “Powered by WordPress” credit line. If it’s there, the answer is immediate and certain. If it’s not there, that tells you nothing definitive either way, this credit line is easy to remove, and most professionally built or agency-built WordPress sites remove it deliberately as a matter of branding preference. Treat a present watermark as strong positive evidence and an absent one as no evidence at all, rather than assuming its absence means the site isn’t WordPress.
2. Try WordPress-Specific URL Paths
Websites built on WordPress typically have certain files and directories specific to the platform, most reliably wp-admin, wp-content, and wp-login.php. Append one of these to the site’s root URL, for example turning example.com into example.com/wp-admin, and load the page. On a genuine WordPress install, this reliably returns the WordPress login screen (even if you don’t have credentials, the login form itself is the tell) or, less commonly, a 403 forbidden error if the admin area is specifically locked down by IP or a security plugin, which is itself still a meaningful signal since that kind of lockdown is a WordPress-specific hardening pattern.
3. Search the Page Source Code
When you’ve landed on the website, right-click and choose “View Page Source” or open your browser’s developer tools (Inspect). Use Ctrl+F (or Cmd+F on Mac) and search for keywords like wp-content, wp-includes, or generator. WordPress core, by default, outputs a meta generator tag in the page head announcing the exact version running, something like <meta name=”generator” content=”WordPress 6.7″ />, though many security-conscious sites deliberately strip this tag out, so its absence isn’t conclusive on its own. Searching for wp-content specifically in image and script paths tends to be more reliable, since that folder structure is fundamental to how WordPress organizes uploaded media and enqueued assets, and it’s rarely renamed even on heavily customized builds.
4. Use a Browser Extension Like Wappalyzer
Install a technology-detection browser extension such as Wappalyzer. Once enabled, it analyzes the page automatically as you browse and reports back not just the CMS (WordPress or otherwise) but the theme where detectable, active plugins where their signatures are visible in the front-end code, the web server software, and any analytics or advertising scripts running on the page. This is genuinely the fastest method for casual, one-off checks, since it runs passively in the background rather than requiring you to manually dig through source code each time.
5. Use a Dedicated Technology-Lookup Website
There are several websites built specifically to look up the technology stack behind any given URL without needing to install anything. WhatCMS, W3Techs, and IsItWP all let you paste in a URL and get back a CMS identification, often along with theme and plugin detection similar to what Wappalyzer offers. These are convenient when you’re checking a site from a device where you can’t install a browser extension, or when you want a quick second opinion to cross-reference against what a browser extension reported.
6. Check the REST API Endpoint
A method worth adding that goes beyond the original list here: nearly every modern WordPress install exposes a REST API at /wp-json/, visiting example.com/wp-json/ on a WordPress site typically returns a JSON response describing the site’s name, description, and available API routes. This is a genuinely reliable check specifically because it’s a functional API endpoint rather than a decorative marker, disabling it entirely (rather than just hiding it visually) requires deliberate developer effort, so its presence is a strong positive signal even on sites that have stripped every other visible WordPress marker.
7. Ask the Developer or Site Owner Directly
If you’ve applied all of the above methods and still can’t confirm it either way, the most reliable option left is simply asking the developer or site owner directly. This sounds anticlimactic after a list of technical detection methods, but for a genuinely obscured site (a headless WordPress setup, for instance, covered below), no amount of front-end inspection may give you a definitive answer, and a direct question resolves it instantly.
Why Some WordPress Sites Are Genuinely Hard to Detect
It’s worth understanding why detection sometimes fails outright, rather than assuming every method above will always work. A few scenarios specifically defeat most or all of the checks covered so far:
Headless WordPress. In a headless setup, WordPress runs purely as a backend content source, exposing content through the REST API or GraphQL, while the actual front end that visitors see is built with a completely separate framework (commonly Next.js, Astro, or another JavaScript framework) that consumes that API and renders its own HTML. A headless site’s rendered page source contains none of the traditional wp-content paths, no generator tag, no WordPress-specific URL structure at all, because the visible front end genuinely isn’t WordPress-rendered HTML. The REST API check (method 6 above) is sometimes the only method that still works here, if the /wp-json/ endpoint is still exposed publicly rather than proxied or hidden behind the headless front end’s own API layer.
Heavy page-builder output. Sites built extensively with Elementor, Divi, or a similar page builder sometimes generate such a dense, framework-specific class naming convention (Elementor’s elementor-element classes, for instance) that a casual glance at the source code reads as “some page builder” long before it registers as specifically WordPress underneath. The underlying wp-content paths for the builder’s own assets are usually still present and detectable, but a quick visual scan of the markup can genuinely mislead someone who isn’t looking carefully at the actual asset URLs.
Aggressive security hardening. A site with a security plugin actively blocking or cloaking wp-admin, wp-login.php, and the REST API, renaming or moving the wp-content directory, and stripping the generator tag, can defeat nearly every method above simultaneously. This is a deliberate, security-motivated obfuscation rather than an accident, and it’s worth recognizing you may simply hit a wall on a site configured this way, no shame in falling back to method 7.
What Detection Tools Can and Can’t Tell You Beyond “Yes, It’s WordPress”
Once you’ve confirmed a site is running WordPress, tools like Wappalyzer, WhatCMS, and W3Techs often surface additional useful detail worth knowing about: the active theme (sometimes, if the theme’s own assets are detectable via their file paths), a partial list of active plugins (again, only those with detectable front-end signatures, server-side-only plugins won’t show up this way at all), the web server software, and sometimes the hosting provider based on IP or DNS patterns. Don’t treat a plugin list from one of these tools as exhaustive, though, plenty of plugins do all their work server-side or in the admin area with zero visible front-end footprint, and those simply won’t appear in any client-side detection tool no matter how thorough.
A Practical Use Case: Competitive and Vendor Research
Beyond simple curiosity, this kind of detection work has real practical uses. An agency evaluating whether to take over maintenance of an existing site benefits from confirming the platform and, where possible, the theme and major plugins before quoting a scope of work, since “it’s WordPress with a custom theme and 40 plugins” is a very different maintenance proposition than “it’s WordPress with a well-known page builder and a dozen plugins.” A business researching competitors’ websites for a redesign project can use the same methods to understand what platform and rough toolset a competitor is running, informative context when scoping your own project. And a site owner who’s inherited a site from a previous developer, with no documentation and no login credentials handed over, can use these exact methods as a starting point for figuring out what they’re actually working with before trying to regain access.
Checking Response Headers for Additional Clues
Beyond the page source itself, a site’s HTTP response headers can offer supporting evidence, viewable through your browser’s developer tools under the Network tab, specifically the response headers for the main document request. Some WordPress hosting setups (particularly certain caching plugins or managed WordPress hosts) add identifying headers like x-powered-by or a caching-plugin-specific header naming the plugin directly. This isn’t universal, plenty of WordPress sites strip or don’t set any WordPress-identifying headers at all, but on the sites where it is present, it’s a useful corroborating signal alongside the source-code and URL-path checks above, particularly useful when you want a second independent confirmation before concluding a borderline case one way or the other.
Building a Quick Personal Checklist
For anyone doing this kind of check regularly, whether for competitive research, client onboarding, or just curiosity, it’s worth having a consistent order of operations rather than reaching for a random method each time. A reasonable sequence: try the /wp-admin/ URL append first, since it’s instant and conclusive when it works; if that’s inconclusive, run a browser extension like Wappalyzer for a fast automated read; if still unclear, check the /wp-json/ REST API endpoint specifically, since it’s one of the harder signals to fully suppress; and only fall back to manually searching page source or cross-referencing a lookup website if the faster checks haven’t resolved it. This ordering front-loads the fastest, most reliable checks and saves the more manual, time-consuming methods for the genuinely stubborn cases where they’re actually needed.
Frequently Asked Questions
Can I tell which specific theme a WordPress site is using?
Often, yes, though not always with full certainty. Theme assets (CSS and JS files) are typically loaded from a path like wp-content/themes/theme-name/, visible in the page source or through a tool like Wappalyzer. Heavily customized themes, or sites using a child theme with a generic or renamed folder, can make the specific parent theme harder to pin down exactly, but the general approach (checking asset paths under wp-content/themes/) works in the large majority of cases.
Does WordPress detection tell me anything about site security or quality?
Not directly. Knowing a site runs WordPress tells you nothing on its own about whether it’s kept updated, well-secured, or well-built, WordPress itself is just the platform, and site quality depends entirely on how it’s configured, which plugins are active, and how diligently it’s maintained. Detection tools that surface the WordPress version number (when visible) can hint at how current the install is, an old, unpatched version number is a real signal worth noting, but the CMS identification alone isn’t a quality or security assessment.
Is it legal or ethical to check what platform someone else’s website runs on?
Checking publicly accessible information like page source code, response headers, and publicly exposed API endpoints through normal browsing (rather than attempting unauthorized access to anything requiring credentials) is standard, ethical, widely practiced research, the same category of activity as viewing a site’s public “About” page. It’s worth keeping the distinction clear between passive detection like this and anything that involves attempting to actually access restricted areas without authorization, which is a completely different, and legally risky, category of activity.
Why does the same site sometimes show different results in different detection tools?
Different tools rely on somewhat different signals and update their detection signatures on different schedules, so it’s not unusual for one tool to catch something (a specific plugin, for instance) that another misses, or for results to lag slightly behind a recent site change. Cross-referencing two or three methods, rather than trusting a single tool’s output as fully authoritative, gives a more reliable picture than any one check alone.
Will these methods work on a WordPress multisite network the same way as a single WordPress install?
Yes, largely. A WordPress multisite network still exposes the same core wp-content and wp-admin structure per individual site within the network, so the detection methods above apply the same way. The one added wrinkle is that multisite installs sometimes use a slightly different URL structure for the admin area on subsites, worth being aware of if a straightforward /wp-admin/ append doesn’t immediately land where expected.
Can a site be “partly” WordPress, like just the blog section?
Yes, and this is genuinely common on larger sites, particularly ones that started on a different platform and added a WordPress-powered blog subdirectory or subdomain later, or vice versa, a WordPress site with a separate, non-WordPress application handling something like a customer portal or a specialized booking system. In these cases, the detection methods above will correctly identify WordPress for the blog or content section specifically while returning no WordPress signals at all for the other parts of the same overall site, worth checking multiple sections separately rather than assuming one result applies site-wide.
Does knowing a competitor uses WordPress actually help my own project?
It can, in a practical, scoping sense rather than a strategic one. Knowing a competitor’s platform tells you roughly what’s achievable within that ecosystem (which is useful context if you’re evaluating platforms for your own project), and combined with theme/plugin detection, it can surface specific tools or approaches worth researching further. It’s not a substitute for your own requirements-driven platform decision, but it’s a reasonable, low-effort data point to fold into that broader research.
What to Do Once You’ve Confirmed It’s WordPress
Confirming a site runs WordPress is usually the starting point for some further action, not the end goal itself. If you’re evaluating a site for a redesign or migration project, the next step is typically identifying the specific theme and major plugins in play, as covered above, since that determines how much of the existing setup is reusable versus needing to be rebuilt. If you’re doing competitive research, cross-referencing the platform finding against the site’s actual functionality (its checkout flow if it’s a store, its community features if it’s BuddyPress-powered) tells you more about what’s achievable within WordPress than the bare platform identification alone. And if you’ve inherited an undocumented site, confirming it’s WordPress is the first step toward actually regaining meaningful access, next comes locating hosting credentials, confirming who owns the domain registration, and getting into wp-admin itself, none of which the detection methods above can help with directly, but all of which become much more tractable once you know definitively what you’re working with.
In summary, determining whether a website is built on WordPress can be accomplished through a combination of quick visual checks, browser extensions, dedicated lookup tools, and, for the genuinely obscured cases, a direct question to whoever built it. These resources offer a quick and convenient way to identify the underlying platform of a website, helping to inform decisions around competitive research, maintenance scoping, or simply satisfying curiosity about how a site you admire was actually built. No single method is foolproof on its own, particularly against a headless setup or deliberate security hardening, but cross-referencing a few of the approaches above resolves the question correctly in nearly every real-world case you’re likely to encounter.
Interesting Reads:
WordPress Website Builder Plugins