Attackers rarely break in through brilliance. They break in through known holes in known versions. Public vulnerability databases list, for every WordPress core, plugin and PHP release, exactly what is broken in it. The only thing an attacker needs to use that list against you is one piece of information: what you run.

Where your site announces itself

  • The generator tag. WordPress prints <meta name="generator" content="WordPress 6.x"> into every page by default.
  • X-Powered-By. Many servers volunteer their PHP version in a response header on every request.
  • Server header. Web servers often include their name and version: Server: Apache/2.4.x.
  • readme.html. The WordPress readme in your web root states the version in its first lines.
  • Asset query strings. Scripts and styles loaded as style.css?ver=6.4.2 leak versions too.

Being honest about what this fixes

Hiding versions does not patch anything, and a determined attacker can often fingerprint software by behavior alone. If a scanner tells you that hiding your version number made you secure, it is overselling. What trimming these signals really does is take you off the cheap target lists: automated campaigns that search for "WordPress 6.2" or "PHP 7.4" and hit every match. That is a real reduction in attack traffic, at zero cost. The actual fix remains the boring one: keep core, plugins and PHP updated.

How to trim the signals

  • Remove the generator tag with a two-line snippet (via the Code Snippets plugin, not functions.php).
  • Turn off X-Powered-By in PHP settings (expose_php = Off) or strip it at the edge.
  • Delete or block readme.html.
  • Behind Cloudflare, response header rules can strip Server and X-Powered-By for you.

A free AuditMerlin scan checks all of these disclosure points and tells you which ones your site is currently broadcasting.