Which PHP Version Should Your WordPress Site Run in 2026?

17 August 2026 · 3 min read · by Osama Jamal

PHP is the layer almost nobody thinks about until something breaks. It is also the single cheapest performance and security improvement available to most WordPress sites, and a meaningful share of the web is running a version that no longer receives patches.

Here is the current picture, what to target, and how to move without taking the site down.

Where each version stands

• PHP 8.1 and below. End of life. PHP 8.1 stopped receiving patches on 31 December 2025. Anything older stopped years ago. If you are here, this is urgent rather than a maintenance item.
• PHP 8.2. Security patches only, ending 31 December 2026. It works, but you have months rather than years, and you will be doing this again before the year is out.
• PHP 8.3. Security supported to the end of 2027. A reasonable holding position with excellent plugin compatibility.
• PHP 8.4. Supported to the end of 2028. Broad ecosystem track record by now. This is the target for most sites.
• PHP 8.5. Released November 2025, supported into 2029. Stable, and the major plugins including WooCommerce and Elementor run on it. Worth taking if you have verified every dependency.

The short answer for a normal business site: PHP 8.4. It is old enough that plugin authors have caught up and new enough that you are not repeating this exercise next year.

Why end of life PHP is a real risk, not a theoretical one

As of early 2026, roughly 55 percent of the top one million PHP sites were still running an end of life version. That is not a niche problem, and attackers know it.

The attack pattern is mechanical. Automated scanners read server fingerprints and response headers that reveal the PHP version, build a list of sites on unpatched versions, then probe that list against known exploits. Nobody is choosing your site specifically. You are on a list because your server announced itself. Most of the cleanup work described in our hacked site process starts with exactly this kind of unattended entry point.

How to check what you are on

In WordPress admin: Tools, then Site Health, then Info, then Server. The PHP version is listed there. It takes fifteen seconds and works on any WordPress site from 5.2 onwards without installing anything.

Your hosting control panel will also show it, usually under a PHP version selector. On most cPanel and managed WordPress hosts, changing the version there is a dropdown and a save, with no downtime.

The upgrade risk is never WordPress core

WordPress core is written to be conservative about PHP versions and handles upgrades cleanly. WordPress 7.0 confirmed compatibility with PHP 8.4 and added support for 8.5, while keeping the minimum floor low for compatibility reasons. That floor is a floor, not a recommendation. We covered what else changed in WordPress 7.0.

The risk sits in three places:

1. Abandoned plugins. The most common failure. A plugin last updated four years ago using a function that PHP removed.
2. Old themes. Particularly heavily customised commercial themes that were never updated after launch.
3. Custom code. The functions.php additions and snippets that accumulated over the years, usually undocumented.

How to upgrade without a bad afternoon

1. Update everything first. Plugins, theme, WordPress core. Most compatibility issues are already fixed upstream and you are just behind.
2. Inventory the dead weight. Any plugin not updated in over two years is a candidate for replacement or removal before you touch PHP.
3. Clone to staging. Every serious host offers this now. If yours does not, that is its own conversation.
4. Switch PHP on staging and turn on debug logging. Set WordPress to log errors to a file rather than displaying them, then click through the site properly: the checkout, the forms, the admin screens, the pages a client actually uses.
5. Read the log, not the homepage. Fatal errors are obvious. Deprecation warnings are the ones that tell you what breaks in the version after this one.
6. Fix, replace, then repeat. Then apply to live at a quiet hour with a backup in place.

One warning. The old PHP Compatibility Checker plugin that people still recommend is abandoned and only checks up to PHP 8.0. Ignore it. Staging plus a debug log catches far more real world problems than a static scanner ever did.

If you do nothing

Your host decides for you. Managed platforms have been force migrating sites off end of life PHP throughout 2026, typically with warning emails and then a hard cutoff. When that happens, a lot of sites jump two or three versions at once, and the failures surface all together on a day nobody planned for.

Choosing the date yourself costs an hour on staging. Having it chosen for you costs an emergency.