Completely Hide the WordPress Version Number and Generator Tags for Security

WordPress can expose its version in the HTML generator meta tag, RSS feeds, and ?ver= query strings attached to enqueued assets. Removing those signals reduces casual fingerprinting, but it is only one small layer of hardening and should not replace updates, firewalls, or access controls.

Add the snippet to a child theme’s functions.php file or use a code snippets plugin.

The snippet

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

add_filter( 'style_loader_src', 'my_site_remove_asset_version', 9999 );
add_filter( 'script_loader_src', 'my_site_remove_asset_version', 9999 );

function my_site_remove_asset_version( $src ) {
  return remove_query_arg( 'ver', $src );
}

wp_generator removes the common <meta name="generator"> output, while the_generator covers generator strings used in feeds and other contexts. The asset filters remove only the ver query parameter and leave other query parameters intact.

Optional legacy discovery links

If the site does not use pingbacks or remote Windows Live Writer publishing, you can also remove the legacy discovery links:

remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );

Do not remove these links blindly if a publishing integration depends on them. Test the RSS feed, REST-based tools, cache behavior, and any asset pipeline after deployment.

What this does not protect

A determined scanner can often infer WordPress from headers, URLs, plugin assets, REST responses, or known behavior. Keep WordPress and plugins patched, use strong administrator authentication, restrict sensitive endpoints, and monitor failed logins. The WordPress hardening documentation provides the broader security checklist.

For endpoint-level hardening, compare this with disabling XML-RPC without a plugin.