A blank white page after a WordPress update usually means PHP hit a fatal error and stopped building the page part way through. Nothing reached the browser, so you got white. It is most often one plugin or one theme that did not survive the update, and WordPress has a built-in way back in.
What a blank page actually is
The WordPress Advanced Administration Handbook covers this on developer.wordpress.org under “Common WordPress errors”. That page was published March 28, 2023 and last modified August 28, 2025. It says both PHP errors and database errors “can manifest as a white screen, a blank screen with no information, commonly known in the WordPress community as the WordPress White Screen of Death”.
The white is the tell. Your server started running your site’s code, hit something it could not do, and quit. It never got as far as sending a page. There is no message on screen to read, since the code that would have printed one never ran.
Updates are when this surfaces. The update did not reach into your theme and snap it. New code arrived, and it stopped fitting old code that was already sitting there. The WordPress.org page on recovery mode says these errors “commonly stem from incompatible or faulty plugins or themes”.
Check your email, then check the junk folder
WordPress has shipped a recovery mode since version 5.2, released May 7, 2019. The WordPress.org documentation page “Recovery Mode” was first published August 14, 2025. That page carries no update date. It says WordPress turns recovery mode on by itself “when it detects a fatal PHP error during a regular page load (not via CRON or background tasks)”.
When that happens, an email goes to the site administrator’s address with a login link in it. Click the link, log in, and the failing plugin or theme is paused for your admin session only. Your dashboard loads with notices pointing at the piece that broke. You can switch it off from there, with no FTP and no file editing.
The link goes to the address set as the admin email, which is not always the address you hand to customers. If those are two different inboxes on your site, open the admin one now.
That email does not always arrive, and WordPress says so itself on that same page. Plugins load in a set order. If your site uses a plugin to change how outgoing mail is sent, and the fatal error happens before that plugin loads, the message goes straight out of your web server instead. The documentation warns that if the server’s email settings are not fully trusted, or its IP address is flagged for spam, the email “might never reach the admin’s inbox”.
There is a second catch. The developer reference for the recovery mode email rate limit on developer.wordpress.org gives the wait between these emails as “Time to wait in seconds. Defaults to 1 day.” Reloading the broken page twenty times does not send twenty emails. You get one, then nothing for the rest of the day.
So look in the junk folder first. If it is not there either, that is not proof your site is healthy. It is only proof the mail did not land.
Why some sites show a message and yours showed nothing
Current WordPress normally shows visitors a line reading “There has been a critical error on this website” instead of a blank page. The Recovery Mode page shows that screen as what a visitor gets. If yours went fully blank, the safety net did not run at all.
Felix Arntz wrote the two Make WordPress Core posts that describe how this was built. “The Improved Fatal Error Protection”, dated March 20, 2019, sets the goal: “It should be possible for an administrator to access their admin backend, even in case of a fatal error.” The public front of your site is what that post calls a non-protected endpoint, “for which plugins or themes should never be paused”.
The same post says it is impossible to pause WordPress core, and that the feature “excludes support for drop-ins and must-use plugins”. If the break sits inside one of those, recovery mode has nothing it is allowed to switch off.
The second post, “Fatal Error Recovery Mode in 5.2”, dated April 16, 2019, says an install can turn the whole feature off by setting a WP_DISABLE_FATAL_ERROR_HANDLER constant, “typically in wp-config.php”. So a totally blank page today is a fair hint that either the error hit too early for the handler to catch, or the handler is switched off. Ask your host whether that constant is set on your account.
When the memory limit is what broke it
The handbook page on editing wp-config.php, published March 28, 2023 and last modified August 16, 2026, says WordPress “will attempt to increase memory allocated to PHP to 40MB” for a single site, and 64MB for multisite. Attempt is the word to notice. That same page adds that “Some hosts do not allow for increasing the PHP memory limit automatically. In that event, contact your host to increase the PHP memory limit.”
The common errors page describes the matching failure in plain terms: an allowed memory size exhausted error means the install “doesn’t have enough memory to achieve what you want”. An update that loads more code at once can tip a site over a line it was already sitting near.
This gets worse the more you carry. Every plugin you keep is another thing loading on every page, and another thing that can fail on update day. Sorting out the plugins nobody maintains any more lowers the odds without changing anything a customer sees.
What this is not a reason to do
One white screen is not a reason to rebuild your website. Paying for a new site to escape one bad plugin update is a poor trade. The question of whether to fix this site or start over is settled by how often it breaks and what it costs you each year, not by one bad morning.
Be honest about the limits of what is cited above, too. Those WordPress pages describe what is meant to happen. None of them publish how often the recovery email actually arrives, or how many blank screens get sorted out without a developer. Nobody measures that, so nobody can tell you the odds for your own site.
If the same site keeps going dark, the update is not really the problem, and a rebuild on a site that does not run plugin code on every visit is worth pricing out. That is a decision for a quiet week, not for the morning a customer tells you the site is down and your phone has stopped ringing.
What to do next
- Open the admin email inbox, and the junk folder, and look for the recovery mode message. Use the link inside it.
- If there is no email, switch plugins off by hand over FTP or your host’s file manager. The Recovery Mode page gives the pattern for one plugin: rename the folder wp-content/plugins/hello-dolly to hello-dolly-1. The common errors page gives the version for all of them at once, renaming the wp-content/plugins folder itself, which it says “will deactivate all of your Plugins”.
- Once the site loads again, switch plugins back on one at a time and reload after each one. The common errors page gives the same order: deactivate them all, then reactivate one by one. The one that blanks the site again is your answer.
- To read the actual error, the handbook page “Debugging in WordPress”, published March 28, 2023 and last modified July 7, 2025, describes writing errors to a log file at wp-content/debug.log. That same page warns it is “not recommended to use WP_DEBUG or the other debug tools on live sites”.
- Ask your host to read the PHP error log for your account and tell you the file named in the last fatal error.
Write down what broke and the date it happened. Three of those notes in a year is data, and it tells you more about the state of the site than any single white screen ever will.