When your website is down, the problem is almost never a line of code: it is a phone ringing, a contact form that no longer comes through, and three people proposing three different fixes at the same time. The rule that saves the most sites is not technical, it is behavioral: break nothing beyond what is already broken. This article follows the protocol we apply when we are called in, in three stages: observe, isolate, repair. None of these steps asks you to delete anything.
First of all: touch nothing for five minutes
Most of the outages we take over got worse in the quarter of an hour after they appeared: someone deleted a plugin instead of deactivating it, or flushed the server cache just before the error log was read. The cause vanished, the outage stayed. Three reflexes, before any hands-on work, halve the time a diagnosis takes:
- Write down the exact time of the first symptom. Not “this morning”: “9:42”. Logs are read by timestamp, and the right minute is enough to isolate the right line among thousands.
- Write down the last action taken on the site. An update, a publication, a change to the DNS zone, a change of plan at the host. More often than not, the cause is contained in that one sentence.
- Capture the message on screen, in full, address included. It disappears as soon as a cache is flushed, and it does not always come back.
Identify the exact symptom
A site does not simply “go down”: it goes down in a precise way, and that way already points to a family of causes.
White screen or blank page
This is a fatal PHP error that the server has chosen not to display: an incompatible plugin, too little PHP memory, a PHP module gone missing after a version upgrade on the host’s side. To turn that emptiness into a readable message, add these three lines to wp-config.php, before the comment “That’s all, stop editing!”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );The log fills up in wp-content/debug.log, and the last “Fatal error” line gives the offending file, and therefore the name of the plugin. The third constant keeps your server paths from being exposed to visitors while you search (WordPress documentation on debugging).
“There has been a critical error on this website”
WordPress’s own message since version 5.2. The site is not lost: WordPress has detected the error, paused the faulty component and sent a recovery link by email, which opens a stripped-down dashboard naming the culprit. If nobody ever sees that email, it is because it goes to the administration address entered under Settings, then General, often the previous provider’s, and it ends up in the spam folder. The link stays valid for twenty-four hours by default, and WordPress sends only one a day.
Error 500 or 503
The problem is on the server side, and the browser tells you nothing useful: the real information is in the host’s error log. Then look at the .htaccess at the root, often rewritten by a caching plugin, and after that at the resource limits of your plan. If the error comes in waves rather than continuously, it is not an outage but saturation: see diagnosing a slow or overloaded site.
“Error establishing a database connection”
Four causes: changed credentials, database service stopped, server saturated, corrupted table. The credentials can be read in wp-config.php, in DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. Do not change them before asking the host whether the service is running: half the time they are correct and it is the server that is not answering. Overwriting a correct password with a wrong one adds an outage to the outage.
The site displays, but with its layout in pieces
Raw text, images stacked on top of each other: the stylesheets are not loading. Four suspects: the site address stored in the database no longer matching the real address, an expired certificate, content called over HTTP inside an HTTPS page, a corrupted server cache. The certificate deserves a mention of its own: once expired, it does not degrade the display, it makes the site unreachable behind a red warning. Free certificates renew every three months, and an automatic renewal that fails in silence is a commonplace outage.
| Symptom | Most frequent probable cause | First action |
|---|---|---|
| White screen | Fatal PHP error from a plugin | Enable WP_DEBUG_LOG and read debug.log |
| “Critical error” | Incompatible plugin or theme | Look for the recovery email, spam folder included |
| Error 500 | .htaccess or server limit | Read the host’s error log |
| Error 503 in waves | PHP processes saturated | Compare with the traffic curve |
| Database error | Service stopped or saturated | Ask the host before touching wp-config.php |
| Layout in pieces | Expired certificate or wrong site address | Check the certificate date |
The four checks that settle half of all cases
Before touching a single file, four free checks, ten minutes.
- Domain, certificate, invoice. An expired domain cuts off the site and the email in one go, which makes the diagnosis disorienting. Check the expiry date with your registrar, the validity of the certificate in the browser’s padlock, the state of your invoices. An invoice three weeks overdue is a commonplace cause of an outage.
- The host’s status page. If an incident is declared there, stop searching: anything you change during the incident will muddy the diagnosis afterwards.
- Is the outage visible from elsewhere? Test from a phone on mobile data, Wi-Fi off, in a private window. If the site displays, the problem is local: your browser cache or your network’s DNS resolution.
- Has an update run in the last twenty-four hours? WordPress applies minor core patches automatically, and many plugins update themselves. The list can be read under Dashboard, then Updates. If so, follow instead what to do when a WordPress update broke your site.
Isolate the cause without deleting anything
When those checks turn up nothing, you have to isolate: cut wide, observe, narrow by halves. Only one verb is allowed, rename, never delete. A deleted plugin sometimes takes its data with it; deactivated, it loses nothing.
Over FTP or from the host’s file manager, rename the wp-content/plugins folder to plugins-off: WordPress can no longer find any plugin and deactivates them all, without losing their settings. If the site comes back, the cause is in there. Put the original name back, then reactivate by halves: with twenty-four plugins, bisection names the culprit in five attempts. Same logic for the theme, by renaming its folder in wp-content/themes. With SSH access, WP-CLI does the same thing more cleanly:
wp plugin deactivate --all
wp theme activate twentytwentyfour
wp plugin activate plugin-nameBack online properly rather than quickly
Getting a site back on its feet and getting it back in working order are two different things: a site that displays because the payment plugin is deactivated is not repaired, it is amputated. List what was deactivated before declaring the incident closed.
Restoring a backup is a choice, not a magic button: it takes you back to the day of the backup, and the orders received since then are lost. Painless on a brochure site, a twenty-four-hour rollback wipes out a day of sales on a store. Ask the question before you click: what exactly do we lose?
While the work is under way, serve a maintenance page rather than a raw error, and a page that answers with a 503 status code and a Retry-After header. That is what WordPress does during its own updates, through the .maintenance file, which returns a 503 Service Unavailable (MDN, page in French) with a Retry-After: 600. A maintenance page that answers 200 tells the search engines that this empty content is the definitive version of your home page: that is how SEO gets lost during an outage, not because of the outage itself.
After the outage: the report that prevents a repeat
An outage repaired without a report will happen again, because nobody will know what was done. Five lines, written the same day:
- Symptom: what was visible, and from what time.
- Cause identified: the plugin, the PHP version, the certificate, the quota.
- Fix applied: what was changed, deactivated or restored.
- Consequence for the data: what was lost, and over what window of time.
- Preventive measure: what will stop the same outage coming back.
On that last line, three measures come up every time. A backup stored away from the main server and restored at least once, because a backup never tested is only a hypothesis. A staging site, so that no update ever plays out live. Monitoring that tests the site every minute: that is the difference between learning of the outage from a tool at 3:12am and from an unhappy customer at 10:30am. Those foundations are detailed in the eight essential WordPress security measures and in what happens when maintenance is ignored.
Our position: when to hand over
We do not think a business owner should have to learn to debug PHP, but we do think they should recognize the moment when carrying on alone costs more than making the call. Five criteria, with no ambiguity:
- Thirty minutes without the slightest progress on the diagnosis.
- The outage involves the database, where mistakes are irreversible.
- Unknown redirects, pages that are not yours, administrator accounts you did not create: this is no longer an outage but an intrusion (Cybermalveillance.gouv.fr quick reference sheet, in French).
- The site sells, and it is the middle of the working day.
- No recent backup exists, or nobody knows whether it works.
What ticket-based technical support does: the case picked up and timestamped, secure access granted then revoked, a documented diagnosis rather than a run of attempts, the site back online, a written report. That last point is what separates an intervention from a quick fix: after a quick fix you are back online, after an intervention you know why you went down. With us, a support ticket is €89 and the pack of five tickets €399 (VAT not applicable, article 293 B of the French tax code): a fixed price rather than an hourly rate, because when a site is down, nobody wants to be watching the meter.
Conclusion
The outage is never the real problem: the real problem is the absence of a safety net. Without a tested backup, a staging site and monitoring, the smallest incident becomes a catastrophe; with all three, it becomes a twenty-minute interlude. If you are reading these lines with a site down, start with the four checks: half the time, they are enough.
Also worth reading: how to secure a WordPress site, step by step and website backups that actually work
Open a support ticket Have my site diagnosed
