You open your website and the page is gone. In its place sits a plain message about an internal server error. There is no menu, no logo and no clue about what went wrong. For a shop, that screen means no orders. For a blog, it means no readers. It is one of the most alarming things WordPress can show you.<\/p>\n
The 500 internal server error in WordPress is not a WordPress message. It comes from the web server. The server tried to build your page, something failed badly, and it had nothing useful to send back. So it sent the only thing it could: a general failure notice. That is why the screen tells you so little. The real error is still there, just hidden from view.<\/p>\n
This guide gets it back for you. You will learn the signs that confirm you have this error and not a different one. You will see every common cause, and exactly what breaks in each case. Then you will work through a fix list in order, from the safest check to the deepest repair. Finally you will set up the habits that stop it happening again.<\/p>\n
The triggers are usually simple. A file edited by hand. A plugin update that went wrong. A theme change. A memory limit reached. A core update that did not finish. Almost every case comes down to one of those, and most are fixed in minutes once you know where to look.<\/p>\n
First, make sure you are looking at the right problem. Several WordPress failures produce a broken page, and they need different fixes. Check the signs below against what you can see.<\/p>\n
Now rule out the errors that look similar. A blank white page with no text at all is the white screen of death, which is a PHP error being hidden rather than reported. A message about a critical error on the website is WordPress catching a fatal error itself and telling you it emailed you. A “503 Service Unavailable” page means the server is up but refusing work, often because of load or maintenance mode. A “database connection” message points at the database rather than at PHP. If you are seeing a 503 instead, read our guide on how to fix the 503 service unavailable error in WordPress<\/a>.<\/p>\n One more check is worth doing. Open the site in a private browser window and on your phone using mobile data. If the error appears everywhere, it is real and server side. If only your own browser shows it, clear your cache and cookies first.<\/p>\n A 500 error is a symptom, and something specific failed underneath it. Below are the causes behind almost every case, and each one has a matching step in the next section.<\/p>\n PHP is strict. One missing semicolon, one stray character or one unclosed bracket stops the whole file from running. If you pasted a snippet into functions.php, edited wp-config.php or changed a template, this is the most likely cause. The giveaway is timing, because the error appeared the moment you saved. Editors that add curly quotation marks instead of straight ones cause this constantly. So do code snippets copied from a web page that included an extra blank line.<\/p>\n On Apache servers, the .htaccess file holds instructions for the web server. WordPress uses it for pretty permalinks. Plugins add rules for caching, redirects and security. If a rule is invalid, refers to a module the server does not have, or the file gets damaged during an update, Apache refuses to serve anything. The official WordPress guide to common WordPress errors<\/a> lists a corrupted .htaccess file as the most likely cause of an internal server error, and it is the easiest one to test.<\/p>\n Every page your site builds gets a memory budget. Importing content, generating images, running a backup or loading a heavy plugin can use it all. When PHP runs out, it stops mid-request. Sometimes you see a clear “allowed memory size exhausted” message. Often you just get a 500. WordPress only asks for 40 megabytes by default on a single site, so a busy site with many plugins can reach the ceiling easily.<\/p>\n Plugins are code, and code can break. A plugin update may call a function that no longer exists. Two plugins may declare the same function name and clash. A plugin may need a PHP feature your server does not have. Any of these produces a fatal error, and a fatal error before WordPress loads its own error handler shows up as a 500. This is the most common cause after .htaccess, and it explains why the error so often follows an update.<\/p>\n Your theme runs on every page, so an error inside it breaks the whole site. The file most often at fault is functions.php, because that is where people paste code snippets they found online. A single bad snippet there is enough to stop every page loading. Themes also break when an update clashes with a child theme, or when the theme calls a function belonging to a plugin you removed. A PHP upgrade can trigger it too, since older theme code may use syntax that newer PHP no longer accepts. The clue is timing: the error appears the moment you save functions.php or finish a theme update.<\/p>\n WordPress core files can be damaged. An update may fail halfway when the connection drops or the server times out. A failed manual upload can leave half a folder. A security problem can alter files. When a core file is missing or broken, WordPress cannot start, and the server returns a 500. The clue here is an error that appeared during or just after an update, with no plugin or theme change involved.<\/p>\n Hosts upgrade PHP, sometimes automatically. Newer PHP versions remove old syntax and old functions. A plugin or theme written years ago may use code that simply no longer runs. The result is a fatal error on every page. This cause often surprises people, because nothing on their own site changed. The change happened on the server.<\/p>\n Some 500 errors are not about your code at all. A script may exceed the maximum execution time the host allows. File permissions may be wrong, and many servers refuse to run files that are writable by everyone. The server may be misconfigured or genuinely having trouble. These causes are less common, but they are the ones left when everything else has been ruled out.<\/p>\n Two things before you begin. First, take a backup of your files and database, or work on a staging copy. Several steps below touch core files, and you want a way back. If your dashboard is down, take the backup through your hosting control panel instead. Second, turn on error logging so you can see the real error instead of guessing. Add these lines to wp-config.php, above the line that reads “That’s all, stop editing”, using FTP or your host’s file manager:<\/p>\n Reload the broken page, then open wp-content\/debug.log. It usually names the exact file and line that failed, which can take you straight to the right step below. Your host also keeps a server error log, often in the control panel or in a file named error_log in your site root. Remember to set WP_DEBUG back to false when you are finished, because debug mode should never stay on for a live site. The WordPress handbook on debugging in WordPress<\/a> explains what each of these settings does. Now work through the steps in order and reload your site after each one.<\/p>\n This step addresses the syntax error cause. One wrong character in a PHP file stops that file running, and everything that depends on it fails with a 500. Confirm it by timing. Did the error appear the moment you saved a file? If your debug log names a file and a line number, you already have your answer. Look at that line and the two lines above it, since PHP often reports the error slightly after the real mistake.<\/p>\n You will be editing live files here, so download a copy of the file before you touch it. If you have a recent backup, restoring just that one file is even safer than editing it. Then connect over FTP, or use the file manager in your hosting control panel, and open the file you changed. Remove the snippet you added. Check for curly quotation marks, which look like \u201c and \u201d instead of straight ones. Check that every bracket you opened is closed. Check there is no blank line or space after the final closing tag in wp-config.php.<\/p>\n Save the file and reload your site. If the page comes back, you have found it. Add the snippet again only if you really need it, and use a code snippets plugin instead of editing files directly, because those plugins check your code before saving it. If the site is still broken, restore the original file from your backup and move to the next step.<\/p>\n This step addresses the corrupted .htaccess file, which WordPress documentation names as the most likely cause. An invalid rule makes the web server refuse the request before WordPress even starts. Confirm it by renaming the file, which is the standard test. This is safe as long as you keep a copy, and it is reversible in seconds.<\/p>\n Connect over FTP or open your hosting file manager and go to your site root, the folder that holds wp-admin, wp-content and wp-includes. You may need to turn on hidden files to see .htaccess, because names beginning with a dot are hidden by default. Download a copy to your computer. Then rename the file on the server to .htaccess_old.<\/p>\n Reload your site. If it loads, the file was your problem. Now rebuild it properly. Sign in to WordPress, open Settings, then Permalinks, and click Save Changes without changing anything. WordPress writes a fresh, correct file for you. If you had custom rules from a plugin, re-save that plugin’s settings so it can add its rules back, and add any other rules one at a time so you can spot a bad one.<\/p>\n Check a blog post and a category page, not just the home page, because permalink problems show up there first. Our guide on how to set up and fix permalinks in WordPress<\/a> shows what a healthy file should contain. If renaming the file changed nothing, rename it back and continue.<\/p>\n This step addresses memory exhaustion. When PHP runs out of memory it stops mid-request, and the server returns a 500 with nothing useful attached. Confirm it in your debug log. A line containing “allowed memory size” and “exhausted” is proof. Another strong clue is an error that only appears during heavy tasks, such as importing, running a backup or opening the media library, while normal pages still work.<\/p>\n You will be editing wp-config.php, so download a copy first. Open it and add this line above the “That’s all, stop editing” comment:<\/p>\n WordPress only tries to reach 40 megabytes on a single site by default, and 64 on a multisite network, so a higher value here is normal rather than excessive. Save the file and upload it back.<\/p>\n Reload the page that was failing. Then open Tools, then Site Health, then the Info tab, and check the memory limit shown under Server. If the value has not changed, your host caps it at a lower level and the setting cannot override that. In that case ask your host to raise the PHP memory limit for your account. If memory was never the issue, remove nothing and move on, because a sensible limit does no harm.<\/p>\n This step addresses the plugin cause. A fatal error inside one plugin stops the request, and because it happens early, you get a bare 500 instead of a helpful message. Confirm it in your debug log first, since the file path in the error usually contains the plugin’s own folder name. If it does, you can skip straight to that plugin.<\/p>\n If you cannot see a log, test by elimination. This takes your site’s features offline briefly, so do it on staging if you can, or at your quietest hour, and back up first. If you can still reach the dashboard, open the Plugins screen, select all, and choose Deactivate. If the dashboard is down, connect over FTP and rename the wp-content\/plugins folder to plugins_old. That turns every plugin off at once.<\/p>\n Now load your site. If it works, the cause is a plugin. Rename the folder back to plugins, then turn the plugins on one at a time from the dashboard, reloading the site after each one. When the 500 returns, the plugin you just enabled is the culprit. Leave it off and check whether an update is available, since the author may already have fixed it. If not, look for an alternative or contact the developer with the exact error from your log.<\/p>\n Verify by loading several pages, including one that uses the feature that plugin provided. If turning everything off made no difference, plugins are not the cause, and you should move on.<\/p>\n This step addresses the theme cause. Your theme loads on every request, so an error inside it breaks the whole site in the same way a plugin does. Confirm it in your debug log, where the file path will point into wp-content\/themes. A theme cause is also likely if the error appeared right after a theme update or after you added code to functions.php.<\/p>\n Switching themes changes how your site looks, so use staging if you have it and take a backup either way. If you can reach the dashboard, open Appearance, then Themes, and activate a default theme such as Twenty Twenty-Four. If you cannot reach the dashboard, connect over FTP, open wp-content\/themes and rename your active theme’s folder. WordPress will fall back to a default theme automatically, as long as one is installed.<\/p>\n Load your site. If it comes back, your theme is the cause. Check for a theme update first, because the author may have already shipped a fix. If you added code to functions.php, remove it. If you use a child theme, compare its files against the parent to find what no longer matches. Contact the theme developer with the error from your log if you cannot see the problem.<\/p>\n Verify by switching back to your theme once the fix is in place, then loading your home page, a post and a page. If the default theme showed the same 500 error, the theme was innocent and the next step is more likely.<\/p>\n This step addresses corrupted or missing core files. If a file in wp-admin or wp-includes is damaged, WordPress cannot start and the server has nothing to return. Confirm it by timing and by log. A 500 that appeared during or just after a WordPress update, with no plugin or theme change, points here. Errors in your log naming files inside wp-admin or wp-includes confirm it.<\/p>\n This step overwrites core files, so back up everything first and never do it without a working copy of your site. Download a fresh copy of WordPress from wordpress.org, matching your current version if you can. Unzip it on your computer. Delete the wp-content folder from the unzipped copy, because that folder holds your themes, plugins and uploads and must not be replaced. Also leave wp-config.php alone, since the fresh download does not contain yours.<\/p>\n Now upload the remaining files over FTP and let them overwrite the existing wp-admin and wp-includes folders and the loose files in your site root. This replaces damaged core files while leaving your content untouched.<\/p>\n Reload your site. If it loads, you may be asked to run a database update, which is normal after replacing core files. Then open Tools, then Site Health, and check for warnings. If the error appeared after a failed update in the first place, our guide on how to fix a failed automated WordPress update<\/a> explains how to stop that repeating. If the 500 is still there, core files were not the cause.<\/p>\n This step addresses an incompatible PHP version. When a host moves you to a newer PHP release, old plugin or theme code can stop running entirely, and every page fails. Confirm it by asking what changed on the server. If nothing on your site changed but the error appeared anyway, check your host’s notices. Errors in your log mentioning an unexpected token, a removed function or a deprecated feature are strong evidence.<\/p>\n Find your current version first. If you can reach the dashboard, open Tools, then Site Health, then Info, and look under Server. If you cannot, your hosting control panel shows the version too. WordPress recommends PHP 8.3 or higher, so a site on 7.4 or older is overdue for a move even if that is not today’s problem.<\/p>\n Changing PHP version can break things, so update your plugins and theme first, take a backup, and test on staging if you have it. Then change the version in your hosting control panel. If a newer version broke your site, switching back to the previous one is a valid short term fix. Use that breathing space to update or replace whatever cannot run on the new version, because old PHP versions stop receiving security fixes.<\/p>\n Verify by reloading Site Health and confirming the version, then clicking through your main pages and any forms. Watch the debug log for new warnings while you test.<\/p>\n This step addresses permissions and server limits, the causes left when your own code is not at fault. Many servers refuse to run a PHP file that anyone can write to, and a script that runs past the maximum execution time is cut off mid-request. Both produce a 500. Confirm it by checking the numbers. In your FTP client or file manager, look at the permissions on wp-config.php, .htaccess and the wp-includes folder.<\/p>\n The standard WordPress scheme, set out in the official guide to changing file permissions<\/a>, is 755 for folders and 644 for files. Anything set to 777 is both a speed risk and a security risk and should be corrected. Changing permissions can lock you out of your own files if you set them too tightly, so change one item at a time and reload the site after each change.<\/p>\n For time limits, look in your server error log for a line about maximum execution time. Our guide on how to fix the maximum execution time exceeded error in WordPress<\/a> covers that case in full. If the limit is the problem, most hosts will raise it on request.<\/p>\n If you have reached this point with no result, the cause is on the server side and your host needs to look at it. Send them three things: the exact time the error started, the lines from your server error log, and the list of steps you have already tried. That turns a vague ticket into something they can act on quickly. If your site is down and you need help now, our guide on emergency WordPress support<\/a> explains what to do while you wait.<\/p>\n Every habit below closes off one of the causes above. Together they turn a site-down emergency into a minor inconvenience.<\/p>\n The 500 internal server error in WordPress looks worse than it is. The page is blank because the server had nothing useful to send, not because your site is lost. Your content, your database and your uploads are all still there. Your job is simply to find the one thing that failed.<\/p>\n Start by confirming the symptom. A 500 error affects every page and does not go away on refresh. A blank white page, a critical error notice, a 503 and a database message are all different problems with different fixes. Getting this right at the start saves you from fixing the wrong thing.<\/p>\n The causes are a short list: a syntax error in a file you edited, a broken .htaccess file, an exhausted memory limit, a plugin conflict, a theme error, damaged core files, an incompatible PHP version, and server limits or permissions. Work them in that order. Undo your last change. Rename .htaccess. Raise the memory limit. Test your plugins. Test your theme. Replace core files. Check PHP. Then talk to your host. Back up before every step, and turn on debug logging first so you are reading the error rather than guessing at it.<\/p>\nReasons Why a 500 Internal Server Error in WordPress Happens<\/h2>\n
A Syntax Error in a File You Edited<\/h3>\n
A Corrupted or Misconfigured .htaccess File<\/h3>\n
The PHP Memory Limit Is Exhausted<\/h3>\n
A Plugin Conflict or a Fatal Error Inside a Plugin<\/h3>\n
A Theme Error, Usually in functions.php<\/h3>\n
Corrupted or Missing Core Files<\/h3>\n
An Incompatible PHP Version<\/h3>\n
Server Limits and File Permission Problems<\/h3>\n
How to Fix a 500 Internal Server Error in WordPress (Step by Step)<\/h2>\n
define( 'WP_DEBUG', true );\r\ndefine( 'WP_DEBUG_LOG', true );\r\ndefine( 'WP_DEBUG_DISPLAY', false );<\/code><\/pre>\nStep 1: Undo the Last Change You Made<\/h3>\n
Step 2: Rename the .htaccess File and Reset Your Permalinks<\/h3>\n
Step 3: Raise the PHP Memory Limit<\/h3>\n
define( 'WP_MEMORY_LIMIT', '256M' );<\/code><\/pre>\nStep 4: Turn Off All Plugins, Then Turn Them On One by One<\/h3>\n
Step 5: Switch to a Default WordPress Theme<\/h3>\n
Step 6: Replace the WordPress Core Files<\/h3>\n
Step 7: Check and Change Your PHP Version<\/h3>\n
Step 8: Check File Permissions and Server Limits With Your Host<\/h3>\n
Best Practices to Prevent a 500 Internal Server Error in WordPress<\/h2>\n
\n
Conclusion<\/h2>\n