Update PHP Version WordPress: Here’s How to Do It Without Breaking Your Site

You probably searched for update PHP version WordPress because WordPress, a plugin, or your host has started making noise about an old PHP version. The warning feels simple: update PHP. The anxiety behind it is less simple: one wrong click in hosting settings can take down a site that was working five minutes ago.

Here is the direct answer: you update PHP for WordPress from your hosting control panel or server, not from the WordPress dashboard. WordPress can show you the PHP version. Your host controls the switch.

TL;DR: To update PHP version WordPress safely, check your current PHP version in Site Health, make a full backup, test the change on staging, and then switch PHP in your hosting control panel. Use PHP 8.3 or higher when your WordPress version, plugins, theme, and host support it; if the site breaks, roll PHP back first and troubleshoot the incompatible plugin, theme, custom code, or server setting.

The PHP selector is usually the easy part. The real work is proving that your theme, plugins, checkout, forms, custom snippets, and server settings can live on the new version.

Start here: the safe PHP update path

If you only need the order of operations, use this:

That order matters. Do not test a server-level change on production just because the button is easy to find. If you manage many sites, WP Remote’s Safe Updates approach is a useful model for matching update risk to the right level of testing.

🛠️ Note: Treat PHP like the floor your WordPress site stands on. WordPress core, plugins, themes, and custom code all run on it. If one old plugin cannot stand on the new floor, the problem may look like “PHP broke my site,” but the real issue is usually incompatible code.

What PHP does in WordPress

PHP is the server-side language WordPress runs on. When someone visits a page, PHP helps WordPress load content, run plugins and themes, talk to the database, and build the HTML the visitor sees.

That means a PHP update can affect more than WordPress core. It can touch a form plugin, WooCommerce extension, page builder module, child theme, mu-plugin, old shortcode, or private plugin written years ago.

WordPress is the dashboard light. Hosting is the engine bay. Site Health can tell you what version is running, but the host panel is where the change usually happens.

Do not use phpMyAdmin for this. phpMyAdmin is for managing the database. It does not tell you which PHP version your WordPress site is running.

Which PHP version should WordPress use?

For most maintained WordPress sites, target PHP 8.3 or higher. WordPress.org recommends PHP 8.3 or greater, and older PHP versions should not be treated as a good long-term choice just because the site still loads.

As of June 2026, use this as the practical version map:

PHP version	Status in June 2026	Practical choice
PHP 8.5	Active support	Good for clean, current stacks after staging tests pass.
PHP 8.4	Active support	Strong target for maintained WordPress sites.
PHP 8.3	Security fixes only	Safe baseline for many sites.
PHP 8.2	Security fixes only	Short-term option if 8.3+ is not ready.
PHP 8.1 or older	End of life or poor long-term target	Avoid except as a temporary rollback.

The important distinction is compatibility versus security support. A WordPress version may still run on older PHP, but that does not make the older PHP branch a smart maintenance target.

Do not chase the newest number blindly either. A modern site with maintained plugins may move cleanly to PHP 8.4 or 8.5. A fragile old site with abandoned premium plugins may need PHP 8.3 first while you replace old code.

🧭 Note: If your host offers PHP 8.5 but your staging site throws deprecation warnings everywhere, PHP 8.3 may be the better production target today. The best PHP version is the newest supported version your actual site stack has proved it can run.

Check your current PHP version

Start inside WordPress. You want to know what PHP version WordPress is actually using, not what one hosting screen appears to say.

In WordPress admin:

1. Go to Tools > Site Health.
2. Open the Info tab.
3. Expand Server.
4. Look for PHP version.

If you run WooCommerce, you can also check WooCommerce > Status for server details.

We verified the Site Health path on a WordPress 6.9.4 test site running PHP 8.4. The labels can shift slightly across WordPress versions, but Site Health is still the right first check.

If Site Health and your host dashboard disagree, trust Site Health for what WordPress is seeing. Ask your host to check the domain, environment, account mapping, and PHP handler.

🔎 Note: A mismatch often means the wrong domain, subdomain, staging environment, or PHP handler was changed. This is common on accounts with add-on domains or separate production and staging containers.

Prepare before changing PHP

This is the section that prevents a five-minute hosting task from becoming an afternoon of recovery work. Before you update PHP, do these checks:

For a small brochure site with a current theme and a few maintained plugins, this may be quick. For WooCommerce, memberships, learning sites, multilingual builds, or custom checkout flows, slow down.

The cost of testing is lower than the cost of finding out during a sale that checkout cannot load. The installed plugins screen is a useful inventory point before you test a new PHP version.

🧯 Note: Rollback is not a maintenance strategy. It is an emergency exit. If you roll back because a plugin fails on modern PHP, plan the fix while the site is stable instead of letting the same plugin trap you later.

Test the PHP update on staging

Staging is where you want ugly surprises to happen. A broken staging site is a useful diagnosis. A broken live store is a business problem.

After you create a WordPress staging site, change PHP only on the staging environment, and then test the parts of the site that make the site useful:

Then check logs. Fatal errors need immediate attention. Repeated warnings deserve investigation. Deprecation notices may not break the site today, but they are a sign that a future PHP jump may be harder.

Do not approve the test because the homepage loads. The homepage can look perfect while checkout, form email, payment callbacks, or scheduled jobs fail quietly.

Staging is mainly for compatibility testing. It may not match production speed because caching, CDN settings, OPcache, and traffic are often different.

🧪 Note: For WooCommerce, place a test order if your staging setup allows it. A PHP update that breaks the payment gateway callback is much worse than one that makes an admin notice look strange.

Update PHP in your hosting control panel

Once staging passes, make the same PHP change in production. The exact labels vary by host, but the pattern is usually the same: choose the site, open PHP settings, select the tested version, save, and wait for the change to apply.

Hosting setup	Where to look
cPanel	MultiPHP Manager or Select PHP Version
Plesk	Websites & Domains > PHP Settings
Managed WordPress hosting	Site tools, environment settings, or PHP version selector
GoDaddy managed WordPress	Product/site settings, production site PHP version
VPS or dedicated server	Server panel, package manager, container config, or administrator workflow
Windows/IIS hosting	IIS/PHP Manager or host support

Before saving, confirm three things:

Do not change PHP, caching rules, CDN settings, plugins, and theme files in the same maintenance window unless your host requires it. If something breaks, you want one obvious change to investigate.

If you cannot find the PHP setting, send your host this:

I need to update the PHP version for my WordPress site: [your domain].

WordPress Site Health currently shows PHP [current version]. Please move the site to PHP 8.3 or higher if my hosting plan and site configuration support it.

Before making the change, please confirm:
- which PHP versions are available for this site
- whether I can roll back to the current version if something breaks
- whether the change applies only to this WordPress site or domain
- whether any required PHP extensions or server settings will change

If PHP 8.3+ is not available, please tell me the newest supported version and the safest upgrade path.

That message asks for the two details that prevent most confusion: scope and rollback.

Verify the update worked

Do not stop after clicking save. Confirm that WordPress sees the new PHP version and that the site still works. After the host change:

Some problems appear only after a scheduled task, payment callback, email job, or traffic spike. Write down what changed and when. If something odd appears later, that note saves you from guessing through the hosting panel.

📌 Note: If you create a temporary phpinfo file to confirm server settings, delete it immediately after use. It can expose server configuration details that should not sit publicly on your site.

What to do if the site breaks

If your WordPress site is down after the PHP update, roll PHP back first. Do not start deleting plugins while visitors are seeing errors. Use this recovery order:

1. Restore the previous PHP version in the host panel, or ask support to do it.
2. Confirm the frontend and WordPress admin are online again.
3. Clear caches if needed.
4. Recreate the PHP update on staging.
5. Use logs to find the plugin, theme, custom snippet, missing extension, or memory issue.
6. Update, replace, disable, or fix the bad code.
7. Test again on staging before retrying production.

Symptom	Likely cause	First action
White screen or fatal error	Incompatible plugin, theme, or custom code	Roll back PHP, then inspect logs on staging.
Admin will not load	Fatal error in admin-loaded code	Roll back PHP. If needed, disable the culprit through File Manager or SFTP.
Checkout or forms break	Extension, gateway, shortcode, or template conflict	Check logs around the failed action.
WordPress still shows old PHP	Wrong domain, environment, or PHP handler changed	Ask the host to verify the mapping.
Deprecation warnings appear	Code works now but is not future-ready	Update or replace the component before the next PHP jump.
Missing extension error	Required PHP module is disabled	Ask the host to enable the extension or choose a compatible PHP build.

If WordPress admin is inaccessible and rollback is delayed, your host File Manager or SFTP can help. For a plugin issue, rename the suspected plugin folder inside wp-content/plugins/ so WordPress deactivates it. For a theme issue, ask your host or developer to switch to a default WordPress theme.

Do this only when you understand the change you are making. The goal is to recover the site cleanly, not experiment on production under pressure.

🧩 Note: A fatal error tells you something stopped execution. A deprecation warning tells you something is outdated but may still run. Treat both seriously, but do not respond to them the same way.

Watch these special cases

Some WordPress sites need a slower PHP update path.

⚠️ Note: The most dangerous site is not always the oldest one. It is the site with one forgotten plugin, one edited theme file, and nobody who remembers why either exists.

Keep PHP current after this update

After this update, add PHP to regular WordPress maintenance instead of treating it like a once-every-few-years emergency.

Unsupported PHP is one security risk among many. MalCare can help monitor broader WordPress website security risks, malware, and vulnerable components after the PHP work is done. It does not update PHP for you because your host controls that. It helps with the part that should not depend on someone remembering to check manually.

FAQs

Can I perform a update PHP WordPress from the dashboard?

No. WordPress can show your PHP version, but your host or server controls it. Use your hosting panel or ask host support.

What PHP version should WordPress use?

Use PHP 8.3 or higher when your host, WordPress version, plugins, theme, and custom code support it. Test PHP 8.4 or PHP 8.5 on staging before using either on production.

Is it safe to update PHP?

Yes, if you prepare first. Back up the site, test on staging, confirm rollback, update PHP through your host, and verify the site after the change.

Why did my WordPress site break after updating PHP?

The usual cause is an incompatible plugin, theme, custom code, missing PHP extension, or changed server setting. Roll back PHP first, then troubleshoot on staging if the live site is back online.

Why does WordPress still show the old PHP version?

You may have changed the wrong domain, environment, account, or PHP handler. Site Health shows what WordPress is actually using, so ask your host to verify the setup.

Final advice

Updating PHP in WordPress is safest when you treat it as a host-level change with a WordPress-level checklist. Check the current version, pick a supported target, back up the site, test on staging, make the host change, and verify the result inside WordPress.

The rule is simple: do not let one hosting-panel click become the first time your site meets a new PHP version. Test first, keep rollback available, and fix old code before it forces the issue.