What to do immediately when WordPress breaks

WordPress breaks in a handful of recognizable ways: a white screen, a critical error banner, a 500 response, a login loop, or a front end that looks fine while the admin panel refuses to load. The first hour is not about fixing everything. It is about stopping the spiral, preserving evidence, and deciding whether this is a five-minute misconfiguration or a failure that needs professional diagnosis.

Most owners arrive in panic mode because the site is revenue, reputation, or both. That urgency is valid. The counterintuitive part is that calm documentation beats heroic clicking. A technician can recover a broken site faster when you have not already overwritten logs, deleted the wrong folder, or run three conflicting “fix” plugins in a row.

What probably happened

WordPress failures usually cluster around a recent change. Something updated — WordPress core, a plugin, PHP on the host, DNS, SSL, a security rule — and the stack no longer agrees on how to boot.

Common patterns we see on intake:

• Fatal PHP errors after a host PHP upgrade or a plugin update that assumes older PHP behavior.
• Plugin or theme conflicts that surface only on certain URLs, admin screens, or logged-in sessions.
• Database connection errors when credentials changed, the database server restarted, or disk quota filled.
• Redirect or cookie loops after SSL changes, security plugins, or mixed HTTP/HTTPS settings.
• Partial outages where the public site loads but wp-admin does not — a situation that feels less urgent until you realize you cannot publish, patch, or remove malware.

Sometimes the trigger is obvious (“we clicked Update All Plugins”). Sometimes it is invisible (“the host migrated us overnight”). Either way, treat the timeline as evidence, not blame.

What to do first

Work through these moves in order. They are deliberately boring. Boring is good when the site is on fire.

1. Document before you touch anything

Capture what you see, not what you assume:

• The exact URL that fails (home page, /wp-admin/, checkout, a single post).
• The full error text or HTTP code (500, 502, 403, blank white screen).
• The time you first noticed it, including time zone.
• What changed in the last 24–72 hours: updates, new plugins, DNS edits, password resets, host tickets.

Screenshot the error if you can. If the site is completely blank, note that too. This is the same evidence list we walk through in what a repair technician needs before intake — gathering it early saves hours later.

2. Check whether the problem is public, admin-only, or both

Load the site in a private browser window (no cookies, no admin bar). If the front end works but /wp-admin/ fails, you are in a different repair lane than a full white screen. Read why a website can work while the admin panel is inaccessible before you start disabling plugins from the dashboard you cannot reach.

3. Protect access and backups

Before experimental fixes:

• Confirm you still have hosting panel access (cPanel, Plesk, managed host dashboard).
• Confirm you know where backups live — host snapshots, UpdraftPlus, ManageWP, Jetpack Backup, etc.
• If you have a recent backup, do not overwrite it by running a restore you have not verified.

If you are not sure backups are restorable, stop trying to “fix forward” and treat backup verification as part of the job.

4. One reversible diagnostic at a time

If you have hosting file access or staging, safe first checks include:

• Renaming the plugins folder via FTP or file manager to force plugins off (then rename it back).
• Switching to a default theme temporarily if the front end is broken and you suspect the active theme.
• Checking disk space and PHP error logs in the hosting panel.

Each change should be one step, with a note of what you changed and how to undo it. If a step makes things worse, undo it before stacking another fix on top.

5. Decide whether this is DIY-safe

You can often recover from a single bad plugin update if you have file access, a recent backup, and time to test. You should not DIY when:

• The site shows signs of compromise (unknown admin users, defaced pages, redirect to spam domains).
• Checkout or donations are broken during a live campaign.
• You have already tried several fixes and the error keeps shifting.
• You do not have backups you trust.

That is the point to stop clicking and start a scoped repair — not after you have deleted wp-content because a forum post said to.

What not to do

These moves turn recoverable outages into longer, more expensive ones. We wrote a full breakdown in how to avoid making a broken website worse; the short list:

• Do not run multiple “repair” plugins at once. They duplicate fixes, hide real errors, and modify the same files.
• Do not delete core WordPress files because a tutorial mentioned “fresh upload.” Partial core replaces cause subtle corruption.
• Do not edit wp-config.php from a random snippet unless you understand each constant and have a backup of the file.
• Do not restore a backup onto production without knowing how old it is and what data you will lose (orders, form entries, new posts).
• Do not share admin passwords in public Slack threads or ticket comments. Use a password manager share or a host-provided temporary user.

If you are tempted to “Update All” again to see if it fixes itself — pause. That is how a single bad edge becomes a chain reaction.

When to stop DIY and call for repair

Stop when additional changes feel like guessing. Good technicians are not magicians; they are systematic. They need a stable failure to inspect, not a moving target you keep poking.

Call for emergency repair when:

• Revenue or safety-critical flows are down (e-commerce checkout, appointment booking, emergency contact forms).
• The site may be hacked or blacklisted.
• Admin and front end are both broken and you lack file or database access.
• You have no verified backup and the host is threatening suspension for disk or malware issues.

Emergency repair should start with diagnosis and scope: what broke, what is recoverable, what reversals are available, and what a fix will cost in time and data — not an open-ended plugin install spree.

A calm checklist you can reuse

Keep this sequence handy for the next incident:

1. Screenshot and timestamp the error.
2. List what changed recently.
3. Test public site vs admin separately.
4. Locate hosting access and last known good backup.
5. Make one reversible change at a time — or stop and hand off with your notes.

WordPress will break again someday. Sites change, hosts upgrade PHP, plugins ship regressions. The owners who recover fastest are not the ones who know the most keyboard shortcuts — they are the ones who protect evidence, avoid damage spirals, and know when a paid diagnostic is cheaper than a week of downtime.