3 Ways to Check Your WordPress PHP Version

Two in five WordPress sites are running a version of PHP that no longer receives security fixes. Not an old version, an unsupported one, where a vulnerability found tomorrow never gets patched. Checking which side of that line you are on takes about thirty seconds and needs nothing but your dashboard.

The thirty second version

Log in and go to Tools, then Site Health, then the Info tab, and expand Server. The line marked PHP version is your answer.

If it starts with 8.3, 8.4 or 8.5, you are fine and the rest of this is background. If it starts with anything else, keep reading, because the number matters more than most people are told.

What the number actually tells you

PHP versions are retired on a published schedule rather than when they stop working. Every release gets roughly two years of active support, where bugs and security holes are both fixed, then a further year of security fixes only, and then nothing at all.

"Nothing at all" is the part that gets glossed over. An end of life version keeps running perfectly well. Your site does not break, no warning appears, and nothing visibly changes. What changes is that when somebody finds a flaw in the language your site is written in, it is never fixed on your server.

Here is where every version stands today, from the official PHP release calendar.

WordPress recommends PHP 8.3 or greater. It will still run on 7.4, and it says so plainly, along with the warning that doing so may expose your site to security vulnerabilities.

Reading the three numbers

A version like 8.4.11 has three parts, and only the first two decide whether you are supported.

• 8 is the major version. Changes here can break plugins and themes, because functions get removed.
• 4 is the minor version. New features, occasional deprecations, rarely anything that breaks a well maintained plugin.
• 11 is the patch. Security and bug fixes only, and this is the number that stops increasing when a version reaches end of life.

The support calendar is set by the first two numbers together. PHP 8.1 is dead; PHP 8.4 is current. They are not "both PHP 8" in any way that matters.

How bad is it really?

Bad enough to be worth thirty seconds. WordPress publishes what its own installs are running, and the picture is not encouraging.

Add up everything unsupported and it comes to 38.8% of all WordPress sites. The single most common version on the entire platform after 8.3 and 8.2 is PHP 7.4, which stopped receiving fixes in November 2022.

Then there is the part worth diarising. PHP 8.2 accounts for another 24.8%, and its security support ends on 31 December 2026. Nothing happens on the day, no site goes down, and the share of WordPress running unpatched PHP quietly goes from around two in five to nearly two in three.

That 1.4% still on PHP 5.6 is the one that stays with you. That version was released in 2014.

Three ways to check

Use the first one you have access to. They do not all answer quite the same question, which matters more than it sounds.

1. Site Health, if you can log in

Covered above, and it is the one to prefer. Go to Tools, Site Health, Info, Server.

The reason to prefer it is not convenience. Site Health reports the PHP that is actually serving your pages, which is the number you care about. The other methods can quietly tell you about a different PHP on the same machine.

2. Your hosting control panel

Every host exposes this somewhere, usually under a heading like Select PHP Version, MultiPHP Manager or PHP Settings. In cPanel it is in the Software section.

This is the place you will need anyway when you come to change it, so it is worth finding even if you already know the answer.

3. The command line, if you have SSH

One command:

php -v

Read the result with care. This reports the PHP command line binary, which on shared hosting is very often a different version from the one running your website. Seeing 8.4 here does not mean your pages are served by 8.4.

If you have WP-CLI, this asks WordPress itself, though it still runs under the command line PHP:

wp eval 'echo PHP_VERSION;'

To get the version your visitors are actually served, ask the server over HTTP instead. Many hosts return it in a response header:

curl -sI https://example.com | grep -i x-powered-by

Plenty of hosts strip that header, quite reasonably, since advertising your PHP version to the internet helps nobody but an attacker. If it comes back empty, go back to Site Health.

The last resort, and why to avoid it

Most guides suggest uploading a file containing <?php phpinfo(); ?> and visiting it in a browser. It works, and it is the wrong habit.

That page publishes your full server configuration to anybody who guesses the filename: absolute paths, loaded modules, environment variables, and often database details. Guessing is not hard, because everybody uses info.php or phpinfo.php. Automated scanners check for exactly those names.

If you genuinely have no other route, give the file a name nobody will guess, and delete it the moment you have your answer rather than at the end of the day. Better still, ask your host, who will tell you in one reply.

Upgrading without breaking the site

Changing PHP version is a dropdown in your hosting panel and takes effect immediately. The work is entirely in what you do before you touch it.

The failure mode is specific and worth naming, because it is the one that catches people. An old plugin or a hand built theme calls a function that the newer PHP removed, and you get a fatal error rather than a warning. The site goes white. Our guide to what to do when an update breaks a site covers the recovery in detail, and the short version is that reverting the PHP version puts it straight back.

In order:

1. Take a backup you have actually tested. Not the one your host says exists. Our guide to backups covers the difference.
2. Update everything first. Most compatibility problems are already fixed in the current release of the plugin. Doing this alone resolves the majority of them.
3. Deal with anything abandoned. A plugin with no update in three years is the likeliest thing to break, and the least likely to be fixed afterwards. Find a replacement before the upgrade, not during.
4. Use staging if you have it. Most decent hosts include it. Switch the PHP version there, click through the site, and pay attention to checkout, forms and anything with a payment gateway.
5. Go one minor version at a time. From 7.4, go to 8.0, then 8.1, and upwards. Jumping straight to 8.4 works often enough, and when it does not you have no idea which step caused it.
6. Turn on the error log before you switch, not after. Add these to wp-config.php and you get a written record instead of a guess.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Errors go to wp-content/debug.log and are not shown to visitors, which is the combination you want on a live site. WordPress's debugging documentation covers the rest. Turn all three off when you are done, because a debug log left running will fill the disk eventually.

Worth saying plainly: the old PHP Compatibility Checker plugin is still widely recommended and has not been updated in years. It does not know about the syntax of any recent PHP release, so a clean report from it means very little now.

Whose job is this?

PHP runs on the server, so your host controls which versions are available. You choose from that list. Neither WordPress nor any plugin can change it, which is why there is no PHP update button in your dashboard.

What varies enormously is how much the host does for you.

If your panel simply has no option above 8.1, that is the answer to a different question, and it is the one worth acting on.

What to do this week

Check the number. If it begins 8.3, 8.4 or 8.5, put a reminder in the calendar for a year from now and get on with your day.

If it begins 8.2, you have until 31 December 2026, which sounds like plenty and is roughly one quiet afternoon between now and then.

If it begins with 7, or with 8.0 or 8.1, you are running unpatched software today. Update your plugins, take a backup, and move up a version. It is usually a ten minute job, and the reason it does not get done is almost never difficulty.

Frequently asked questions