How to check the WordPress version your site runs

Most people look up their WordPress version for one of a few reasons. A security release has come out, a plugin says it needs a newer WordPress, a scanner report has flagged the site, or someone has inherited a site and nobody knows what’s on it. Checking takes seconds when you can log in. The trouble starts when you can’t log in, or when two tools give you two different numbers.

This guide goes through each method, from the official screen to the command line, and explains which results you can trust. The WordPress version is only one number. Before an update you’ll usually want the plugin versions too, and our guide to listing plugins with wp plugin list covers those.

Which method fits your access, and how far to trust it

Which method you use depends mostly on the access you have, and the results are not equally trustworthy. Checks that read the installation give the real answer. Checks that read the public website only give clues.

Your access	Method	How much to trust it
Admin login	Tools → Site Health → Info → WordPress	Authoritative: the version WordPress reports for itself
Admin login	At a Glance widget, admin footer, Dashboard → Updates	Authoritative, from the same source, and faster for everyday checks
WooCommerce admin	WooCommerce → Status → WordPress environment	Authoritative
Host portal	Your host’s site dashboard	A convenience, not proof, and it may need a refresh
File manager, SFTP or SSH	$wp_version in wp-includes/version.php	Authoritative, if you open the right installation
SSH with WP-CLI	wp core version	Authoritative, read from the files on the server
Public site only	Generator tag, feed, readme.html, ?ver= strings	A hint at best, which may be missing, cached or misleading

Base any decision on one of the authoritative rows: whether to update, whether a plugin will work, whether a scanner is right. The public clues are fine for a quick look at a site you don’t control. They shouldn’t settle anything.

Where the dashboard shows your WordPress version

Site Health is the most reliable screen. WordPress.org’s documentation says its Info tab lists the version your site is currently using. Site Health was added in WordPress 5.2, so any site you’re likely to run today has it.

1. Log in to wp-admin as an administrator.
2. Go to Tools → Site Health and click the Info tab. The page opens on the Status tab, which lists problems and recommendations but not the version, and this is where most people get stuck.
3. Expand the WordPress section and read the Version line.

The same tab has a Server section, which shows your PHP version. Keep the two separate: the PHP version is the one people most often report by mistake. WordPress.org’s Site Health screen documentation lists every section on the Info tab.

The Info tab is read only, so you can’t break anything by opening it. If you’re asking for help, use the Copy site info to clipboard button and paste the report into your support thread. It covers the WordPress version, PHP version, active theme and plugin list in one go, which is what a volunteer needs to tell a core problem from a plugin conflict.

Three other screens show the version too:

• At a Glance on the Dashboard home screen. This widget can be hidden under Screen Options, so if you don’t see it, it may just be switched off.
• Dashboard → Updates, which also tells you whether a newer release is available.
• The admin footer, bottom right, on most admin screens.

If one of these is missing, try another. Plugins and custom admin themes sometimes hide the footer or remove widgets. That doesn’t mean something is wrong.

How to check without logging in to WordPress

If it’s your own site, you don’t need wp-admin. You need access to the files or to the server. Three methods work.

Read wp-includes/version.php

WordPress keeps its version in a file. Open your hosting file manager or connect over SFTP, find the folder that holds wp-config.php, wp-admin and wp-includes, and open wp-includes/version.php. Look for this line:

$wp_version = '7.1.2';

Only read the file. Don’t edit it or save it. Ignore $wp_db_version a few lines down: that’s a database schema revision, a different number, not the release you’re looking for. The usual mistake here is opening the wrong installation. Hosting accounts often hold a staging copy, an old copy in a folder like /old/, or several sites next to each other. Check the folder path against the domain before you trust the number. Staging copies often drift from production, so don’t assume they match.

Run wp core version over SSH

If you have SSH access and WP-CLI, one command gives you the answer:

cd /var/www/example.com/public
wp core version

Or point the command at the site from anywhere on the server:

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

The WordPress Developer Blog points out that wp core version is not the same command as wp cli version. The second one reports the version of WP-CLI itself, and people mix them up all the time. If you see Error: This does not seem to be a WordPress install. Pass --path=`path/to/wordpress` or run `wp core download`., you’re in the wrong directory. Move into the site folder or pass --path.

According to the wp core version command reference, the command runs before WordPress loads. That means a plugin with a fatal error usually won’t stop it from answering.

Look in your host’s dashboard

Many hosts show the WordPress version in their control panel, often on a site overview or updates screen. Make sure you’re signed in to the right account and looking at the right site or environment. On two managed hosts:

• WordPress.com (plugin-enabled sites): open the Hosting Dashboard and select the site. The version appears under the site’s title and address.
• WP Engine: in the User Portal, go to Sites, choose the environment, and look at Updates on the Overview page.

Treat the number as a convenience, not proof. WordPress.com says it may run one version behind while it tests a new release. WP Engine’s support docs tell you to refresh the portal’s Updates section if the version shown might be out of date. If the host’s number doesn’t match Site Health or WP-CLI, go with Site Health or WP-CLI.

WooCommerce stores: the Status report

If you run a store, WooCommerce → Status shows the WordPress version under WordPress environment. WooCommerce’s guide to updating PHP and WordPress mentions Site Health as another option. The same report also shows the WooCommerce version and the PHP version, so read the WordPress row. This report is also what support forums usually ask for, so it’s worth knowing where it is.

Which number is actually the WordPress version

A WordPress site has at least five version numbers, and a status report may show all of them together:

Number	What it is	Where you see it
WordPress core	The release you’re running, such as 7.1.2	Site Health → Info → WordPress, version.php
PHP	The server language version	Site Health → Info → Server
WooCommerce	The store plugin’s own release	Plugins screen, WooCommerce → Status
Database revision	An internal schema number, not a release	version.php, WP-CLI
?ver= on CSS and JS files	A cache-busting string, often a theme or plugin version	Page source

If a plugin’s requirements, a PHP upgrade or a support ticket depends on the core version, take it from the WordPress row and nowhere else.

Can you tell another site’s version from outside?

Sometimes. From outside you only have clues, and they’re often missing. There are two to try, in this order:

1. Page source. View the source of the homepage and search for generator. An unmodified site outputs <meta name="generator" content="WordPress 7.1.2" />.
2. The RSS feed. Open /feed/ and look for <generator>https://wordpress.org/?v=7.1.2</generator>.

Many sites hide both. In September 2026, SmartWP scanned the 20,000 most-visited domains. Of the 13,621 that responded, 1,203 ran WordPress, and of those, 40.7% showed the version in the generator tag, 21.1% showed it only in the RSS feed, and 38.2% showed it in neither place (SmartWP’s version study). SmartWP also offers a version-checking tool, so treat the study as a useful snapshot, not a census. Still, the lesson holds: check the feed after the page source, because many sites that hide the tag still expose the feed.

Two other clues often come up, and both are weak. readme.html no longer shows the version number in current WordPress, and many sites block it with a 403 or remove it entirely. ?ver= strings on stylesheets often belong to a theme or plugin, not to WordPress.

If nothing turns up, you’ve learned nothing. Security plugins and some themes remove these clues on purpose. A hidden version doesn’t mean the site isn’t WordPress, and it doesn’t point to any particular version. If you need the real number, you need access to the site.

What to do when your checks disagree

Almost nobody gets stuck on how to check. People get stuck when the answers don’t match. A scanner reports an old version on a site you updated last week. The host panel shows one release and Site Health shows another. Or a plugin complains that WordPress is too old when you know it isn’t.

First, confirm the version with a method that reads the installation itself: Site Health, version.php or wp core version. Then look into why the other tool disagrees. A scanner may be reading a cached page, a CDN copy or a stale clue. A host panel may need a refresh. Don’t swap files around or re-run updates because a scanner told you to.

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.

Sometimes the version is right and something else is wrong. In one resolved WordPress.org support thread, a store owner saw plugin requirements in red, as if WordPress were out of date, and core updates weren’t showing up. The WooCommerce Status report confirmed WordPress was current. The real cause was a conflict with another plugin, found by isolating plugins one at a time. That process is explained in our guide to fixing plugins that are not working.

If the check itself fails, the problem is bigger. A missing or broken version.php, or a site that returns a 500 error after an update, points to a failed core update. Restore from a backup, or reinstall the same version from a fresh download. Our guide to the WordPress white screen covers recovering a site that won’t load.

What to do once you have the number

Compare it with WordPress.org’s release archive. As of September 22, 2026, the archive listed 7.1.2, a security release, as the latest. It also said only the most recent release in the 7.1 series is safe to use and actively maintained. Don’t rely on a version number printed in an article, including this one. Check the archive on the day you check your site.

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’re behind, updating is a separate job. WordPress.org’s Updating WordPress guide covers it. In short:

• Take a backup you know you can restore, and try the update on staging if the site matters.
• Update from Dashboard → Updates.
• If WordPress asks for FTP details, the server’s file ownership isn’t set up for direct updates. Use the correct credentials or ask your host to fix the ownership. Don’t loosen permissions across the whole site.
• If a “briefly unavailable for scheduled maintenance” notice won’t go away after a failed update, delete the .maintenance file in the site root. That clears the notice but doesn’t finish the update.
• If you update by hand, never delete the existing wp-content folder. It holds your themes, plugins and uploads.
• Check the version again afterwards. Don’t assume an auto-update ran just because it’s switched on.

Agencies and freelancers taking on a client site usually record the core, PHP, plugin and theme versions at intake, with the date. That way the next mismatch has a baseline to compare against.

If you’d rather hand over the check and the updates that follow, SiteSelf handles WordPress core and plugin updates on request through chat. It tells you what’s about to change before it starts, records what it did, and reports what it checked afterwards.