Get Pro

Why You Should Hide Your WordPress Version Number

by

Right-click on any WordPress site, View Source, and search for “generator.” You’ll find this:

<meta name="generator" content="WordPress 6.7.2" />

That one line tells every attacker exactly which version of WordPress you’re running. And if you’re behind on updates — even by a single point release — they know exactly which exploits to try.

It’s in your HTML . It’s in your RSS feed. It’s in your REST API responses. WordPress is shouting your version number from every rooftop, and most site owners don’t know it.

What is the WordPress version tag?

WordPress adds a tag to several outputs by default:

  • HTML head on every frontend page
  • RSS feed XML header
  • Atom feed header
  • RSD (Really Simple Discovery) document
  • REST API response headers
  • Version query strings on core CSS and JS files (e.g., ?ver=6.7.2)

This was originally designed to help the WordPress community track adoption numbers and for compatibility checks. In practice, it’s an information disclosure that benefits attackers far more than the community.

Why should you care?

Targeted exploit matching. When a WordPress security vulnerability is disclosed, it comes with specific affected version numbers. CVE-2024-XXXXX affects WordPress 6.4 to 6.4.3, for example. An attacker with a list of known vulnerable URLs can scan for the generator tag, match your version to the CVE database, and launch targeted exploits — all automated, all in minutes.

This isn’t hypothetical. Automated scanners like WPScan and Shodan index WordPress version numbers at scale. There are public databases mapping WordPress versions to known vulnerabilities. Hiding your version number doesn’t make you secure, but it removes the easiest reconnaissance step from the attack chain.

Update lag is universal. Even if you update WordPress religiously, there’s always a gap between when a security release drops and when you apply it. WordPress 6.7.2 might fix a critical vulnerability that was present in 6.7.1. If you’re running 6.7.1 and broadcasting it, you’re a target during that window. A day or two of lag is normal — but that’s exactly when attackers are most active, targeting the newly disclosed vulnerability.

It’s a signal of amateur setup. This one’s less about security and more about professionalism. A site that broadcasts its WordPress version hasn’t had basic hardening applied. To attackers, that signals an easy target — if you didn’t hide the version, you probably didn’t limit login attempts or disable XML-RPC either.

The quick fix

Add this to your theme’s functions.php or site-specific plugin:

// Remove WordPress version from head, feeds, and scripts
remove_action( 'wp_head', 'wp_generator' );

// Remove version from RSS feeds
add_filter( 'the_generator', '__return_empty_string' );

// Remove version from scripts and styles
add_filter( 'style_loader_src', 'ovkit_remove_wp_version_strings', 9999 );
add_filter( 'script_loader_src', 'ovkit_remove_wp_version_strings', 9999 );

function ovkit_remove_wp_version_strings( $src ) {
    if ( strpos( $src, 'ver=' . get_bloginfo( 'version' ) ) ) {
        $src = remove_query_arg( 'ver', $src );
    }
    return $src;
}

This removes the generator meta tag from HTML and feeds, and strips the WordPress core version from enqueued assets. Plugin and theme version strings remain (those are handled by the Remove Query Strings feature).

Note: This doesn’t remove version information from the REST API wp/v2 endpoints. To do that, you’d need additional filtering on the REST API response headers.

The one-click solution

OvKit includes Remove WP Version under Features → Security. One toggle covers all the locations: HTML meta tag, RSS feeds, Atom feeds, script/style version strings, and REST API headers. Complete version information removal across every output.

What happens after you fix this?

  • The tag disappears from your page source
  • RSS and Atom feeds no longer include version info
  • Core CSS/JS files load without ?ver=6.7.2 — cleaner URLs and better caching
  • Automated scanners can’t determine your exact WordPress version — they’d need deeper fingerprinting techniques

Check your work: view your page source, search for “generator” and for your WordPress version number. Both should return zero results.

To be clear: this is security through obscurity. It’s not a replacement for keeping WordPress updated. A determined attacker can fingerprint your version through other methods — analyzing core file checksums, specific Gutenberg block markup, or admin AJAX response patterns. But you’re not trying to stop nation-state hackers. You’re trying to get off the automated scan lists, and hiding the version number does exactly that.

FAQ

If I hide the version, won’t I still be vulnerable to attacks?

Yes, if you don’t update. Hiding the version number is one layer. Keeping WordPress, themes, and plugins updated is the actual fix. Think of version hiding as removing the label from a locked door — it doesn’t make the lock stronger, but it stops opportunists from knowing which key to try.

Does hiding the version number affect WordPress updates or plugin compatibility checks?

No. WordPress checks versions internally for update notifications and compatibility — those mechanisms use server-side version constants, not the frontend meta tag. Hiding the public-facing version has zero effect on your dashboard update notices or plugin compatibility.

Is the WordPress version also visible in wp-login.php or wp-admin?

Yes, the WordPress admin footer shows the version number, but that’s only visible to logged-in users — not a public disclosure concern. The login page itself doesn’t expose the version directly, though the login form’s CSS file URL might contain a version parameter. OvKit’s version removal covers these cases too.

Related reads: