There is a particular kind of panic that comes with loading your own website and seeing a blank white screen. Or a payment gateway that fails at the last step. Or a "There has been a critical error on this website" message where your homepage used to be. If that is where you are right now, this post is written for you.
The good news: the overwhelming majority of WordPress emergencies are far more fixable than they look. The bad news: most business owners waste the first critical hours doing things that make the problem harder to diagnose. This post covers what to do, what not to do, and what a properly run emergency fix looks like.
First, Stop and Do These Four Things
Before you touch anything else, spend ten minutes on this. It will save hours later.
- Write down exactly when it broke. Was it after a plugin update? After your host emailed about a PHP version change? After someone edited a page? The timing is usually the single biggest clue.
- Take a screenshot of the error. The exact wording matters. "Error establishing a database connection" and "critical error" point to completely different causes.
- Check whether it is only you. Open the site on your phone with WiFi off, or run it through a tool like Down For Everyone Or Just Me. A caching or DNS issue on your own machine looks identical to a dead site.
- Stop making changes. This is the one people get wrong. Deactivating plugins at random, reinstalling themes, or restoring a backup over a broken site destroys the evidence a developer needs and can turn a 30-minute fix into a rebuild.
What Actually Breaks WordPress Sites
After twelve years of these calls, the causes cluster tightly. Roughly in order of how often I see them:
1. A plugin or theme update conflict
By far the most common. WordPress, a plugin, and a theme all get built by different people. An update to one can break an assumption another was relying on. It usually shows up as a white screen, a critical error message, or a specific feature silently failing while the rest of the site looks fine.
2. A PHP version change at the host
Hosts periodically force PHP upgrades for security. Older plugins that were never updated stop working the moment the version changes. If your site broke overnight with nobody touching it, this is the first thing to check.
3. Memory limits
Sites grow. Product catalogues expand, plugins accumulate, and eventually a page needs more memory than the host allows. This tends to break the heaviest pages first — the shop page, the admin dashboard, the media library — while the homepage stays fine.
4. A broken payment or shipping integration
The expensive one. WooCommerce checkouts break when a payment gateway changes its API, an SSL certificate lapses, or a currency or shipping plugin conflicts with a recent update. Customers reach the final step, fail, and leave — and unless you are watching your abandoned cart numbers, you can lose a week's sales before noticing.
5. Hacked or injected code
Less common than people fear, but real. Symptoms include redirects to unfamiliar sites, spam content appearing in search results, or admin accounts you did not create. This one needs a different response to everything above — see the warning below.
The Fastest Safe Diagnostic You Can Run Yourself
If you are comfortable in the WordPress dashboard and the site is not an active e-commerce store mid-trading, there are two checks worth doing before you call anyone.
Turn on the error log. Ask your host to enable WordPress debug logging, or switch it on in wp-config.php. The resulting log usually names the exact plugin file causing the failure. That single line often turns a two-hour investigation into a ten-minute fix.
Check the host's error log. Most hosting control panels expose a PHP error log without any code changes at all. Fatal errors appear there with a file path and a line number.
That is genuinely as far as I would push a non-developer. What comes next — deactivating plugins in sequence, switching themes, editing core files — should happen on a staging copy, not a live site, and that is where a professional earns their fee.
A Warning About Restoring Backups
Restoring a backup feels like the obvious move. Sometimes it is. But on an active e-commerce site, restoring to yesterday's backup can erase every order, customer account and stock change made since. I have had to reconstruct a weekend of orders from payment gateway records because someone rolled back a WooCommerce store to "fix" a display bug.
If your site takes orders, bookings or form submissions, treat a restore as a last resort — and export your orders table first.
What a Properly Run Emergency Fix Looks Like
"Emergency fix" should mean something specific. Here is how I run an emergency WordPress fix, and it is a reasonable standard to hold any developer to.
- Diagnosis before quoting. I look at the site and the logs before naming a price. A quote given without looking is a guess, and guesses get revised upward halfway through.
- A full backup before any change. Files and database, stored off the server, before a single line is touched. This is non-negotiable regardless of how obvious the fix looks.
- Fix on a staging copy where possible. Live debugging on a trading store is how small problems become large ones.
- A fixed price agreed up front. You approve a number before work starts. If the diagnosis reveals something bigger, you get a written quote and a choice — not a surprise invoice.
- A written explanation at handover. What broke, what I changed, and what will stop it happening again. If your developer cannot explain the cause in plain language, they may have patched a symptom.
Gather Your Access Details First
This is worth being honest about, because it is where most emergency jobs quietly stall. Nobody can start until they have what they need:
- WordPress admin login
- Hosting control panel or SFTP access
- The name of your host and the plan you are on
- A description of when it broke and what changed
Gather those before you send the first message. The difference between a fix that lands quickly and one that drags on is almost never the coding — it is waiting on a password.
How to Stop It Happening Again
Emergency fixes treat the symptom. These habits treat the cause, and none of them require a developer on retainer:
- Automated off-server backups, daily. If your only backup lives on the same server as the site, you do not have a backup. Most decent hosts offer this; several plugins do it for free to cloud storage.
- Update on a staging site first. Even a monthly habit of testing updates on a copy catches the majority of conflict breakages before your customers do.
- Uptime monitoring. Free tools will email you within five minutes of the site going down. Finding out from a customer is both slower and considerably more embarrassing.
- Prune your plugins. Every plugin is a dependency that can break. If you are not using it, delete it rather than deactivating it — inactive plugins still carry security risk.
- Know your PHP version. Ask your host what it is and when it next changes. Ten minutes of preparation beats an unplanned outage.
If your site is generally healthy but slow, clunky or hard to update, the underlying issue may be the build rather than any single fault. That is a different conversation — see the seven signs your website is costing you customers — and usually a better investment than a series of emergency patches.
When to Call Someone
Call immediately, without attempting a fix yourself, if any of the following is true:
- The site takes payments and checkout is affected
- You see evidence of a hack — redirects, unknown admin users, injected spam
- You do not have a recent, verified backup
- You have already tried two or three fixes and the situation has got worse
That last one is not a criticism. It is the most common way a straightforward job becomes a complicated one, and recognising it early saves you money.
The Short Version
Document what you see, stop changing things, gather your access details, and get a diagnosis before you pay for a fix. Most WordPress emergencies are a known problem with a known solution, and the delay is usually process, not difficulty.
If your site is down right now and you would rather hand it to someone: I run WordPress and WooCommerce emergency fixes as small, fixed-price jobs, prioritised ahead of longer project work. Send me the error and your host details and you will get a diagnosis, a fixed price and a delivery date before you commit to anything.
