How to check your WordPress version, and what to do when it is out of date

To check your WordPress version, log in and look at the bottom right of any admin screen, which reads "Version 7.1.2" or similar, or open Dashboard → Updates. Without logging in, view the page source and search for generator: a default install prints <meta name="generator" content="WordPress 7.1.2">, the same line every vulnerability scanner reads first. This guide lists every way to check the version, explains how getReport decides that a WordPress, Joomla or Drupal release is out of date, and gives an update routine that does not break the site. It belongs to our guide to what a CMS is and how to tell what a site is built with.

Quick answer

• In the dashboard: the admin footer ("Version 7.1.2"), the At a Glance widget, Dashboard → Updates, or Tools → Site Health → Info → WordPress.
• On the server: wp core version with WP-CLI, or the $wp_version line in wp-includes/version.php.
• From outside: the <meta name="generator"> tag, the <generator> line in the RSS feed at /feed/, or the ?ver= number on core stylesheets and scripts.
• Latest release: WordPress 7.1, released on 19 August 2026, with maintenance releases since. Only the newest branch is officially supported.
• Out of date? Back up, then update core, themes, plugins and PHP, in that order, checking the site between steps.
• Hiding the version is a finishing touch, not a fix.

How to check the WordPress version in the dashboard

Any of these works for a logged-in administrator:

1. Admin footer. Every wp-admin screen shows "Version x.y.z" in the bottom right. If an update is waiting, it reads "Get Version x.y.z" instead.
2. At a Glance. The Dashboard widget says "WordPress x.y.z running Theme name theme".
3. Dashboard → Updates. Shows the installed version, whether a newer one exists, and the pending plugin and theme updates.
4. Tools → Site Health → Info. The WordPress section lists the version; the Server section lists the PHP and database versions, which you will need before updating.
5. About page. The WordPress logo in the top-left corner of the toolbar → About WordPress shows the version and what changed in it.

How to check it on the server

When the admin does not load, the files tell you. Over SFTP or in the host's file manager, open wp-includes/version.php:

// wp-includes/version.php
$wp_version = '7.1.2';

With shell access and WP-CLI, one command does it, and --extra adds the database and TinyMCE versions:

wp core version --extra

wp core check-update then lists newer releases, and wp plugin list --update=available the plugins that are behind.

How to check any site's WordPress version from outside

Three places reveal the version on a default install, and all of them are public:

The readme.html file at the site root no longer states the version in current releases; it only confirms that the site runs WordPress. If none of the three shows a number, the owner has removed it, and the honest answer is "WordPress, version unknown". Our guide to telling whether a site is WordPress covers the signs that remain.

Joomla and Drupal announce themselves the same way: Joomla prints <meta name="generator" content="Joomla! - Open Source Content Management"> (the version is off by default), and Drupal 8 to 11 print <meta name="Generator" content="Drupal 11 (https://www.drupal.org)"> with the major version only, plus an X-Generator response header.

The CMS detector reads the same signals and shows the version when the page reveals one, with the evidence it matched.

Why the version matters

Most hacked sites run old code: not exotic zero-days but known holes in a plugin, theme or core release that a patch fixed months earlier. Vulnerability disclosures for WordPress plugins are published every day with the affected version range, and bots try the matching exploit on every site whose page reveals a vulnerable version, without a human involved.

Updating removes the holes; hiding the number only removes the shortcut. Plugin versions leak the same way through asset URLs (/wp-content/plugins/contact-form-7/includes/js/index.js?ver=5.7.2), and so do JavaScript libraries, as the guide to outdated JavaScript libraries shows.

Support is the second reason. WordPress.org officially supports only the newest release branch; security fixes reach older branches as a courtesy, and most plugins test only against recent versions. Joomla 3 and 4 and Drupal 7 no longer get security releases at all.

How getReport checks the CMS version

The report reads every <meta name="generator"> tag on the fetched page, in any capitalisation, and falls back to the X-Generator response header. When one names WordPress, Joomla or Drupal with a version number, the finding compares it with the newest release line in the report's own list:

• WordPress is out of date when it is two or more minor releases behind that line; one release behind passes.
• Joomla and Drupal are compared by major version, so an older major line is flagged even while it still receives security fixes. Treat that as a reminder to plan the upgrade, not an emergency.

No generator tag, or a tag without a version, and the finding does not appear; the report never guesses from other signals and never requests readme.html or admin URLs.

For WordPress sites, the WordPress health check also lists the plugins the page loads assets from, with the version from each file's ?ver= parameter, and looks every slug up in the wordpress.org directory:

A plugin that adds nothing to the front end, such as a backup plugin, is invisible to the report and to any other outside scanner.

How to update WordPress safely

1. Back up, and know how to restore

Take a full backup of files and database before any update. A host snapshot is the fastest; UpdraftPlus and similar plugins work everywhere. Restore it once on a staging copy, because a backup you have never restored is a hope, not a plan.

2. Use staging when the gap is big

One or two minor releases behind: updating live with a backup is fine. Several releases behind, a new major version, or a page builder and a shop: clone the site to staging (most hosts have a one-click copy) and run the whole routine there first. Keep staging behind a password.

3. Update in order: core, themes, plugins

1. Core: Dashboard → Updates → Update to version x.y.z. Minor releases (7.1.1 → 7.1.2) are security and bug fixes and install automatically by default; major releases (7.0 → 7.1) occasionally change how a theme or builder behaves.
2. Themes: update the parent theme. Edits made directly in its files are overwritten; that is what child themes are for.
3. Plugins: a few at a time, security and SEO plugins first, then the page builder, then the rest.

After each group, open the home page, one post or product, a form and the cart. A white screen means a PHP error: the host's error log names the plugin, and renaming its folder over SFTP deactivates it.

4. Update PHP

WordPress 7.1 needs PHP 7.4 or later, but the PHP project itself no longer supports anything older than 8.2 with security fixes. Check Site Health for warnings, switch the PHP version in the host's control panel on staging first, then production. A newer PHP version is usually also faster.

5. Turn on the auto-updates that are safe

Minor core releases have installed automatically since WordPress 3.7; leave that on. Plugins and themes have per-item auto-update links since WordPress 5.5: turn them on for plugins that release often and have never broken the site, and keep the page builder and WooCommerce manual. The same policy in code:

// wp-config.php: core: minor releases only (the default)
define('WP_AUTO_UPDATE_CORE', 'minor');

<?php
// wp-content/mu-plugins/auto-updates.php: auto-update every plugin and theme
add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');

Auto-updates run at night without anyone watching, so they need daily backups behind them.

6. Replace closed and abandoned plugins

A plugin closed on wordpress.org gets no more updates, and if the reason was a security issue, the hole is public: replace it this week. A plugin not updated in two years is not broken yet, but nothing will be fixed; find a maintained alternative and test it on staging. In both cases delete the old plugin, because a deactivated plugin's files can still be requested directly.

Hide the version, as a finishing touch

Once the site is current, you can stop printing the exact release. In a must-use plugin or a child theme's functions.php:

<?php
// wp-content/mu-plugins/hide-generator.php
remove_action('wp_head', 'wp_generator');   // the meta tag in pages
add_filter('the_generator', '__return_empty_string'); // feeds too

The ?ver= numbers on core assets still show the version to anyone who looks, so this is cosmetic: an up-to-date site with the tag is safe, and an old site without it is not. Version numbers in response headers (X-Powered-By: PHP/7.4.3) are a separate finding in the security headers checker, covered in Server and X-Powered-By headers.

Joomla and Drupal

Joomla: Joomla 6 has been the current line since October 2025. Joomla 4 reached end of life then, Joomla 3 in August 2023, and Joomla 5 gets security fixes until October 2027. Moving from 3 to a later major is a migration, best done on a copy; within a line, System → Update → Joomla applies patches. System → System Information shows the installed version.

Drupal: Drupal 11 is current. Drupal 7 support ended in January 2025, Drupal 10 reaches end of life on 9 December 2026, and Drupal 12 is scheduled for the same week. Drupal 10 sites should move to 11 now, since majors cannot be skipped. Reports → Status report shows the version; Composer sites update with composer update drupal/core-recommended --with-dependencies followed by drush updatedb.

Common mistakes

• Hiding the version and calling it done. The tag is gone, the site is still years behind, and a plugin hole gets it hacked. Update first.
• Updating without a tested backup. A white screen at 5 p.m. and no way back.
• Skipping PHP. "This plugin requires PHP 8.0" and a site stuck on old plugin versions.
• Deactivating a closed plugin instead of deleting it. The vulnerable file is still on disk.
• Editing the parent theme. Every theme update erases the changes; use a child theme.

Questions people ask

How do I check my WordPress version without logging in?

View the page source and search for "generator": a default install prints <meta name="generator" content="WordPress 7.1.2">. If that is gone, open /feed/ and look for the <generator> line, or search the source for /wp-includes/ files with a ?ver= number. If all three are hidden, only someone with admin, file or WP-CLI access can read the exact version.

What is the latest version of WordPress?

WordPress 7.1, released on 19 August 2026, is the current major release as of September 2026, with maintenance releases such as 7.1.2 since. WordPress.org officially supports only the newest branch, so update to the latest 7.1.x. The releases page on wordpress.org and Dashboard → Updates always show the current number.

Should I remove the WordPress generator tag?

It is fine to remove it once the site is up to date, and it saves bots a step. It is not a security fix: scanners read the version from asset ?ver= numbers and feeds as well, and an outdated site without the tag is still vulnerable. Update core, themes and plugins first, then remove the tag with remove_action('wp_head', 'wp_generator').

Is it safe to update WordPress to a new major version?

Usually yes, with a backup and a quick test. Major releases change the editor and APIs, so themes, page builders and shop plugins occasionally break. On a simple site, back up and update live. On a site with a builder or WooCommerce, update on a staging copy first, check the home page, a form and checkout, then repeat on production.

Which PHP version does WordPress need?

WordPress 7.1 runs on PHP 7.4 or later, but use PHP 8.2 or newer: older PHP versions no longer get security fixes from the PHP project, and newer ones are usually faster. Tools → Site Health → Info → Server shows your current version. Switch it in the host's control panel, on a staging copy first.