How to hide the WordPress version number?

To hide the WordPress version number, remove the generator meta tag with remove_action( 'wp_head', 'wp_generator' ), empty the generator output in feeds with the the_generator filter, strip the ver= query string from core scripts and styles, and block public access to files like readme.html. You can do all of this with a few lines of code in a small custom plugin, or with a security or performance plugin that includes a "remove version" option.

Hiding the version makes it harder for automated scanners to match your site against lists of known vulnerabilities, but it is a minor hardening step, not a fix. The real protection is keeping WordPress updated. In this guide, you'll learn every common place the version number appears, how to remove each one safely, how to avoid breaking browser caching in the process, and how to check your work.

Why Hide the WordPress Version?

When your site announces which WordPress version it runs, anyone can compare that number against public vulnerability databases. Attackers rarely do this by hand. Instead, automated tools crawl thousands of sites, read the version, and flag any that are running a release with a known security issue.

Hiding the version helps in a few modest ways:

• Fewer easy matches: Automated scanners that rely on the generator tag will skip your site or mark it as unknown.
• Less information leakage: As a general rule, your site shouldn't volunteer details about its software stack.
• Cleaner source code: Removing the generator tag and unnecessary query strings tidies up your HTML output.

What Hiding the Version Won't Do

It's important to be honest about the limits here:

• It won't hide that you use WordPress: Paths like /wp-content/ and /wp-includes/ make that obvious.
• It won't stop fingerprinting: Determined tools can often estimate your version by comparing the contents of core CSS and JavaScript files against known releases.
• It won't protect an outdated site: If you're running a vulnerable version, attackers can simply try the exploit regardless of what your HTML says.

So treat this as housekeeping on top of the real defence: enabling automatic updates for minor releases, updating to new major versions promptly, and keeping plugins and themes current.

Where Does WordPress Show Its Version Number?

Before removing anything, it helps to know where the version appears. On a typical site, you'll find it in these places:

1. The generator meta tag: WordPress adds a <meta name="generator" content="WordPress 6.x" /> tag to the head of every front-end page.
2. RSS and Atom feeds: Your feeds include a generator element with a URL that contains the version.
3. Script and style URLs: Core assets are loaded with a query string such as ?ver=6.x, which is used for cache busting.
4. The readme.html file: Every WordPress installation ships with readme.html in the root folder. It confirms that WordPress is installed, and older releases displayed the version in it.
5. The admin footer: Logged-in users see the version at the bottom of the dashboard. This is only visible to logged-in users, so it's not a public leak.

Themes and plugins may also add their own version strings to assets, but those reveal plugin versions rather than the core WordPress version.

Method 1: Remove the Version With Code

The code below handles the generator tag, feeds, and core asset query strings. Put it in a small custom plugin so it keeps working if you change themes. Create a file called sajjad-hide-version.php in wp-content/plugins/ (or in wp-content/mu-plugins/ if you want it always active) and add:

<?php
/**
 * Plugin Name: Hide WordPress Version
 * Description: Removes the WordPress version from the head, feeds, and core asset URLs.
 * Version:     1.0.0
 * Author:      Sajjad
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// 1. Remove the generator meta tag from the front-end head.
remove_action( 'wp_head', 'wp_generator' );

// 2. Remove the generator from RSS, Atom, and other feeds.
add_filter( 'the_generator', '__return_empty_string' );

// 3. Remove the core version from script and style URLs.
function sajjad_remove_core_version_query( $src ) {
    if ( ! is_string( $src ) || '' === $src ) {
        return $src;
    }

    $wp_version = get_bloginfo( 'version' );

    // Only touch assets that use the core WordPress version.
    if ( str_contains( $src, 'ver=' . $wp_version ) ) {
        $src = remove_query_arg( 'ver', $src );
    }

    return $src;
}
add_filter( 'style_loader_src', 'sajjad_remove_core_version_query', 9999 );
add_filter( 'script_loader_src', 'sajjad_remove_core_version_query', 9999 );

If you'd rather use your child theme's functions.php, you can paste everything after the plugin header there instead. Activate the plugin from Plugins > Installed Plugins (mu-plugins activate automatically).

A few notes on this code:

• remove_action( 'wp_head', 'wp_generator' ) removes the meta tag that WordPress adds by default.
• the_generator filter controls the generator output for feeds and other places that call the_generator(). Returning an empty string removes it everywhere.
• The asset filter only removes ver when it matches the core version, so plugin and theme assets keep their own version strings and cache busting.

A Better Option for Asset Query Strings

Removing the ver parameter entirely has a side effect. That parameter tells browsers and CDNs when a file has changed. Without it, visitors may keep a cached copy of an old core script after you update WordPress, which can cause strange bugs until their cache expires.

A safer approach is to replace the version with a hash. The file still gets a unique cache-busting value after each update, but the value no longer reveals the version:

<?php
function sajjad_hash_core_version_query( $src ) {
    if ( ! is_string( $src ) || '' === $src ) {
        return $src;
    }

    $wp_version = get_bloginfo( 'version' );

    if ( str_contains( $src, 'ver=' . $wp_version ) ) {
        // wp_hash() uses your site's unique salts, so the value can't be reversed
        // into a version number, but it still changes when WordPress updates.
        $hashed = substr( wp_hash( $wp_version ), 0, 10 );
        $src    = add_query_arg( 'ver', $hashed, $src );
    }

    return $src;
}
add_filter( 'style_loader_src', 'sajjad_hash_core_version_query', 9999 );
add_filter( 'script_loader_src', 'sajjad_hash_core_version_query', 9999 );

Use either this function or the removal function from the plugin above, not both. add_query_arg() replaces the existing ver value rather than adding a second one.

Method 2: Use a Plugin

If you'd rather not touch code, several well-known plugins include an option to remove version information:

• All-In-One Security (AIOS): Has a setting to remove the WordPress generator meta information under its settings screens.
• Perfmatters: Includes toggles to remove the WordPress version and query strings from static resources.
• Solid Security: Offers tweaks for reducing information exposed by WordPress, depending on your version and plan.

Check the plugin's settings after installing, because these options are usually off by default. If you already run a security or performance plugin, look through its settings before adding another one.

Block Access to readme.html and Other Revealing Files

The readme.html file in your site's root confirms that WordPress is installed, and older versions listed the version number at the top. license.txt and wp-config-sample.php also confirm a WordPress installation. None of them need to be publicly accessible.

You could delete these files, but WordPress puts them back on every update. Blocking them at the server level is more reliable.

Apache or LiteSpeed

Add this to your root .htaccess file, outside the # BEGIN WordPress and # END WordPress markers:

# Block public access to files that reveal WordPress details
<FilesMatch "^(readme\.html|license\.txt|wp-config-sample\.php)$">
    Require all denied
</FilesMatch>

Nginx

Add this inside your site's server block, then test and reload Nginx:

# Block public access to files that reveal WordPress details
location ~* ^/(readme\.html|license\.txt|wp-config-sample\.php)$ {
    deny all;
}

sudo nginx -t && sudo systemctl reload nginx

Visiting https://example.com/readme.html should now return a 403 Forbidden response.

Don't Forget Plugin and Theme Versions

Attackers are often more interested in plugin versions than the core version, because most WordPress vulnerabilities are found in plugins. Plugin versions can show up in:

• Asset query strings: For example, ?ver=3.2.1 on a plugin's stylesheet.
• Plugin readme.txt files: Every plugin from the WordPress.org directory includes a readme.txt in its folder, which lists a "Stable tag" version.
• HTML comments: Some plugins, especially SEO and caching plugins, add a comment in your page source with their name and version.

You can block direct access to plugin and theme readme.txt files with a server rule. On Apache:

# Block readme and changelog files inside plugin and theme folders
<If "%{REQUEST_URI} =~ m#^/wp-content/(plugins|themes)/.+/(readme|changelog)\.(txt|md)$#i">
    Require all denied
</If>

And the Nginx equivalent:

location ~* ^/wp-content/(plugins|themes)/.+/(readme|changelog)\.(txt|md)$ {
    deny all;
}

That said, there's a limit to how much you can hide. The most effective response to plugin vulnerabilities is still to update promptly and remove plugins you no longer use.

How to Check That the Version Is Hidden

Once your changes are in place, clear any page cache (your caching plugin, your host's cache, and your CDN) so you're testing fresh output. Then check each location.

1. View the page source: Open your homepage, press Ctrl+U (or Cmd+Option+U on a Mac), and search for "generator". The WordPress generator tag should be gone.
2. Check your feed: Visit https://example.com/feed/ and search for "generator" again.
3. Check asset URLs: In the page source, search for ver= followed by your WordPress version. Core scripts and styles should no longer show it.
4. Check readme.html: Visit https://example.com/readme.html in a private window. It should return a 403.

You can also check from the command line:

# Look for any generator tags on the homepage
curl -s https://example.com/ | grep -i "generator"

# Look for the generator in the main feed
curl -s https://example.com/feed/ | grep -i "generator"

# Confirm readme.html is blocked (expect 403)
curl -I https://example.com/readme.html

If a generator tag still appears, it may come from a plugin rather than WordPress core. Page builders and SEO plugins sometimes add their own generator tags, and many of them have a setting to turn it off.

The Most Important Step: Stay Updated

Hiding your version number is only worthwhile if the version you're hiding is current. A few habits matter far more than anything in this article:

• Keep automatic minor updates on: WordPress installs security and maintenance releases automatically by default. Don't disable this unless you have a managed update process.
• Update major versions promptly: Test on a staging site if you can, then update production.
• Enable auto-updates for trusted plugins: Go to Plugins > Installed Plugins and click Enable auto-updates for plugins you trust.
• Remove what you don't use: Deactivated plugins can still contain vulnerable files. Delete them.

---

FAQ: Hiding the WordPress Version

---

Conclusion

Hiding the WordPress version number comes down to a handful of small changes: remove the generator tag from the head, clear it from feeds, replace or remove the core version in asset URLs, and block access to readme.html and similar files. A short custom plugin handles most of this cleanly, and a server rule takes care of the files WordPress restores on every update.

Just keep the bigger picture in mind. Hiding the version reduces how much your site gives away to automated scanners, but it's the updates behind it that actually keep attackers out. Keep automatic minor updates on, update plugins and themes promptly, remove anything you don't use, and treat version hiding as the finishing touch rather than the foundation.