Where PHP stands in 2026
PHP has an old reputation and a current reality, and they have drifted apart. The reputation comes from the early years, when the language let you write almost anything and a lot of what was written was careless. The reality is a maintained language on a yearly release cycle, with a type system, a mature framework ecosystem, and the hosting support that comes from being one of the most widely deployed ways to run a website.
On the share: W3Techs reports that PHP is used by 69.8% of all the websites whose server-side programming language it knows. Read the base carefully. It is a share of sites where a language could be detected, not of every site, and a site built entirely in JavaScript, or behind a service that hides its stack, may not be in it. It is a measure of what is deployed, which is not the same as what people choose for a new project today.
Our own measurement points the same way at a local scale. We fetched the homepage of 853 Pune business websites on 2026-10-04, and WordPress, which is written in PHP, ran 29.4% of the 647 that answered. That is a floor, since detection misses sites that hide their markers. The full breakdown, and its limits, is in our research on what Pune business websites are built on.
The version you are on matters more than the language
Most of the old complaints about PHP are complaints about old PHP, and most of the risk in running it today is running an old version. The PHP project publishes a support table, and each branch gets two years of active support and then two more of security fixes only. On the table as we read it on 4 October 2026:
| Branch | Released | Active support until | Security support until |
|---|---|---|---|
| 8.2 | 8 Dec 2022 | 31 Dec 2024 | 31 Dec 2026 |
| 8.3 | 23 Nov 2023 | 31 Dec 2025 | 31 Dec 2027 |
| 8.4 | 21 Nov 2024 | 31 Dec 2026 | 31 Dec 2028 |
| 8.5 | 20 Nov 2025 | 31 Dec 2027 | 31 Dec 2029 |
Two things follow. A site still on 8.2 has until the end of this year before it stops receiving even security fixes. And anything older than that is no longer on the table at all. If you inherit a PHP site, the first question is which branch it runs, and the answer is often the entire risk assessment.
WordPress sets its own bar. Its requirements page recommends PHP 8.3 or greater, with MariaDB 10.11 or greater or MySQL 8.0 or greater, and HTTPS support. It notes that WordPress still works on PHP 7.4 and above, and says in the same place that those versions have reached end of life and may expose a site to security vulnerabilities. Working and supported are different things.
When PHP is the right choice
- You are building on WordPress, or extending it. Themes, plugins and custom blocks are PHP, and fighting that costs more than it saves.
- The site is mostly content that an editor changes: a business site, a blog, a brochure with a news section. A mature CMS that non-developers already know is worth more than a clever stack.
- Hosting has to be cheap and boring. PHP runs on a very wide range of ordinary hosting without special setup, and for a small business that is a real advantage.
- You are maintaining an existing PHP application that works. A rewrite is a project with its own risk, and a site that serves its owners is not improved by being rebuilt in a newer language.
- Your team or your hire pool already knows it. A language people can staff is a practical argument, and for this one it is a strong one.
Notice what those have in common. None of them is about PHP being the best language in the abstract. They are about fit: the shape of the work, the tooling around it, and who will maintain it in three years.
When it is not
- The product is a web application with a lot of interactive state in the browser. You will be writing JavaScript for the front end regardless, and a second language for the server is a cost, not a benefit. Many teams in that position use one language across both.
- You need real-time features, such as live updates pushed to open pages or long-lived connections. The usual PHP model is one short request per page load, and holding connections open is possible but works against the grain. We cover that trade in our guide to real-time updates.
- The work is long-running: queues, streaming, heavy background processing. It can be done, and other runtimes are more natural for it.
- You are building something where a type-checked language shared between server and client would remove a whole class of mistakes. Modern PHP has types, but the shared-language argument is separate.
None of that is a reason to rewrite a working PHP site. It is a reason to ask the question at the start of a new project, rather than to default to whatever the last project used.
What we do, and why that is not a verdict
This site is built with Next.js and TypeScript, and the sites we build for clients usually are too, with a content system the client owns. That is a choice for the kind of work we do, not a judgement on PHP. If a client's business already runs on WordPress and it is doing the job, the right advice is usually to keep it, update it, and move it to a supported PHP version, rather than to rebuild it for our convenience.
- Find out which PHP branch the site runs on, and when that branch loses security support.
- Check the same for the CMS and every plugin it depends on.
- Decide whether the problem is the language, or the age of the install. It is usually the second.
- Only then compare a rebuild with an upgrade, on cost and on what the owner can do afterwards without a developer.
What this does not cover
- The W3Techs figure is a share of sites whose server-side language it can detect, measured by a third party with its own method. We read it on 2026-10-04 and it moves.
- The support dates are those on php.net on 2026-10-04. They are published by the project and can be revised, so check the page before relying on a date.
- The Pune figure is WordPress among homepages that answered, with detection that undercounts. It says nothing about how many of those sites run a supported PHP version, which we did not measure.
- This is a guide to fit, not a benchmark. We have not measured PHP against any other language for speed or cost, and make no claim about it.
- It is written from the viewpoint of a studio that builds in TypeScript, and says so. Weigh it with that in mind.
Sources
- Supported versions, The PHP Group. Retrieved 4 October 2026.
- WordPress requirements, WordPress.org. Retrieved 4 October 2026.
- Usage statistics of PHP as server-side programming language on websites, W3Techs. Retrieved 4 October 2026.
- Pune business websites, 647 homepages that answered out of 853 attempted. One homepage request per host, platform read from the markers the page carries. The WordPress share is of the hosts that answered and is a floor. Run: scripts/pune-stack.mjs, 2026-10-04 15:27 UTC.
Revisions
- 4 October 2026 First published, written from php.net, WordPress.org and W3Techs read on this date, and from our own Pune measurement.
This page is revised in place rather than replaced, so its address does not change.