A broken WordPress site rarely announces itself politely. It is a white screen where the home page was, an editor that spins and never saves, a checkout that stopped taking orders, or an email from the hosting company that arrived while everyone was busy. By the time it is called broken, it has usually been fragile for months — the break is just the day the fragility became visible.
The rescue work I do follows the same order every time, and knowing that order is useful even if you never touch the site yourself — because it tells you what a competent rescue looks like, and what to be suspicious of when someone proposes a fix in the first five minutes.
First: stop the bleeding, take a copy
Before any diagnosis, two things happen. The site gets a full copy taken — files and database — because a rescue that makes things worse with no way back is not a rescue. And if the site is actively harming the business (a hacked page serving spam, a checkout charging wrongly), that specific harm gets stopped first, even crudely, even by taking a page offline. Diagnosis happens on a site that is no longer getting worse.
Triage: find what actually changed
A working site does not break spontaneously; something moved. The error log says what failed, the update history says what changed recently, and the host’s control panel says what they changed silently — PHP version bumps being the classic. The discipline is to resist fixing anything until the actual cause is identified, because treating symptoms scatters the evidence.
- A plugin update that conflicts with another plugin or the theme — the most common cause by far, found by switching plugins off in halves until the failure disappears.
- A PHP version jump on the host’s side that older plugin or theme code cannot run on.
- An expired licence quietly disabling something the site depended on — page builders and premium add-ons fail this way.
- Database corruption or a full disk, which look dramatic but are usually mechanical to fix.
- A compromise — spam pages, injected redirects, admin users nobody created. This changes the job entirely: cleaning must be complete or it is pointless.
Most rescues end here: isolate the conflict, roll back or replace the offender, bring the stack back to versions that coexist, and put update discipline in place so the same failure cannot repeat silently. A specific example from this practice: an Elementor editor that returned a 500 error on every save traced back to a plugin declaring compatibility it did not have — the write-up is in the notes, with the exact diagnosis path.
The decision nobody wants: repair or rebuild
Sometimes triage reveals a site that is not worth repairing. Years of accumulated plugins doing overlapping jobs, a theme abandoned by its developer, customisations nobody can explain, no staging environment, and a database carrying the sediment of every experiment ever run on the site. Repairing that is archaeology billed by the hour, and every fix disturbs something else.
The honest recommendation at that point is a clean rebuild that keeps the content and drops the rot. It feels more drastic than it is. The content — pages, posts, images, products — is the part with real value, and it migrates. What gets left behind is exactly the accumulation that caused the fragility.
The tooling on this site was proven at the extreme end of that: an entire production site rebuilt from nothing but its backup archive — database and wp-content out of a ZIP, reconstructed into a clean install with nothing else carried over. That is the limit case, and knowing the limit case is reachable makes the ordinary rebuild a much smaller decision than it sounds.
What prevention actually costs
Almost every rescue I have done would have been prevented by three habits: updates applied on a schedule rather than never or instantly, a backup that someone has actually test-restored, and a staging copy where changes land before production. None of these require a developer on staff. All of them are cheaper than one emergency.
The rescue toolingThe forensic analyser and the rebuild-from-ZIP utility, with the case study.What to check before it goes backA rebuild earns nothing if the redirects are dropped or a staging noindex ships. The 49-point pass, with the launch-day traps marked.A rescue, step by stepThe Elementor 500-on-save diagnosis from this practice, written up in the notes.Tell me what happenedGot a broken install? Describe the symptom — I will tell you straight whether it is a repair or a rebuild.Repair the site if the problem is one thing. Rebuild it if the problem is everything.