When WordPress shows “There has been a critical error on this website,” your site can partially or completely go down—hurting sales, SEO, and trust. This guide gives you a calm, decision-based path to restore access fast, identify the cause, and prevent repeat incidents. It combines the official Recovery Mode path with a manual (no-email) method and adds practical debugging, safe repairs, security checks, and a maintenance checklist.
Audience and promise
- Skill: Beginner–Intermediate WordPress users, site owners, agencies
- Time to first recovery: 5–30 minutes (conflicts), longer for DB/malware
- Outcome: Get back online first, then fix the root cause safely
Decision Matrix: Where to Start
Pick the path that matches your current state. This saves time and reduces risk.
| Your state | Fastest path | Why |
| You received a “Your Site is Experiencing a Technical Issue” email | Recovery Mode (below) | Deactivates the exact culprit safely via a special login |
| You have no email and are locked out of the dashboard | Manual recovery via FTP/SFTP | Regains access by disabling plugins/themes without logging in |
| You still have dashboard access | Isolate conflicts + Site Health | Quicker triage with built-in tools; no file access required |
Safety first
- Back up files and database before changes. If you can’t back up, at least avoid deleting files; prefer rename/replace.
- Keep a private window open to test the frontend while you make changes.
Fix When You Still Have Dashboard Access
If you can still log in to wp-admin, you can fix the issue without file access.
Isolate the conflict
Go to Plugins then to Installed Plugins. Deactivate recent or suspicious plugins first. Switch to a default theme temporarily. Go to Appearance then to Themes. Activate a default theme like Twenty Twenty-Four.
Check Tools and Site Health
Review Critical issues and Recommendations. Expand each item for guidance. This includes PHP version, REST API issues, module extensions, and scheduled events.
Reproduce and confirm
Test the frontend in a private window. If it loads, re-enable items one at a time. The error will return. This shows you the culprit.
Update or replace
Update the conflicting plugin or theme. Check its changelog for compatibility. Replace it with a maintained alternative.
Tip: Keep Query Monitor enabled during testing. It will show warnings and slow hooks.
Quick Fix if You Got the Recovery Email
The Recovery Email has the subject, “Your Site is Experiencing a Technical Issue.” It has a one-time link. This link logs you into a special Recovery Mode. The failing code is disabled just for your session.
Click the Recovery Mode link and log in
WordPress will skip loading the failing plugin or theme for you. If the link has expired, trigger a new error. Visit the broken page. Check your inbox again. You can also use the manual method.
Follow the admin notice to deactivate the culprit
The banner names the problem plugin or theme. Click Deactivate. Take a screenshot of the notice. This is for your records.
Verify the frontend
Open the site in a private window. If it loads, you have a conflict. If not, try deactivating the flagged theme or other suspect plugins.
Update or replace the culprit
Update to the latest version. Check its changelog for compatibility notes, especially the PHP version. If there is no update, contact the developer. Consider other options if problems continue. For example, replace a plugin that is no longer supported.
Exit Recovery Mode and re-test
Log out and back in normally. Confirm the site loads for non-recovery sessions too.
Time: 5–15 minutes.
Risk: Low.
Works best when: WordPress can email you.
Fix Without Email or Dashboard (FTP/SFTP Path)
No email and no dashboard? Use FTP/SFTP or your host’s File Manager. This gets you access back. It disables extensions at the file level.
Disable all plugins quickly
Rename wp-content/plugins to plugins.deactivated. Test your site. If it loads, you have a plugin issue. Rename it back to plugins. Reactivate plugins in batches. This will find the culprit faster than reactivating one by one. Once you find it, keep only the problem plugin deactivated. Then update or replace it.
Switch to a default theme
Make sure a default theme is present. The folder is wp-content/themes. A good choice is Twenty Twenty-Four. Rename your active theme folder. For example, change mytheme to mytheme.off. WordPress will then use the default theme. If the site loads, your original theme needs updates or fixes.
Check must-use plugins and drop-ins
Look inside wp-content/mu-plugins. Temporarily rename the files there. Check wp-content/object-cache.php. Rename it to disable object caching. If the site is still broken, check logs, memory, core files, the database, and permissions.
Time: 10–30 minutes.
Risk: Low-Medium.
Works without: Admin access.
How to connect (FTP/SFTP or File Manager)
cPanel: Log in. Go to Files. Then go to File Manager. Navigate to your site root. This is often public_html.
Plesk: Log in. Go to Files. Then go to httpdocs. Find your WordPress directory.
SFTP (preferred): Use FileZilla or Cyberduck. You will need your host, username, and SFTP port, often 22. Make sure you are in the directory that has wp-admin, wp-content, and wp-includes.
WP-CLI shortcuts
(This is if you have shell access.)
# File: (remote shell)
wp plugin deactivate --all
wp theme activate twentytwentyfour
wp plugin activate plugin-slug
wp plugin update --all
Multisite considerations
Network-activated plugins affect all sites. Use the Network Admin to deactivate them. Or use this code.
# File: (remote shell)
wp plugin deactivate plugin-slug --network
A single sub-site can break. Test with a default theme and minimal plugins on that sub-site first.
Turn On Debugging and Read Error Logs
Logs show you which file and line failed. Enable them for a short time. Reproduce the error. Review the log.
// File: ./wp-config.php
// Enable WordPress debugging (add above the line that says “Happy blogging”)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Reproduce the error. Then open wp-content/debug.log. Look for plugin and theme names. Look for fatal errors. Examples include Allowed memory size exhausted, Call to undefined function, and Class not found. After you fix the problem, remove the constants. Or set them back to defaults. This prevents the log from getting too big.
If you’re unsure how to interpret the messages, see our WordPress Error Logs Explained guide — it shows real log examples and what each common error actually means.
Optional via WP-CLI
(If you have shell access.)
# File: (remote shell)
# Toggle maintenance tools
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw
Tip: Once the site is back, install Query Monitor. It can catch warnings before they cause an outage.
Examples: Reading debug.log and what to do
[21-Jan-2025 09:14:22 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted in /wp-content/plugins/builder/includes/parser.php on line 417
Raise memory and trim heavy plugins or modules.
[21-Jan-2025 09:16:07 UTC] PHP Parse error: syntax error, unexpected ‘}’ in /wp-content/themes/mytheme/functions.php on line 102
Revert your last edit via FTP. Fix the bracket or semicolon. The site should load right away.
[21-Jan-2025 09:17:53 UTC] PHP Fatal error: Uncaught Error: Call to undefined function my_missing_fn() in /wp-content/plugins/custom-plugin/custom.php:55
Update or replace the plugin or theme. Make sure all dependencies are installed.
Disable plugins via database
You cannot reach files. But you have phpMyAdmin access. You can disable all plugins this way.
- Open phpMyAdmin.
- Select your WordPress database.
- Open the wp_options table. Your prefix may be different.
- Find option_name = active_plugins.
- Edit it. Set option_value to a:0:{} . This disables all plugins.
- Load your site. If it works, re-enable plugins in the dashboard one by one.
Caution: Back up the database first. Do not change other options.
Increase PHP Memory and Clear Caches
Memory exhaustion is a common problem. It happens often on page builders, imports, or heavy admin screens.
// File: ./wp-config.php
// Increase PHP memory for WordPress
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');
Guidance: Many shared hosts have a memory limit. The constant may not change it. If errors continue, upgrade your plan. Or reduce heavy plugins. Clear plugin caches, server caches, and your CDN. Purge them, then hard-refresh. You can also test in a private window. Do not use many optimization plugins. One good solution is better than three that conflict.
Time: 5–10 minutes.
Risk: Low.
Watch: Host limits and plugin bloat.
Symptom-based quick fixes
After a plugin update: Revert the plugin. Upload the prior version via FTP. Or restore from backup. Tell the developer about the problem.
After editing functions.php: Immediately revert the change over FTP. Use a code editor with PHP linting. This prevents syntax errors.
After a core update: Reinstall core and verify checksums. Replace only wp-admin and wp-includes.
White screen on a specific page: Enable logging. Open the page to capture errors. Common causes are shortcode conflicts or template overrides. If you’re seeing a blank page site-wide, follow our detailed WordPress White Screen of Death Fix guide to restore visibility safely.
Reinstall Core Files (Safe and Non-Destructive)
Core files can be corrupted or changed. Replace them with a fresh copy. Your content will stay intact.
Path A (Dashboard available): Go to Updates. Click Re-install Now. WordPress will refresh core. It will not touch wp-content.
Path B (FTP/SFTP): Back up your files and database. Download the latest WordPress from wordpress.org. Extract it. Upload and overwrite only wp-admin and wp-includes on the server. Do not overwrite wp-content or wp-config.php. Test the site.
Optional with WP-CLI:
# File: (remote shell)
wp core verify-checksums
wp core download --skip-content --force
Time: 10–20 minutes.
Risk: Low when wp-content is preserved.
Repair the Database
Corrupted tables or interrupted updates can cause fatal errors.
WordPress repair tool (temporary)
// File: ./wp-config.php
// Allow DB repair tool (temporary)
define('WP_ALLOW_REPAIR', true);
Then visit /wp-admin/maint/repair.php. You can repair and optimize. Remove the constant afterward.
phpMyAdmin (hosting control panel)
Select your database. Check all tables. Choose Repair table. Back up the database first. If repairs fail, restore from a good backup.
Time: 10–30 minutes.
Risk: Medium.
Always: Back up first.
Check File Permissions and Ownership
Wrong permissions can stop WordPress from reading or writing files.
Recommended:
- Directories: 755
- Files: 644
- wp-config.php: 600–640
Linux shell (if available):
# File: (remote shell)
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
Never use 777 on production. On a VPS or dedicated server, make sure files are owned by the web user. For example, www-data on Ubuntu. Ask your host if you are not sure.
Upgrade PHP and Resolve Server Limits
Outdated PHP can cause fatal errors. This happens after plugin or theme updates. Upgrade to a PHP version that your WordPress and extensions support. Hosts usually have a selector in cPanel or Plesk. Test on a staging site if you can. Check extension requirements and changelogs.
You may still get 500 errors or timeouts. If this happens, review PHP max execution time, I/O limits, and OPCache settings. Talk to your host about this.
Time: 10–20 minutes.
Risk: Medium.
Validate: Compatibility on staging.
Security and Malware Checks
Malware can break pages, inject code, or change core files.
Indicators: Unknown admin users, changed dates on core files, suspicious uploads in wp-content/uploads, obfuscated base64 code.
Actions: Scan with a reputable security plugin or service. Compare core files against checksums. Replace altered files. Remove backdoors. Change all passwords. Update salts in wp-config.php. If you find signs of a problem, perform a full response. Clean, patch, and update everything. Then harden your site.
Time: 30–120+ minutes.
Risk: Medium-High.
Consider: Professional help.
When to Contact Your Host or a Pro
Contact your host if logs point to server limits, file ownership, PHP crashes, or if you cannot get to error logs.
Provide:
- Timestamps of the outage.
- The last change you made.
- wp-content/debug.log and server error logs.
- WordPress and PHP versions.
- A list of themes and plugins.
- The steps you have tried.
Rollback strategy and safe testing
Before major updates:
- Create a full backup (files + database). Verify you can restore on staging.
- Use a staging site to test updates. Promote to production after validation.
- Keep a changelog of updates and custom code changes to speed up incident response.
If something breaks in production:
- Roll back the exact change that preceded the outage (plugin/theme/core edit).
- Restore the last known-good backup if rollback is not feasible.
Prevention Checklist
- Daily automated backups; periodically test a restore on staging
- Weekly updates for WordPress core, plugins, and themes
- Monthly security scans, Site Health checks, and DB optimization
- Keep plugin stack lean; avoid overlapping functionality
- Configure SMTP so Recovery Mode emails arrive reliably
- Use staging to test major updates before production
Once your site is back online, it’s worth reviewing the full WordPress Error Troubleshooting Guide to prevent similar issues it covers database errors, file permissions, update issues, and more.
FAQs
What causes the WordPress critical error?
Typically a plugin/theme conflict, PHP memory exhaustion, corrupted core files, database issues, or malware.
Can I fix it without dashboard access?
Yes. Disable plugins and switch to a default theme via FTP/SFTP; enable debug logging; increase memory; repair the DB; or safely reinstall core files.
What if I didn’t get the Recovery Email?
Use the manual FTP/SFTP path. Also set up SMTP so future technical issue emails are delivered.
How high should I set the memory limit?
Start at 256M. If memory errors persist, reduce heavy plugins or upgrade hosting. Avoid arbitrarily huge limits that hide real bottlenecks.
Are page builders (e.g., Elementor) a cause?
Sometimes, as with any plugin. Deactivate to test; update or replace if confirmed.
How long does a fix take?
Conflicts often resolve in 15–30 minutes. Malware or DB repairs can take longer.
Restore access first, then use logs and systematic isolation to identify and fix the root cause. With the safe procedures and checklist above, you’ll not only resolve the outage but also reduce the chances of it happening again.
