You turned on debugging, reproduced the fault, and opened debug.log. It is four thousand lines of text, most of it repeated, none of it obviously about your problem.
This is where most people give up and go back to deactivating plugins at random. It is a shame, because the log usually does contain the answer, and the skill needed to find it is smaller than it looks. It comes down to knowing which lines to ignore, which line to keep, and one thing about that line that is genuinely counterintuitive.
First: what a log line is made of
Every entry follows the same shape.
[04-Sep-2026 11:42:07 UTC] PHP Fatal error: Uncaught Error: Call to undefined
function acme_helper() in /home/user/public_html/wp-content/plugins/acme-forms/includes/render.php:218
Stack trace:
#0 /home/user/public_html/wp-includes/class-wp-hook.php(324): acme_render_form('')
#1 ...
Four parts, and each one is useful.
The timestamp. In UTC, not your local time. This matters more than it sounds, because your first filter is going to be time.
The severity. Fatal error, Warning, Notice, or Deprecated. This is your second filter and it does most of the work.
The message and the file path. What PHP could not do, and where it gave up.
The stack trace. The chain of calls that led there, most recent first. Numbered #0, #1, #2 and so on.
Rule 1: sort by severity, and start at the bottom of the list
The four severities are not equally interesting, and treating them as a single list of "errors" is why the file feels unreadable.
Fatal error means PHP stopped. If your site showed a white page or a critical error message, this is your line and everything else in the file is background. Search the log for the word Fatal first. If there is exactly one, you may be finished in thirty seconds.
Warning means PHP carried on but something was wrong. Warnings occasionally explain a visible fault, more often they do not.
Notice and Deprecated are almost always noise. Deprecated notices in particular say a plugin is using an old style of PHP code that still works today, which is a maintenance concern for the developer and nothing at all for you. A healthy site can generate thousands of them.
If you read only the fatal errors and nothing else, you will solve most of the problems that brought you here.
Rule 2: match the timestamp to the moment you broke it
A log accumulates. If debugging has been on for a week, the file holds a week of every plugin's grumbling, and the entry you want is one of them.
This is why deliberately reproducing the fault matters. Note the time to the minute, remember the log is in UTC, and go to that section of the file. Everything from before you started is history.
If you can, do it more cleanly: delete debug.log, reload the broken page once, and open the fresh file. What is in it now is what happened just then, and nothing else. That single step turns an unreadable file into a short one and is by far the most effective thing in this article.
Rule 3: the file named in the error is often the victim, not the cause
This is the part that costs people the most time, and almost nothing on the subject says it plainly.
A fatal error names the file where PHP stopped. That is not the same as the file responsible. If plugin A removes a function or changes a hook that plugin B relies on, PHP will fail inside plugin B, because that is where the impossible instruction sits. Deleting plugin B fixes the symptom and misidentifies the cause, and if plugin B was the thing you actually needed, you have made a bad trade.
The stack trace is what protects you here. Read it from the bottom up rather than the top down. The bottom is where the request began; the top is where it failed. If the trace passes through another plugin's directory on the way, that plugin is part of the story.
Two shapes are worth recognizing.
Call to undefined function or Call to undefined method usually means something that was expected to exist does not. Either a plugin was deactivated while another still depends on it, or an update removed something.
Cannot redeclare means two things are trying to define the same name. This is a genuine two-party conflict, and both parties will be visible in the message.
What to do once you have a suspect
You have a plugin directory name from a file path. That is a strong lead and not yet a verdict.
Check its version and its update status first. A fatal error immediately after an update to that plugin, or immediately after a WordPress update, points at compatibility rather than at the plugin being broken in general. If a plugin's feature stopped working while the site stayed up, our guide to a plugin that stopped working after an update covers that specific pattern.
Then confirm it, rather than assuming. Deactivate the suspect, reproduce the fault, and see whether it is gone. If it is, you have a confirmed cause. If it is not, you had a victim, and the conflict test is the way forward.
If the site is fully down and you cannot reach the admin, the log is still readable over FTP or in your host's file manager, and reading it before you start changing files is what stops the guesswork. Our critical error walkthrough covers the locked-out route.
When the log says nothing useful
Three cases where the log will not answer you, so you do not spend an hour expecting it to.
An empty log with a broken site. The failure happened before PHP ran, or outside PHP entirely. Check your host's own error log, and check whether the response is a server error page rather than a WordPress one.
A log full of warnings and no fatal error, with a visibly broken page. The problem is probably not PHP at all. Styling, JavaScript, caching and content issues do not appear here.
A log full of one repeated deprecation notice. That is a plugin that has not been updated for a newer PHP version. It is worth knowing and it is not your outage.
Afterwards
Turn debugging off and delete the log when you are finished. A log left running grows without limit, and on a default configuration the file sits inside a publicly reachable folder. Neither of those is a crisis and neither is a good permanent state.
Version context. Written against WordPress 7.1, released 2026-08-19, the current major release on our record. The log format described here is PHP's, not WordPress's, and it does not change between WordPress versions. Release dates come from our own dated record of the WordPress.org release page, last read 2026-08-19. The example log line above is illustrative and uses an invented plugin name; it is not taken from a real site.
