How to Access WordPress Admin with a Fatal Error Warning

You can access WordPress admin with a fatal error warning by using Recovery Mode first, then switching to FTP based fixes if Recovery Mode isn’t available. Most support tickets about this exact error get solved in under fifteen minutes. That’s usually without touching a single line of code.

Here’s what nobody tells beginners. Panicking and randomly deleting plugin folders almost always makes the fatal error harder to trace, not easier. The fix works best when you follow it in order.

This guide walks you through eight numbered fixes. Each one starts with the safest option and ends with a full backup restore. Every sub-step includes a screenshot-ready action, so you can follow along even on your first FTP login.

What Is a WordPress Fatal Error Warning?

A WordPress fatal error warning is a message that appears when PHP, the language WordPress runs on, hits code it can’t execute. The result is usually a blank white screen or a message reading “There has been a critical error on this website.”

WordPress core, every theme, and every plugin rely on PHP to load correctly. When one file breaks, the whole page fails to render. This is sometimes called the white screen of death, though sites running WordPress 5.2 or later usually show text instead of a blank page.

Common triggers include a bad plugin update, a theme conflict, an outdated PHP version, or a server that ran out of memory. Understanding how WordPress and PHP work together makes the rest of this guide easier to follow, and our guide on how WordPress and PHP work together covers the basics if you’re new to the platform.

Before You Start: What You’ll Need

You need four things before touching any fix below. Gather these first so you’re not searching for logins mid-fix.

• FTP or File Manager access, found in your hosting control panel, usually under “Files”
• Your WordPress admin email inbox, since WordPress sends Recovery Mode links here
• A recent backup, if your host keeps one automatically
• Ten to fifteen minutes without a break.

Most hosts, including Bluehost, SiteGround, and Hostinger, place File Manager right on the main dashboard screen. Look for a folder icon or the word “Files.”

Step 1: Read the Error Message First

Before you fix anything, read what the error actually says. This single step saves the most time, and it’s the one most guides skip entirely.

1. Go to the dashboard where the fatal error shows. Search the error text for the word “in,” followed by a path like /wp-content/plugins/.
2. A path pointing /wp-content/plugins/ means a plugin is the problem, whereas /wp-include Or /wp-admin  Usually means a core file issue.
   

Step 2: Access WordPress Admin with a Fatal Error Warning via Recovery Mode

WordPress Recovery Mode is the safest way back in. It pauses the broken plugin or theme just for your login session.

1. Open the inbox tied to your WordPress admin email and look for a message titled “Your Site is Experiencing a Technical Issue.” WordPress introduced Recovery Mode in version 5.2 to stop fatal errors from locking admins out completely. See WordPress’s Recovery Mode documentation for more.
   
2. Click the link in the email. It takes you straight to your login screen. Enter your normal WordPress credentials as usual.
   
3. If no email arrived, use the manual Recovery Mode URL: yourdomain.com/wp-login.php?action=entered_recovery_mode.
   
4. Once you’re in, WordPress shows a banner naming the broken plugin or theme. Click Manage Plugins or Manage Themes and deactivate the flagged one
   

Recovery Mode only pauses the broken code for your own login session, so other visitors to your site won’t notice a change while you work. Log out, then log back in normally to confirm the fatal error warning is gone.

Limitation: Recovery Mode won’t trigger for errors that happen during background tasks like cron jobs. If your error only shows up during scheduled processes, skip ahead to Step 3.

Step 3: Deactivate Plugins via FTP or File Manager

If Recovery Mode didn’t work, or the error is blocking your whole site, you can still access WordPress admin with a fatal error warning through FTP instead.

1. Open FileZilla, Cyberduck, or your Site’s File Manager.
   
2. Once connected, open the /wp-content folder, then open /plugins. You’ll see a folder for every plugin installed on your site.
   
3. Right-click the /plugins folder and rename it to something like /plugin-disabled. This deactivates every plugin at once.
   
4. Go back to /yoursite.com/wp-admin and log in. If the fatal error warning is gone, a plugin caused it.
   
5. Rename the folder back to /plugins. Then open your Plugins page and reactivate each one individually, checking your site after every single activation.
   

The plugin that brings the error back is the cause. Delete or replace it once you’ve confirmed which one it is.

Step 4: Switch to a Default WordPress Theme

Using the same FTP connection, follow these steps to check if your theme is the cause:

1. Open /wp-content, then open /themes.
   
2. Find your current theme’s folder and rename it. For example, change /mytheme to /mytheme-old.
   
3. Reload your site. WordPress automatically switches to a default theme, such as Twenty Twenty-Four, once it can’t find your active one.
   

If the error clears, contact your theme developer or restore your original theme from a backup copy.

Step 5: Increase the PHP Memory Limit

A fatal error can also happen when a script runs out of memory. Raising the limit often solves it with one small edit.

1. Open your site’s root folder and find /wp-config.php. Right-click and choose Edit, or download it to your computer first.
   
2. Paste this line just above the comment that says “That’s all, stop editing”:

define( 'WP_MEMORY_LIMIT', '256M' );

3. Save the file, upload it back if you edited it locally, then reload your site.
   

Note: Some hosts limit memory limits at the server level, so this line won’t change anything on its own. In that case, contact your host and ask them to raise the PHP memory limit directly on their end.

Step 6: Turn On Debugging to Find the Exact Cause

If you’re still stuck, WordPress debugging shows you exactly which file and line number broke.

1. In the same wp-config.php file, add these three lines:

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

WordPress’s own debugging documentation explains that enabling WP_DEBUG_LOG writes every PHP notice, warning, and fatal error to a dedicated file instead of displaying them publicly. Full details are in the WordPress debugging documentation.

2. Visit your site once more. This triggers WordPress to start writing errors to a log file instead of showing them to visitors.
   
3. In the site folder, open /wp-content and look for a new file called debug.log. The first entry at the top usually names the exact cause, down to the file and line.
   
4. Once you know the cause, change WP_DEBUG back to false. Leaving debugging on exposes site details you don’t want visible to visitors.
   

Step 7: Check for Malware

A fatal error caused by injected code looks identical to a normal plugin conflict, so don’t skip this check.

1. Watch for signs that malware is the cause: unfamiliar admin users, strange redirects, or files you don’t recognise inside /wp-content.
   
2. Install a security plugin like Wordfence or Sucuri through FTP, since your admin area may still be inaccessible. Many hosts also offer a built-in malware scanner inside the control panel.
   

Step 8: Restore From a Recent Backup

Look for a Backups or Restore Points tab in your hosting dashboard and pick the most recent backup dated before the fatal error appeared.

Any changes made after that backup date, including new posts, comments, or orders, will be gone. Check with your host about partial restores if that’s a concern.

If You’re on Managed WordPress Hosting, Do This Instead

Hosts like Kinsta, WP Engine, and SiteGround often skip FTP entirely in favour of built-in tools.

Check your hosting dashboard for a “PHP Error Log” or “Error Log” viewer before opening FTP. It shows the same information as debug.log without any code editing.

Many of these hosts also offer one-click staging sites, so you can test a fix safely before applying it to your live site. If your store runs WooCommerce and keeps breaking after updates, a WooCommerce store troubleshooting review can catch plugin conflicts before they cause another fatal error.

How to Prevent This From Happening Again?

A few habits cut your chances of hitting this error again to almost zero.

• Test updates on staging first, especially for WooCommerce stores where a broken checkout costs real revenue
• Check plugin reviews and update dates before installing anything new
• Keep WordPress core and PHP updated, since old versions lose compatibility over time
• Set a weekly backup schedule if your host doesn’t already run one

Conclusion

Getting locked out with a fatal error warning feels urgent, but the fix almost always follows the same order. Start with Recovery Mode, then move to plugins, theme, memory, and debugging if needed.

Most site owners can access WordPress admin with a fatal error warning again within fifteen minutes using the FTP based steps above, even without coding experience. Reading the error message first, before touching any files, saves the most time of all.

If you’d rather hand the troubleshooting off, DevDiggers’ team offers WordPress development services built around exactly this kind of recovery work. You can also reach out to our WordPress support team if the error keeps coming back after you’ve tried every step here.

Frequently Asked Questions (FAQs)