It means the version of PHP your host runs your site on has fallen behind. Behind what is the part the warning leaves out. It can mean you are below the version WordPress asks for, which is a recommendation and not a cutoff. It can also mean you are on a version nobody patches any more, which is the one worth acting on this week. PHP is the programming language WordPress is written in, and your site will usually keep working exactly as it did yesterday either way.
What PHP is, and who controls it
PHP is a programming language, and WordPress is written in it. WordPress.org’s own wording is that PHP is “the programming language used to build and maintain WordPress.” It runs on your host’s server, not on your customer’s phone, so nobody visiting your site ever sees it or knows it is there.
You did not install it and you cannot change it from inside WordPress. Your hosting company put it there, and your hosting company decides which versions you are allowed to pick from. WordPress.org says the same thing in its own words: “Your hosting company determines which versions of PHP are available for your site, and many hosters let you change this yourself.” That is why the warning comes from them.
WordPress.org’s Requirements page, published January 23, 2023 and last modified May 7, 2026, recommends “Version 8.3 or greater.” Read that verb. The page recommends. It does not say a lower version stops working.
What “out of date” actually means
PHP.net, the official home of the language, publishes a Supported Versions page. It sorts every version of PHP into three states, in its own words:
- Active support: “A release that is being actively supported. Reported bugs and security issues are fixed and regular point releases are made.”
- Security fixes only: “A release that is supported for critical security issues only. Releases are only made on an as-needed basis.”
- End of life: “A release that is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities.”
Only four versions sit on that table: 8.2, 8.3, 8.4 and 8.5. PHP 8.2 gets security fixes until 31 Dec 2026, 8.3 until 31 Dec 2027, 8.4 until 31 Dec 2028 and 8.5 until 31 Dec 2029. That page carries no update date.
Everything older sits on PHP.net’s End of Life page instead. PHP 8.1 ended 31 Dec 2025. PHP 8.0 ended 26 Nov 2023. PHP 7.4 ended 28 Nov 2022. That page carries no update date.
So the warning has two readings, and they are not the same size of problem. On 8.2 you are under what WordPress recommends and still on a version PHP patches. On 7.4, nothing in it has been patched since November 2022, and nothing in it ever will be again.
How to find the version your site is on
Log into WordPress and go to Tools, then Site Health, then the Info tab. That is the path given in WordPress.org’s Site Health screen documentation, published June 18, 2021 and last modified July 12, 2026. Open the Server section. The line you want is labeled PHP version.
The Status tab on that same screen is worth a look while you are there. The documentation lists “Your site is running an outdated version of PHP, which requires an update” among the critical issues it can raise, filed under the type Security. WordPress is telling you the same thing your host did, in the same admin area you already log into.
Here is a number you can go and check for yourself. WordPress.org publishes the spread of PHP versions across all the sites that report in, at api.wordpress.org/stats/php/1.0/. When that was read for this article, 17.518% of sites were still on PHP 7.4 and 11.748% were on 8.1. Add up every version below 8.2 and it comes to 39.5%. Roughly four sites in ten are running PHP that nobody patches.
That figure moves. That page carries no update date, so go and read it yourself rather than trusting this copy of it.
What this does and does not put at risk
Old PHP does not mean your site is broken today. It usually means the site works fine and is quietly unpatched. What changes is exposure, not certainty. Nobody can tell you your site will be broken into, and anyone who tells you it definitely will is selling you something. Unpatched software is one door of several, and the failed logins piling up in your logs are the door most owners actually see.
Be careful with the speed claim, too. WordPress.org’s own update page, published February 8, 2018 and last modified July 29, 2026, says your website “may be faster” on a newer version, and in the very next line that it “will be more secure.” The two claims carry different verbs. The Site Health documentation hedges the same way, saying “you may see a positive effect on your site’s performance.”
Read those verbs literally. Security support is a published fact with dates on it. A speed gain is a maybe, and a page load has a lot of other things in it, which is a separate question covered in why an old site gets slower every year. Move PHP for the security dates. Treat anything else as a bonus that may not show up.
What to do next
Often the whole job is one dropdown in your host’s control panel. If yours does not offer one, it is a support ticket asking them to move you, and a host that still says no is a reason to look at changing hosts.
WordPress.org’s update page lists four things to do before the version changes, in this order:
- Make a backup of your website. A backup nobody has ever restored is a guess, not a safety net.
- Update WordPress, your themes and your plugins from the Updates screen.
- Check PHP compatibility. The page points at the PHP Compatibility Checker plugin for this.
- Fix what it flags, which usually means asking the theme or plugin author to look at it.
Then the change itself:
- Look up the version you are on. Tools, Site Health, Info, Server.
- Compare it to the PHP.net table and note whether your branch appears there at all.
- Move up one version at a time rather than jumping from 7.4 to 8.4 in one go.
- After each move, load your site, submit your own contact form, and click through a few pages.
- If something looks wrong, switch the version back in the same panel, then work out which plugin objected.
WordPress.org does not promise this is painless, either. Its own page says the update should not be a problem, and then says plainly that it cannot rule out trouble with your themes or plugins.
That is where these updates go sideways. Code written for PHP 7 can simply stop running on PHP 8, and a plugin nobody has touched in years is the one that finds out first. That is the reason for the backup step, not pessimism. If the site comes back blank after a version change, a white screen has its own set of steps.
If your host offers a current version in a dropdown and your plugins are up to date, this is a short job you can do yourself with nothing to buy. Do that, and skip the rest of this.
The harder case is a site where every step up breaks something old that has no maintainer left. A site built without PHP has no PHP version to keep current, since its pages are finished before anyone visits. That is how the sites built here work. That is not a reason to replace a site that is doing its job. It is only worth raising if you are already stuck on a version nobody patches, held there by plugins nobody maintains.