How to determine your WordPress version

You check your WordPress version and get one number. A security scanner reports a second one, and a CSS file’s URL seems to show a third. They can’t all be right. One of them comes from the installation itself, and the others are signals that the installation, a plugin or a cache happens to send out.

Determining the version is mostly about knowing which kind of answer you have. If you just need the quickest place to look, our short guide to checking the WordPress version covers that. This article covers the next step: which source to trust, how to read it from the server, and what to do when two sources disagree.

Which checks give you the real answer?

Checks that read the installation give the real answer. Checks that read the public website only give clues. The table ranks them by how directly they read the installed files.

Method	Access needed	What the result means
wp core version	SSH with WP-CLI	The installed version, read from the files on the server
wp-includes/version.php	SSH, FTP or the host’s file manager	The installed version, if you open the right installation
Site Health → Info	WordPress administrator	The version WordPress reports for itself
At a Glance, Updates, admin footer	Logged-in user	Fast everyday checks, same source
Generator meta tag, feed, ?ver=, readme.html	None	A clue that may be missing, cached or misleading

Base any decision on one of the first four rows: whether to update, whether a plugin will work, whether a scanner is right. The last row is fine for a quick look at a site you don’t control. It shouldn’t settle anything.

How to find the version in the WordPress dashboard

If you can log in as an administrator, open Site Health. WordPress.org’s documentation puts it under Tools → Site Health → Info, and the WordPress section of that tab lists the version.

1. In the admin menu, go to Tools → Site Health.
2. Open the Info tab.
3. Expand the WordPress section and read Version.

If the menu doesn’t show Site Health, one of two things is going on. WordPress.org’s support page says the feature arrived in WordPress 5.2, so the site may be older than that. Or your account doesn’t have administrator rights. On a site that old, finding the version is the smaller problem.

The version also shows in a few faster places: the At a Glance box on the dashboard home, Dashboard → Updates, and the bottom-right corner of most admin screens. On a WooCommerce store, go to WooCommerce → Status and look under WordPress environment. That system status report is also what WooCommerce support usually asks for.

Site Health is also a useful first stop on a site you’ve just inherited. One screen shows the WordPress, PHP, theme, plugin and server details before you touch anything.

How to read the version from the server

Server access gives you the answer with no dashboard, cache or security plugin in between. That matters when you can’t log in, when the dashboard is broken, or when you need a result you can paste into a ticket.

With WP-CLI

WP-CLI’s documentation describes wp core version simply as the command that “displays the WordPress version.” Run it from the WordPress root folder, or point it at the folder:

wp core version
wp core version --path=/var/www/example.com/public_html
wp core version --extra

--extra adds more detail, including the database revision that the core files expect. On a multisite network, every site runs the same core version, so checking any one of them answers for the whole network.

If WP-CLI replies “Error: This does not seem to be a WordPress install. Pass –path=path/to/wordpress or run wp core download.”, it usually isn’t broken. Liquid Web’s troubleshooting guide puts that message down to running the command from the wrong directory. Add --path. If the path is correct and the error stays, check the folder permissions for the user you’re logged in as.

From wp-includes/version.php

The release number lives in one line of wp-includes/version.php. In a terminal:

cd /path/to/wordpress
grep '^\$wp_version' wp-includes/version.php

Without a terminal, open the file in your host’s file manager or over FTP and find the line that starts with $wp_version =. Two warnings apply. First, read the file and leave it alone. Editing the number changes nothing about the code and makes every later check wrong. Second, the same file also holds $wp_db_version. That is a database schema revision, a different and much longer number. It is not the release you’re looking for.

Servers that host several sites, or keep staging next to production, are where people read the wrong wp-includes folder. Before you trust the number, confirm that the folder is the one serving the domain you care about.

Checking that the files are what the number claims

A version number tells you what the installation says it is. It doesn’t tell you whether someone changed the files. wp core verify-checksums compares the core files against WordPress.org’s published checksums. A mismatch can come from a half-finished update or a local edit as easily as from an attack, so look into it before you replace anything.

What a public check can and cannot tell you

Without a login, you can only collect clues. Try them in this order and treat every result as provisional.

1. Page source. View the source of the home page and search for “generator”. WordPress core prints a line like <meta name="generator" content="WordPress x.y.z"> through wp_generator() on the wp_head hook.
2. The feed. Open /feed/ and look for a generator line such as wordpress.org/?v=x.y.z. The feed comes from a separate function, the_generator(), so it can still show the version after the HTML tag is gone.
3. Asset URLs under /wp-includes/. WordPress’s wp_enqueue_style() reference says that when an asset is registered without its own version, WordPress adds the installed core version as the ?ver= value. Core files under /wp-includes/ are the most likely to show it. Files from plugins and themes carry their own versions.
4. /readme.html. Sources disagree on whether current installs still show a version in this file. Hardened sites often delete or block it, and a 404 or 403 tells you nothing.

Expect to come up empty fairly often. SmartWP scanned the 20,000 most-visited domains in September 2026 and reports that 38% of the WordPress sites it found hid their version. Paths like /wp-content/ can confirm a site runs WordPress, but they don’t reveal the version. An honest result is often “WordPress, version unknown”. That doesn’t mean the site is current, and it doesn’t mean the site isn’t WordPress.

Why two tools report different versions

They’re usually measuring different things. Work through these in order, because the early ones explain most cases.

1. Check from inside first. Use Site Health or wp core version to see what the installation says.
2. Confirm the installation. Make sure you’re on the right site, path, domain, and production rather than staging.
3. Clear every cache. WordPress.org’s Updating WordPress page notes that a cache can keep showing the old version after an update. Clear the caching plugin, the host’s cache and any CDN, then look again.
4. Finish the update. If WordPress shows a database update prompt, run it. If the site is stuck in maintenance mode after a failed update, the same page says to delete the .maintenance file over FTP.
5. Question the scanner. A scanner that reads a version from a bundled library or a plugin’s ?ver= string can report an old WordPress version on a site that has been updated. If your files and WP-CLI agree with each other, read the scanner’s evidence before you replace anything.

Don’t fix a disagreement by copying core files over the site. Find out which number is wrong first, and keep both results with their sources until you know.

Should you hide the version once you know it?

You can, but it’s a minor step and it doesn’t make an old site safe. WordPress’s Hardening handbook puts keeping WordPress updated first and treats security through obscurity as unsound when it’s the main defence. It doesn’t help SEO either: Google’s list of the meta tags it supports doesn’t include generator.

If you do hide it, cover more than the obvious tag:

• remove_action( 'wp_head', 'wp_generator' ); removes only the tag in the page head.
• The feed’s generator line is separate output, so it needs its own handling.
• Plugins and page builders can print their own generator tags.
• Stripping every ?ver= string breaks cache-busting, and visitors may then get old CSS and JavaScript after you deploy a change.

Plugins exist for this. Check their status before you install one. The WordPress.org listing for Meta Generator and Version Info Remover covers the head tag, RSS feeds and asset versions, but it also warns that the plugin hasn’t been tested with the latest three major WordPress releases. Server rules can reduce what the site reveals too. Our article on Apache security for WordPress covers blocking files like readme.html.

What to do with the number

Compare it with the current release. If you’re behind, plan an update: take a backup you know how to restore, test on staging if the site makes money, and never delete wp-content during a manual update. Old versions are still common. W3Techs counted 4.8% of detected WordPress sites on version 5, 2.0% on version 4 and 0.2% on version 3 on Oct. 10, 2026. Those figures come only from sites that reveal their version, so the real share may be different.

If you’d rather not run the update yourself, “update WordPress and tell me what changed” is the kind of request SiteSelf takes on through chat. Its page on keeping WordPress up to date explains how that work is handled.

If you look after many sites, checking them one by one in the dashboard doesn’t scale. Add the version check to onboarding and to whatever tool you already use to manage multiple WordPress websites.

Frequently asked questions

Can I find the WordPress version of a site I don’t own?

Only through public clues: the generator tag, the feed, core asset URLs and readme.html. Detection tools read the same signals, so when a site hides them, the tools hit the same wall. Report the result as a clue, or as “unknown”.

Does a missing generator tag mean the site isn’t WordPress?

No. Removing it is a common hardening step, and many security plugins and hosts do it. Paths such as /wp-content/ and /wp-includes/ in the page source are better evidence that a site runs WordPress.

Is the ?ver= number on a stylesheet the WordPress version?

Sometimes. WordPress adds the core version only when the asset doesn’t set its own, which mostly means core files under /wp-includes/. A number on a plugin or theme file is that plugin’s or theme’s version.

How do I get the version in PHP code?

Community answers suggest get_bloginfo( 'version' ), which returns the release string from inside WordPress. Use it in admin-only output, not on public pages, unless you’re happy to show the version to anyone who looks.

What about sites hosted on WordPress.com?

WordPress.com Support says plugin-enabled sites show the version in the Hosting Dashboard, under the site title and address. Other WordPress.com sites always run the latest version, so there’s nothing to check.

I updated but the dashboard still shows the old version. Did it fail?

Usually not. Clear the plugin, host and CDN caches and check again. If the site is stuck in maintenance mode, delete .maintenance over FTP. If WP-CLI still reports the old version after that, the update didn’t finish, and the Updating WordPress guide covers a manual retry.