To check your WordPress version, log in and open Dashboard, Updates: the screen says "Current version: 7.1.4" (or whatever you run) near the top. Without a login, open wp-includes/version.php on the server and read the $wp_version line, or run wp core version if you have WP-CLI.
Those three are the reliable ones. Most guides also list the admin footer, the "At a Glance" widget and the page source, and those usually agree, but each one can show you the wrong number in a specific situation.
There is also a second version number most guides never mention: the database version. When it disagrees with the files, you get the "Database Update Required" screen.
This post goes through every method, says which ones can mislead you and why, and ends with the case where it matters most: matching a test site to a live one.
Where is the WordPress version in the dashboard?
There are four places in wp-admin. They do not all read the same value.
| Where | What it shows | Can it mislead? |
|---|---|---|
| Dashboard, Updates | "Current version: 7.1.4" | No. It reads version.php directly. |
| Tools, Site Health, Info, WordPress | Version, with PHP and the database server in other sections | No. Same direct read. |
| Admin footer, bottom right | "Version 7.1.4" | Yes. When you are behind, it shows the version you should install, not the one you have. |
| "At a Glance" widget | "WordPress 7.1.4 running Twenty Twenty-Five theme." | Yes, if a plugin rewrites the version. |
The difference comes from WordPress core itself.
Since WordPress 6.7 there is a function, wp_get_wp_version(), whose docblock says it "Returns an unmodified value of $wp_version. Some plugins modify the global in an attempt to improve security through obscurity."
The Updates screen and Site Health use that function.
The footer, the "At a Glance" widget and the generator tag use get_bloginfo( 'version' ), which returns the global. If a hardening plugin has overwritten the global, those three report whatever the plugin set.
Why does the footer say "Get Version" instead of my version?
The footer is not really a version display. It is an update prompt, built by core_update_footer() in wp-admin/includes/update.php.
If your user can update core and an update is available, it prints a link reading "Get Version 7.1.4", which is the new version, not yours. Only when you are up to date does it say "Version 7.1.4".
Two more cases change it. On a beta or release candidate, it reads "You are using a development version (7.2-beta1). Cool!"
For a user without the update_core capability, it always prints "Version" and the installed number.
On multisite that means site admins see the version, while a super admin on an outdated network sees the update link.
The About page drops the beta suffix
The "About WordPress" screen (the WordPress logo in the toolbar, then About WordPress) splits the version on the first hyphen, so on 7.2-beta1 it shows "7.2".
If you are confirming which beta or RC you are on, use the Updates screen.
How do I check the WordPress version without logging in?
Four places, from most to least reliable.
wp-includes/version.php. Over SFTP, SSH or your host's file manager, open the file and read the first variables:
$wp_version = '7.1.4';
$wp_db_version = 61833;
This is the source of truth for the files. It is also where WordPress gets $required_php_version (7.4 in 7.1) and $required_mysql_version (5.5.5).
WP-CLI. From the WordPress folder:
wp core version
wp core version --extra
The plain command prints 7.1.4. The --extra form adds the database revision, the TinyMCE version and the package language.
WP-CLI reads version.php without loading WordPress, so a broken plugin cannot stop it, and a plugin that rewrites the global cannot fool it.
The page source. On the front end, view the source and search for generator:
<meta name="generator" content="WordPress 7.1.4">
Core adds it with add_action( 'wp_head', 'wp_generator' ). Many security plugins and themes remove that action, so finding nothing proves nothing.
The feed. Open /feed/ and look for the generator line. Core hooks the same tag into the RSS2, Atom, RDF and comment feeds, so it is often still there when someone removed only the wp_head one:
<generator>https://wordpress.org/?v=7.1.4</generator>
Does readme.html still show the version?
No. The readme.html in a WordPress 7.1.4 package lists the minimum and recommended PHP and MySQL versions but contains no WordPress version number.
Older guides and scanners still point at it.
What about ?ver= on stylesheet URLs?
You will see ?ver=7.1.4 on URLs like wp-admin/css/login.min.css on the login page. That works because core sets the default asset version to the WordPress version, and stylesheets registered without their own version inherit it.
It is a weaker signal than it looks. It comes from get_bloginfo( 'version' ), so a plugin that rewrites the global changes it too, and plugin and theme assets carry their own version numbers, not WordPress's.
Is hiding the WordPress version worth doing?
It is a small benefit, not a fix. Hiding the generator tag stops the laziest automated scanners, but the same information leaks through feeds, asset URLs and the presence of files added in specific releases.
What actually protects a site is running a patched version.
If you have to choose between hiding the number and updating, update. Our guide to automatic plugin updates covers that side.
What is the WordPress database version?
Every WordPress release ships two numbers in version.php: $wp_version for the files and $wp_db_version for the database schema it expects. 7.1.4 expects 61833.
The database records the schema it was last upgraded to in the db_version row of wp_options. Read it with:
wp option get db_version
On every admin page load, wp-admin/admin.php compares the two. If (int) get_option( 'db_version' ) does not equal $wp_db_version, a single site is redirected to wp-admin/upgrade.php, the screen titled "Database Update Required" with an "Update WordPress Database" button.
So "what version am I on" has two answers that can disagree.
The files can be 7.1.4 while the database still says it was last upgraded by an older release. That happens when:
- core files were copied over by hand, by a deploy, or by a restore that included
wp-includesbut not the database (or the reverse) - an update ran out of time between copying files and running the upgrade routine (see why WordPress updates fail)
- you imported a database from an older site into newer core files
One trap here: wp core version --extra prints "Database revision", but that is the number the files expect, read from version.php, not the one stored in the database.
The WP-CLI handbook says so for multisite. Compare it against wp option get db_version yourself.
On multisite, every site has its own
Each site in a network has its own options table, so each has its own db_version. A network can run 7.1.4 files with half its sites still on an older schema until someone runs Network Admin, Updates, Upgrade Network.
Check a single site with wp option get db_version --url=site.example.com. Our post on WordPress Network Admin explains what Upgrade Network skips.
How do I know the files really are that version?
version.php is just a file.
A partial update, a hand edit or a compromised site can leave it saying one thing while other core files are something else. To check, compare every core file against WordPress.org's checksums for that version:
wp core verify-checksums
It downloads the checksums for the version in version.php and compares the installed files. If wp-includes/version.php itself fails, or dozens of files do, the number you read earlier is not telling you the truth about the install.
How do I check the PHP version WordPress is using?
Tools, Site Health, Info, Server shows the PHP version the web server runs WordPress under. That is the one that matters.
Be careful with wp --info or php -v over SSH: they report the PHP that runs on the command line, which on some hosts is a different binary from the one serving web requests.
If the numbers disagree, trust Site Health for "what runs my site".
Matching a test site to the live version
This is the case where the number stops being trivia. A plugin conflict that only shows on 7.0, or a fix that depends on a database upgrade routine, will not reproduce on a test site running the latest release.
Check all three on the live site first: the files and the database over WP-CLI, and PHP in Site Health (for the reason above).
wp core version
wp option get db_version
Then build the test site on the same WordPress line and PHP version. In SandyWP the create form has a WordPress version field: the latest release (currently 7.1.4) by default, the 7.2 beta, and older lines back to 6.6.
PHP is 8.2 to 8.5, switchable later.
The WordPress beta page is the one-click route for testing a plugin against the next release.
Every sandbox has SSH with WP-CLI, so the three commands above run on the copy too, and you can confirm the two sites match before you start testing. If you need the live content as well, Cloner copies the database and wp-content into a sandbox without changing the live site.
One honest limit: a sandbox gives you a fresh install of the version you pick.
If the bug you are chasing is a half-finished update, with mismatched files and database, reproduce it on a copy of the actual server, which is what a host's staging copy or a full backup restore is for.
Our post on testing before updating to 7.1 walks through the other side: moving a copy forward a version and watching what breaks.
The short version
- Logged in: Dashboard, Updates. It reads the file directly and nothing can rewrite it.
- Not logged in:
wp-includes/version.php, orwp core version. - Visitor only: page source
generatortag, then/feed/. Absence means nothing. - The footer shows the version you should install when you are behind.
- The database has its own version.
wp option get db_versionis the stored one;--extrais not. wp core verify-checksumstells you whether the files really are the version they claim.
