To fix a WordPress 500 error, check your error logs, then test the configuration, plugins, and theme with reversible changes. The status means your server couldn’t complete the request, but it doesn’t identify the cause.
You’ll often see it after an update, migration, or configuration edit. Start with a backup, then repeat the failing request after each change so you can identify what fixes it.
Key Takeaways
- Preserve your files and database before troubleshooting, even when you can’t access WordPress.
- Read your hosting error log before changing settings. WordPress debug logging can provide additional evidence.
- Change one thing at a time, undo unsuccessful tests, and contact your host when the problem involves server limits or services.
1. Run Quick Checks and Preserve a Recovery Point
Rule out a cached response
Refresh the failing page once, then open it in a private browser window to check whether the first result came from a stale response in your browser cache. Test both your homepage and /wp-admin/ to establish whether the failure affects your entire site.
Clear your browser cache and site-specific cookies, although removing cookies will log you out. If the dashboard works, clear WordPress cache too. In WP Rocket, use Clear and preload cache.
When WordPress is inaccessible, purge available hosting or CDN caches through their separate control panels. These checks remove stale responses; they won’t repair an ongoing PHP failure.
Back up before editing files
Use UpdraftPlus if you can access the dashboard. If you need to backup your site without dashboard access, use cPanel backups or your host’s backup system to preserve both files and the database.
You can also download files through FTP or SFTP and export the database through phpMyAdmin. Our WordPress backup methods cover these recovery options.
Save separate copies of files you’re about to edit. Your hosting file manager and SFTP usually remain available when WordPress itself fails.
2. Check Logs Before Guessing at the Cause
Start with your hosting error log
Open your hosting control panel’s viewer for server error logs, or access the files through SFTP or SSH. On DreamHost, the server log is named error.log; other hosts use different locations.
Reproduce the failure once and note the time, including your timezone. Then inspect entries around that moment rather than unrelated older warnings.
Record the fatal error, affected file path, and failing URL. If the server rejects the request before WordPress starts, the server record may contain evidence that WordPress cannot record.
Enable private WordPress debug logging
Use WordPress debug mode to record errors without displaying them to visitors. Download wp-config.php, then edit it above the “That’s all, stop editing!” comment. Change existing definitions instead of creating duplicates:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
These settings enable logging without displaying WordPress debug messages to visitors. The WordPress configuration handbook documents these constants.
Block public access to the log before testing. If you can’t protect it, use your hosting error log instead.
Repeat the failing action, then inspect /wp-content/debug.log. The file may not exist until WordPress records an error. Remove passwords, tokens, and other private details before sharing excerpts.
3. Test the .htaccess File
On Apache and compatible LiteSpeed configurations, an invalid rule in the .htaccess file can cause a 500 response. Nginx doesn’t use this file, so skip this test on an Nginx-only setup.
In your WordPress root, alongside wp-config.php, enable hidden-file visibility. Download .htaccess, then rename it to .htaccess.disabled and reload your site.
If the error disappears, the file’s rules caused the failure. Open Settings > Permalinks and select Save Changes without changing your URL structure. WordPress can regenerate its rewrite rules when the directory is writable.
The official permalink settings documentation covers cases requiring manual updates.
If the test changes nothing, restore the original filename. Keep custom redirects and security rules backed up before rebuilding the .htaccess file. Our WordPress .htaccess guide explains their placement.
Avoid adding generic php_value directives. Unsupported directives can themselves trigger a 500 error.
4. Review PHP Memory and Version Settings
Increase memory only when justified
When logs report memory exhaustion, a higher PHP memory limit may help. In wp-config.php, above the stop-editing comment, you can request:
define('WP_MEMORY_LIMIT', '128M');
Edit an existing definition rather than adding another. Don’t replace a higher allowance with this lower value.
Some workloads need PHP limits of 256M or 512M, but neither value is a universal requirement. WordPress constants request memory within your hosting restrictions; they can’t bypass a server-enforced ceiling.
If the allowance doesn’t increase, your host may need to change the PHP limit. Repeated exhaustion also warrants investigating the workload.
Review compatibility after updates or migration
If the failure began after a PHP version change, return to the last working configuration while you arrange compatible software updates.
After migration, differences between the old and new PHP environments can expose incompatible plugin or theme code. Plugin conflicts are also common after a move.
Our WordPress PHP compatibility guide provides background for planning a supported configuration. Test subsequent changes on staging whenever possible.
5. Correct Inappropriate File Permissions
Incorrect permissions can prevent your server from reading files or entering directories, producing a WordPress 500 error.
The usual starting values are 755 for directories and 644 for files. Your SFTP client’s file properties or hosting file manager lets you change them.
Apply corrections to the affected files rather than resetting everything blindly. Your host may require stricter permissions for sensitive files such as wp-config.php.
Never use 777 as a shortcut. It grants unnecessary write access.
After a migration, correct numeric permissions may still leave an ownership problem. Have your host repair ownership instead of broadening access permissions to compensate.
6. Isolate Plugins, Then Test Your Theme
Disable plugins without deleting them
If you can log in, deactivate the most recently changed plugin first. Otherwise, deactivate plugins individually and repeat the failing action after each change.
Without dashboard access, rename /wp-content/plugins/ to plugins.renamed through SFTP. This temporarily prevents ordinary plugins from loading.
If access returns, visit the Plugins screen while the folder remains renamed so WordPress records the missing plugins as deactivated. Then restore its name to plugins and reactivate plugins individually.
If activation causes another crash, rename that plugin’s individual folder to regain access. Our plugin conflict troubleshooting guide covers controlled isolation.
Must-use plugins and some caching drop-ins remain active. Don’t move host-managed files without support.
Switch to an installed default theme
If disabling plugins doesn’t help, activate a working default WordPress theme, such as Twenty Twenty-Two or Twenty Twenty-Three.
Without dashboard access, you can temporarily rename the active theme’s folder under /wp-content/themes/, provided a working default theme is already installed. If WordPress doesn’t recover, restore the folder name and ask your host to activate the default theme.
Repeat the original failure after switching. If it disappears, keep the working theme active while you repair the original.
Restore renamed folders after testing, but don’t reactivate software that reproduces the crash.
7. Replace Damaged Core WordPress Files
An interrupted update or incomplete transfer can leave core files damaged. Try this after configuration, plugin, and theme tests fail, or when an update clearly stopped partway through.
Download a clean package of the same WordPress version your site runs. Extract it locally, then upload clean copies of wp-admin and wp-includes through SFTP, replacing their existing contents.
Leave wp-content and wp-config.php untouched. Your uploads, plugins, themes, and database shouldn’t be replaced during this test.
Keep your backup available throughout the transfer. Once uploading finishes, test the original failing page and the dashboard before making further changes.
8. Escalate Server Problems and Remove Temporary Changes
Contact your hosting provider if the error persists, or immediately if you can’t access backups or logs. Shared hosting can enforce low memory limits. PHP worker failures, server-side timeouts, external connection problems, or server configuration issues may require host intervention.
Send the failing URL, timestamp with timezone, redacted log excerpt, recent changes, and tests you’ve completed. This gives support a reproducible failure instead of a generic report.
After testing, set the three constants shown above to false; this disables debugging, logging, and public display. Delete the temporary log or secure any retained copy. WordPress’s Site Health documentation explains its warning about enabled debug logging.
Restore unsuccessful test changes and re-enable unaffected plugins. Purge caches again, then test login, forms, and any checkout or upload action that previously failed.
Frequently Asked Questions
Can you fix a WordPress 500 error without losing content?
Usually, yes. Renaming folders, disabling plugins, and replacing only core files preserve your database and uploads. However, keep a full backup before testing. Restoring an older database can overwrite newer orders or comments.
What should you prioritize after a migration?
Start with the new host’s logs, then test plugins and carried-over .htaccess rules. PHP compatibility, permissions, and ownership can also differ between servers. Avoid repeating a full migration before isolating the failure.
Can persistent 500 errors hurt SEO?
Yes. Persistent server errors obstruct crawling and can eventually cause affected URLs to leave Google’s index. There’s no fixed recovery deadline. After restoring service, use Google’s crawl troubleshooting guidance to investigate remaining crawl problems.
Restore Service With Reversible Changes
Your strongest evidence is a repeatable result: the same request fails before one change and succeeds afterward. Logs help you choose that change without guessing.
Keep the confirmed problem component disabled until you have a tested repair. Finish by removing temporary debugging, restoring working settings, and retaining a complete recovery backup.
