Maintenance
How to check your WordPress version — and why it is probably public.
There are five ways to find out which version of WordPress a site is running. Three of them work from outside, without logging in, on most sites — which is the interesting part.
If you can log in
1. The dashboard footer
Log in and look at the bottom right of any admin page. It says Version 6.x.x. That is the whole method.
2. Dashboard → Updates
More useful, because it tells you both what you are running and whether that is current. It also lists pending plugin and theme updates in the same place, which is where you want to be anyway.
3. Tools → Site Health → Info
The most complete answer. Expand the WordPress section for the version, and while you are there, the Server section gives you your PHP version and the Database section your MySQL or MariaDB version. All three matter, and people usually only think about the first.
If you cannot log in
This is where it gets interesting, because these work on anyone’s site.
4. The generator meta tag
Open any page, view source, and search for generator. By default WordPress emits:
<meta name="generator" content="WordPress 6.4.2" />
Present on most WordPress sites, because it is on by default and removing it is a deliberate act.
5. Version strings on assets
Even with the generator tag removed, WordPress appends a version query string to core scripts and stylesheets:
/wp-includes/css/dist/block-library/style.min.css?ver=6.4.2
Search the page source for ver=. Core assets carry the WordPress version. This catches
people who removed the meta tag and assumed they were done.
And the one everybody forgets
Some sites still expose /readme.html in the web root, which states the version in large
friendly letters near the top. Check whether yours is reachable. If it is, delete it — it is
documentation for an installation that finished years ago.
Why any of this matters
Let us be precise, because this topic attracts overstatement in both directions.
Knowing your version does not let anyone in. It is not a credential and it is not a flaw. A site running a current, fully updated WordPress can publish its version on the home page and be no worse off.
What it does is make you cheap to find. A great deal of attack traffic is indiscriminate: scan enormous numbers of sites, read the version off each one, and only spend effort on those running something with a known, published vulnerability. Disclosing your version is what gets you onto the shortlist.
So removing it is security through obscurity, and obscurity is not security. It patches nothing. But it costs you nothing either, and it removes you from the cheapest category of target. The honest summary is: worth doing, in about tenth place, after everything in the security checklist that actually matters.
If you are on an old version, hiding the number is not the fix. Updating is the fix. Hiding the version of an out-of-date install is putting a cover over a warning light.
How to stop publishing it
The conventional snippet, for a child theme’s functions.php or a small plugin:
remove_action('wp_head', 'wp_generator');
That removes the meta tag. It does not remove the ?ver= strings on core assets,
which is why so many sites that have “hidden the version” still announce it to anyone who
looks at the second place.
Stripping those as well takes a filter on style_loader_src and
script_loader_src, and it needs care: version strings exist to bust browser caches, so
removing them entirely can leave visitors holding a stale stylesheet after you update. Replacing the
version with a stable site-specific value is better than deleting it.
Guru Site Health reports version disclosure as a finding and can fix it in one click, covering both the meta tag and the asset strings, with an Undo — because this is exactly the kind of change you might want to reverse when you are debugging a caching problem at eleven at night.
While you are checking versions, check these two as well
The WordPress version is the one everybody asks about and rarely the one that matters most.
- Your PHP version. In Tools → Site Health → Info → Server. PHP versions reach end of life on a published schedule, after which they stop receiving security fixes entirely. A great many WordPress sites run on a PHP version that has not had a security patch in years, and the site gives no indication of it. Your host’s control panel will usually let you change it in a couple of clicks.
- Your database version. Same page, Database section. Less urgent, but old MySQL versions reach end of life too.
If you check your WordPress version once a quarter, check all three at once. It is the same screen.
Frequently asked questions
How do I check what version of WordPress I am running?
Log in and look at the bottom right of any admin page, or go to Dashboard → Updates, which also tells you whether it is current. Tools → Site Health → Info gives the fullest answer, including your PHP and database versions.
How can I check the WordPress version of a site I do not own?
View the page source and look for a <meta name="generator"> tag, or search for ver= on core stylesheet and script URLs, which carry the WordPress version. Some sites also still expose /readme.html, which states it directly.
Is it dangerous to show your WordPress version?
Not directly — the version number is not a credential and knowing it does not let anyone in. What it does is put you on the shortlist for indiscriminate automated scanning, which reads the version off large numbers of sites and only spends effort where a known vulnerability exists. Hiding it is worth doing but is no substitute for updating.
How do I hide the WordPress version?
remove_action('wp_head', 'wp_generator'); removes the meta tag, but not the ?ver= strings on core scripts and stylesheets, which disclose the same thing. Handling both needs filters on style_loader_src and script_loader_src, done carefully — those version strings also bust browser caches.
Does hiding the WordPress version break anything?
Removing the generator meta tag is harmless. Stripping version strings from asset URLs can cause caching problems: browsers use them to tell that a file changed, so removing them entirely can leave visitors with a stale stylesheet after an update. Replacing the version with a stable site-specific value avoids that.
What else should I check alongside the WordPress version?
Your PHP version, which matters more. PHP releases reach end of life on a published schedule and stop receiving security fixes, and many WordPress sites run on an unsupported one with no indication anywhere in the admin. Tools → Site Health → Info shows WordPress, PHP and database versions on one screen.
Find these on your own site in about ten seconds
Guru Site Health runs 32 checks across updates, security, database, media, accessibility and SEO, and gives you one score. Thirteen of the findings can be fixed from the dashboard in one click, and every fix can be undone. It makes no external requests — nothing about your site ever leaves it.