Change a website’s PHP version through your hosting provider—not by editing a page or installing a WordPress setting—and do it only after checking compatibility, reviewing the PHP migration notes, and preparing a rollback. The safest target is a currently supported PHP branch that your application and all its dependencies support; choosing the newest number alone is not enough.
Where the PHP version is changed
PHP runs on the web server, so the version is usually controlled in your hosting dashboard or by your hosting provider. The exact location and available versions depend on the host; there is no universal control-panel path. Follow the provider’s current instructions, or ask support which PHP branch the site uses, what targets are available, and how to switch back if needed.
This process applies to PHP websites generally. WordPress is used below as a concrete example, but WordPress’s requirements do not automatically apply to other applications.
Choose a supported version your site can run
PHP supports each branch with two years of active support followed by two years of security-only support. PHP’s lifecycle table, checked October 8, 2026, lists the following end dates. Check the live PHP supported versions table before making a decision, because lifecycle dates change.
| PHP branch | Active support ends | Security support ends |
|---|---|---|
| 8.2 | December 31, 2024 | December 31, 2026 |
| 8.3 | December 31, 2025 | December 31, 2027 |
| 8.4 | December 31, 2026 | December 31, 2028 |
| 8.5 | December 31, 2027 | December 31, 2029 |
For each version your host offers, weigh its support status and end date, the compatibility of your application and dependencies, and whether your host supports that version. A currently supported branch with verified compatibility is a safer choice than simply selecting the highest number.
WordPress 7.0 is a specific case
In a 2026 clarification, the WordPress project identifies PHP 7.4 as the minimum supported version for WordPress 7.0 and PHP 8.3 as the minimum recommended version. These are WordPress project recommendations, not a guarantee that every plugin, theme, custom integration, or other PHP application works on those branches. See the WordPress 7.0 PHP compatibility clarification and check compatibility for the site’s actual components.
Check what the version change may affect
Before switching, identify the PHP version the site currently uses and check the compatibility of the whole application: its CMS or framework, themes, plugins or packages, custom code, integrations, and required PHP extensions. Core compatibility alone does not establish that add-ons will work.
Read the PHP migration guide for the exact transition. PHP documents backward-incompatible changes, deprecations, and removed extensions. If moving across more than one major version, review each intervening guide, not only the guide for the final jump. PHP says changes should be tested before switching versions in production. Start with the PHP 8.5 migration guide for a move to 8.5, then consult the corresponding migration guide for each other transition.
When your host offers staging, test the upgrade there first. Exercise the site’s essential user journeys—not just the home page—and investigate errors before applying the change to production.
Prepare a backup and rollback before switching
Back up both the site files and database using your host’s documented process. Know how to restore them, and confirm how to return to the previous PHP version before making the change. A backup is useful only if you can restore it; a host-supported version rollback may be the fastest response to a runtime regression.
Change the version and verify the live site
- Confirm the current version and target. Check the host dashboard or contact support. Select a supported branch that the application and its dependencies have been checked against.
- Review migration notes and compatibility. Read the PHP guides for every transition and check the site’s core, extensions, custom code, and required PHP extensions.
- Back up and establish rollback. Save the site files and database, and make sure you know how to restore them or revert the PHP version through the host.
- Switch through the provider’s documented method. Use the host’s control panel or support process; do not assume another provider’s button names or paths apply to your account.
- Test the site promptly. Load important public pages and try the actions that matter for this site, such as logging in, submitting forms, checking out, publishing, or running API tasks. Review application and server error logs for new failures.
- Roll back if essential behavior breaks. If the host allows it, switch back to the known-good PHP version and retest. If you cannot revert or diagnose the problem, contact the host or a qualified professional and restore the known-good state as needed.
What to do if the site breaks
First determine whether the failure began with the PHP switch and whether the host can restore the prior runtime. A broken page, failed login, missing extension, or error in a key workflow can point to an incompatibility, but the specific cause depends on the site and its logs. Avoid leaving a production site in a broken state while debugging: revert the version if possible, then investigate the failing component in staging or with professional help before trying again.
WordPress’s guidance likewise recommends reverting the PHP version or contacting the host or a professional if problems arise. See WordPress: How to update PHP for its platform-specific advice.
Recommended Free Tools
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
