WordPress site down? A first-30-minutes emergency checklist

When a production WordPress site suddenly breaks, the first objective is not to try every fix you can find. It is to identify the failure, preserve useful evidence, avoid making the outage worse, and choose the safest recovery path.

Minute 0–5: establish what is actually down

“The website is down” can describe several very different failures. Before changing plugins, restoring files, or editing configuration, narrow the scope.

• The whole domain is unreachable: browser timeout, DNS error, connection refused, or hosting error page.
• WordPress loads a critical-error message: often a PHP fatal caused by a plugin, theme, custom code, or compatibility problem.
• The frontend works but wp-admin does not: login, permissions, security rules, cookies, or an admin-only code path may be involved.
• wp-admin works but the public site fails: theme, caching, frontend code, routing, or a public-facing plugin may be the trigger.
• Only one workflow is broken: checkout, payments, forms, search, subscriptions, or an integration may have failed while WordPress itself remains online.

Check the site from another network or device if practical. If possible, also check the hosting control panel or server status independently of WordPress. That helps separate an application failure from a DNS, network, or hosting outage.

Minute 5–10: record the symptoms before changing anything

Capture the exact message, affected URL, approximate time the problem started, and what changed immediately beforehand. A screenshot and a short timeline can save much more time than a vague note that “WordPress stopped working.”

Useful questions include:

• Was WordPress Core, a plugin, a theme, PHP, or the server updated?
• Was new code deployed?
• Did the host change PHP, database, firewall, or caching settings?
• Did DNS, SSL, Cloudflare, or a reverse proxy change?
• Was a plugin activated, deactivated, or configured differently?
• Did the problem appear during checkout, cron, imports, or another scheduled task?

If the outage started immediately after a known change, that does not prove the change is the only cause, but it gives you a much better starting point than disabling everything at random.

Minute 10–15: check the safest evidence sources

1. WordPress Recovery Mode

WordPress has a built-in Recovery Mode for some fatal PHP errors. When it activates, the administrator email address may receive a special recovery link and information about the component that failed. In Recovery Mode, the faulty plugin or theme can be paused for your administrator session so you can investigate without blindly modifying the whole installation.

2. PHP and server error logs

A critical error or HTTP 500 response is far more useful when you can see the corresponding PHP or web-server error. Check the hosting control panel, PHP logs, application logs, or your normal observability system before replacing files.

3. WordPress debug logging

WordPress provides WP_DEBUG and WP_DEBUG_LOG for troubleshooting. On a production site, do not expose raw warnings and stack traces to visitors. When temporary debugging is needed, logging errors while keeping display disabled is safer than printing them publicly, and debugging should be disabled again when the investigation is finished.

Minute 15–20: route the incident by symptom

“There has been a critical error on this website”

Start with Recovery Mode and the fatal-error logs. Plugin, theme, custom-code, PHP-version, or memory-related failures are common causes. If the failing component is clear, disabling only that component is preferable to making a large number of unrelated changes at once.

White screen or blank response

Treat it similarly to a critical error: look for PHP fatal errors, resource exhaustion, or output failures. Modern WordPress often shows a critical-error screen instead of the classic white screen, but blank responses can still occur depending on the server and failure mode.

“Briefly unavailable for scheduled maintenance” never disappears

WordPress creates a temporary .maintenance file during updates. If the process is interrupted, that file can remain behind. Removing a stale file may clear the maintenance message, but that is only the first step: confirm whether Core, plugin, or theme files were left partially updated and test the site afterward.

403 Forbidden

A 403 means the request reached the server but access was denied. Common areas to inspect include file permissions and ownership, web-server rules, security plugins, WAF or CDN rules, blocked IP ranges, and hosting security controls. A 403 is not automatically evidence of malware.

500 Internal Server Error

A 500 is a broad server-side failure. PHP fatals, corrupted or incompatible configuration, plugin/theme code, exhausted resources, and server rules can all produce it. The server or PHP log is usually more useful than the browser message itself.

Too many redirects / redirect loop

Check WordPress URL settings, HTTPS/proxy configuration, caching, redirect plugins, CDN rules, and web-server redirects. If the redirect is conditional, sends visitors to unrelated domains, appears only for search traffic or mobile users, or returns after being “fixed,” investigate the possibility of a malicious redirect rather than assuming it is a configuration loop.

Locked out of wp-admin

Separate an ordinary login problem from an authorization or security problem. Password issues, cookie/domain mismatches, security-plugin lockouts, broken login customizations, and role changes can all block access. Unfamiliar administrator users or unexpected role changes are a different category and deserve a security review.

WooCommerce checkout or payments stopped working

Do not treat this like a cosmetic frontend issue. Check recent plugin and theme updates, payment-gateway logs, JavaScript errors, WooCommerce logs, scheduled actions, webhooks, API failures, and whether orders are partially created even when the customer sees an error. Protecting order and payment data matters more than making the page “look fixed” quickly.

Minute 20–25: preserve a recovery point

Before substantial repairs, preserve the current files and database whenever access allows it. This is not the same as blindly restoring a backup. The current state can contain useful evidence and, on transactional sites, newer business data that does not exist in yesterday’s backup.

A backup taken after the failure can still be useful as a forensic and rollback point. If you already have a known-good backup, note its timestamp and what data would be lost if you restored it.

Minute 25–30: choose the smallest safe recovery action

At this point, you should have a symptom, a timeline, and ideally an error or suspicious change to investigate. Choose the narrowest action that tests the most likely cause.

1. Known failed plugin/theme update: isolate or roll back that component rather than changing unrelated parts of the site.
2. Stale maintenance mode: remove the stale maintenance state, then verify the interrupted update completed correctly.
3. PHP fatal with a clear component: disable or fix that component, then retest the exact failed workflow.
4. Hosting or server outage: work from the infrastructure layer instead of changing WordPress unnecessarily.
5. Unclear or suspicious incident: preserve evidence and investigate before replacing files or restoring backups.

When to stop DIY troubleshooting

Trial-and-error is most dangerous when the site is transactional, the failure is recurring, or you no longer know which changes caused which result. Stop and get experienced help when:

• checkout, payments, subscriptions, or order processing are affected
• you would need to restore a database and are unsure what recent data would be lost
• the error returns after apparently being fixed
• you cannot access both WordPress and the hosting/server tools
• multiple plugins or custom components fail after a PHP/server change
• you see unfamiliar users, unexpected files, spam pages, malicious redirects, or hosting malware warnings

For production outages without clear signs of compromise, WordPress emergency support is the appropriate path. The goal is to diagnose the root cause, restore the site safely, and verify the affected workflow instead of applying a temporary workaround and hoping the problem does not return.

When the outage may actually be a security incident

A broken site and a hacked site can overlap, but they are not the same thing. A failed update, PHP fatal, or server error should not automatically be labelled malware. Security investigation becomes more appropriate when there are additional indicators such as:

• unknown administrator or privileged users
• unexpected PHP files or recently modified Core files
• redirects to unrelated domains
• spam or SEO pages appearing in search
• malware alerts from the host, browser, or security tooling
• files that return after being deleted
• scheduled tasks or cron jobs you did not create

In that situation, use the WordPress hacked-site checklist and treat cleanup as an investigation into persistence and root cause. If compromise is confirmed, WordPress malware removal should preserve evidence and close the original entry point rather than just deleting visible files.

What not to do in the first 30 minutes

• Do not bulk-update everything while you are still trying to identify which change caused the failure.
• Do not restore an old production database casually on WooCommerce or other data-changing sites.
• Do not delete suspicious files before preserving evidence if compromise is possible.
• Do not expose debug output publicly just to get a more detailed browser error.
• Do not assume a 403, 500, or critical error automatically means malware.
• Do not keep stacking fixes without testing after each change; otherwise you lose the ability to identify what actually solved the problem.

FAQ

The practical takeaway

The first 30 minutes of a WordPress outage are primarily about diagnosis. Establish the scope, record what changed, read the logs, preserve a recovery point, and make the smallest reversible change that tests the most likely cause.

That approach is slower than clicking random fixes for five minutes, but much faster than turning one production failure into several overlapping problems.