When WordPress breaks, it usually picks the most annoying way to do it.

Before: you get a blank white page, a 500 error, or a plugin that just refuses to work, and WordPress gives you zero explanation.

After: you know exactly where the error comes from, which file, which line, and usually which plugin or theme caused it.

This guide walks through a practical way to trace WordPress errors with tools you already have — no extra plugin required.

I’ll keep it step‑by‑step, so you can follow along even if you’re not a full‑time developer.

1. Basic Prep Before You Start Tracing Errors

First, let’s get your site into a state that’s easier to debug.

Whenever possible, do this in a staging site or a copy of your site first. If you must do it on a live site, work during low traffic and be ready to revert changes quickly.

The basic prep:

1. Temporarily deactivate all plugins.
2. Switch your theme to a default theme.

This sounds boring, but it’s the fastest way to check if the problem comes from your own code, a plugin, or a theme.

1.1 How to deactivate all plugins

If you still have access to the WordPress dashboard:

1. Go to Plugins → Installed Plugins.
2. Use the checkbox at the top to Select All.
3. In the Bulk actions dropdown, choose Deactivate and apply.

If your site is totally broken and you can’t access wp‑admin at all, you can still force‑deactivate plugins via files:

1. Open your hosting File Manager or connect via FTP/SFTP.
2. Go to wp-content/.
3. Find the folder named plugins.
4. Rename it to something like plugins-off.

WordPress will think there are no plugins, so it deactivates them all. To restore them later, just rename the folder back to plugins.

1.2 Switch the theme to a default one

If you can open the dashboard:

1. Go to Appearance → Themes.
2. Activate a default WordPress theme (for example, Twenty Twenty‑X).

If you cannot access wp‑admin:

1. Go to wp-content/themes/ in File Manager or FTP.
2. Note the folder name of your current active theme.
3. Rename that theme folder to something like mytheme-off.

When WordPress can’t find the active theme, it tries to fall back to a default theme. If no default theme is installed, you may need to upload one manually.

Once plugins are off and theme is default, check if the error is still there.

• If the error is gone → likely caused by a theme or plugin.
• If the error is still there → more likely core code, custom code, or server/PHP configuration.

Either way, now we’re ready for proper tracing.

2. Turn On WP_DEBUG in wp-config.php

WordPress actually has built‑in debugging, but it’s off by default.

To turn it on, we edit the wp-config.php file.

Safety note: Always make a quick backup of wp-config.php before editing. Even just downloading a copy to your computer is fine.

2.1 How to enable WP_DEBUG

1. Open File Manager in hosting, or connect via FTP/SFTP.
2. Find wp-config.php in your WordPress root folder (same folder as wp-admin, wp-content, etc.).
3. Edit the file.

Look for a line like this (or similar):

define( 'WP_DEBUG', false );

Change it to:

define( 'WP_DEBUG', true );

If that line doesn’t exist, add this above the line that says /* That's all, stop editing! Happy publishing. */:

define( 'WP_DEBUG', true );

With WP_DEBUG enabled, WordPress will start showing PHP errors and warnings instead of hiding them.

That alone often reveals:

• which file is crashing
• which line
• and what kind of error it is

3. Save Errors to debug.log Instead of the Screen

Seeing errors on screen is useful, but logging them to a file is much better, especially when:

• the error only happens sometimes
• visitors are hitting the site while you debug
• you want a record of what’s happening

WordPress supports a built‑in debug.log file.

3.1 Configure WordPress to write debug.log

Still in wp-config.php, near the WP_DEBUG line, add these:

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

Quick explanation:

• WP_DEBUG — turns debug mode on.
• WP_DEBUG_LOG — tells WordPress to save errors to /wp-content/debug.log.
• WP_DEBUG_DISPLAY — hides debug messages from the HTML output (helpful so visitors don’t see raw errors).

After saving, visit the problematic pages on your site to trigger the error.

Then check wp-content/debug.log. If it doesn’t exist yet, refresh the error page once or twice.

4. Add register_shutdown_function for Fatal Errors

Some PHP errors are so bad they stop everything instantly (fatal errors). Those sometimes don’t show nicely, especially on white‑screen situations.

register_shutdown_function() is a PHP function that lets you run your own code right before PHP dies. In the context of WordPress debugging, you can use it to log something when a fatal error happens.

4.1 What does register_shutdown_function do here?

In simple words:

• It lets you say: “When the script crashes, run this little piece of code first.”
• That piece of code can log details to a file.

You’d typically use this if your error is not appearing clearly in debug.log, but you know the site is still dying somewhere.

4.2 Basic implementation idea

You add a register_shutdown_function() in a place that always loads (for example, a custom small mu‑plugin, or similar). Inside it, you can check error_get_last() and then log it.

The flow is:

1. Script dies.
2. Shutdown function runs.
3. It checks the last error and writes it to your log.

This is an extra tool when normal logging isn’t catching fatal errors clearly.

5. How to Read and Analyze debug.log

Once debug.log starts filling up, the next step is learning how to read it without getting lost.

5.1 Where to find debug.log

You’ll usually find it here:

• wp-content/debug.log

Open it using your hosting File Manager’s text editor or download it and open with any text editor on your computer.

5.2 What a log line looks like

A typical log line will usually have:

• date and time
• type of message (Notice, Warning, Error, etc.)
• the actual message
• the file path and line number

You scan for the latest entries first (usually at the bottom) and look for:

• PHP Fatal error
• PHP Warning
• PHP Notice (less critical but can still help)

Often, you’ll see a pattern like:

• same plugin or theme folder name
• same function mentioned repeatedly

That’s your first strong hint where the bug lives.

Once you know which file and line are involved, you can open that file, check what it’s doing, and decide whether to disable it, fix it, or ask the plugin/theme developer.

6. Search for error_log Files in File Manager

Besides debug.log, many servers generate their own error_log files in different folders.

These can be very helpful when WordPress itself doesn’t log something.

6.1 How to find error_log in File Manager

In your hosting File Manager:

1. Look for a Search feature (sometimes called Search, Find, or similar).
2. Search for error_log (exact name).

You might find multiple error_log files, often sitting in directories where errors happened. For example:

• in the WordPress root
• inside wp-admin or wp-includes
• inside a plugin folder

6.2 What’s inside error_log

Open one of those error_log files and you’ll see PHP error messages with similar structure:

• timestamp
• type of error
• message
• file and line

Sometimes, the server’s error_log will show errors that didn’t make it into debug.log, especially if they happened before WordPress fully loaded.

Just like with debug.log, work from the latest lines upward.

7. Use error_log() for Manual Debugging

Sometimes everything looks fine in your code, but the behavior is wrong.

This is where error_log() shines: it lets you print your own messages into the PHP error log (and often into debug.log) without showing anything to site visitors.

7.1 How to use error_log()

You drop lines like this into your PHP code temporarily:

error_log( 'Reached point A in my code' );

Or log variable values:

error_log( 'User ID is: ' . $user_id );

After that, trigger the action (reload the page, submit the form, etc.), then check debug.log or error_log.

You’ll see your custom messages appear in the log, so you know exactly which parts of your code are running and what values they use.

7.2 When manual debug with error_log() is useful

Use it when:

• the code runs but doesn’t do what you expect
• you’re not sure if a specific function is being called
• you want to see what values variables have at certain points

It’s like old‑school debugging with echo, but without breaking the page output.

Just remember to remove or comment out error_log() calls when you’re done.

8. Use die() for Quick, In-Your-Face Debug

die() (or exit()) is the hammer of PHP debugging.

When you call die(), PHP stops right there and prints what you tell it to.

8.1 How to use die() for manual debugging

Example:

die( 'Stopped here' );

Or if you want to see a variable:

die( print_r( $data, true ) );

You put this temporarily in the code where you suspect the problem is.

When you reload the page, if you see the die() output, you know the code reached that point.

If the page crashes before or never shows it, your problem is likely earlier in the execution.

8.2 When die() is effective

Use die() when you want:

• a quick, brutal check of execution flow
• to see exactly what a variable contains, right now

It’s not pretty for users, so don’t leave it in production code. But during troubleshooting, it can point you straight at the broken spot.

9. Check Server Logs When Needed

Sometimes, WordPress logs and error_log files still don’t tell the full story.

In those cases, server‑level logs may help.

9.1 What are server logs?

Server logs are files maintained by the web server or PHP engine itself.

They keep track of:

• PHP errors
• web requests
• sometimes resource issues or crashes

They live outside WordPress and are controlled by your hosting environment.

9.2 How to access server logs

This depends on your hosting, but usually you’ll find them via:

• a Logs or Error Logs menu in your hosting control panel
• a path your host documents for Apache/Nginx/PHP logs

If you’re unsure, this is one of the few times it’s reasonable to ask your hosting support: “Where can I see my PHP error logs and web server logs?”

9.3 When to check server logs

They’re useful when:

• the site fails before WordPress really loads
• you get 500 errors with no info in debug.log
• you suspect server configuration or resource limits

Server logs can show fatal errors, memory limit issues, or other low‑level problems that WordPress can’t catch.

10. Tips, Best Practices, and Clean-Up

To keep things safe and sane while debugging, a few habits help a lot.

10.1 Safety and cleanliness

• Use staging when you can: Debug on a clone of your site, not your main money‑maker.
• Backup before big changes: Especially before editing wp-config.php or theme/plugin files.
• Keep permissions reasonable: Don’t open up permissions too wide just to make logs work.

10.2 Don’t forget to turn debugging off later

Once you’ve found and fixed the issue, it’s good practice to turn off debug mode on production.

In wp-config.php, you’d typically set:

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

You can leave WP_DEBUG_LOG on if you want long‑term logging, but many people turn it off on live sites to avoid huge log files.

10.3 Summary of the tracing flow

When WordPress breaks:

1. Disable plugins and switch to a default theme to narrow down the source.
2. Enable WP_DEBUG in wp-config.php.
3. Turn on WP_DEBUG_LOG and check wp-content/debug.log.
4. Look for any error_log files via File Manager.
5. If needed, add register_shutdown_function() to catch fatal errors.
6. Use error_log() and die() for targeted manual debugging.
7. As a last resort, check server‑level logs or ask hosting where they are.

Follow that path and you’ll rarely be stuck with a mystery 500 error or blank page again.

If this saved you time, bookmark CrushEdge for more fixes.