You did not click Update. Nobody touched a plugin. The site was working yesterday, and today it is a blank page. If your host recently changed your server's PHP version (many hosts do this on their own schedule as old PHP branches stop receiving security fixes), that change, not a WordPress update, is very likely the trigger.
This article is written for the reader who already suspects that. If you are not sure yet what caused the white screen, the first section below helps you confirm it before you do anything else.
Version and verification. Written against WordPress 7.0.2, released 2026-07-17, current stable. WordPress requires PHP 7.4 or greater; 8.3 or greater is recommended. Last verified 2026-08-06 against wordpress.org.
Confirm this is actually what happened
A blank white page with no error text is the classic symptom of a PHP fatal error that WordPress cannot recover from and display a message for. It has several possible causes, but two facts point specifically at a PHP version change rather than a WordPress update:
- You did not click Update, and no plugin auto-updated around the same time (check your host's activity log or your email for auto-update notifications, if you have any).
- Your host's status page, dashboard, or an email from them mentions a PHP or server change, or the timing lines up with a scheduled maintenance window they announced.
If instead you did recently update WordPress itself, what actually happens during a WordPress update is the more useful starting point. The causes and the fix are different, even though the symptom looks identical from where you are sitting.
Before you touch anything: the backup you have not tested is an assumption
A backup you have never restored is not a safety net, it is a belief about a file. Before you start deactivating plugins or asking your host to change anything else, find out where your most recent backup actually is, whether it includes both the database and the files, and what the real restore procedure looks like. If the honest answer is "I'm not sure," that is the finding, and it changes how carefully you should proceed with everything below.
Why this matters here specifically: a blind, one-by-one plugin deactivation on a site that is already white-screened, with no confirmed backup, turns a recoverable outage into a guess. Knowing you can restore is what makes it safe to experiment.
Step 1: get back into the admin, if you can
Try loading /wp-admin directly rather than the homepage. Sometimes the front end of a site fails on a PHP incompatibility in a theme file while the admin, which uses different code paths, still loads. If the admin loads, you can deactivate plugins and switch themes through the interface, which is the safer route. If the admin is also white, you will need FTP or your host's file manager for the steps below.
Step 2: ask "did WordPress update, or did PHP?" (and why the answer changes what you do)
This is the fork the generic white-screen guides skip. If PHP changed and WordPress did not, the WordPress core files are unchanged and are not the suspect. The suspect is any plugin or theme code that has not been updated in a while and was written against assumptions an older PHP version allowed and a newer one does not (a function that was removed, a type check that got stricter, a deprecated feature that finally stopped working). That points you at your plugins and theme, not at WordPress core, and not at a rollback of WordPress itself.
Step 3: the fastest safe response, ask your host to roll PHP back one step
This is the part most white-screen guides do not mention, and it is usually the fastest way back online: ask your host to move you back to the PHP version you were on before, as a temporary measure. This is not a permanent fix and it is not meant to be one. WordPress.org's own guidance is that older, unsupported PHP versions carry their own security exposure. But it buys you a working site while you sort out which plugin or theme actually needs updating, rather than doing that diagnosis live on a broken site.
If your host offers self-service PHP version switching in their control panel, you can usually do this yourself in a couple of minutes. If not, it is a fast support request, and most hosts treat "my site went down after your PHP change" as a priority ticket.
Step 4: if you can't roll PHP back, find the incompatible code the slow, safe way
If reverting PHP is not available to you, or your host's next required deadline means you cannot stay on the old version, work through this in order, checking the site after each step:
- Rename your plugins folder through FTP or your host's file manager (from
wp-content/pluginsto something likewp-content/plugins-off), which deactivates every plugin at once without needing the admin. If the site comes back, a plugin was the cause. - Rename the folder back, then rename each plugin's own subfolder one at a time, checking the site after each rename, until the site breaks again. The plugin whose rename caused the break is your suspect.
- If renaming plugins does not fix it, switch your active theme to a default WordPress theme through the same file-manager rename technique on the themes folder. A theme with PHP code that assumes an older version is a less common cause than a plugin, but it happens.
- Update the plugin or theme you found to its current version, since the maintainers have very likely already fixed the incompatibility in a later release. Only after updating it should you reactivate.
This is deliberately the slow path. It is also the one that does not require guessing, and guessing on a live site with no confirmed backup is the failure mode this article is trying to prevent.
Step 5: once the site is back, the real fix is not "leave PHP where it worked"
Rolling PHP back gets the site online. It does not fix the underlying problem, which is that something in your plugin or theme stack is not compatible with current PHP, and staying on an old PHP version indefinitely trades one risk for another. Once you have identified and updated the specific plugin or theme, check your PHP version and move forward deliberately rather than leaving the version wherever it landed during the emergency.
What this is not: a WordPress update problem
It is worth saying plainly, because the symptom is identical: this scenario has nothing to do with clicking Update Now, and none of the WordPress-core rollback or recovery procedures apply here. If it turns out you are wrong about the trigger, a WordPress update did in fact run around the same time, the WordPress 7 guide for site owners is the place to start instead, and it links onward to the update-specific recovery paths.
Frequently asked questions
Why did my WordPress site turn white after my host changed my PHP version?
A newer PHP version can stop running code that an older plugin or theme was written against, most often a removed function or a stricter type check. The white screen is WordPress being unable to display a normal error page for that failure.
Is this the same as the WordPress "critical error" message?
No. The critical error screen is WordPress's own recovery-mode message and includes text and an email link. A blank white page with no text at all is a different failure mode, usually further upstream, before WordPress can display anything.
Can I just ask my host to undo the PHP change?
Yes, and for most sites that is the fastest safe response. Ask your host to move you back to the PHP version you were on before, as a temporary measure while you find and update the incompatible plugin or theme.
How do I find which plugin or theme caused it?
Rename the plugins folder through FTP or your host's file manager to deactivate every plugin at once. If the site returns, rename folders back one at a time until it breaks again, then update that specific plugin.
Is it safe to leave PHP on the older version indefinitely?
No. It gets the site running again, but an outdated PHP version has its own security exposure. Treat the rollback as temporary while you update the actual incompatible code.
