Like the blog? Get the book »

How to Remove the WordPress Version Number

How to Remove the WordPress Version Number

In this DigWP tutorial, we take a look at a the potential security risk inherent in displaying your site’s WordPress version number to anyone or anything that happens to stop by for a visit. For anyone who has been working on securing their WP-powered website, one of the most commonly seen security tips around the WordPress-o-Sphere has got to be this:

Don’t display your WordPress version number publicly. Many WordPress developers often display the WordPress version in the source code. But having this information publicly available makes it easy for attackers to exploit known vulnerabilities on a particular version.

This sort of thinking is referred to as “security through obscurity,” and may or may not be an effective way to increase the overall security of your site.

By default, WordPress executes the wp_generator() function whenever the wp_head() hook is called. Typically, this hook is located in your theme’s header.php file within the <head> section of the document markup:

Screenshot of the wp_head() hookThe wp_head() hook as seen via the header.php file

Then, after WordPress processes your web page, the wp_generator() function outputs the following code (depending on page view) to your browser:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="" /> 
<link rel='index' title='Digging into WordPress' href='' />
<meta name="generator" content="WordPress 2.8.1" />

Notice that last line there? There are many posts on WordPress security that point out how specifying your version number is a security risk. Whether or not this is the case is certainly debatable, but the thinking is that you should avoid revealing this sensitive information in order to prevent attacks targeting specific versions of WordPress.

Now for the fun part. Assuming that sharing your version information is bad, how to go about removing the information? Well, that depends on how savvy you are with WordPress. Here are several methods to prevent WordPress from displaying your version-specific number, ranked in order from the absolute worst way to the absolute right way. That is, until someone shows us how to do it in less than 41 characters ;)

The absolute worst way to remove the WP version number

I have seen recent posts where the author actually recommends deleting the wp_head() hook! Here is an example:

Study what things this function outputs for you, and just hardcode them into your theme files since these values will unlikely change.

While there are indeed valid reasons for removing this important WordPress hook, removing the version number from your source code is not one of them.

A pretty good way to remove the WordPress version number

Much better than simply deleting the wp_head() hook, this method serves us well by placing the version-removal function in the theme’s functions.php file, where it belongs. By returning an empty string for the_generator, this function removes the version information by preventing output of its <meta> tag:

function remove_version_info() {
     return '';
add_filter('the_generator', 'remove_version_info');

This method has the added bonus of removing the version information from not only your blog pages, but from your feeds as well.

The right way to remove the WordPress version number

Going a step beyond the previous method, this technique gets the job done quite eloquently, with a mere 41 characters of code:

remove_action('wp_head', 'wp_generator');

Just place that single line into your theme’s functions.php and enjoy a small taste of “security through obscurity”. :)

Update: A New Way to Remove the WP Version Number

Since this article was written, a lot has changed with WordPress. Here is a new way to prevent WordPress from displaying its version number:

// remove version from head
remove_action('wp_head', 'wp_generator');

// remove version from rss
add_filter('the_generator', '__return_empty_string');

// remove version from scripts and styles
function shapeSpace_remove_version_scripts_styles($src) {
	if (strpos($src, 'ver=')) {
		$src = remove_query_arg('ver', $src);
	return $src;
add_filter('style_loader_src', 'shapeSpace_remove_version_scripts_styles', 9999);
add_filter('script_loader_src', 'shapeSpace_remove_version_scripts_styles', 9999);

No editing required. Add to functions.php and done. Or add via simple custom plugin. The choice is yours! :)

31 responses

  1. switch to branch tree and create crontab to do daily update would be much better than hiding version number.

    • Ideally, perhaps, but not practically. Updates can break things, especially as the site configuration grows more complex. Not sure how many users are going to “switch to branch tree and create crontab,” but it is an excellent idea for a tutorial.

      Thanks for the tip :)

      • Isn’t that only mostly true on major updates? (f.e. 2.7 -> 2.8)
        And according to this, branch tree only contains fixes on major bugs and security issues.

      • Not sure what you mean by “only mostly true,” but any update involves conflict potential. Automating the process is not a one-size-fits-all solution, although doing so is better for security than simply hiding the version number.

      • I mean, on major updates the chance of something broken is pretty high while this is not usually the case on minor updates. I would say the chance of something broken in minor updates is low especially if all the plugins/theme used are actively developed and coded properly. There is always chance of something broke though.

      • I do see your point, but keep in mind that a majority of users (and I would guess a vast majority) have no idea how to “branch and cron,” as it were. Conversely, adding a line to functions.php is something that most users can do, should they decide it’s worthwhile.

  2. Useful information. Thanks

  3. Wow, loving the simpler method. I used the first code for my client’s project – not for security reasons though, but more of them afraid WP from tarnishing their branding (I have no idea why, but I guess they’re simply bigots). The second method you’ve proposed looks a lot simpler and shorter.

    One question though: Is it valid in older versions of WP? (stupid question and I know the answer is probably yes)

    • Within reason, yes — but if you travel too far back in time, these methods may not work. I think the remove_version_info() function will work in more versions than the remove_action() method, but I may be mistaken.

  4. Thanks for the info. I’ve seen other solutions that didn’t even work. This one does.

  5. Thanks Jeff for your posts, I am learning a lot and am fairly new to WP here… when you say “Just place that single line into your theme’s functions.php and enjoy a small taste of “security through obscurity”. :)” where exactly do you place that code? At the beginning, the end? Thanks!

    • can go anywhere inside the function.php file in your themes folder.

      • Thanks John!

      • if you do not have a functions.php file create on and put this line anywhere inside it <?php remove_action('wp_head', 'wp_generator'); ?>. I mistyped it above it needs to be functions.php not function.php it has to have the “s” on the end.

  6. Smooth Crminal

    Ok so why “security through obscurity” is better? I can’t see the point of removing version number because this doesen’t resolve anything.

    • I don’t think he said ‘”security through obscurity” is better’ anywhere in this post. He only explains the better way doing it. Not that doing this is better.

    • Sp@mmers and Script Kiddies frequently target blogs and look for version numbers to determine which insidious script to run. Some don’t bother with version numbers, but if a sp@mmer or SK knows of a security exploit on a certain version number, then they will have their tool spider for blogs with a certain version number to hit.

  7. Lalor McMahon

    Great tip Jeff. Just wondering what would be needed in order to customise the meta information to insert design/author details of the theme etc?

    • If you are referring to the <meta> tags in the document <head>, you could add something like this to your functions.php file:

      function custom_meta() {
             echo "<meta name='author' content='Jeff Starr' />";
      add_action('wp_head', 'custom_meta');

      I also have a simple plugin that does this very thing, enabling you to customize a variety of common meta tags.

  8. The way I did this was to edit a line in the /wp-includes/defaults-filter.php file. In that file you’ll find the following line:

    add_action('wp_head', 'wp_generator');

    Replace that line with:

    remove_action('wp_head', 'wp_generator');

    • Ah, another brave soul who prefers to hack the WP core ;)

      May I ask why you chose this method as opposed to going the functions.php route?

  9. Jeff,

    I must say there are many ways to find out the version of WordPress you are using.

    Just view the source of your login page and you will see the things like:


    By examining the versions of the CSS files, TinyMCE and other JavaScripts it is possible to find out what version of WordPress is actually used.

    An example: you have “/wp-includes/js/” in your server. Dev-versions (not minified) of JS appears as of WP 2.8.

    Version of 20090625 of colors*.css is likely to indicate WP 2.8.1 (although I am too lazy to check which numbers WP 2.8 used).

    • Insightful as always, Vladimir. I will be checking into these files and examining their default availability and accessibility. Hopefully preventing access is possible, as I am not seeing any way of renaming these files via functions.php. There are many scans for WordPress generator version, but I have never seen any for these specific files, not that it isn’t happening, but probably to a much lesser extent. Still a bit disconcerting though. Thanks for the heads up.

  10. Jeff,

    Personal preference I guess. It made sense to me to stamp out the function where it was being triggered. The other wp-head hooks are there as well. I’d welcome your thoughts on the pros and cons of each approach though.

    • The main argument against hacking the WP core is of course that it complicates the upgrade process. For production sites, I might agree with this, but for learning and development purposes, there is no better way to learn WordPress than to “dig in” and start hacking around in the core. I owe most of what I know about WordPress to breaking (and fixing) things in the core. So the question goes back to you: how do you go about upgrading? Do you have multiple sites?

      • Jeff, thank you. I simply make a backups of the files I have made edits to in /wp-includes. So when I upgrade, which I typically do manually, I can reapply the necessary changes where necessary. Not the most elegant I’ll admit…

      • Jeff,

        Update. After giving this some more thought I think your approach is indeed more effective. As you suggest, it does make upgrades easier ;-)

        Thanks for the terrific article.

  11. When it comes to security, isn’t keeping wp up to date better than hidding the version number?

    Nice and clean fix as always though.

    • I don’t think there’s any one thing that is going to keep your public site totally secure. It’s more like a culmination of various layers of protection. Hiding the version number is merely one of those (hopefully) many layers.

  12. Ramyasadasivam

    Thq :-)

Comments are closed for this post. Contact us with any critical information.
© 2009–2024 Digging Into WordPress Powered by WordPress Monzilla Media shapeSpace