Why hide your WordPress version number?

WordPress can expose information about the version of the software running a website through several public outputs.

That information is useful for debugging, compatibility and cache management, but it can also make reconnaissance easier for automated scanners.

If a scanner can identify that a website runs WordPress and obtain a plausible version number immediately, it can compare that information with known vulnerabilities and prioritize the site accordingly.

This is why many WordPress hardening configurations remove publicly visible version information.

But hiding the WordPress version number needs to be understood correctly.

A visible version number is not itself a vulnerability, and removing it does not patch an outdated WordPress installation.

A determined scanner may still recognize WordPress and may even estimate the version through other fingerprints. Themes and plugins can also reveal their own versions independently.

Hiding the version number is therefore best classified as reconnaissance reduction: removing information that does not normally need to be advertised publicly while keeping the actual security priorities focused on updates, strong authentication, secure configuration and monitoring.

Where does WordPress expose its version number?

WordPress can publish version-related information through more than one output.

Removing only one visible meta tag does not necessarily address the other sources.

The generator meta tag

WordPress provides the wp_generator() function, which is attached to the front-end wp_head output.

The official WordPress wp_generator() documentation describes it as the function responsible for displaying the XHTML generator information.

Depending on the site and configuration, the resulting HTML may identify WordPress and include its version.

That gives automated tools an extremely easy signal because they only need to inspect the source of a normal page.

RSS and Atom feeds

The front-end page is not the only location where generator information can appear.

WordPress uses the_generator() to produce generator information for multiple output formats, including:

• HTML;
• XHTML;
• RSS;
• Atom;
• RDF;
• exports.

This means an administrator can remove the generator information from the page head while still leaving another version signal in a feed if the implementation does not account for those outputs.

Script and stylesheet query parameters

WordPress also supports version strings on enqueued JavaScript and CSS resources.

A typical asset URL may include a query parameter such as:

?ver=7.x

The exact value depends on how the asset was registered.

The official documentation for wp_enqueue_script() and wp_enqueue_style() explains that their $ver parameter is added to the resource URL for cache-busting purposes.

Importantly, when $ver is set to false, WordPress automatically uses the currently installed WordPress version as the version number.

When $ver is null, no version is added.

Therefore, some public asset URLs can expose the current WordPress version directly.

Why does revealing the WordPress version matter?

Software version numbers help describe the exact state of an application.

That can be useful to legitimate administrators, but it is also valuable during reconnaissance.

Attackers can correlate versions with known vulnerabilities

Security vulnerabilities frequently affect a particular range of software versions.

An automated scanner can therefore follow a simple logic:

1. identify WordPress;
2. identify or estimate the version;
3. compare it against vulnerability intelligence;
4. send tests relevant to that version.

The version number does not create the vulnerability.

It makes selecting the correct tests easier.

Fingerprinting becomes cheaper

Without an explicit version number, a scanner may need to combine multiple clues.

It might inspect:

• core asset behavior;
• known files;
• REST responses;
• HTML structure;
• WordPress-specific paths;
• changes introduced between releases.

If the page simply publishes the exact version, that extra work is unnecessary.

For the wider reconnaissance process, see How Attackers Fingerprint WordPress Sites.

Automated scanning operates at scale

Most public WordPress sites are exposed to automated scanning whether their owners notice it or not.

A bot does not need to personally select a business as an important target.

It can discover large numbers of sites, classify their technology stacks and prioritize those that appear relevant to a particular exploit campaign.

Easy version disclosure helps that classification process.

Does hiding the WordPress version actually improve security?

Yes, but only modestly and only in the correct sense.

Removing version information can eliminate easy reconnaissance data.

It does not fix the underlying software.

It reduces information disclosure

If a piece of information has no reason to be public, removing it can reduce the amount of useful data available to automated tools.

This follows a general hardening principle:

do not expose implementation details unnecessarily.

A scanner that receives an exact version immediately has more information than one that only knows the site appears to run WordPress.

It does not patch vulnerabilities

Suppose a site is running an outdated WordPress release with a known security vulnerability.

Removing the generator tag does not change the vulnerable code.

If an attacker identifies the version another way, or simply tests the vulnerability broadly, the site remains exposed.

This is why version hiding must never be used as an excuse to postpone updates.

It should be a secondary control

The security priority should remain:

1. keep WordPress current;
2. update themes and plugins;
3. remove abandoned components;
4. protect authentication;
5. apply least privilege;
6. reduce unnecessary attack surface;
7. then reduce avoidable information disclosure.

Version hiding belongs in that final hardening layer.

Why hiding the generator tag alone is not enough

A commonly recommended WordPress snippet removes the generator action from the page head.

That closes one source of information, but it does not automatically address every other output.

Feeds have separate generator output

RSS and Atom feeds can contain their own generator information.

An implementation that removes only the front-end HTML generator may therefore leave another version disclosure path intact.

Asset URLs can still contain the version

Even after generator information disappears, scripts and stylesheets may still contain ?ver= parameters.

When those values correspond to the installed WordPress version, an automated scanner does not need the generator tag.

Plugins and themes can publish their own versions

WordPress core is only one part of the stack.

A plugin might expose its version through:

• asset URLs;
• HTML comments;
• REST namespaces;
• public documentation;
• CSS headers;
• JavaScript variables;
• custom meta tags.

A theme can do the same.

Removing the WordPress core version therefore should not be described as removing all software-version information from the website.

Can attackers still determine the WordPress version after you hide it?

Possibly.

Removing explicit version strings makes identification harder, but fingerprinting rarely depends on one signal.

WordPress itself remains recognizable

OWASP’s Web Security Testing Guide uses WordPress as an example of application fingerprinting and notes recognizable paths such as:

• /wp-includes/;
• /wp-admin/;
• /wp-content/.

Response behavior from these paths can help identify WordPress even when the generator information is absent.

Core assets change between releases

Specific WordPress releases can introduce, remove or modify:

• JavaScript files;
• stylesheets;
• REST behavior;
• HTML output;
• core functionality;
• public assets.

A sufficiently capable fingerprinting tool can compare those characteristics against known WordPress releases.

The result may be a version range rather than an exact version, but that can still be useful to an attacker.

Other components provide additional clues

The installed theme, plugins and their behavior can also suggest the age of the WordPress environment.

For example, a plugin version may require a minimum WordPress release, narrowing the possible core range.

This is another reason why hiding version information should be considered friction rather than concealment.

What about the ?ver= query parameter and caching?

This part requires care because version query parameters are not present purely to expose software information.

They serve a legitimate cache-management purpose.

Version strings support cache busting

Browsers, CDNs and reverse proxies can cache static resources aggressively.

If an asset URL remains unchanged after the file itself changes, clients may continue serving an older cached copy.

A versioned URL solves that problem.

For example, changing:

style.css?ver=1.4

to:

style.css?ver=1.5

produces a different URL from the cache’s perspective.

The client therefore retrieves the updated resource.

Removing visible query parameters should not destroy version tracking

A version-hiding implementation should avoid breaking the site’s ability to invalidate cached assets.

The goal is to prevent public disclosure of an unnecessary version value, not to create stale CSS and JavaScript after every update.

WordPress exposes the script_loader_src and style_loader_src filters, which allow the final public asset URLs to be filtered.

A carefully designed implementation can therefore alter the public URL without requiring developers to stop versioning assets internally.

Not every ?ver= value is the WordPress core version

This distinction is important.

Plugins and themes frequently provide their own asset versions.

For example:

plugin.js?ver=4.8.2

might indicate:

• a plugin version;
• an internal build version;
• a file modification value;
• another arbitrary developer-provided string.

A scanner can treat it as a clue, but it should not automatically assume every ver parameter equals the WordPress core version.

What version hiding cannot protect you from

The easiest way to misuse this hardening measure is to give it responsibilities it does not have.

Outdated WordPress core

If WordPress needs a security update, hiding the version does not apply the update.

An exploit may work regardless of whether the attacker knows the exact version first.

Vulnerable plugins and themes

Many WordPress compromises originate from extensions rather than WordPress core itself.

Removing the core version does nothing to patch a vulnerable plugin.

Brute-force attacks

Password attacks do not normally require an exact WordPress version.

If wp-login.php or another authentication surface is available, an attacker can attempt credentials regardless.

See WordPress Brute-Force Attacks, Explained.

Username enumeration

The core version and account identifiers are different pieces of reconnaissance data.

Author archives, public content or APIs can potentially expose username-related information independently.

See How Attackers Collect WordPress Usernames and Email Addresses.

XML-RPC exposure

Removing the version number does not disable xmlrpc.php.

If XML-RPC is unnecessary, review it separately using What Is XML-RPC in WordPress, and Why Disable It?.

How to hide the WordPress version safely

A good implementation should target the public disclosure points without damaging normal WordPress behavior.

Remove the front-end generator output

WordPress attaches wp_generator() to the page head.

Developers can remove that output using WordPress hooks rather than editing core files.

remove_action( 'wp_head', 'wp_generator' );

Core files should never be modified directly for this purpose because a WordPress update can overwrite those changes.

Filter generator output across formats

Because WordPress uses the_generator() for several formats, a complete implementation should consider feeds rather than looking only at normal HTML pages.

The exact implementation should be tested against the site’s feed requirements.

Handle asset URLs deliberately

Scripts and styles can be filtered through WordPress’s loader hooks.

But indiscriminately stripping every query parameter from every asset is not necessarily a good implementation.

Query parameters can have purposes unrelated to WordPress version disclosure.

A robust approach should identify the relevant version parameter and preserve any unrelated URL information.

Never modify WordPress core

Do not edit files under wp-includes or wp-admin merely to remove a version string.

Use hooks, a plugin or another maintainable configuration layer.

How TheOneWP handles WordPress version disclosure

TheOneWP provides a dedicated Disable WordPress Version Number module for this specific hardening task.

Its verified implementation targets three WordPress core disclosure points.

Generator meta output

The module removes WordPress core’s generator information from front-end page output.

This prevents ordinary page-source inspection from receiving the default core version through that channel.

RSS and Atom generator output

The module also addresses WordPress feed generator output rather than stopping at the HTML page head.

This matters because otherwise a scanner could simply request a feed after discovering that the front-end generator tag had disappeared.

Visible version parameters on scripts and styles

The module strips the visible ?ver= parameter from enqueued script and stylesheet URLs.

The verified TheOneWP implementation keeps WordPress’s internal versioning logic intact, so the feature is designed not to disable the underlying asset-version management used for cache invalidation.

It does not claim to hide every possible software version

The module specifically addresses WordPress core’s normal disclosure points.

If a theme or plugin independently publishes its own version number, that is separate output and is outside this module’s scope.

That boundary is important because “hide the WordPress version” and “hide every component version in the entire application” are very different technical objectives.

How version hiding fits into a real WordPress hardening strategy

Removing the WordPress version is most useful when it sits inside a larger set of controls.

Keep everything patched first

WordPress core, themes and plugins should be updated according to a controlled maintenance process.

If a component is no longer maintained, replacing or removing it is more valuable than hiding its version.

Protect authentication

Use:

• long, unique passwords;
• two-factor authentication for privileged accounts;
• login rate limiting;
• least-privilege roles;
• authentication monitoring.

A version number does not protect or expose a password directly, so login security needs its own controls.

Use A WordPress Login Hardening Checklist for the broader authentication model.

Reduce other unnecessary fingerprints

Version disclosure is only one reconnaissance signal.

You may also review:

• author identifiers;
• unused XML-RPC access;
• verbose PHP errors;
• unnecessary server headers;
• unused plugins;
• public debug information.

The goal is not to disguise WordPress at any cost. It is to avoid giving away information or interfaces that have no useful purpose.

Assume WordPress can still be detected

This is perhaps the most important mindset.

Your site should remain secure after an attacker knows:

• it uses WordPress;
• which theme it uses;
• which public plugins appear to be installed;
• where its login page is;
• which version family it may be running.

If the security model depends on an attacker never discovering these facts, the security model is too fragile.

WordPress version-hiding checklist

• Keep WordPress core updated before worrying about hiding its version.
• Keep active plugins and themes updated.
• Remove abandoned or unused plugins and themes.
• Check whether the front-end generator tag exposes WordPress version information.
• Check RSS and Atom feeds separately.
• Inspect scripts and stylesheets for visible ?ver= parameters.
• Remember that not every asset version equals the WordPress core version.
• Use WordPress hooks rather than editing core files.
• Preserve cache-busting behavior when changing public asset URLs.
• Do not describe version hiding as vulnerability remediation.
• Do not assume WordPress becomes undetectable after hiding the version.
• Review theme and plugin version disclosure independently.
• Review author identifier exposure independently.
• Disable unused XML-RPC functionality when appropriate.
• Do not disable required APIs merely to conceal the technology stack.
• Keep public debugging and verbose errors disabled in production.
• Use strong authentication for privileged accounts.
• Use rate limiting against automated login abuse.
• Monitor suspicious scanning and authentication activity.
• Maintain tested backups so security incidents remain recoverable.

Related guides

• How Attackers Fingerprint WordPress Sites
• What Is XML-RPC in WordPress, and Why Disable It?
• WordPress Brute-Force Attacks, Explained
• A WordPress Login Hardening Checklist
• How Attackers Collect WordPress Usernames and Email Addresses
• WordPress REST API Security Basics
• How to Limit Login Attempts in WordPress
• How to Monitor WordPress Login Attempts
• WordPress File Permissions Explained
• WordPress Staging Site Best Practices

Final recommendation

Hiding your WordPress version number is a sensible hardening measure when it is implemented safely and described accurately.

WordPress can expose version information through several public channels, including generator output, feeds and versioned asset URLs.

Removing those easy signals reduces the information available to automated reconnaissance tools and makes direct version-based targeting slightly less convenient.

But the benefit has strict limits.

A determined scanner can still identify WordPress through its architecture and may estimate versions through other fingerprints. Plugins and themes can expose their own information independently. Vulnerabilities remain exploitable whether or not their version number appears in the HTML.

For that reason, the correct priority is:

1. patch WordPress, themes and plugins;
2. remove obsolete software;
3. protect accounts and authentication;
4. reduce unnecessary interfaces and exposure;
5. then remove unnecessary implementation details such as explicit version numbers.

Do not hide an outdated WordPress installation and call it secure.

Hide the version because the public does not normally need it, while maintaining the site as though an attacker already knows exactly what software is running.

That is the useful security model: reducing easy reconnaissance without depending on secrecy for actual protection.