Each guide leads with the fastest fix, then works through the causes in order of likelihood. No preamble, and no withholding the answer.
| What the site is doing | Start here |
|---|---|
| One sentence about a database connection | Database connection error |
| A worded message about a critical error | Critical error |
| Completely blank white page, no text at all | White screen of death |
| Redirects elsewhere, spam content, or a browser warning | Hacked site recovery |
| Loads, but slowly | Speed optimization |
| Broke immediately after an update | Critical error |
WordPress cannot reach its database. Usually a credentials mismatch after a migration — occasionally corrupted tables or an exhausted connection limit.
Read the fixA PHP fatal error, caught by WordPress. It has probably already emailed you a recovery link naming the plugin responsible.
Read the fixA completely blank page with no message. The first job is turning the silence into a readable error, then working through plugins, theme and memory.
Read the fixA recovery checklist in the right order — preserve evidence, contain, rotate credentials, clean, then close the entry point so it does not recur.
Read the fixA speed checklist ordered by impact. Most slow WordPress sites are fixed by image weight and page caching alone.
Read the fixWhen the error is not one of the five above, this sequence resolves most of what remains. It is ordered so that the cheapest, most reversible checks come first.
WP_DEBUG_LOG and read the log. A generic message on screen is not the error; the log entry is.functions.php edits.Writing down what you changed while you are changing it. Debugging sessions routinely introduce a second problem on top of the first — a setting toggled and forgotten, a file renamed and left renamed. Keeping a short list of what you altered is the difference between fixing one fault and creating two.
Four of the five guides here describe failures that follow a change. The compromise follows an update that was not applied; the critical error and the white screen follow one that was; the slow site follows two years of small additions nobody tracked.
That is what makes an activity log and one-click reversal disproportionately valuable here — not because it prevents mistakes, but because it collapses the expensive part, which is working out what changed and undoing it safely.
See how one-click undo works, or read the WordPress maintenance guide for the scheduled checks that catch most of this early.
Start by identifying which error you have, because the diagnostic paths differ. A worded database message, a critical error notice, a blank page and a slow page are four different problems. From there the general sequence is the same: find the real error message, undo the most recent change, then rule out plugins and the theme.
What changed most recently. The overwhelming majority of sudden WordPress failures follow a plugin update, a theme edit, a core update or a host-side change. Knowing the last change turns an open-ended investigation into a single hypothesis you can test in a minute.
Enable debug logging by adding WP_DEBUG and WP_DEBUG_LOG to wp-config.php, then reload the page and read wp-content/debug.log. Keep WP_DEBUG_DISPLAY set to false so visitors never see errors, and turn all of it off once the site is working again.
Use FTP, SFTP or your host's file manager. Renaming the wp-content/plugins folder deactivates every plugin at once and restores admin access in most cases; renaming the active theme folder does the same for theme faults. Neither deletes anything, so both are safe to try.
Scheduled health checks across every site, with one-click undo on anything that changed.
Start free