One of the most common questions we get is „I have plugin X installed, but the report doesn't list it.“ That's almost always expected behaviour, not a bug. InspectWP runs a single anonymous visit to your site, just like any visitor, and works only with what's publicly visible. This article explains what that means in practice.
1. How detection works in principle
InspectWP loads the URL you provide, exactly once, with a real headless browser. We then look at:
- The rendered HTML and inline scripts.
- All CSS and JavaScript files the page loads.
- Image and font URLs, especially their paths.
- HTTP response headers and cookies.
- Meta tags and structured data.
From these signals we infer which plugin or theme is in use. We do not log into your site, we do not access wp-admin, and we do not read your wp-content directory directly. We only see what any anonymous visitor would see.
2. Why a plugin can be invisible
There are several legitimate reasons a plugin doesn't show up:
- It's a backend-only plugin. Many plugins (admin tools, backup plugins, staging tools, internal SEO checkers, role managers) never output anything to the frontend. There's nothing to detect.
- It only loads on specific pages. A booking plugin may only load its assets on the booking page. If you crawl your homepage, it won't appear. Try crawling the page where the plugin is actually used.
- It only loads for logged-in users. A members-area plugin may load nothing for anonymous visitors. Same effect as above.
- Aggressive optimization is hiding it. Caching and optimization plugins can combine, minify or rename assets to the point where the original plugin name is no longer recognizable. See section 4.
- It's a very new or very niche plugin. Detection works best for plugins that leave a recognizable, stable footprint. New releases or hand-made plugins may not be in our recognition rules yet.
- The plugin was deactivated. A deactivated plugin loads nothing on the frontend. Worth double-checking in Plugins → Installed Plugins.
3. Why a theme can be misidentified
Theme detection is usually quite reliable, because themes typically leave clear traces in the asset paths (/wp-content/themes/your-theme/...). It can still go wrong:
- Child themes: If you use a child theme, you may see both the parent and the child listed. That's correct: WordPress loads both.
- Renamed themes: Some agencies rename a parent theme folder for branding reasons. If the new folder name doesn't match anything in our recognition rules, the theme appears as „unknown“ or with the renamed slug.
- Page builders that ship with their own theme: Some page builders effectively replace the theme. The detected theme is then the builder's base theme, not what you might expect.
- Multisite with theme overrides: On a multisite, the active theme can differ per subsite. Make sure you crawled the right URL.
4. The asset-optimization trap
This is the single most common reason for missing plugins on otherwise normal sites. Plugins like WP Rocket, LiteSpeed Cache, Autoptimize, W3 Total Cache, Perfmatters or built-in CDN optimizers can do all of the following:
- Combine many CSS files into one large file with a generic name like
combined-abc123.css. - Combine many JavaScript files the same way.
- Minify and obfuscate file contents.
- Rewrite asset paths to a CDN, dropping the
/wp-content/plugins/...prefix. - Inline critical CSS so the original stylesheet is no longer requested.
When all of that runs at once, individual plugin signatures vanish. The plugin is still working perfectly on your site, we just can't see it from outside.
5. CDN, reverse proxy and edge caches
If your site is behind Cloudflare, BunnyCDN, KeyCDN or a managed-host edge cache, the response we see may already be heavily transformed. Some CDN features (Rocket Loader, automatic minification, Mirage, Polish) further alter the HTML and assets. The plugins are still there, the public fingerprint just changed.
6. Server-side rendering and JavaScript apps
Sites built with headless WordPress (a JavaScript frontend talking to WordPress via REST or GraphQL) usually expose almost no traditional WordPress signals. The frontend is essentially a custom app. In those cases, detection of WordPress itself, let alone individual plugins, is limited or impossible from outside.
7. What to do when something is missing
- Crawl the page where the plugin is actually used, not just the homepage.
- Crawl as a logged-out visitor, in a private browser tab, to see the same view InspectWP sees.
- Temporarily turn off file combination in your caching plugin and re-crawl.
- Check whether the plugin is actually outputting anything on the frontend (View Source in your browser).
- If you're sure the plugin produces frontend output and is still missing, write to us at hello@inspectwp.com with the report URL and the plugin name. We continuously expand our recognition rules.