By default WordPress prints its own version number into every page it serves. When that line is missing it has usually been removed deliberately, and there are still four other places the number leaks out — none of which require a login.
The fastest external check
Run the URL through the WordPress Theme Detector. It reads the generator meta tag and reports the version when one is published, alongside the other platform signals.
If it reports WordPress but no version, the tag has been stripped. That is not a failed check — it is a finding, and the manual methods below are what you use next.
Method 1: the generator meta tag
The one the tool reads. View source and search for generator:
<meta name="generator" content="WordPress 6.9.6" />
Present on a default install, absent on any site that has followed a hardening guide. It is the first thing those guides tell people to remove, so treat its absence as no information rather than as a well-maintained site.
Method 2: the RSS feed
Widely missed, because removing the meta tag does not remove this. Open the site's feed:
https://example.com/feed/
and search the XML for generator:
<generator>https://wordpress.org/?v=6.9.6</generator>
This is emitted by a different function to the one that writes the <meta> tag. Plenty of sites strip one and leave the other, which makes the feed the single most productive place to look once the head tag has gone.
Method 3: version strings on core assets
WordPress appends a ?ver= query string to the scripts and stylesheets it enqueues, and for core files that value is the WordPress version:
<link rel="stylesheet" href="/wp-includes/css/dist/block-library/style.min.css?ver=6.9.6">
Two cautions. Only read ?ver= on files under /wp-includes/ — a ?ver= on a theme or plugin asset is that theme or plugin's own version, and reading it as the WordPress version is a common mistake. And some optimisation plugins strip query strings from asset URLs entirely as a caching tweak, which removes this signal as a side effect rather than on purpose.
Method 4: readme.html
On installs that have not deleted it, the file WordPress ships at the document root names the version in its first heading:
https://example.com/readme.html
Deleting it is standard hardening advice and it is also recreated by some update routines, so it is worth checking even on a site that looks otherwise tidy. A 404 here tells you nothing either way.
What the number actually tells you
Read it as three parts. In 6.9.6, the 6.9 is the major release and the trailing 6 is a security and maintenance release.
Since WordPress 3.7, minor releases install themselves automatically unless somebody has turned that off. So a site sitting several patch versions behind on the same major line is not merely un-updated — automatic updates have been disabled or are failing, which is a more serious finding than the version gap itself. A site one major release behind with the current patch level is a normal, deliberately conservative setup.
The version alone does not tell you the site is vulnerable. Managed hosts routinely backport security fixes without changing the reported number, and a site behind a properly configured firewall running an old version may be at less risk than a current one with three abandoned plugins. Treat the number as one input, and check which plugins the site loads before drawing a conclusion — outdated plugins are a far more common route in than outdated core.
Checking a site you own
Every external method above can be defeated. None of these can.
In the admin. The version is in the footer of every admin screen, bottom right. The At a Glance panel on the dashboard shows it with the active theme.
Tools → Site Health. More useful than the number: it reports whether core, themes and plugins are current, whether automatic updates are working, and what PHP version you are on. If you only look at one thing, look here.
In the files, over SFTP or a file manager. Open wp-includes/version.php:
$wp_version = '6.9.6';
This is the authoritative value — it is the variable everything else reads from.
In cPanel, the WordPress management tool most hosts install lists every detected install with its version, which is the quickest way to audit several sites at once. The file manager gets you to version.php if that tool is not present.
On the command line, with WP-CLI, from the site's root directory:
wp core version
wp core check-update
The second is the one worth running. It tells you what is available rather than only what is installed, and it exits quietly when there is nothing to do — which makes it safe to put in a cron job that mails you only when a site falls behind.
Should you hide the version?
The honest answer is that it buys you very little, and the search demand for removing it is much larger than its security value.
Attacks against WordPress are automated and indiscriminate. A bot requests a known vulnerable path on every address in its list and acts on whatever answers; it does not read your meta tag first and skip you for being current. Hiding the version does not reduce the number of attempts you receive, and it does not protect an unpatched install from an attempt that succeeds.
Where it genuinely helps is narrow: it removes your site from the results when someone searches a public index for every site running one specific vulnerable version. That is a real scenario, and it is also entirely solved by not running that version.
If you want it gone anyway, the point is to remove all of it. Removing only the meta tag is the common half-measure, and it leaves the feed, the ?ver= strings and readme.html in place. Do all four, then check your own URL from outside and confirm.
And keep the order right: update first, hide second. A current install with a visible version number is in a considerably better position than a hidden one that is nine months behind.
If the version you find is out of date
For your own site, the sequence that avoids breaking it: take a full backup including the database, update plugins first, then core, then the theme, and load the front end and one admin screen after each step rather than at the end. If something breaks you will know which step did it.
If automatic minor updates have been switched off, find out why before switching them back on. Occasionally there is a real reason — a plugin pinned to a specific core version — and that reason is itself the problem to fix.
Start by confirming what the site publishes with the WordPress Theme Detector, or read how to tell if a site is built on WordPress if you are not yet sure it is.