How the RevealTheme Detector Works
When you enter a URL into one of our detectors, a lot happens in the two seconds before you see results. Here's the technical walkthrough for the curious — including the limitations we can't engineer around.
Step 1 — Fetching the public HTML
When you submit a URL, our server fetches the public webpage at that URL using a standard browser User-Agent. This is the same HTML that your browser would receive if you visited the site directly. We don't bypass paywalls, scrape login-protected content, or use any authentication.
The fetch uses a 20-second timeout. We follow up to 10 redirects (which handles HTTP → HTTPS redirects, www → non-www, and country redirects). If the site returns a 4xx or 5xx response, or doesn't respond within the timeout window, we return a clear "could not reach" error rather than guessing.
Step 2 — Sniffing the platform
Before we try to identify a specific theme, we check which CMS the site is running. We look for fingerprints of all 7 supported platforms — WordPress, Shopify, Magento, Joomla, Drupal, Moodle, and PrestaShop — and pick the strongest match.
If you submit a Shopify URL to our WordPress detector (or vice versa), we tell you so and link to the right detector. No guessing, no false positives.
Step 3 — Theme detection
For WordPress specifically, theme references typically appear in the page HTML at paths like wp-content/themes/THEME_NAME/style.css. We extract every such reference from anywhere in the document — link tags, script tags, inline JavaScript, JSON-LD blocks, even text content. This catches themes that heavily optimized sites have hidden from standard detection tools.
For each detected theme, we attempt to fetch the theme's style.css file. The header of that file contains the official theme name, author, version, URI, and description — direct from the theme developer. That's the source of the rich theme info we display alongside the detection result.
Step 4 — Plugin detection
Plugin detection uses two parallel approaches. First, we extract any file paths that match wp-content/plugins/PLUGIN_NAME/. Second, we run dozens of signature-based checks — looking for specific HTML structures, CSS class names, inline JavaScript variables, and HTTP response headers that uniquely identify popular plugins like Elementor, Yoast SEO, WPForms, WooCommerce, Wordfence, and more.
The two-approach design catches plugins that hide their file paths (via caching or asset bundling) but still leave behind distinctive signatures. For every detected plugin, we look it up in the WordPress.org Plugin Directory to enrich the result with the plugin's official name, description, author, and screenshots.
Step 5 — Hosting + DNS lookups
For hosting provider identification, we do a DNS lookup on the domain and inspect the IP address, ASN, and reverse DNS. We cross-reference this against a database of known hosting provider IP ranges to identify the provider. The accuracy is high for major hosts (AWS, Cloudflare, Hostinger, SiteGround, etc.) and lower for niche providers.
What we can't do
A few cases where detection won't work, no matter how good our code gets:
- Cloudflare bot challenge. Sites with strict Cloudflare bot protection (the "Performing security verification..." screen) block our fetcher just like they'd block any automated request. There's no clean way around this.
- Heavy custom themes. If a theme has been so heavily modified that every reference to the original theme name has been stripped from the HTML, we have nothing to detect.
- Aggressive caching with rewritten asset paths. Plugins like LiteSpeed Cache, WP Rocket, and Cloudflare's Rocket Loader sometimes rewrite asset URLs to obscure the source. Our signature-based detection catches most of these, but not all.
- Static export sites. A WordPress site that's been exported to static HTML loses most of the runtime signatures that make detection possible.
What we don't do
We've been asked. The answers are no:
- We do not store the URLs you submit
- We do not log IP addresses for marketing purposes
- We do not share detection data with vendors
- We do not bypass authentication, robots.txt, or other access controls
- We do not run the detector on internal/private IPs (127.0.0.1, 10.x.x.x, etc.) for security reasons
The full privacy details are in our Privacy Policy.
API access
We don't currently offer a public API, but limited programmatic access is available on request for agencies and researchers. Email hello@revealtheme.com with your use case and expected request volume.
Why isn't this open source?
The detection rules are the core of the product, and we update them frequently as themes and plugins evolve. Open-sourcing them would slow our update cadence. That said, we publish detailed posts on detection techniques in our blog — search for "detection" to find them.
Ready to try it?
Use whichever detector matches the site you want to inspect: