How do I fix 'Your site is running an outdated version of PHP' in WordPress?

PHP is set by your host, not by WordPress. Take a full backup, update WordPress, the theme and every plugin first, delete plugins you do not use, then pick a newer supported PHP version in your host panel (cPanel: MultiPHP Manager or Select PHP Version; Plesk: PHP Settings). Check the home page, forms, checkout and admin right after; if something breaks, switch back in the same panel.

Will updating PHP break my WordPress site?

Usually not, if plugins and the theme are updated first. The ones that break are plugins with no update in years. Test on a staging copy if your host offers one. If a plugin does break, switching the PHP version back in the host panel restores the site at once, and WordPress emails the admin a recovery link that names the plugin.

Which PHP version should my WordPress site use?

The newest version your host offers that php.net still lists as supported and that WordPress recommends on wordpress.org/about/requirements. Moving several versions at once is fine once plugins are current, and saves doing it again next year.

Which Site Health warnings can I ignore?

Outdated PHP, no HTTPS, failed scheduled events, background updates not working and a public error log should be fixed. Missing optional modules and the object cache or page cache suggestions are speed or convenience items that a small, fast site can leave.

More fixes

"PHP Update Recommended" and Site Health warnings on WordPress

PHP is the language your WordPress site runs on, and your host, not WordPress, decides which version. Each PHP version gets security fixes for a few years and then none, so a site set up in 2019 and never touched is often still on 7.4, which stopped getting fixes in November 2022. WordPress notices and puts a red box on the dashboard. Moving up is a setting in the host panel and takes a minute; the care goes into checking that your plugins are ready first. Below is a rebuilt example (not a real client), the safe order of steps, and what the other Site Health warnings mean.

The WordPress dashboard

What the checks found

First: find out which PHP you run and which you can move to

Read the version WordPress sees. Tools > Site Health > Info > Server shows the PHP version. The dashboard box ("PHP Update Recommended", or "PHP Update Required" when it is very old) shows it too.
Check what is still supported. php.net's "Supported Versions" page lists which versions get security fixes and until when; wordpress.org/about/requirements says which one WordPress recommends. Pick the newest version your host offers that is on both lists, not just the next one up, so you do not repeat this in a year.
Find the switch in your host panel. On cPanel hosts it is "MultiPHP Manager" or "Select PHP Version"; on Plesk it is the domain's "PHP Settings"; managed WordPress hosts put it in the site's own dashboard. If you only see a version list with no buttons, the host manages it and a support ticket does it.

Then: the safe order of steps

Take a full backup (files and database) and download it. Most host panels have a one-click backup; a plugin such as UpdraftPlus works too.
Update WordPress, every plugin and the theme first, on the old PHP. Current versions are what plugin authors test on new PHP. A plugin with no update in three or four years is the one most likely to break; its page on wordpress.org says "Tested up to" and often "Requires PHP".
Remove what you do not use. Deactivated plugins and spare themes still sit on the server and still need to work with the new PHP. Delete them (keep one default theme such as Twenty Twenty-Four as a fallback).
Use a staging copy if your host has one. Many do, one click. Switch the copy's PHP, click through it, then do the real site.
Switch the live site, then check it right away. Load the home page, a contact form (send yourself a test), the shop's cart and checkout if there is one, and the admin. If anything breaks, switch the version back in the same panel: it is instant and nothing is lost. WordPress also emails the admin a recovery link that names the plugin that failed.
Fix the one plugin, not the whole plan. If one plugin breaks, update it, swap it for a maintained one, or ask its author; then switch again. Do not stay on unsupported PHP for one plugin.

The other Site Health warnings, and which ones matter

What Site Health says	What it means	What to do
"Your site is running an outdated version of PHP"	Your PHP no longer gets security fixes, or soon will not	Fix it: the steps above
"Your site does not use HTTPS"	Visitors see "Not secure"; forms send in the clear	Fix it: the "Not secure" guide
"You should remove inactive plugins" / "inactive themes"	Unused code that still needs updates	Delete them; keep one default theme
"Background updates are not working as expected"	Security releases may not install on their own	Usually a host setting or a leftover `.git` folder; ask the host or check `wp-config.php` for `AUTOMATIC_UPDATER_DISABLED`
"A scheduled event has failed" or "is late"	WordPress's timer (WP-Cron) is not running jobs: backups, scheduled posts, emails	Often a security plugin or caching blocking it; a real server cron job fixes it for good
"Your site could not complete a loopback request" / "The REST API encountered an error"	The site cannot call itself; the block editor and scheduled jobs suffer	A firewall or security plugin rule, or basic-auth on the site; whitelist the site's own address
"One or more recommended modules are missing" (imagick, intl)	Optional PHP add-ons for image handling and languages	Tick them in the same PHP panel if offered; harmless if not
"Your site is set to log errors to a potentially public file"	`WP_DEBUG_LOG` left on; the log can be downloaded by anyone	Turn debug off in `wp-config.php` and delete `wp-content/debug.log`
"You should use a persistent object cache" / "Page cache is not detected"	Speed suggestions	Fine to leave on a small site that loads quickly; see a slow site if it does not

What not to do

Do not ignore the red box because the site "works". Old PHP keeps working; it just stops getting fixes, and plugins drop support for it one by one, so updates start failing quietly.
Do not jump PHP before updating plugins. That order is what turns a one-minute switch into a broken site.
Do not install a plugin that hides the Site Health warnings. The warning is not the problem.

For most small sites this is a backup, a round of updates, one setting and ten minutes of clicking through pages. If you would rather hand it over, or a plugin breaks on the new version, that is what the box below is for. Related: WordPress years out of date, "Parse error: syntax error" right after an update, and "There has been a critical error".