WordPress Site Broken? The Fixes I Reach For First

When a WordPress site breaks, most owners do the same thing. They Google the symptom, land on a forum thread from 2017, and start changing things. Three hours later the site is still broken, and now nobody knows what was changed along the way. I fix WordPress sites live on screen share for a living, and the biggest difference between a fast fix and a long night is the first ten minutes. Here is what I actually do first.

Read the error. The exact error.

A white screen, a 500 error, and a message about a database connection are three different problems with three different fixes. So my first move is never to change anything. It is to read. I look at the exact words on the screen, the exact URL where it happens, and whether it hits the whole site or just one page. If the admin dashboard still loads, that alone cuts the list of suspects in half. Vague reports like "the site is down" send people down rabbit holes. Specific ones get fixed.

Ask what changed last

WordPress sites rarely break on their own. Something changed. A plugin updated itself overnight. The theme got an update. The hosting company moved the site or raised the PHP version. Somebody edited a page builder layout and saved it. I keep a fuller list of these checks in my WordPress troubleshooting guide, but the habit matters more than the list. Before touching a single setting, figure out the last change. Half the time, the fix is undoing or adjusting that one thing.

Check the error log before guessing

WordPress and the server both keep logs, and the log usually names the culprit outright. It will say which plugin file, on which line, ran into what problem. Guessing means deactivating plugins one by one and hoping. The log turns that into a short conversation: here is the file, here is the error, here is the fix. If you do not know where your error log lives, that is fine. Most owners do not. But any repair that skips it is working blind.

Isolate the conflict safely

When the log points at a conflict, the job is to prove it without breaking anything else. That means working in a safe order:

• Take a fresh backup first, even of the broken site, so there is always a way back.
• Disable the one suspect plugin the log named, not the whole list.
• If plugins are clean, switch to a default theme briefly to test the theme.
• Touch one thing at a time, and retest after every change.

The shotgun approach, turning everything off at once, sometimes revives the site but teaches you nothing. The broken piece stays in the pile, waiting to break it again on the next update.

Check the PHP version

This one catches people off guard. Hosting companies raise the PHP version, the language WordPress runs on, and older plugins or themes simply cannot run on the new version. The site worked yesterday and falls over today, and nothing in the dashboard changed. I check the PHP version against what the theme and key plugins support before I blame anything else. Sometimes the fix is updating an abandoned plugin. Sometimes it is replacing it. Either way, it is a known problem with a known fix.

Why forum advice wastes hours

Forum answers are written for the version, hosting setup, and plugin mix of the person who asked. Yours is different. A fix that saved one site can be the thing that locks you out of yours, and "locked out" is its own headache, as I cover in how to get back into WordPress when you are locked out. Work from the error, the log, and the last change, and the repair stays boring. Boring is good.

This is exactly the work I do in a live repair session. You share your screen, we read the error together, and you watch the site come back one tested step at a time. Standard fixes are $99 for the first hour, and the work is covered by a 30-day warranty. If your WordPress site is down right now, take a look at how my website repair sessions work and book a time.