TLDR: Removing the WordPress version number reduces an easy reconnaissance vector for attackers and cleans up theme and meta output. I walk you through safe methods: edit functions.php, use a small plugin snippet, hide versions in styles and scripts, remove readme and generator tags, purge caches, and verify the change. Follow step-by-step and avoid overwriting core files or using unsafe plugins.
Why I decided to strip the version — and what you’ll learn
I remember the night I discovered my site exposed its WordPress version in multiple places. I had just finished a plugin and theme cleanup and a scanner flagged a known-vulnerable release. I felt exposed and wanted a practical, low-risk fix that I could apply across client sites. That experience shaped this straightforward guide.
In this article I explain what the WordPress version number is, why it matters for security and privacy, exactly how to remove it using code or plugins, and what mistakes to avoid. You will get concrete code snippets, checklist steps, and ways to verify the removal without breaking updates or functionality.
What is the WordPress version number?
The WordPress version number is a small string (for example 6.4.1) that WordPress prints in several places: the HTML meta generator tag, RSS feeds, enqueued script and stylesheet query strings, and sometimes in readme.html files left on the server. It is primarily for site owners and tools, but it also tells attackers which vulnerabilities might apply to your site.
Why does removing the WordPress version number matter?
Removing the version number does not harden your site like a firewall or a patched core, but it reduces trivial information leakage. As you know, automated scanners and bots often probe sites by looking up version numbers and targeting known exploits. By hiding the version you make automated targeting slightly harder and reduce noisy scans.
When removing the version is not enough
To be clear: hiding the version is a small part of a defense-in-depth strategy. You still must run updates, use reputable plugins, secure logins, and keep backups. However, removing easy reconnaissance details is a tidy, low-effort improvement that I recommend after you harden the rest of your stack.
How WordPress exposes the version
Let me list the common places you’ll find the version so you know what to fix:
- HTML head meta generator tag
- Query strings appended to script and style URLs, like style.css?ver=6.4.1
- readme.html in the WordPress root
- RSS feed generator tag
- Admin pages and some plugin outputs
How do you remove the WordPress version safely?
Let’s break it down into concrete options. I give the pros and cons of each, plus exact code you can use. Pick one or combine non-conflicting steps. Always test on staging first.
- Method 1: Add a small snippet to your theme or child theme functions.php
- Method 2: Use a lightweight plugin that removes generator tags and query strings
- Method 3: Remove or rename the readme.html file from the server
- Method 4: Configure caching and CDNs to serve cleaned assets and then purge caches
Method 1 — The functions.php snippet I use (recommended for devs)
I usually add a few lines to my child theme functions.php so updates to the theme do not lose the change. Add this snippet (explain what each line does in comments):
You will remove the generator meta tag from the head and the version in RSS feeds and enqueued assets. This is fast and does not touch core files. It is safe, but if you change themes you must copy the snippet to the new theme or use a simple site-specific plugin.
Method 2 — Use a small plugin if you prefer a UI
If you are not comfortable editing PHP files, use a reputable security or optimization plugin that offers an option to remove the generator tag and strip version query strings. I recommend choosing a plugin with good reviews and minimal features so you avoid bloat. Many small security plugins expose exactly the toggle you need.
Method 3 — Remove readme.html and other exposed files
WordPress includes a readme.html in the root that lists the version. I remove or rename that file on client sites. If you cannot delete it, replace it with a blank file or restrict access via .htaccess or server rules. That prevents automated scanners from reading the version text file.
Method 4 — Strip version query strings from assets
WordPress appends the version to static asset URLs. That can be disabled so URLs look cleaner. However, query strings are sometimes useful for cache busting during updates. If you strip them, make sure your caching configuration or file fingerprinting keeps browsers from using stale files.
Practical step-by-step checklist I follow
Here is the exact workflow I run on a staging site before applying changes to production:
- Backup the site and database.
- Apply the functions.php snippet or install the chosen plugin.
- Delete or protect readme.html and remove unused files.
- Test the front end and admin area for errors.
- Clear all caches and CDN edge caches.
- Verify removal with an HTML view and RSS check.
When it is time to clear caches, make sure you purge both server caches and any CDN caches. If you use a caching plugin, purging a cache after these changes is essential. If you use a WordPress cache system, be sure to purge cache WordPress so the cleaned output goes live immediately.
How to verify the version number is removed
After you apply fixes use these quick checks:
- View page source and search for generator or version strings.
- Check the RSS feed and confirm the generator tag is gone.
- Open style and script files and confirm they no longer include ?ver= strings if you removed them.
- Try a simple automated scanner or use an online WordPress detection tool to confirm the visible version is hidden.
If you want to confirm your site does not leak other metadata, you might also run a small cleanup on your WordPress database. I often recommend cleaning unused transients and orphaned options. In case you need instructions for that, here is a resource to safely clean WordPress database after you make configuration changes.
Common pitfalls and what to avoid
To avoid trouble, watch out for these mistakes I saw people make:
- Editing core WordPress files. That breaks updates and causes maintenance pain.
- Removing query strings without ensuring cache invalidation elsewhere, which can serve stale CSS or JS to users.
- Installing large feature-bloated plugins just to hide a meta tag. Use a tiny trusted plugin or a simple snippet instead.
- Failing to purge caches after changes. The old output may still be served from cache or CDN.
When hiding the version backfires
Occasionally a plugin or theme relies on the version string for compatibility checks. If you remove the version and the plugin stops working, you can revert the snippet or use a site-specific plugin that offers a toggle. Always test on staging and keep a quick rollback plan.
Advanced: server rules and security headers
For sites under stricter security policies I add server-level rules to block access to readme.html and other publicly readable version files. You can also set security headers and use a WAF to minimize risk. In addition, using a consistent update schedule and limited admin accounts gives you far better protection than hiding the version alone.
Quick developer-friendly code summary
Here is the minimal set of actions developers use:
- remove_action(‘wp_generator’, ‘wp_generator’); to stop the meta tag
- filter style and script URLs to strip query vars with a small filter hooked to style_loader_src and script_loader_src
- delete readme.html from the root or block it with server rules
FAQ — Will hiding the WordPress version stop hackers?
No. Hiding the version is one small step in a layered defense. It deters trivial automated scans but will not stop targeted attacks or vulnerabilities in unpatched plugins. To protect your site, apply updates, use strong credentials, and run regular backups.
FAQ — Can I break my site by removing the version?
Generally no, if you use safe methods. The main risk is cache issues if you strip asset query strings without a cache-busting alternative. Always test on staging and keep backups. If a plugin checks the version and fails, temporarily restore the generator or use a conditional approach.
FAQ — How do I check if my site still reveals a version?
View page source and search for generator or ver=. Check RSS feeds in a browser. For an extra check, use an online WordPress detection guide to check if website is WordPress and see which traces remain. These checks help you confirm whether you still leak identifying information.
To summarize
Removing the WordPress version number is a simple, low-risk cleanup that reduces basic information leakage. Use a child theme snippet or a small plugin, delete readme files, then purge caches and verify. However, do not rely on obscurity; keep WordPress and plugins updated and maintain strong security practices.
Try the steps on staging, then roll them to production. If you want, tell me what hosting or caching plugin you use and I will give clipboard-ready code tailored to your setup.