Before You Touch the PHP Setting
You update PHP for a WordPress site in your hosting account, not inside WordPress: find the PHP version menu in your host's control panel, pick a newer version, and save. The setting takes seconds. What decides whether the site survives is the work around it, which is knowing your current version, checking that every plugin and theme supports the new one, testing on a copy, and having a way back.
This is for the owner of a WordPress site who has seen a notice about an outdated PHP version, or whose host has announced that an old version is being retired. If a developer built the site and you have never opened the hosting account, the first section still applies to you.
Find Out Which PHP Version You Run Today
Open the WordPress dashboard and go to Tools, then Site Health, then the Info tab. Expand the Server section and read the line labeled PHP version. WordPress's own guide to updating PHP uses the same route. That number is what the web server uses to load your pages, and it is the one that matters.
It is not always the number you will see elsewhere. Command-line PHP on a server can be a different version from the one serving your site, which is why a developer's terminal may say 8.1 while Site Health says 7.4. Trust Site Health for the website itself.
Write the number down, along with the date. If something goes wrong later, "the site ran on 8.1 until Tuesday" is the sentence that gets you back to a working state fastest.
Pick a Target That Is Supported, Not Merely Newer
Every PHP branch gets two years of active support, then two years of security fixes only, then nothing. The PHP supported versions page shows the current calendar. As of October 2026 it lists 8.2 through 8.5, with these dates:
- PHP 8.2 gets security fixes until 31 December 2026.
- PHP 8.3 gets security fixes until 31 December 2027.
- PHP 8.4 is in active support until 31 December 2026, with security fixes until 31 December 2028.
- PHP 8.5 is in active support until 31 December 2027, with security fixes until 31 December 2029.
The end-of-life table shows that 8.1 ended on 31 December 2025, 8.0 on 26 November 2023, and 7.4 on 28 November 2022. A site on any of those no longer receives security patches from the PHP project.
WordPress itself currently recommends PHP 8.3 or greater on its requirements page, and says it still works with 7.4 and up in legacy environments, with a warning that those versions are past end of life. So 8.3 is the sensible target for a site that has to be updated this month: recent enough to be supported for another year, and mature enough that plugin authors have had time to catch up. Move to 8.4 or 8.5 when your plugins say they are ready, not when the calendar says they exist.
Check That Your WordPress Version Can Run It
The WordPress core team keeps a compatibility table of WordPress versions against PHP versions. At the time of writing it shows WordPress 6.9 and later working with PHP 8.0 through 8.5. It shows 6.8 and 6.7 working through 8.4 but not 8.5, and 6.6 and older working through 8.3 but not 8.4.
That matters because the order of operations is forced on you. If you are on an old WordPress release and want PHP 8.4, you update WordPress first, then PHP. A site that skips this check ends up with core files that break on the new PHP, and then you cannot even reach the dashboard to fix it.
Look at Every Plugin and Theme for Two Fields
Plugins and themes from WordPress.org list a Requires PHP version and a Tested up to version on their directory pages. Neither is a guarantee, but they are the author's own statement. Go through your plugin list and flag anything that has not been updated in over a year, or whose listed PHP requirement is lower than your target and whose last release predates it.
Premium plugins are the usual trouble. A paid plugin whose license lapsed stops delivering updates, so the version on your site may be years behind the one that supports modern PHP. Renewing or replacing it comes before the PHP change, not after. If tracking that is a chore, our premium plugin license management keeps keys and renewal dates in one place.
WordPress's guide also mentions the PHP Compatibility Checker plugin, and says plainly that it is not perfect and can miss problems or flag false ones. Use it as a first pass over your code, then let a real test on a copy of the site make the call.
Make a Backup You Have Seen Restore
WordPress's guide says a backup lets you return the site to how it is right now. Reverting also needs your host to move PHP back, so the backup and the version switch are two separate undo steps. Take a fresh backup of both the database and the files immediately before you change anything, and confirm it landed somewhere other than the server itself. Our WordPress maintenance checklist goes into what a backup should contain and how to prove it restores.
Making the Change and Recovering If It Goes Wrong
The safe pattern has four moves: copy the site to a staging area, switch the PHP version on the copy, click through everything that earns you money, and only then switch production. It takes an afternoon the first time. A broken live site takes longer.
Test on a Staging Copy First
A staging site is a private duplicate of your website on the same host, usually created from a button in the hosting dashboard. Many managed hosts include one. Set the copy to the new PHP version, not your live site, and leave the live site on the old one while you work.
Then use the copy the way a customer would. Load the home page and the busiest inner pages. Submit the contact form and check the message arrives. If you sell anything, add an item to the cart and get as far as the payment step. Log in as an editor and publish a draft. Log into the admin and open the plugin screens you rely on. Those are the places that fail first, because they run the most custom code.
Turn on the Error Log While You Test
Plugins that are not ready for a newer PHP version rarely announce it. Often the page loads and something small is wrong. Ask WordPress to write problems to a file instead of printing them to visitors. In wp-config.php, the WordPress debugging documentation describes three constants: WP_DEBUG set to true, WP_DEBUG_LOG set to true so messages go to wp-content/debug.log, and WP_DEBUG_DISPLAY set to false so nothing appears on the page itself.
Do this on the staging copy only. When you finish testing, open debug.log and read it. Two kinds of lines matter. A line starting with "Deprecated" means code still works but uses something the new PHP plans to remove. A line starting with "Fatal error" means a page stopped. Note the file path in each line, because it names the plugin or theme at fault.
Know the Two Warnings You Will Probably See
Most upgrade noise from older code falls into two families. Both are described in the PHP manual, so you can search for them by name.
The first arrives with PHP 8.2. According to the PHP 8.2 deprecations page, creating dynamic properties is deprecated, which means code that assigns a value to an object property its class never declared now triggers a notice. Plugins that were written loosely can produce hundreds of these. The fix belongs to the plugin author: declare the property.
The second arrives with PHP 8.4. The PHP 8.4 deprecations page says implicitly nullable parameter types are deprecated. A function written as function foo(T1 $a = null) should be written function foo(?T1 $a = null). Again, a notice, not a crash, but a sign the code has not been touched in a while.
Deprecation notices do not break the site today. They tell you the plugin will break on a later version. A fatal error is different, because it stops the page. Treat the first as a to-do list and the second as a blocker.
Where the Setting Lives at Your Host
Hosts put the switch in different places, but it is nearly always labeled PHP, PHP Version, or PHP Manager. On cPanel hosting, the tool is MultiPHP Manager. The cPanel documentation walks through it: tick the domain, choose a version from the PHP Version menu, and click Apply. If the menu is missing the version you want, it is not installed on that server or not available to your account, and only the host can add it.
One cPanel detail to watch is the Inherit choice, which uses the server default. The documentation says that with Inherit selected, the system will not allow you to set PHP-FPM. If you are changing the version for speed as well as safety, pick a specific version.
On managed WordPress hosts, the option is usually in a per-site Tools or Settings area. If you cannot find it, the WordPress guide suggests emailing the host, and a short message works: name the domain, the current version, and the target. When the setting is hidden, ask for the change rather than hunting for it.
Switch Production, Then Watch It
When the staging copy comes through clean, pick a quiet hour, take one more backup, and change the live site to the same version. Ask for the first look from someone who did not do the switch, because the person who made the change tends to click the pages they already tested.
Over the next day, check the error log again, check that scheduled tasks still run, and test the forms once more. Scheduled posts and backups depend on a working cron, and a plugin that fails quietly in the background will not show on any page you load. Our guide to missed scheduled posts covers that failure.
Roll Back Fast When a Page Breaks
The way back is the same menu. Set the PHP version back to the number you wrote down, save, and reload. The WordPress guide says to change the version back, contact your host or a developer, or ask the host to restore the previous version and then restore your backup. A white screen right after the change is nearly always an incompatible plugin, and fixing the white screen of death shows how to find which one.
Once the site is back, go to the plugin named in the log, not to the host. Update it, replace it, or ask its author for a release that supports your target version. Then try again on staging.
When the Upgrade Is Worth Handing Off
Moving PHP is a routine job done a few times a year, rarely often enough to feel routine. If the site takes payments, collects leads, or has more than a handful of plugins, the cost of a mistake is higher than the cost of having someone else do it. Managed PHP upgrades are part of our WordPress maintenance service, so a version change is planned and tested instead of arriving as a surprise on the day a host retires it. If you are also unsure the host is a good fit, our WordPress hosting includes staging, and the slow site causes guide explains how an old PHP version caps everything above it.
