The WordPress debug log is the fastest way to find what is breaking your site, but a raw debug.log is a wall of repeated lines that hides the real problem. The goal here is simple: turn logging on, then paste the log into a tool that groups and counts the errors so the worst offender jumps out.
Turn on the WordPress debug log
By default WordPress does not write a log file. Edit wp-config.php and add these lines above the “stop editing” comment:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG switches on error reporting. WP_DEBUG_LOG sends those errors to a file at wp-content/debug.log. Setting WP_DEBUG_DISPLAY to false keeps the errors out of your live pages so visitors never see them. Reload the page that is misbehaving, then open wp-content/debug.log and copy its contents.
Why grouping the log matters
A busy site can write the same PHP warning hundreds of times per minute. Scrolling that by hand tells you almost nothing. What you actually want to know is which errors repeat most, because the one firing thousands of times is usually the plugin or theme causing the real damage.
That is what the WordPress Debug Log Analyzer does. It groups identical messages, counts how many times each one fired, and separates PHP warnings, notices, fatal errors, and deprecation notices so you can triage at a glance instead of reading every line.
Analyze your log in three steps
- Open the WordPress Debug Log Analyzer.
- Paste the text you copied from
wp-content/debug.loginto the box. - Read the grouped results, sorted by count, and start with the most frequent error.
The tool reads only the log text you paste. It does not fetch your site or connect to your server, and everything runs in your browser, so nothing about your site ever leaves your device.
Fixing what you find
Once an error is grouped, the file path and line number in the message point you at the culprit. Deprecation notices usually mean a plugin or theme is overdue for an update. Repeated fatals almost always trace back to one extension, so deactivate it and watch whether the count stops growing. When you are done debugging, set WP_DEBUG back to false so the log stops filling on a production site.
Related tools
- Serialized Data Fixer: repair broken serialized strings that throw errors after a careless search and replace.
- JSON Formatter & Validator: clean up and validate JSON payloads that show up in your stack traces.
- WordPress Salt Generator: refresh your security keys while you are already editing
wp-config.php.
Turn on logging, paste the log, and let the counts tell you where to look first.