Stop telling automated scanners exactly which WordPress version you're running
Disable WordPress Version Number strips the version number from every place WordPress publishes it by default — the generator meta tag, RSS/Atom feeds, and the ?ver= parameter on every script and stylesheet — without breaking asset cache-busting.
- Removes the generator meta tag from every front-end page.
- Removes the separate generator tag WordPress feeds publish.
- Strips ?ver= from every enqueued script and stylesheet URL.
- Internal cache-busting keeps working exactly as before.
<meta name="generator" content="WordPress 6.7.1" /><!-- no generator tag printed -->style.css?ver=6.7.1style.cssWhat does Disable WordPress Version Number do?
When the remove_wp_version module is active, TOWP_Remove_Wp_Version removes the wp_generator callback from wp_head, so the <meta name="generator"> tag never prints in the page's HTML. The the_generator filter gets forced to return an empty string, closing the separate generator tag WordPress prints inside RSS and Atom feeds. Finally, style_loader_src and script_loader_src get filtered at a very late priority to strip the ?ver= query parameter from every enqueued script and stylesheet URL, while WordPress's own internal versioning for cache-busting purposes continues to work exactly as before.
The exact WordPress version gets published for free, on every page
Since WordPress prints its own version number by default in several places, most sites hand it out without anyone deciding that was a good idea.
A version number isn't a vulnerability, but it's the first clue
By itself, knowing which WordPress version a site runs doesn't expose anything, but it's exactly what an automated scan reads first to decide whether a site is worth targeting.
It's published in three separate places, not just one
The generator meta tag is the obvious one, but the same version number also leaks through RSS/Atom feeds and through the ?ver= parameter on every script and stylesheet URL.
Three leak points, closed at once
The module removes the version number from every place WordPress publishes it by default, without touching how assets actually get cached.
The generator meta tag, gone
The meta name="generator" tag that names the exact WordPress version never gets printed in the page head at all.
Feeds stop announcing it too
RSS and Atom feeds get their own separate generator tag emptied out, closing a leak point a meta-tag-only fix would miss.
?ver= stripped, cache-busting intact
The version query parameter disappears from every script and stylesheet URL, while WordPress's own internal versioning keeps working for actual cache-busting purposes.
Every default leak point, closed
Every capability below is present in the supplied PHP class and its settings registration.
wp_generator unhooked from wp_head
The exact callback WordPress uses to print the version-revealing meta tag gets removed from the hook entirely, rather than filtered after the fact.
A separate leak point, closed too
the_generator returns an empty string, closing the version tag WordPress feeds publish independently of the page head.
style_loader_src and script_loader_src filtered
The ?ver= query parameter gets removed from every enqueued script and stylesheet URL, at a late enough priority to catch anything already added.
Only the visible parameter disappears
WordPress's own internal asset versioning continues functioning normally; only the version string printed in the URL gets removed.
Runs after anything else that touches the URL
The loader-src filters run at priority 9999, specifically so the version parameter gets stripped regardless of what else has already modified the URL.
No unnecessary work on URLs without a version
The version-stripping logic checks for the ver= parameter's presence before attempting to remove it, skipping the work entirely when there's nothing to strip.
Where removing the version number helps most
The module supports any public site where the version number offers no benefit to a genuine visitor.
Reducing what an automated scan learns for free
Remove the version fingerprint that lets a scanner quickly check it against a list of known vulnerabilities for that specific release.
General hardening for any public site
Close an easy, zero-cost information leak as part of a broader approach to reducing what the site reveals about itself.
Sites whose feeds get consumed by external tools
Remove the version fingerprint from feed output too, not just the page head, for sites where feeds are actually read by something external.
Less to fingerprint, nothing else disturbed
The module combines a genuine reconnaissance reduction with zero impact on how assets actually get cached.
A fixed set of hooks, nothing recurring
The verified implementation stays lightweight since it changes a small set of hooks once.
One hook removed, three filters added
The entire module is a small, fixed set of hook changes made once, at initialization, not per request.
An early exit for URLs with nothing to strip
The version-stripping check skips any further processing for a URL that never had a ver= parameter to begin with.
No impact on actual asset loading
Scripts and stylesheets load exactly as they would otherwise; only the version parameter visible in their URL changes.
Removes a shortcut, changes nothing about access
The code closes an information leak without touching any capability or permission.
Removes a reconnaissance shortcut, not a vulnerability itself
A version number alone doesn't expose anything directly, but it's routinely the first data point an automated scan collects before deciding what to try next.
Closes all three publication points together
The meta tag, the feed tag, and the asset query parameter all get addressed, rather than leaving two of the three still leaking the version.
No new capability or access path introduced
The module only changes what appears in public output; it doesn't add, remove, or alter any permission or access control.
Configuration requires the same access as any other setting
Enabling the module happens through the standard TheOneWP settings screen, available only to an administrator.
Built directly around WordPress's own generator and asset hooks
The supplied code integrates through APIs present in WordPress core; this page makes no compatibility claim beyond the verified implementation.
wp_head and wp_generator
The native WordPress action and callback responsible for printing the generator meta tag in the page head.
the_generator filter
The native WordPress filter controlling the generator tag printed specifically inside RSS and Atom feed output.
style_loader_src and script_loader_src
The native WordPress filters used to modify the final URL of every enqueued stylesheet and script.
TheOneWP versus common alternatives
Compare the verified implementation with a typical meta-tag-only fix.
| Capability | TheOneWP Disable WordPress Version Number | Other common solutions |
|---|---|---|
| Generator meta tag | Removed via remove_action, not just filtered | Frequently the only leak point addressed |
| Feed generator tag | Separately emptied via the_generator | Often overlooked entirely |
| Asset version parameter | Stripped from every script and stylesheet URL | Rarely addressed by a meta-tag-only fix |
| Cache-busting behavior | Internal versioning left fully intact | Some approaches risk breaking asset cache invalidation |
| Administration | A single toggle, nothing further to configure | Usually requires a code snippet covering only part of the leak |
Confirm the fingerprint is gone in four steps
Since there's nothing to configure beyond enabling it, verification is the real workflow here.
Enable Disable WordPress Version Number
Activate the module from the TheOneWP Components settings tab; there's nothing further to configure.
View the page source to confirm the meta tag is gone
Check the front-end HTML head and confirm no generator meta tag appears.
Check the site's feed output
Visit the site's RSS or Atom feed URL and confirm the generator tag no longer names a version.
Inspect a script or stylesheet URL
Confirm an enqueued asset's URL no longer includes a ?ver= parameter.
Treat this as reconnaissance reduction, not a patch
Removing the version number closes an easy leak; it doesn't substitute for actually staying updated.
Treat this as one part of a broader hardening approach
Removing the version number reduces easy reconnaissance; it doesn't replace keeping WordPress, themes and plugins actually updated.
Don't rely on version-hiding as a substitute for updates
A hidden version number doesn't protect a site that's genuinely running outdated, vulnerable software.
Check custom themes or plugins for their own version output
Some themes or plugins print their own version numbers separately; this module only covers WordPress core's own default outputs.
Revisit after a major WordPress update
Confirm the version number still doesn't appear anywhere after updating, since a theme or plugin update could reintroduce its own separate leak.
Avoid mistaking a hidden version for a patched one
A couple of assumptions are worth correcting before relying on this module too heavily.
Treating a hidden version number as a substitute for updates
Removing the visible version doesn't patch anything; keeping WordPress, themes and plugins updated is still what actually matters.
Assuming every version leak is covered
This module addresses WordPress core's own default outputs; a theme or plugin that prints its own version number separately isn't covered.
Worrying this will break asset caching
WordPress's internal cache-busting versioning stays fully intact; only the visible ?ver= parameter in the URL gets removed.
Disable WordPress Version Number FAQ
These answers come directly from the verified class and its settings registration.
What does Disable WordPress Version Number do?
It removes the WordPress version number from the generator meta tag, RSS and Atom feeds, and the ?ver= parameter on every script and stylesheet URL.
Does this break asset caching or cache-busting?
No. WordPress's internal versioning for cache-busting purposes keeps working exactly as before; only the visible parameter in the URL gets removed.
Is a visible version number actually a vulnerability?
Not by itself, but it's typically the first thing an automated scan reads to decide whether a site is worth targeting for known vulnerabilities in that version.
Does this remove the version from RSS and Atom feeds too?
Yes. Feeds have their own separate generator tag, which the module empties out independently of the page head.
Will this hide the version number that a theme or plugin prints on its own?
No. The module addresses WordPress core's own default outputs specifically; a theme or plugin that prints its own version separately isn't covered.
Does hiding the version number replace the need to keep WordPress updated?
No. It reduces easy reconnaissance, but it doesn't patch anything; keeping WordPress and its plugins updated is still essential.
Is there anything to configure beyond enabling the module?
No. The module works automatically once enabled, with no additional settings.
Does this affect performance in any way?
No. The change is a small, fixed set of hook modifications made once, with no ongoing per-request overhead.
Can a determined scanner still figure out the WordPress version some other way?
Possibly, through other fingerprinting methods, but this module closes the three most common and easiest sources.
Who can enable this module?
Only an administrator with access to the TheOneWP settings screen.
Stop publishing your exact WordPress version to every scanner.Close all three leak points at once.
Use Disable WordPress Version Number to remove the generator meta tag, the feed generator tag, and the ?ver= parameter, without affecting how assets get cached.