Starting a website?

Purpose-Built Templates

ZU2B Blueprints

Business in a Box

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free
FAQ • Support

How to Find Which Plugin Just Crashed Your Site

Field Note #141
🔬 Generalized 🟢 Beginner ⏱ 30 Minutes ✓ Observation from Experience
Your site is down. Not “looks a little off” down — a full 500 error, a blank white page, or a message about a technical difficulty. You didn’t touch anything today. So what changed?
Nothing you did directly, probably. But something on your site changed on its own — most likely a plugin quietly updating itself in the background, days before the crash actually showed up.

What’s actually happening
A 500 error almost always means something in your site’s PHP code hit a fatal error. The frustrating part is that the error message itself rarely tells you which plugin is responsible — it just tells you something broke. And because plugin auto-updates can happen quietly, days or even a week before you notice a problem, the timing can be genuinely misleading. It’s easy to assume “nothing changed today” just because the trigger and the symptom didn’t happen on the same day.

How to tell the difference
You generally can’t tell just by looking — a 500 error caused by a plugin conflict looks identical to one caused by a theme issue or a server hiccup. The only reliable way to know is to isolate it directly, which is exactly what the fix below does.

The fix
If you can’t get into wp-admin at all, use your hosting’s File Manager (or FTP) to navigate to wp-content/.
Rename the plugins folder to something like plugins-disabled. This deactivates every plugin at once, since WordPress can no longer find any of them.
Try loading your site and wp-admin again. If it works now, you’ve confirmed a plugin is the cause — not your theme, not the server.
Create a new, empty folder named plugins. Log into wp-admin — you’ll see all your plugins listed but inactive, since WordPress is now looking at an empty folder.
Move your plugins back in from plugins-disabled into the new plugins folder one at a time, reactivating each one in wp-admin after it’s moved, and reloading the site after each. The moment the site breaks again, the plugin you just re-added is your culprit.
Leave that specific plugin out (or deactivated) and bring everything else back. If it’s a plugin you need, check whether an update is available — a fix may already be out for the exact bug that just hit you.

How to avoid it next time
You can’t fully prevent a plugin update from introducing a bug — that risk exists any time you keep software current, and staying current is still the right call overall. What actually helps: know this exact recovery process before you need it, not while your site is down and you’re improvising. It’s a fast, calm process once you’ve done it once, and a stressful, slow one the first time you’re figuring it out live.

Tagged in :

More from the field