WordPress

A generator meta tag naming WordPress — weight 95, the strongest signal.

`/wp-content/` asset paths — weight 70; `/wp-includes/` paths — weight 60.

A `/wp-json` link in the markup — weight 55, or in a `Link` response header — weight 60.

A `wordpress_` or `wp-settings-` cookie — weight 60.

Any one of the strong signals is enough; several together report with the highest confidence the scale allows.

WordPress core hooks its generator function to the page head by default, and that function outputs `<meta name="generator" content="WordPress x.y.z">` with the installed version.

Core also adds a REST API discovery link to the page head and a `Link` header to responses by default, which is why those two signals are so common.

The version check reports a core version only when it is published this way or in a core asset's version string, and never infers one.

A published version is an inventory fact. What matters is whether it is current, which the version tool page explains how to judge.

Endpoint checks: whether the login page, the XML-RPC endpoint and the REST API index answer — each with a single plain request, and never with a login attempt or a method call.

File checks: accidentally served configuration or backup files, the default readme and licence files, and directory listings in standard folders.

Inventory: plugins and themes whose assets appear in pages already crawled, with versions only where they are advertised.

Runtime and caching: the PHP version from server headers, and caching or object-cache plugins identifiable from their public signatures.

None of these runs on a site that is not recognised as WordPress, which keeps other sites free of irrelevant findings.

The exposure tool page explains exactly which paths are requested and how to read the result without over-reacting.

The version tool page explains where versions become public and what to do with the list.

A served configuration file has its own problem page, because it is the one finding in this set that exposes credentials.

An unsupported PHP version is a problem page too, since it affects every plugin on the site.

Plugins that add no public assets to the pages crawled — many administrative plugins are invisible from outside.

Whether an installed plugin version has a known vulnerability: the audit reports the versions it observes, not a vulnerability database verdict.

User accounts, roles and the admin area, which are never probed.

Backups, updates scheduling and file permissions, which are server-side.

WordPress core's script loader sets the default version of registered scripts and styles to the installed WordPress version.

Core assets are therefore requested with a `ver=` query string carrying that version, which is why removing the generator tag alone does not hide it.

The version check reads this core asset version as its second source, and reports it only when the string is present.

Plugin and theme assets carry their own version strings, which is what the plugin and theme inventory reads.