Detect the theme and plugins
What the report covers
Fetch
One request to the homepage, following redirects, with the headers and cookies kept for fingerprinting.
Identify
WordPress signals are counted first. If there are none, the response is matched against sixty other platforms.
Read the theme
The theme folder is found from asset paths and its style.css header is parsed for name, author, version and parent.
Classify
Themes and plugins are checked against WordPress.org and a vendor list, then labelled free, paid or custom with a reason.
How theme detection works
WordPress does not announce its theme anywhere, but it cannot hide it either. Every stylesheet and script a theme loads comes from a folder under /wp-content/themes/, and that folder name is the theme's slug. The tool finds every such path in the page, counts them, and treats the most-referenced folder as the active theme. It then requests that folder's style.css, which by WordPress convention starts with a comment block naming the theme, its author, its version and, for child themes, the parent it extends via the Template line.
Sites that rename wp-content, serve assets from a CDN or use a Bedrock-style layout are handled by reading the real prefix from the page rather than assuming the default. When a site inlines all of its CSS or an optimiser rewrites every path, the theme folder never appears in the HTML and the report says so instead of guessing.
Free, paid or custom — how the label is decided
Three checks run in order, and the first that matches wins. The report always shows which one fired.
| Label | What matched | Confidence |
|---|---|---|
| Free | The slug exists in the WordPress.org theme or plugin directory. Free themes that sell an add-on (Astra, Kadence, GeneratePress) are still free; the add-on shows up separately if it is installed. | High — the directory is authoritative. |
| Paid | The slug is a known commercial product (Divi, Avada, Elementor Pro, WP Rocket, Gravity Forms …), or its Theme URI / Author URI points at a marketplace or vendor such as ThemeForest, Elegant Themes or StudioPress, or it belongs to a family that is only sold (WooCommerce.com extensions, Crocoblock, Thrive). | High for the vendor list, medium for family rules. |
| Custom | Not in either list, and either its URI points back at the site itself, its name contains the site's brand, it is a child theme, or style.css carries no author information at all. | Medium to high, depending on which clue. |
| Unknown | A third-party plugin that is not on WordPress.org and matches no vendor rule. Its readme is read when one is public. Most of these turn out to be commercial, some are agency builds. | Low — treat as a lead. |
Plugins are found three ways, and each row says which: asset paths under /wp-content/plugins/ are the most reliable and also carry a version number; markup fingerprints such as wpcf7 form classes or a caching plugin's HTML comment catch plugins whose files are combined by an optimiser; and the REST API root at /wp-json/, when public, lists a namespace for every plugin that registers one.
When the site is not WordPress
Roughly six in ten CMS-driven sites are WordPress, which leaves a long tail of everything else. The same response is checked for hosted builders that keep the theme inside their own platform — Shopify, Wix, Squarespace, Webflow, Framer, Weebly, GoDaddy, HubSpot — then for traditional CMSs such as Joomla, Drupal, Ghost, Craft, TYPO3 and Magento, then for static site generators like Hugo, Jekyll, Astro, Eleventy and Docusaurus, and finally for JavaScript frameworks like Next.js, Nuxt and SvelteKit that may be rendering content from a headless CMS.
A site that matches nothing is not automatically custom. If it sets no session cookie, links to plain .html files and sits on a static host like Netlify, GitHub Pages or S3, it is reported as a static HTML site. If cookies or headers reveal Laravel, Django, Rails or ASP.NET with no CMS on top, it is reported as custom-built on that stack. Only when nothing at all matches does the report say unrecognised, and it says exactly that.
What you cannot see from the outside
Everything here is read from the public response, which sets hard limits. Plugins with no front-end output — backup tools, most security plugins, admin-only utilities — leave no trace. The number of plugins actually active is therefore always at least the number listed, usually more. Version numbers on plugin assets are what the plugin chose to append and are occasionally the WordPress version instead; the report only trusts a value that looks like a real release number and differs from core. A site behind a bot challenge returns the challenge page rather than its HTML, and the report flags that rather than reporting the challenge vendor as the platform.
Reading the results
| Finding | What it means | What to do |
|---|---|---|
| Child theme marked custom, parent marked free | The design is a free theme with site-specific overrides. Common and healthy. | Updates to the parent will not break the customisation. Keep both updated. |
| Theme marked "premium or third-party", medium confidence | Not on WordPress.org and not a known vendor. Usually a marketplace theme. | Follow the Theme URI in the report; the vendor page settles it. |
| Plugin version behind latest | The site loads an older build than WordPress.org currently ships. | Worth flagging if it is yours; a hint about maintenance if it is not. |
| WordPress version shown from ?ver= | The generator tag was removed but core scripts still carry the version. | Cosmetic. Hiding the version does not harden a site. |
| Host shown as a CDN only | Cloudflare or Fastly sits in front and the origin host does not identify itself. | Use the host checker for DNS-level clues. |
| Platform "bot challenge" | The site blocked the request before serving HTML. | Try the site's www / non-www variant, or a specific inner page URL. |
Some product links in results are affiliate links. They cost you nothing, never change what is detected or how it is labelled, and help keep these tools free.
Why this matters for outreach and audits
Knowing what a site runs on changes the conversation. A prospect on Shopify has no use for a WordPress plugin recommendation; a site on Divi with twenty premium plugins has a maintenance budget; a bespoke theme with no parent means a developer is somewhere in the picture. For agencies inheriting a site, the free-paid-custom split is the first line of the licence audit — every paid item needs a licence key that someone must still hold.
Once you know the platform, the next questions are where it lives and who runs it: the domain lookup for registrar, DNS and hosting in one report, the host checker for the company actually serving the site, and the SSL checker for the certificate in front of it.
Questions
How do you tell whether a theme is free, paid or custom?
The theme folder name is checked against the official WordPress.org directory first — a match means free. Otherwise the slug and the Theme URI or Author URI in style.css are compared with a list of commercial themes and marketplaces such as ThemeForest, Elegant Themes and StudioPress; a match means premium. A theme on neither list that points back at the site, is named after the site, or carries no author details at all is labelled custom. Anything else from a third party is marked likely premium with lower confidence.
Can it detect every plugin a site uses?
No tool can. It lists every plugin that leaves a trace in the page: assets under /wp-content/plugins/, markup fingerprints, cache signatures in HTML comments, and REST namespaces when /wp-json/ is public. Admin-only plugins, most security plugins and anything hidden by an optimiser that rewrites paths will not appear. The list is a floor, not a ceiling.
Why does it show a child theme and a parent theme?
Many sites run a child theme — a thin layer of overrides on top of a full theme. The child is what WordPress reports as active and is almost always site-specific, so it is labelled custom. The parent determines the design and the licence, so both are classified and the report says which is which.
What happens when the site is not WordPress?
The response is checked against fingerprints for hosted builders, traditional CMSs, e-commerce platforms, static generators, JavaScript frameworks and back-end stacks. A flat-file site on a static host is reported as static HTML. If nothing matches at all, the report says unrecognised rather than guessing.
Does it detect the WordPress version?
When the site publishes it. Most sites leave the generator meta tag in place. Sites that remove it often still expose the version through the ?ver= parameter on core scripts. If both are stripped, no version is shown, and when one is found the report says which source it came from.
Is checking a site this way allowed, and does the owner know?
Everything read here is what the site already sends to any browser: the homepage, its headers, and a few public files like style.css. There is no login attempt, no crawling of private areas and no vulnerability scanning. The site sees one ordinary page view. Results are cached briefly so repeat lookups do not repeat requests, and nothing is logged.
More in this category
What to run next
Once you know what a site is built on, these tell you where it lives and who runs it.
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.