Fix WordPress Errors in Minutes, A UK Technician’s Playbook

fix WordPress errorsThe fastest way to fix WordPress errors is to check your admin email for a recovery mode link first, then disable plugins via SFTP if there’s no email. Most white screens, critical errors, and 500 errors trace back to a single plugin or theme conflict. Once you isolate it, your site or admin area comes back within minutes. If you get stuck, professional web design agencies offer rapid repair support and starter website packages for anyone who’d rather hand the fix to a professional.

TL;DR:

• A recovery mode link from WordPress email allows deactivating problematic plugins or themes without file access, speeding up fixes.
• White Screen of Death is usually caused by a PHP fatal error, which can be diagnosed by enabling debug logs and testing theme and plugin deactivation.
• Critical errors and 500 server errors often relate to plugin, theme, .htaccess, or permission issues, which require specific step-by-step troubleshooting.
• A database connection error typically involves verifying wp-config.php credentials and testing server responsiveness before repairing tables.
• Frequent errors can be mitigated by regular backups, staged updates, and monitoring site health, reducing the need for emergency fixes.

Table of Contents

• How to identify the type of WordPress error (quick triage)
• White Screen of Death (WSoD): step-by-step fixes
• Critical error message and recovery mode
• Internal Server Error (500): causes and fixes (.htaccess, permissions, re-install core)
• Error establishing a database connection: wp-config and host checks
• Connection timed out, memory and execution limits
• Failed auto-upgrade and maintenance mode
• Pretty permalinks 404s and images not working
• How to read and use logs and WP_DEBUG effectively
• Prevention and safe practices: backups, staging and update protocol
• How InteractiveWebsite diagnoses a WordPress error
• What actually matters when your WordPress site breaks
• Need it fixed today rather than diagnosed yourself?
• Sources

How to identify the type of WordPress error (quick triage)

Every WordPress error leaves clues. Before you touch a file, work out which type you’re dealing with, because each one needs a different fix.

Start by looking at what you actually see on screen:

• Completely blank white page with no text at all — usually the White Screen of Death, caused by a PHP fatal error.
• “There has been a critical error on this website” — WordPress caught a fatal error and may have emailed you a recovery link.
• “500 Internal Server Error” — a server-level failure, often tied to .htaccess or a corrupted core file.
• “Error establishing a database connection” — WordPress can’t talk to its database at all.
• Part of the site loads but styling or images break — usually a mixed content issue or a permissions problem, not a fatal error.
• wp-admin loads fine but the front end doesn’t (or vice versa) — points to a theme or caching issue rather than a core failure.

Once you’ve spotted the symptom, gather evidence before acting. Check your admin email inbox for a WordPress recovery notice, note the exact HTTP status code your browser shows, and log into your hosting control panel to check its error log. If wp-admin is reachable, that alone tells you plugins and the database are probably fine, which narrows the search considerably.

This evidence decides your next move. A blank page with no email points you towards the White Screen of Death fixes below. A named plugin in a recovery email sends you to the critical error section. A database message sends you straight to the database connection checks. Matching symptom to section saves you from trying fixes that were never going to work.

White Screen of Death (WSoD): step-by-step fixes

A blank white screen with no error text is almost always a PHP fatal error that WordPress can’t display because error output is switched off. WordPress.org’s own troubleshooting guidance and a tested nine-method checklist from Kinsta both point to the same order of operations.

1. Check for a Recovery Mode link first. If WordPress detected the fault itself, it may have emailed you a special link that opens a limited admin view where you can deactivate the specific plugin or theme responsible, no file editing required.
2. Rename the plugins folder via SFTP if there’s no email and wp-admin is inaccessible. Connect with an SFTP client, navigate to wp-content, and rename plugins to something like plugins-off. This deactivates every plugin at once.
3. Switch to a default theme. If plugins weren’t the problem, rename your active theme’s folder or activate Twenty Twenty-Four through the database if you can reach phpMyAdmin, which rules out theme code as the cause.
4. Enable debug logging by adding the WP_DEBUG constants to wp-config.php, then reload the broken page once and open wp-content/debug.log to see the exact file and line that failed.
5. Increase PHP memory temporarily as a stopgap. This often restores access immediately, but treat it as triage, not a cure, until you’ve found which plugin is actually hungry for memory.

Pro Tip: Rename the plugins folder rather than deleting files inside it. Once you’ve confirmed a plugin is the culprit, rename the whole folder back, then rename each individual plugin’s subfolder one at a time until the white screen returns. Whichever folder you just renamed is your suspect.

An unusually long blog post can also trigger a blank page by hitting PHP’s text-processing limits, which is worth ruling out if everything else checks out clean.

Critical error message and recovery mode

“There has been a critical error on this website” is WordPress’s fatal-error protection kicking in deliberately, rather than the site simply breaking. When it triggers, WordPress can send an email to the site admin containing a special recovery link. That link opens a stripped-down admin session built specifically to let you deactivate the offending plugin or theme without needing SFTP at all.

Once you’re in recovery mode:

• Look for the plugin or theme WordPress names as the likely cause; it usually appears directly in the recovery screen.
• Deactivate it, then check whether the site loads normally again.
• If it’s a plugin, check for an update before reactivating, or roll back to the previous version if the update caused the problem.
• Test the front end and wp-admin separately before declaring it fixed.

If no recovery email ever arrived, check your spam folder, then fall back to manually renaming the plugins folder via SFTP and enabling WP_DEBUG_LOG to catch the same fatal error the email would have described.

Internal Server Error (500): causes and fixes (.htaccess, permissions, re-install core)

A 500 error is a generic server failure, which makes it the trickiest to diagnose blind. Work through these checks in order, because each one rules out a major cause before you move to the next.

1. Rename .htaccess to .htaccess-old via SFTP, then visit Settings > Permalinks in wp-admin and click Save to regenerate a fresh, clean version. A corrupted .htaccess file is one of the most common 500 triggers.
2. Check file and folder permissions. WordPress expects folders at 755 and files at 644; anything looser or tighter can trigger a server-level refusal.
3. Re-upload fresh copies of wp-admin and wp-includes from a clean WordPress download, leaving wp-content untouched. WordPress.org confirms this resolves corruption introduced by a failed update without touching your content or media.
4. Raise PHP memory in wp-config.php if the error log shows exhaustion rather than a syntax fault.

If none of that clears it, contact your host with the exact error log timestamp and the request URL that triggered the 500. Hosts can usually pull server-side logs your own dashboard doesn’t show.

Error establishing a database connection: wp-config and host checks

This message means WordPress can’t reach its database, and the fault sits in one of three places: your credentials, the database server itself, or corrupted tables.

Start with wp-config.php. Confirm these four constants match exactly what your hosting control panel shows:

• DB_NAME — the database name
• DB_USER — the database username
• DB_PASSWORD — the password, with no stray spaces or quotation marks
• DB_HOST — often localhost, but some hosts require a specific server address

If those all look correct, test connectivity directly. A short PHP script using mysqli_connect() or a login attempt through phpMyAdmin tells you whether the database server itself is responding.

If credentials are right and phpMyAdmin still won’t connect, the fault is on the hosting side. WordPress.org’s troubleshooting FAQ recommends contacting your host directly at this point, since persistent failures with correct credentials often indicate a server problem or, occasionally, a compromised site. If phpMyAdmin loads but tables look damaged, WordPress’s built-in repair tool (accessed by adding WP_ALLOW_REPAIR to wp-config.php) can fix corrupted tables, or you can restore from your last known-good backup.

Connection timed out, memory and execution limits

A timeout usually means a script is running longer than the server allows, or a process has exhausted available memory. Both are fixable without touching code.

• Raise WordPress memory by adding define('WP_MEMORY_LIMIT', '256M'); to wp-config.php. Note that some hosts cap memory at the server level regardless of what you set in WordPress, so check your hosting plan’s limits too.
• Increase max execution time through php.ini or a .user.ini file if you have access, giving long-running tasks (large imports, big searches) more time to finish before the server cuts them off.
• Identify the resource-hungry culprit by disabling plugins one at a time, or moving a copy of the site to a staging environment where you can test freely without risking the live site.

Pro Tip: Raising memory fixes the symptom, not the cause. If the same plugin keeps needing more memory every few months, that’s a sign to replace it rather than keep raising the ceiling.

Failed auto-upgrade and maintenance mode

A stuck “Briefly unavailable for scheduled maintenance” message means an update was interrupted, usually by a timeout or a lost connection, and WordPress never removed its lock file.

1. Connect via SFTP and delete the .maintenance file from your site’s root directory. This alone clears the message immediately.
2. Check whether the update actually completed. If core files look incomplete, re-upload a fresh WordPress copy; if a plugin update failed, reinstall it from the WordPress.org repository or restore your last backup.
3. Verify site health afterwards: load the front end, log into wp-admin, check that recent posts and media still display, and confirm plugins are all showing the correct version.

Pretty permalinks 404s and images not working

If posts and pages suddenly return 404 errors, your rewrite rules have likely broken, usually after a server change or a corrupted .htaccess file.

Go to Settings > Permalinks and click Save Changes without altering anything. This forces WordPress to regenerate .htaccess from scratch and usually fixes the problem in seconds.

If that doesn’t work, or the button seems to save without effect, ask your host whether mod_rewrite is enabled on your server. Without it, pretty permalinks can’t function at all, regardless of what WordPress does on its end.

• Manually replace .htaccess with WordPress’s default rewrite block if regenerating through wp-admin fails.
• Check upload folder permissions if images specifically return 404s while pages work fine; a folder locked to the wrong permission level blocks image delivery even though the file exists.
• Rule out caching or CDN plugins serving stale rewrite rules from before the fix.

How to read and use logs and WP_DEBUG effectively

Guessing wastes time; the debug log tells you exactly what broke and where. Add these two lines to wp-config.php, just above the line that reads /* That's all, stop editing! */:

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

• WP_DEBUG_LOG writes every PHP error, warning, and notice to wp-content/debug.log, without showing anything to site visitors.
• WP_DEBUG_DISPLAY set to false keeps errors out of the public-facing site, which matters on a live production site.
• Reproduce the error once, then open debug.log and look for the first fatal error entry. The initial fatal error in the log typically names the exact plugin file and line number responsible, even when several errors cascade after it.
• Also check your host’s server-level error log (often called an “error_log” file), which sometimes catches faults that never reach WordPress’s own logging.

Turn WP_DEBUG_DISPLAY back to false and clean up the debug log once you’ve fixed the issue, since leaving detailed errors visible or logged indefinitely is a minor security risk on a public site.

Prevention and safe practices: backups, staging and update protocol

Most of the errors above are preventable with three habits.

• Run scheduled, tested backups covering both files and the database, and actually restore one occasionally to confirm it works before you need it in an emergency.
• Use a staging environment for updates. Test WordPress core, then your theme, then plugins, one at a time, checking the site after each step rather than updating everything simultaneously.
• Keep your admin recovery contact current. Confirm the email address WordPress uses for recovery notices is one you actually check, and that you can access it without needing the broken site to do so.

Pro Tip: Update plugins one at a time on a staging copy first, not all at once on the live site. It takes longer, but it turns a mystery multi-plugin conflict into an obvious single-plugin problem.

How InteractiveWebsite diagnoses a WordPress error

A recent case landed on our desk as a full white screen with no admin access at all. The recovery email hadn’t arrived, so we went straight to SFTP, renamed the plugins folder, and the site came straight back. Enabling WP_DEBUG_LOG afterwards confirmed a single outdated caching plugin was the fault; we replaced it and restored full functionality within the hour.

That kind of diagnosis is routine work for us. Web design agencies often have experience launching websites for freelancers and small businesses, with clients sometimes seeing noticeable increases in traffic within their first months. Local SEO and site performance are common focus areas, so speed fixes like this tend to be routine rather than guesswork.

What actually matters when your WordPress site breaks

Most WordPress troubleshooting guides bury the fastest fix under ten paragraphs of theory. That’s backwards. The recovery mode email, when it arrives, does more diagnostic work in one click than most people manage in an hour of manual searching, because WordPress has already identified the plugin or theme for you.

Where conventional advice falls short is in treating every error as equally mysterious. It isn’t. A blank page, a 500 error, and a database error are three different failure categories with three different first moves, and conflating them wastes the exact minutes that matter when a business site is down and losing enquiries.

Prioritise evidence over instinct. Check the email, check the log, check the status code, in that order, before touching a single file. Debug logging isn’t an advanced technique reserved for developers; it’s the single fastest way to stop guessing and start fixing. Everything else, staging environments, phased updates, tested backups, exists to make sure you rarely need this playbook at all.

— Mario

Need it fixed today rather than diagnosed yourself?

If your site’s down and you don’t have the time or nerve to start renaming folders over SFTP, InteractiveWebsite can take it off your hands. Unlike a freelancer juggling a dozen tickets, we work London small businesses and startups directly, which means faster turnaround and someone who actually answers the phone. Our Starter Website package covers 1 to 3 pages built fresh for £499 £424.15, ideal if a broken site has convinced you it’s time to rebuild rather than patch.

Professional help makes the most sense in three situations: your site’s been hacked rather than simply broken, you don’t have a working backup to fall back on, or you’re facing a deadline that a few hours of trial-and-error could blow. Get in touch through our website development services page, tell us what’s broken and when you need it fixed, and we’ll take it from there.

Sources

For further reading, WordPress.org’s common errors page covers most fixes in official detail. The debug-log-manager plugin simplifies reading logs without SFTP, and FileZilla remains the standard free SFTP client for file-level work. If you contact hosting support, always include the exact log excerpt and timestamp; it saves several back-and-forth messages.

• Common WordPress errors
• How to fix a critical error in WordPress
• How to Fix the WordPress White Screen of Death | Linuxize
• 9 Proven Methods to Fix the WordPress White Screen of Death

Recommended

• Transform Your Business with Expert Website Development in London

Written with BabyLoveGrowth to get discovered by AI