Is your website on a supported PHP version? A 2026 guide for business owners

Quick answer: PHP is the programming language behind most websites, and each PHP version only gets security fixes for a few years before it reaches “end of life” and the fixes stop. Running an end-of-life version doesn’t break your site — it keeps working — but it quietly stops receiving security patches, so known holes stay open. As of 2026, PHP 8.1 and older are already end of life, PHP 8.2 ends on 31 December 2026, and the safe target for most sites is 8.3 or 8.4. If you don’t know what your site runs, that’s the first thing worth finding out.

Software that runs a business website usually doesn’t announce when it’s getting risky. It just keeps loading pages. That’s what makes PHP versions a blind spot: a site on a four-year-old, unpatched version looks and feels identical to one that’s fully up to date — right up until the day it doesn’t.

This guide is the plain-English version of what we’d tell a client who asked, “Should I be worried about my PHP version?”

What PHP is, in one paragraph

PHP is a programming language that runs on the web server and builds your pages when someone visits. WordPress, WooCommerce, Laravel apps and a large share of business websites are written in it. When you hear “the site runs PHP 8.2,” it means the server uses version 8.2 of that language to run your website’s code. Newer versions are faster and more secure; older ones gradually stop being maintained.

Who is actually responsible for patching it?

This trips up a lot of owners, because the answer depends on your setup:

• Managed hosting (many WordPress-specialist hosts): the host usually keeps the PHP version patched and current. Your job is to confirm they do, and that you’re on a version they still support.
• cPanel / shared hosting: you often choose the PHP version yourself in the hosting panel. That means the responsibility to pick a supported version is yours, even though the host provides the options.
• Your own server or VPS, or a custom app: you, or your developer, own it entirely. Nothing updates unless someone does it.

If you’ve never been told which of these you’re on, that uncertainty is itself the risk — it usually means nobody has explicitly owned the job.

The 2026 PHP support timeline

PHP publishes exactly when each version stops receiving fixes. Here’s where things stand, straight from PHP’s end-of-life and supported versions pages:

PHP version	Status as of 2026	What it means
7.4	End of life since 28 Nov 2022	No fixes from PHP for nearly four years
8.0	End of life since 26 Nov 2023	No fixes from PHP
8.1	End of life since 31 Dec 2025	No fixes from PHP
8.2	Security fixes only, until 31 Dec 2026	Patched for now; ends soon
8.3	Security fixes until 31 Dec 2027	Supported
8.4	Active until 31 Dec 2026, security until 31 Dec 2028	Supported
8.5	Active until 31 Dec 2027, security until 31 Dec 2029	Newest; supported longest

When a version reaches end of life, the PHP project stops releasing security fixes for it. (Your Linux distribution or hosting vendor may backport some fixes for a while, but that’s a safety net, not a plan.) The practical takeaway for 2026: 8.1 and older are already unsupported, and 8.2 is on the clock — we’ve covered what the 31 December 2026 deadline means in detail.

“But it still works” isn’t “it’s safe”

This is the single most common misunderstanding. An end-of-life PHP version runs your site exactly as it always did. Nothing visibly changes on the day support ends. What changes is invisible: when a new vulnerability is discovered — as two critical ones were in October 2026 — supported versions get a patch and unsupported ones don’t. The hole just stays open.

So “it still works” and “it’s still safe” are two different claims. A site can be fully functional and quietly exposed at the same time.

This is more common than you’d think

If you’re on an old version, you’re in a lot of company — which is reassuring socially and alarming security-wise.

W3Techs data (read October 2026) suggests about half of all PHP sites run a version PHP no longer patches. The working: roughly 27% of PHP sites are still on PHP 7, about 8% on PHP 5, and within PHP 8 another ~6% are on 8.0 and ~15% on 8.1 — both end of life. Add those up and you’re near half. (These are global estimates, not a precise count of your corner of the web, but the shape is clear.)

For WordPress specifically, WordPress.org’s own stats show a large share of sites still on 8.1 or older, with another big block on 8.2 — which means a substantial portion of WordPress sites will be on unsupported PHP after 31 December 2026 unless they move. WordPress itself now recommends PHP 8.3 or greater, and WooCommerce recommends the same, both warning that older versions “have reached their official End Of Life and may expose your site to security vulnerabilities.”

What upgrading PHP actually involves

For most sites it’s less dramatic than it sounds, but it’s not always a one-click toggle either. In short:

1. Find your current version — see how to check which PHP version your website runs.
2. Update the software on top first. Out-of-date plugins, themes or framework versions are the usual reason an upgrade breaks something.
3. Test on a copy, not live. Switch PHP on a staging copy, then check the things that matter — checkout, forms, logins — before you touch the real site. We’ve written up how to upgrade PHP on WordPress or WooCommerce without breaking it.
4. Have a rollback ready. If something does go wrong, you want to be able to step back calmly — see recovering from the “critical error” message.

Custom applications are their own case. A Laravel app, for example, ties its supported PHP versions to the framework version, so upgrading PHP can mean upgrading the framework too. And occasionally an old site is far enough behind that it’s worth weighing an upgrade against a rebuild — a decision we’ve set out a framework for in when to rewrite versus refactor legacy software.

How to not be caught out

Three habits cover most of it:

• Know your version and your deadline. If you’re on 8.2, your date is 31 December 2026. If you’re already on 8.1 or older, your date was in the past.
• Know who’s responsible. Host, you, or your developer — pick one, in writing.
• Treat upkeep as ongoing, not a one-off. PHP versions age out every year or two. Whoever looks after your site should be tracking this, not reacting to it. (If you’re choosing a provider, our notes on red flags when hiring a development agency are a useful filter.)

If you’d like someone to work out what your site runs, when it ages out, and what the upgrade would involve, that’s squarely part of what we do under web development. Start a project or get in touch and we’ll give you a straight answer, including “you’re fine, leave it” if that’s the truth.

Common questions

Which PHP version should I be using in 2026? For most WordPress and WooCommerce sites, PHP 8.3 is the current recommendation, with 8.4 a good choice too. The key rule is simpler than the version number: be on something PHP still supports, and move off 8.2 before 31 December 2026.

Is PHP 7.4 still safe to use? No. PHP 7.4 reached end of life in November 2022 and hasn’t received security fixes from the PHP project since. It may still run your site, but any vulnerability found since then stays unpatched unless your host has specifically backported a fix.

Will upgrading PHP break my website? It can, mainly when old plugins, themes or custom code rely on behaviour that newer PHP removed or tightened. That’s why the upgrade is done on a staging copy and tested before going live, with a rollback ready. Done properly, most sites upgrade without visible impact — and often get a speed improvement.

Who is responsible for keeping my PHP version up to date? It depends on your hosting. On managed hosting the host usually handles it; on cPanel or shared hosting you typically choose the version; on your own server or a custom app, you or your developer own it entirely. If no one has clearly owned the job, that’s worth fixing.