A Bloated WordPress debug.log: Tracking the Source and Cleaning Up

A wp-content/debug.log file weighing tens of megabytes is not just a disk-space issue. It is an almost certain sign that the site is throwing a PHP error hundreds or thousands of times per minute - each one costing CPU, slowing page generation and burying real warnings under a flood of noise.

Why this matters

Every error PHP throws - even a small Notice - forces the server to build a stack trace, stringify it and write it to disk. On a log that fills quickly this becomes measurable I/O. We have seen sites doing twice the disk activity just to write Deprecated warnings about code that does not affect anything. On top of that, a bloated debug.log makes real debugging much harder - when something serious finally surfaces, it is buried under thousands of repeating lines. Finally, some security and backup plugins include the file in archives - backing up a 200 MB log every night is wasted bandwidth and storage.

The most common cause: an old plugin or theme whose code is incompatible with the newer PHP version. In PHP 8.1 and especially 8.2 many features that were previously Deprecated became Warning or Fatal: Creation of dynamic property, passing null to non-nullable parameter, and others. Plugins that were not updated for PHP 8 compatibility will fill the log without breaking the site visibly.

How to detect

Open wp-content/debug.log via FTP, the host's File Manager, or SSH. Look at the entries - usually there is a pattern: the same error repeats hundreds of times. The line includes the full path:

PHP Deprecated: Creation of dynamic property in /home/user/public_html/wp-content/plugins/old-plugin/lib/foo.php on line 42

The path /wp-content/plugins/old-plugin/ identifies the offending plugin. Or, more efficiently:

grep -oE "plugins/[^/]+" wp-content/debug.log | sort | uniq -c | sort -rn | head

That ranks plugins by how often they appear in the log.

How to fix

1. Identify the plugin or active theme producing most entries (see above).
2. If an update is available, install it. The author has very likely already addressed PHP 8 compatibility.
3. If the plugin is unmaintained (last update over two years ago) find a replacement and migrate. Unmaintained plugins are also a security risk.
4. For commercial themes, file a support ticket and request a fix. In the meantime create a child theme and copy the offending files there to patch manually without losing changes on the next update.
5. After fixing, truncate the log: echo "" > wp-content/debug.log or delete it via FTP and upload an empty file.
6. In production it is better to disable file logging entirely: in wp-config.php set WP_DEBUG_LOG to false and WP_DEBUG_DISPLAY to false. Enable debug only when actively investigating.

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Common mistakes

• Leaving WP_DEBUG on in production: every minor warning is written to disk continuously. Turn it on only when actively chasing a bug.
• Truncating debug.log without fixing the source: the file refills within a day. Fix the source.
• Globally suppressing errors in code: adding error_reporting(0) in functions.php hides everything, including real bugs. Prefer filtering specific levels: error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);.
• WP_DEBUG_DISPLAY=true on production: this also prints errors to every visitor - leaking server paths and DB details.

Verifying the fix

After cleanup keep WP_DEBUG on for one day and watch whether the file starts filling again. If it stays empty or near empty, the fix worked. If it fills within an hour, return to the detection step - there is another source you missed. RankPlus will report green on the next scan.