Is It WP? WordPress Evidence Checker

Read the ledger before the verdict

Each signal has one of three states: found, not found or unavailable. Not found means the inspected response did not contain that recognizable clue. Unavailable means the relevant request or response could not be used. These states are not interchangeable. If a firewall serves an error page, the absence of a theme path tells you little about the page an ordinary visitor receives. The compact view shows the first six signal rows and key stack fields. Export JSON for the complete signal list and returned theme stylesheet metadata, including clues not shown in that compact view.

The current weights are explicit: REST core contributes 45, WordPress generator metadata 35, discovery 25, each content/includes path signal 20, recognizable core scripts 15, cookie prefixes 12, publishing discovery 10 and pingback 8. The sum is capped at 100. Ten references to one plugin do not create ten independent platform signals; an asset count and a clue weight answer different questions.

The verdict also considers whether the main page was inspectable. A failed, error, truncated or non-HTML page is inconclusive even if some clues survive. With usable HTML, REST core plus another clue, or at least three clues totaling 55 or more, yields strong evidence. Thirty or more without those conditions can yield likely; a smaller positive score stays inconclusive. These are implementation rules, not measured probabilities or proof of a live backend.

Why different pages expose different APIs

The checker prefers the public discovery URL when it can read one from an HTTP Link header or HTML. Otherwise it derives a conventional wp-json/ candidate from visible content paths or the page origin. It does not search every subdirectory. A publication running under /news/ can therefore behave differently from a homepage served by another system, particularly when the homepage exposes no useful API relation.

The REST discovery documentation defines the https://api.w.org/ relation. For this tool, the practical question is whether the candidate actually returns recognizable core namespaces or routes. A link pointing to an API and a usable API index are separate evidence rows; a link alone does not establish that its destination worked during the check.

Custom namespaces are also worth retaining, but their names are not automatically a plugin inventory. An owner may register routes in a theme or custom code. Older publishing clues such as RSD, Windows Live Writer markup and X-Pingback carry smaller weights. ClockTools observes those references; it does not submit publishing requests or test credentials. A disabled publishing interface can change the evidence without changing the CMS.

Use component paths to ask better inventory questions

A resource under /wp-content/themes/atelier/ identifies a visible directory slug. The strongest theme candidate is the one with the most referenced assets, with alphabetical ordering as a tie-breaker; that is not an authenticated active-theme selection. ClockTools may fetch its conventional style.css and display the header fields it can read. If no name is returned, the slug remains a slug rather than an invented product name.

Two theme directories deserve investigation, not an automatic conflict warning. In the child-theme model, a Template value identifies a parent directory. In an illustrative report with atelier-child and atelier, ask which contains local customizations and which supplies parent files. A cached or independently referenced resource can create a second slug too. Confirm the arrangement in the site’s administration before planning an update.

Plugin references under /wp-content/plugins/ and /wp-content/mu-plugins/ are grouped by visible slug and asset count. Must-use plugin documentation explains the special loading model, but an exposed directory still does not reveal every installed component. A contact page may load form assets that the homepage never uses. For a migration, inspect that public page separately and reconcile the findings with the owner’s active and must-use inventory.

Server-only plugins, bundled assets, custom paths and CDN rewriting can be invisible here. Conversely, an old cached reference can remain after a component was removed. A version in theme metadata concerns that theme; an arbitrary asset ?ver= value is not a reliable WordPress core version. The core version clue is read only from an explicitly identifying generator value, so a blank version field is often the correct result.

Keep header fields in their own roles: Theme Name is the published display name, Author and Theme URI are declared attribution, and Text Domain identifies a translation domain rather than a website hostname. Those declarations can help find the maintainer’s intended documentation, but they are editable text. They do not authenticate ownership, establish a license entitlement or demonstrate that an update is available for the deployed files.

Separate content production from page delivery

A traditional site can serve WordPress-generated HTML directly, while a cached site serves an earlier copy. A static export can preserve the same markup and asset directory names without running WordPress for each visitor. A headless frontend can obtain content from a private or separate WordPress service without publishing any familiar paths. The checker observes delivery evidence, not every system involved in producing the content.

This distinction explains both kinds of surprising result. A high score on an exported site can be a fair description of public clues while a claim about the live backend would be wrong. A no-signal result on a headless frontend can also be fair while the editors still use WordPress. Ask the owner where content is authored, how it is built and what serves the public response. Those answers are more useful for a project than arguing over one detection label.

For a fixed example, the existing static-export scenario contains generator metadata and wp-content references but no usable core REST response. Those two clues total 55, yet by themselves do not meet the three-clue strong-evidence rule; with usable HTML the result can be likely. If the main page is blocked or truncated, it remains inconclusive. A higher score can result when copied publishing clues are present too, without proving that the backend is running.

Resolve a surprising result without probing private pages

Start with the submitted page and final URL. A redirect can lead to another host, a language page or a generic challenge, so you may not have inspected the content you expected. Compare the response status and inspected byte count before examining component names. If the HTML was truncated, clues beyond the inspected portion may be missing; do not treat that list as exhaustive.

The inspection is anonymous and bounded: a public page, one REST candidate and, when available, one theme stylesheet. It does not execute the page’s JavaScript. Initial query strings are removed, so a query-dependent page may not match your browser view. Do not work around that by submitting a signed preview URL or a login link. Use a normal public path, and inspect your own authenticated pages locally.

For a blocked API or rate limit, keep the unavailable row, try later and review your own access rules if appropriate. Do not disable protection just to improve a detector score. For a public version disclosure, verify installed versions and updates in the authenticated system; this tool performs no vulnerability comparison. A useful correction report includes the safe page URL, time, expected clue and relevant public response, not just “the score is wrong.”