Paste any URL into the field above and this WordPress theme detector will tell you exactly what theme and plugins the site is running. You get the theme name, parent theme if applicable, the author, a direct store link, and a full list of active plugins from a single scan. First, it checks whether the site is WordPress at all.
Here is what a WordPress scan returns:
Not sure the site is even WordPress? The tool checks first and tells you. If it's running on a different platform, we'll point you to the right detector instead.
When you submit a URL, the detector runs two checks in sequence. First, it looks for WordPress-specific markers in the page source: script handles registered by WordPress core, REST API references, and known file paths like /wp-json/ or /wp-content/. If those markers are present, the site is confirmed as WordPress and theme detection begins.
To find the WordPress theme, the tool reads the stylesheet link in the page head. WordPress almost always loads its active theme via a path in this format:
/wp-content/themes/{theme-name}/style.css
That folder name is the theme's slug. From there, the tool fetches the theme's style.css header, which contains the theme name, version, author, and tags as registered by the developer. For child themes, both the child and parent stylesheets are read so you see the full picture.
Plugin detection works differently. Plugins leave fingerprints throughout the front-end: registered script handles, stylesheet enqueue names, HTML comments, and widget class names. The detector cross-references these against a known database of plugin signatures to identify what's running.
To use this WordPress checker, enter the full URL, including https://, in the field above and click detect. Results appear within a few seconds.
If you're not sure a site is built on WordPress, the easiest way to check is to run it through this tool. It will confirm yes or no in seconds. But if you want to understand what the detector is actually looking for when it checks if a website is WordPress, here's what to know.
WordPress leaves several recognizable markers in a site's front-end code. Any one of them is a strong indicator:
/wp-content/themes/ or /wp-content/plugins/)<meta name="generator" content="WordPress X.X">/wp-login.php returning a valid responseSome site owners use security plugins that remove the generator tag and obscure other markers. Even in those cases, the /wp-content/ folder structure is very difficult to hide completely, which is why this tool can detect WordPress in most hardened configurations.
If you need to check across multiple CMS platforms, our CMS detector can identify WordPress, Shopify, Squarespace, Wix, and more from a single scan.
When you come across a site with a design you want to study or replicate, the first question is usually: what WordPress theme is that? Knowing the theme name tells you where to get it, how much it costs, and who made it.
Most themes used on professional WordPress sites are commercially available. Once you identify the theme, you can purchase it and use it as a starting point for your own site. You can also use the theme name as a concrete reference when briefing a developer. Saying "I want something based on the Astra theme, modified to look like this" is far more efficient than trying to describe a visual style from memory.
Theme research is also useful for competitive analysis. If several competitors in your industry are using the same theme, that theme probably performs well for the content type and audience you share. Knowing that shapes both your design choices and your expectations for what the theme can handle.
For more on what to do once you have a theme name, see our guide on how to find what WordPress theme a site is using.
A basic theme name is useful, but this WordPress theme checker returns enough context to act on the result immediately. Here is what each scan includes for the theme:
Some themes are configured to strip or hide identifying markers, typically through security plugins. In those cases, the detector returns whatever partial information is available and notes that the theme could not be fully identified. A partial result is still useful: the theme slug from the stylesheet path is often enough to search for and find the theme manually.
The plugin list is often more valuable than the theme name. A theme shapes how a site looks; plugins shape what it can do. When you find a site with features you want to replicate, the plugin list tells you exactly what's making those features work.
Think of the theme as the frame and walls of a building. The plugins are the wiring, plumbing, and fixtures that make it functional. Two sites can run the same theme and work completely differently depending on which plugins are active. This is why studying plugins alongside the theme gives a much more complete picture of how a site was built.
The plugin detector reads the site's front-end code for plugin signatures: enqueued script and stylesheet handles, HTML class names, inline script patterns, and HTML comments. Each of these can point to a specific plugin, and the detector cross-references them against a database of known plugin fingerprints.
When you scan a WordPress site, you get the theme name and the plugin list side by side. That combination gives you the full picture of how the site was assembled.
For each detected plugin, the results include the plugin name and, where available, the version number. Version data is useful beyond competitive research: an outdated plugin version is one of the most common ways WordPress sites get compromised, so this is practical for security audits too.
Some plugins cannot be detected because they operate entirely server-side and leave no trace in the front-end code. Payment processors, certain backup solutions, and server-level firewall plugins typically fall into this category. The checker returns what is visible from the outside; it does not claim to catch every plugin in every configuration.
If you prefer to check manually, or if you want to verify what this tool found, here is how to find a WordPress theme without any external tool. This works in any browser.
Right-click on the page and select "View Page Source" (or press Ctrl+U on Windows / Cmd+Option+U on Mac). Then search for wp-content/themes/ using Ctrl+F. The folder name that follows is the theme slug. For example, /wp-content/themes/astra/ means the site uses the Astra theme.
Once you have the theme slug, go directly to https://example.com/wp-content/themes/{theme-slug}/style.css in your browser. If the file loads, the top of it contains the full theme header: the Theme Name, Author, Version, and a description. This is the same information the detector reads automatically.
Search the page source for name="generator". WordPress adds a meta tag here by default: <meta name="generator" content="WordPress 6.X">. Its presence confirms the site is WordPress. Note that many sites remove this tag for security reasons, so its absence doesn't mean the site isn't WordPress.
The manual approach works but takes more steps. Running a URL through the WordPress detector above gets you the same information in a few seconds, including the full plugin list, which is much harder to compile by hand.
The theme name is the starting point, not the destination. If your goal is to build a site that performs like a competitor's, pay as much attention to the plugin list as the theme. The visual design usually comes from the theme, but the features that make a site effective, whether that's conversion rate, content quality, or user experience, typically come from the plugins.
Work through the plugin list systematically. Look up plugins you don't recognize and understand what each one does. If a competitor site loads product pages with rich filtering, there's a filtering plugin in the list. If it has a chat widget, a chat plugin will be there. Matching a site's capabilities means identifying and replicating the key plugins along with the theme.
Also check the version numbers. A competitor running an outdated theme or outdated plugins is potentially vulnerable. That's worth knowing if you're in a space where site security affects trust.
For a full breakdown of detection methods, including manual source-code techniques and browser DevTools approaches, see our guide on how to find what WordPress theme a site is using.
The fastest way to check if a website is built on WordPress is to paste the URL into this tool and click detect. Results appear in seconds. If you prefer to check manually, look at the page source for paths containing /wp-content/themes/ or /wp-content/plugins/. You can also look for a generator meta tag reading WordPress X.X. Any of these markers confirm a WordPress installation.
Paste the site URL into the WordPress theme detector above. The tool reads the site's stylesheet path and the theme's style.css header to return the exact theme name, author, version, and a link to purchase or download it. If you want to check manually, view the page source and search for wp-content/themes/. The folder name that follows is the theme slug.
Some themes are deliberately configured to hide their identity. Security plugins like Wordfence or iThemes Security can remove the generator tag, rename asset paths, or block direct access to theme files. In these cases, the detector may return only a partial result or the theme slug without full metadata. Even with security hardening, the /wp-content/themes/ folder structure is difficult to completely hide, so a partial detection is usually still possible.
A WordPress theme controls how a site looks: its layout, typography, color scheme, and page structure. A plugin controls what the site can do: adding features like contact forms, e-commerce, SEO tools, or membership systems. Themes and plugins work together, which is why scanning both at once gives a more complete picture of how a site was built than checking the theme alone.
Yes. When you scan a WordPress site, the tool returns both the active theme and a list of detected plugins. For each plugin it identifies, you get the plugin name and, where available, the version number. Some plugins that work entirely server-side cannot be detected from the front end, but the tool returns everything that leaves a visible trace in the page code.
