Give your WordPress site its first task.
Connect the site you already have, add your agent to Slack or Telegram, and tell it what you need.
Connect your siteStart with 500 free credits. No credit card needed.
On this page
Key takeaways
- Check the host’s PHP error log first. WordPress’s debug.log stays empty when the failure happens before WordPress loads.
- Plugin and theme conflicts right after an update are the most commonly reported cause. One example: a 500 that appeared only on a WooCommerce product template after an Elementor 3.22.0 update.
- Every standard fix has a trap: renaming .htaccess wipes custom redirects, WP_MEMORY_LIMIT can’t go above the host’s PHP cap, and WordPress says never to set directories to 777.
- When the WordPress logs are clean, the cause is usually below WordPress: a full database, a max_allowed_packet limit, upload caps or firewall rules. Send the host the URL and the exact time.
- Google slows crawling when it gets 5xx responses and can eventually drop URLs that keep returning them, so a 500 that only bots see still costs you.
The page loaded an hour ago. Now it shows “500 Internal Server Error”, “HTTP ERROR 500” or nothing at all. The message names no file and no plugin, and turning plugins off at random can turn one failing request into a whole-site outage.
Treat the 500 as a symptom. You fix it in three moves: find the log entry for the failing request, make the one change that entry points to, then confirm the original request works again.
What a 500 tells you, and what it doesn’t
A 500 tells you the server hit a problem it couldn’t recover from while building the response. It doesn’t tell you why. WordPress.org’s Advanced Administration Handbook lists several possible causes behind the same message: a corrupted .htaccess file, a plugin or theme problem, PHP running out of memory, and damaged core files. Hosts add permissions, PHP version mismatches, database limits and server configuration.
Where the error shows up is your first clue. It can take down the whole site, only /wp-admin, or a single action: saving WooCommerce settings, publishing in a page builder, uploading media through async-upload.php, or checkout. If a PHP fatal error is caught by WordPress, you may see “There has been a critical error on this website” instead of a bare 500. If the screen is simply blank, our guide to fixing a WordPress white screen covers that version of the problem.
Why the log comes before the plugin list
The log entry is the diagnosis. Everything before it is guessing. WordPress, WooCommerce and the major hosts all give the same order:
- Write down the failing URL and the time. Note whether you were logged in and what you clicked.
- Reproduce it once. Now you have an exact timestamp to match in the log.
- Open the server’s PHP error log. On most hosts it sits in the control panel under a name like “Errors” or “Logs”. If you can’t find it, ask the host for the entries at your timestamp.
- On a WooCommerce store, also check WooCommerce → Status → Logs. WooCommerce’s documentation says this log records PHP fatal errors. Look for a log named
fatal-errors. - Read the file path and line number. A path inside
wp-content/plugins/some-plugin/tells you which plugin to look at.
If the host log is out of reach and WordPress still loads far enough to run, turn on WordPress’s own log in wp-config.php, above the line that says “That’s all, stop editing”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Errors then go to wp-content/debug.log and visitors don’t see them. WordPress’s debugging documentation says these tools are meant for local and staging sites and recommends logging over displaying. Turn the lines off when you’re done, because the log can hold file paths and request data.
An empty debug.log tells you something too. In one WordPress.org support thread, the 500 happened before WordPress loaded, so WordPress never had the chance to write anything. That points you back to the server log.
Which fix matches which log line
| What the log shows | Likely cause | First move |
|---|---|---|
Fatal error in /wp-content/plugins/name/ | That plugin | Rename its folder, then roll it back or update it |
Fatal error in /wp-content/themes/name/ | Theme or a recent code edit | Revert the edit or switch to a default theme |
| “Allowed memory size of … bytes exhausted” | PHP memory | Raise the limit, or ask the host to |
“Invalid command” or “Request exceeded the limit of 10 internal redirects” pointing at .htaccess | Rewrite rules | Back up the file, rename it, regenerate it |
| “Permission denied” | Permissions or ownership | Reset to the host’s recommended values |
Failed opening a file in wp-includes | Missing or damaged core file | Replace wp-admin and wp-includes |
| Nothing from WordPress at all | Server, database or firewall | Escalate to the host with URL and time |
Nobody publishes measured data on which cause is most common. Support threads lean toward plugins, and some tutorials name .htaccess first. The sections below follow how often each one comes up in support threads.
A plugin or theme, usually right after an update
This is the pattern support forums see most. In one WordPress.org thread, updating Elementor to 3.22.0 produced a 500 only when editing a WooCommerce single-product template. The homepage still edited fine. Deactivating the ReviewX plugin made it go away, and reinstalling it did not.
If wp-admin works, deactivate the suspect named in the log, or roll it back to the last version that worked. If wp-admin is down, connect over SFTP or the host’s file manager and rename wp-content/plugins/plugin-name to plugin-name-off. WordPress deactivates a plugin whose folder has disappeared. No suspect in the log? Rename the whole plugins folder, then bring plugins back one at a time. Our guide to fixing plugins that stop working walks through that routine.
On a live store, turning plugins off breaks things for customers. The Troubleshooting plugin gives you a Troubleshooting Mode that disables plugins for your session only. Two cautions. Deactivating a plugin can trigger its own 500 when other plugins depend on it. And having everything switched off is a diagnosis, not a fix. Once you’ve found the culprit, turn the rest back on.
A broken .htaccess file, on Apache only
Download a copy of .htaccess from the site root, then rename the file on the server to .htaccess-old. If the site comes back, go to Settings → Permalinks and click Save Changes. WordPress then writes fresh rewrite rules. Copy any custom redirects or security rules back from your saved copy one block at a time, and test after each one.
This only applies on Apache. On Nginx, WordPress doesn’t read .htaccess, and renaming it changes nothing. If the file keeps breaking after you fix it, something keeps rewriting it. Look at which plugin writes to it, often a security or cache plugin, and fix that.
PHP memory exhausted
Only raise memory when the log says “Allowed memory size … exhausted.” WordPress’s wp-config documentation gives the setting as define( 'WP_MEMORY_LIMIT', '128M' );. The host’s PHP memory_limit still caps it, so if your number has no effect, ask the host. A site that already has 512M or more and still runs out usually has a plugin stuck in a loop or loading too much data. Find that plugin rather than raising the limit again.
File permissions
WordPress’s permissions documentation gives 755 or 750 for directories and 644 or 640 for files, and says never to set directories to 777. A recursive 777 is a security hole, and it can still leave the wrong user owning the files. Use the values your host documents.
Damaged core files
When the log names a missing file in wp-includes or wp-admin, download the same WordPress version your site runs. Then replace those two folders. Leave wp-content and wp-config.php alone, since they hold your site.
Causes below WordPress
Some 500s never show up in WordPress logs. In one WordPress.org thread, a 500 that appeared only in wp-admin after a plugin update came from a database write hitting MySQL’s max_allowed_packet limit, not from a plugin bug. In an agency case study, a database on shared hosting had reached its 2 GB cap because one plugin’s logs were never rotated. Clearing the data would only have bought time. Changing the plugin’s logging settings stopped it from coming back.
Other causes in this group: upload and request-size limits during imports, firewall rules such as ModSecurity rejecting legitimate requests, and underpowered hosting failing on and off under traffic. These are the host’s to confirm.
How to tell it’s actually fixed
A homepage that loads proves very little. Retest the exact request that failed. Then check the admin screen your team uses and one real transaction, such as a form submission or a test order. Read the log again for new fatal errors. Clear page and CDN caches separately: a cached error page can outlive the fix, and a cached good page can hide one that’s still broken. Turn debugging off, and write down what you changed and how to undo it.
Check Google Search Console as well. Google’s crawler documentation says Google slows crawling when it gets 5xx responses and can eventually drop URLs that keep returning server errors. A plugin can return 500s only to bots or scripts, so “it works for me” doesn’t mean Google sees a working page. The URL Inspection live test shows what Google gets.
When to stop and get help
Stop when the WordPress logs are clean, when the log points at the database, PHP-FPM or a firewall, or when you can’t reach the files at all. Send the host the failing URL, the exact time you reproduced the error, and what you’ve already ruled out. Ask them to check the server log for that moment, your resource limits, and any firewall rule that matched. Before you restore a backup, read what your backup plugin actually covers, and make sure you aren’t restoring from the same source that broke the site.
Access is the usual bottleneck. A freelancer with only a wp-admin login can do nothing once wp-admin itself returns 500, so get SFTP or control-panel access before the next incident. If you’d rather hand the diagnosis off, SiteSelf can find and fix site errors through chat. For a 500 that locks you out of wp-admin, it needs hosting (SSH) access, not just its connector plugin.