Hide the WordPress version number

What the checker sees

Two places. The page's <meta name="generator" content="WordPress 6.8.2"> tag, which WordPress prints in the head by default, and /readme.html, the file that ships with every copy of WordPress and names the installed version at the top.

Why it matters, and how much

A version number turns "is this site vulnerable?" into a lookup. Scanners that sweep the web for a known bug look for exactly this string. Hiding it does not patch anything: an out-of-date site is still out of date. It removes the easy match, which is worth two minutes of work, and updating is still the real fix.

Remove the generator tag

Put this in a must-use plugin, so a theme change cannot undo it. Create wp-content/mu-plugins/hide-version.php:

<?php
// Stop WordPress printing its version in the page head and in feeds.
add_filter( 'the_generator', '__return_empty_string' );

Plugins can add generator tags of their own, for example Elementor or WooCommerce with their version numbers. The checker only reads the WordPress one, but the same reasoning applies to the rest.

Stop readme.html answering

Deleting the file works until the next core update puts it back. Blocking it at the web server lasts. For nginx:

location = /readme.html {
    return 404;
}

For Apache 2.4, in .htaccess or the site's configuration:

<Files "readme.html">
    Require all denied
</Files>

What the checker does not flag

Core scripts and styles carry the version in their ?ver= query string. Stripping it from every file also breaks cache busting for plugin files, so most sites are better off leaving it alone and keeping WordPress up to date.

Check the fix

curl -s https://example.com/ | grep -i 'name="generator"'
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/readme.html

The first command should print nothing about WordPress, and the second should print 403 or 404. If a page cache serves the old page, purge it first.