A wordpress website white screen is a browser result, not a diagnosis. The page is white. That is all the visitor can tell you.
The server may have returned a 500, a 200 with an empty body, or nothing before the browser gave up. Those three are different faults. Guessing a plugin from the colour of the screen is how a short outage becomes an afternoon.
This page is the branch. You record what the browser actually received, then you read a log line that names a file. A companion page already covers the patch habit, diagnosing a white screen before you patch it.
Use that one when you already know which change went out. Use this one when all you have is white.
Write down the status before you touch a file
Open the URL in a private window, or fetch it with curl from outside the office. Record the HTTP status and the byte count of the body. Do this before you rename a folder, switch a theme, or restore last night’s backup. A restore is a guess with a longer rollback.
People search whitescreen wordpress as one smashed word, and they search white screen death with the “of” left out. The queries describe the same picture. They still don’t tell you the status code. Treat every one of them as a request for a branch, not as a request for a magic plugin to disable.
If you are on the phone with the person who saw it, ask three things. Which URL. What time, in which timezone.
Did a login page, a product URL, or only the homepage go white? A fault that hits one URL is often a template. A fault that hits every URL is often PHP dying before WordPress draws anything.
You cannot see that split from a single screenshot of the homepage.
Also ask whether they are logged in. A page that is white for an editor and fine for a stranger is a different bug from a page that is white for everyone. Caching can split those two.
Note it. Don’t “clear all caches” as a personality trait. Clear a cache after you know whether the origin is white too.
Branch A: the status is 500, or the log says fatal
A 500 means PHP, or the process in front of it, refused the request. The white is just display_errors being off. The sentence you need is in the PHP error log, the host’s PHP-FPM log, or wp-content/debug.log if logging was already on.
Turn logging on if it was off, reproduce once, and read the newest fatal. Don’t flip display_errors on for the whole world while you think. A public fatal is a gift to anyone scanning the site.
A useful fatal names a file path and a line. If the path sits under wp-content/plugins, that plugin is the suspect. Disable that one.
Reload the URL. If the status changes, you have a cause, not a hunch. If the path sits under the active theme, the theme is the suspect.
Switch only then.
Memory exhaustion is one fatal among many. It looks like “allowed memory size exhausted” and it names a number. Compare that number with the machine.
One recorded case, not logged by us as a white screen specifically, was a 1-core, 1 GB machine running three WordPress sites. It stayed unstable because memory_limit was 1024M, the entire box before the operating system and MySQL. A single PHP process used 80 to 124 MB.
The stable change was memory_limit at 256M and workers from 6 to 4.
So a memory fatal can be why a request dies and the visitor sees white. It is not the default explanation for every white screen. If the log does not say exhausted, don’t spend the hour on php.ini because the symptom feels similar.
If the log does say exhausted, don’t “add more memory” until you have compared the ceiling with installed RAM. Setting 1024M on a 1 GB machine is how that box got worse, not better.
Six workers at the top of the 80 to 124 MB range are 744 MB. MySQL is extra. The browser will not show you that sum.
The log plus the ini file will. A host panel that hides both leaves you in branch A with no sentence to read. Getting the log is the repair step.
Restarting PHP without reading it is a coin flip.
Branch B: the status is 200 and the body is empty
A wordpress blank page with HTTP 200 did not crash in the way a 500 crashes. Something returned success and then printed nothing, or printed only whitespace. The usual causes are a theme function that returned early, a plugin that cleared the buffer after a warning, or a PHP notice that happened before any HTML and got swallowed.
Check the log anyway. Warnings are shy when display_errors is off, and they still get written if logging is on. A 200 with an empty body plus a warning that names a missing function is a theme or a plugin that ran in the wrong order.
The status code lied by being polite. Believe the log line.
If the log is silent, look at who is empty. Fetch the homepage, a single post, and a product URL. If only one template is empty, you are in that template’s file, not in a server-wide crisis.
If all of them are empty, suspect an mu-plugin or a must-use drop-in that runs before the theme. Those files hide in wp-content and don’t appear in the plugin screen. People rename wp-content/plugins and then stare at a still-white site.
The drop-in never lived in that folder.
Caching makes branch B look haunted. The origin might now return a real page while a cached 200 still stores the empty body. Fetch once with a cache-bypass header the host documents, or fetch from the machine itself.
If the origin is healthy and the edge is empty, you have a stale object. Purge that URL. Don’t reinstall WordPress because a cache held an empty 200.
Branch C: the browser gave up
A spinner, a timeout, or a connection reset is not a white screen in the strict sense, and people still report it as one. Nothing came back in time. The worker may be stuck, the database may be wedged, or the machine may be out of RAM and killing processes. The visitor’s screenshot is white because the paint never started.
This is where the 1 GB story matters as capacity, not as a slogan. If workers are set above what RAM can hold, requests pile up and the next one waits until the browser quits. Cutting workers from 6 to 4 on that box was a stability change.
It did not make the machine faster in a benchmark brochure. It stopped the pile-up. Look at whether PHP-FPM is at its worker cap while the site “is white”.
If it is, you are in a queue, not in a theme bug.
Disk can fake the same wait. A multi-site server went from 91 percent full to 37 percent full after cache rows were removed from the database. One of those rows was 30 MB.
A full disk makes writes fail. Sessions, logs, and temporary files then misbehave, and the front end looks blank or endless. Check free disk before you condemn a plugin that merely happened to run first.
Time to first byte tells branch C apart from a page that is merely heavy. On waimaodulizhan.com the homepage TTFB moved from 2.14 seconds to 0.067 seconds when an nginx fastcgi_cache block was added. The machine stayed.
A slow TTFB with a body that does arrive is a performance fault. A request that never finishes is the timeout branch. Don’t mix them up and buy RAM for a missing cache stanza, or add a cache stanza for a process that is stuck in a lock.
What not to do first
Don’t rename the entire plugins directory as the opening move when a log is available. You will hide the fatal and create a second outage if a must-have plugin is how the site routes. Rename one plugin, the one the log named.
If you truly cannot get a log, renaming plugins is a test you owe the site, and you put them back one at a time until the white returns. Write down the name that brought it back. That note is the diagnosis.
The rename was only the instrument.
Don’t restore a backup over a site you haven’t read. Backups can reintroduce the fatal, especially if the fatal is a bad setting in the database rather than a file you just uploaded. And don’t leave backup copies in the theme directory when you are done experimenting.
On one site, 36 .backup files in the theme directory were downloadable from the public web. A white-screen afternoon is how those copies get created in a hurry.
Don’t confuse this with a form that fails. A form can sit on a healthy page and still drop the message. One site key was registered on a different domain, and the form stayed broken for 12 days while 207 paid clicks landed on it.
The page was not white. The enquiry was. That fault is an invalid domain on the site key.
Fixing it will not paint a blank homepage, and painting the homepage will not send the form.
Mail is a third lookalike. The screen is fine, the thank-you line shows, and the inbox stays empty. That layer is why WordPress stops sending email. It does not belong in the plugin-rename ritual.
After the branch is known
A 15 MB image in the first screen made hundreds of product URLs fail Core Web Vitals while the server was healthy. Those pages were not white. They were heavy.
The thresholds are an LCP within 2.5 seconds, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, as web.dev states them. If your “white screen” is actually a page that arrives and then shifts, you have left this article. Go measure.
Don’t keep hunting fatals.
When the log has a name, patch that name on a copy if you have one, then on production, then fetch the same URL with curl again. The status and the byte count should have changed. A screenshot from a logged-in editor is a weaker proof, because caches and admin bars lie.
Keep the log line in the ticket. Future you will not remember which plugin it was.
Updates belong in the same note. A routine plugin or PHP bump can replace a working URL with branch A between lunch and the first complaint. The fatal will usually name the file the update just wrote.
Read that line before you roll the whole site back to a backup from last week. A rollback that you haven’t read can restore an older fatal and drop every content change since the backup. If you have a staging copy, reproduce there with the same memory_limit as production.
A staging box with a huge ceiling will hide the exhaustion you are about to ship.
Tianwen Network was founded in 2017. The memory figures, the disk figures, and the 36 public backup files are from work on sites in our care, stated as failure shapes, not as a claim that your white screen is the same bug. We will not guess it for you from a one-line email that says only “site down”. Send the URL, the status code, and the newest fatal if you have it.
Questions a blank page actually raises
Is every WordPress white screen a plugin conflict?
No. Record the HTTP status first. A 500 with a fatal is one branch. A 200 with an empty body is another. A timeout is a third. The log names the file. The colour of the screen does not.
Can a 1024M memory limit blank the site?
It can kill a request, and a killed request looks white when error display is off. On a 1-core, 1 GB machine, memory_limit of 1024M left three WordPress sites unstable. A PHP process used 80 to 124 MB. The stable change was 256M and workers cut from 6 to 4. Read the log for memory exhaustion before you raise the ceiling. We are not claiming every white screen is this bug.
Should the plugins folder be renamed first?
Only when you cannot get a log. If the fatal names one plugin, disable that one and reload the same URL. Renaming the whole folder hides the sentence you needed.
Is a broken contact form the same fault?
No. One form was dead for 12 days while 207 paid clicks landed, because a reCAPTCHA site key was registered on another domain. The page was not white. Fixing the key will not paint a blank homepage.