How to Recover a Broken WordPress Site

A WordPress site can break in five distinct ways. The recovery process depends on which one you’re facing. This guide walks through how to identify the failure mode and the working fix for each.

Step 1: Identify the Failure Mode

Visit the site. What do you see?

A) White screen, no content. “White Screen of Death.” Usually a PHP fatal error.

B) Error message naming a specific file. Often “Fatal error: … in /wp-content/plugins/xyz/file.php on line N.” The error tells you exactly which file failed.

C) “Briefly unavailable for scheduled maintenance” that doesn’t go away. WordPress got stuck mid-update.

D) Database connection error. “Error establishing a database connection.” MySQL connection failed.

E) Site loads but admin doesn’t. Front-end works; /wp-admin/ returns errors or redirects in a loop.

F) Site loads slowly and times out. Server overload, plugin loop, or hosting issue.

Each has a different triage path.

Failure A & B: PHP Fatal Error (White Screen or Error Message)

Step 1: Enable WordPress debug mode.

Edit wp-config.php via FTP/SFTP. Find define('WP_DEBUG', false); and change to:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Reload the site. The error is now written to /wp-content/debug.log. Read the log; the error names the specific plugin or theme file causing the failure.

Step 2: Deactivate the offending plugin or theme.

If a plugin is causing the error, rename its folder via FTP: /wp-content/plugins/[plugin-name]/ to /wp-content/plugins/[plugin-name]-OFF/. WordPress will deactivate it automatically. Reload the site.

If a theme is causing the error, rename its folder similarly. WordPress will fall back to a default theme.

Step 3: Identify why the plugin/theme failed.

Common causes:

• Recently updated and incompatible with current WordPress or PHP version.
• PHP version on the server was upgraded and the plugin is incompatible.
• Conflict with another recently-updated plugin.
• Corrupted plugin files from an interrupted update.

Step 4: Fix or replace.

Download a fresh copy of the plugin from WordPress.org (or the vendor). Replace the files via FTP. Reactivate. If it works, the original copy was corrupted. If it doesn’t, the plugin is incompatible — wait for a fix or replace the plugin.

Failure C: Stuck in Maintenance Mode

WordPress creates a .maintenance file at the root during updates. If an update fails partway through, this file is left behind and the site shows “Briefly unavailable for scheduled maintenance.”

Fix: Connect via FTP and delete the .maintenance file from the root of the WordPress install.

After removing the file, the site should load. The interrupted update may have left things in a half-applied state; check whether the update needs to be re-run or rolled back depending on what was updating.

Failure D: Database Connection Error

Possible causes:

1. Database server is down. Check with your host.
2. Database credentials in wp-config.php are wrong (somebody changed something).
3. Database is corrupted.
4. Site exceeded its database connection limit (common on shared hosting under traffic spikes).

Triage:

1. Confirm with your host whether the database server is operational.
2. Open wp-config.php and confirm DB_HOST, DB_USER, DB_PASSWORD, DB_NAME match what’s set in the hosting control panel.
3. If credentials are correct, try the WordPress automatic database repair: add define('WP_ALLOW_REPAIR', true); to wp-config.php, then visit yoursite.com/wp-admin/maint/repair.php. Remove this line from wp-config after the repair completes — leaving it exposes a vulnerability.
4. If connection limit is the issue, the host needs to bump the limit or the site needs to move to better hosting.

Failure E: Front-End Works, Admin Doesn’t

Usually one of:

1. A plugin that hooks into admin specifically is failing.
2. wp-admin files are corrupted.
3. A redirect plugin or security plugin is misconfigured.
4. User account is corrupted.

Triage:

1. Try /wp-login.php directly. If it works, the issue is admin-specific. If it doesn’t, the issue is broader.
2. Deactivate all plugins via FTP (rename /wp-content/plugins/ to /wp-content/plugins-OFF/, then create a new empty plugins folder). Try admin.
3. If admin works with plugins deactivated, re-enable one at a time to identify the culprit.
4. If admin doesn’t work even with plugins deactivated, re-upload fresh /wp-admin/ and /wp-includes/ files from a fresh WordPress download matching your version.

Failure F: Site Loads Slowly / Times Out

The slow load isn’t a “broken” site in the strict sense, but it produces the same effect for users.

Triage:

1. Check your host’s resource usage dashboard. If CPU or memory is pegged, hosting is the bottleneck.
2. Check for runaway plugins: a misconfigured backup plugin running constantly, a security scanner stuck in a loop, a cron job that doesn’t terminate.
3. Check the database: slow queries can cause whole-site timeouts. Hosting providers usually expose slow query logs.
4. Check for an active DDoS or scraping attack: sudden traffic from one IP range or one country.
5. Disable plugins one by one to identify any that’s eating resources.

If the cause isn’t immediately obvious, this is the failure mode most likely to need professional triage — the symptoms are systemic, the causes can be subtle.

When to Escalate

The honest decision points for calling a professional:

• The site is generating revenue and every hour costs real money.
• You’ve spent more than two hours on triage and the issue isn’t narrowing.
• The error log mentions files you don’t recognize or paths that aren’t standard WordPress.
• You’ve made changes during triage and aren’t sure how to undo them.
• The site is on a managed host where you don’t have full server access.

Synergetic’s Emergency WordPress Diagnostic is built specifically for this: fixed price, engineer triage within 24 hours, scope confirmed before any further work begins. Diagnostic-first means you pay for the diagnosis whether or not the fix is in scope, which prevents the “we’ll just have to keep digging” billing pattern that hourly emergency work produces.

The decision rule for when to call: When to Call Emergency WordPress Help.

After Recovery: Prevent the Repeat

A site that broke once will break again unless something changes. The standard preventive measures:

• A reliable backup with verified restoration (so the next break isn’t a recovery emergency).
• Regular updates with staging testing (so updates don’t break things on production).
• Uptime monitoring with response architecture (so you find out before customers do).
• Documented credentials and access (so triage isn’t slowed by missing logins).

A WordPress care plan bundles all of these. For sites with a history of breaks, the math on prevention vs. another emergency is usually decisive.

For specific plugin conflict triage: WordPress Plugin Conflict Diagnosis.