WinningWP content is free to all. If you make a purchase through referral links on our site, we earn a commission (learn more).

Fixing The Dreaded ‘Internal Server Error’ in WordPress (Step by Step)

WordPress Deals

We’ve all been there — a site that was functioning perfectly well just seconds ago suddenly decides to throw a fit and spits out an internal server error. If you’re lucky, the WordPress admin still works, but, in some cases, even that may refuse to cooperate. In this article, we’ll explain what an internal server error is, and, more importantly, how to fix it.

Important: Always make a complete backup of your site (even if it’s not working as it should be) before making any changes — better safe than sorry!

Let’s get cracking.

What Is an Internal Server Error?

Internal server errors are annoying to users and developers alike because they don’t provide any information about the root of the problem — they just tell you there is one. Imagine if you went to the doctor and said you felt pain, but refused to reveal where that pain was — it’d make it very hard for the doctor to treat it! That’s the difficulty with an internal server error — there’s no indication of where the problem’s coming from.

Internal Server Error

(click to enlarge)

What’s more, the name ‘internal server error’ can be misleading, because, in almost all cases, your host (and/or server) isn’t to blame. If you take a look at the HTTP specifications, you can see that an internal server error means the following:

The server encountered an unexpected condition that prevented it from fulfilling the request.

There’s nothing wrong with the server itself — it’s simply encountered something it can’t figure out.

To figure out what’s going on, you’ll need to do a little troubleshooting and trial and error. By systematically going through the things that could be going wrong, you’ll be able to figure out what’s causing the problem and, more importantly, how to fix it.

How to Fix WordPress 500 Internal Server Error

We recommend you perform these steps in order. That is, start at Step #1 and work your way through the list. In a few situations, we’ll tell you to skip ahead based on the results of one of the steps. But, in general, go from top to bottom!

Beyond that, just a reminder that we always recommend backing up your site before making any of the changes on this list. If you can’t access your WordPress dashboard to use a backup plugin, you should still be able to create a backup through your hosting dashboard — ask your host’s support for help if you’re not sure how.

Now, let’s get to fixing…

0. Enable Debugging

The first step should be to at least try to make sense of the error — you could get lucky! Depending on how your server handles errors, what you’re seeing may not actually be a server error at all. Instead, it could be an error in your site’s code (typically the code of a plugin or theme).

To see whether this is the case, you’ll need to edit the wp-config.php file in your website’s root directory:

  1. Download the file (via FTP).
  2. Open it (using a text editor).
  3. Search for WP_DEBUG.

If the line already exists, change false to true and re-upload the file to the server.

If this line isn’t in your config file, create it by adding the following line of code somewhere above the line that says /* That's all, stop editing! Happy blogging. */:

define( "WP_DEBUG", true );

Reload your website and see if the error changes. If it does, and you now see a ‘fatal error’ message that points to a specific line of code in a specific file, then you’re looking at a relatively simple code error. Assuming said error originates from a plugin or theme, you’ll need to disable the offending product and/or work on fixing the issue yourself (or have someone else take a look at it if you’re not able to work out what’s happening on your own).

Note: Once you’ve finished with this step, make sure to change the WP_DEBUG value back to false, so you don’t accidentally leave debug mode enabled. By default, it will display debug messages on your entire site, which is confusing for your visitors and a potential security risk.

1. Check if Your WordPress Dashboard Works

The next step is to test whether or not you’re able to access your backend WordPress dashboard.

Visit your website admin at http://yoursite.com/wp-admin/. If this page loads properly and allows you to log in, you can be reasonably sure the issue is with a plugin or with your theme. If your admin loads, continue to step two. If it doesn’t, skip to step four.

2. Disable All Plugins

Next, it’s time to test if the issue is coming from a plugin. There’s almost no way a plugin can cause issues if it’s disabled, so the easiest way to test this is to disable all of your plugins at once. This won’t delete your plugins, nor will it make you lose any of your data (that’s still safely stored in your database). What it will do is disable their code from running, which will fix the problem if a plugin’s code is triggering the internal server error.

If your WordPress dashboard is working fine, you can disable plugins by following these steps:

  1. Go to the Plugins area in your WordPress dashboard.
  2. Use the checkbox to select all plugins.
  3. Use the Bulk actions drop-down to Deactivate them.
  4. Click Apply.

Deactivate all WordPress plugins via the dashboard

If you’re unable to deactivate plugins via your dashboard for some reason, you can also deactivate them via FTP by following these instructions:

  1. Connect to your WordPress site’s server via FTP.
  2. Navigate to the wp-content folder.
  3. Rename the plugins folder to plugins-deactivated.

How to bulk deactivate plugins via FTP

If you’ve disabled all of your plugins and your site still won’t load, go to step three.

If your site’s up and running, the next step is to figure out which specific plugin is causing issues.

To do this, you’ll need to reactivate your plugins one by one. Keep checking for that internal server error after activating each plugin. When you’ve found the culprit, you can decide what to do with it. The best course of action is to keep the plugin disabled and notify the author immediately. If it’s a mission-critical plugin, you should probably look for a better, more stable alternative.

Note: If you deactivated your plugins via FTP, you’ll need to rename the folder back to the original plugins name before you can start reactivating plugins.

In some very rare cases, running old software such as PHP 5.3 may cause issues. Before replacing a plugin that’s proved to be trustworthy so far, take a look at step seven.

3. Switch to a Default Theme

If deactivating your plugins didn’t solve the issue, your theme could also be the culprit. You can verify this by switching to a default WordPress theme. We recommend using Twenty Twenty, which is the latest default theme.

If you’re still able to manage themes from your WordPress dashboard, you can do this by going to Appearance -> Themes. If you already deleted the default theme, you can reinstall it from WordPress.org.

If you can’t switch themes from your WordPress dashboard, you can also perform this via FTP by following these instructions:

  1. Connect to your WordPress site’s server via FTP.
  2. Navigate to the wp-content/themes folder.
  3. [Optional] If you don’t have the Twenty Twenty theme installed, you can install it by uploading the theme folder that you download from WordPress.org (make sure to extract the ZIP file before uploading the folder).
  4. Rename the folder of your current theme to [theme-name]-deactivated.

When you rename the folder of your active theme, WordPress will automatically fall back to the default theme (as long as the default theme is installed).

If switching to Twenty Twenty solves the problem, you can re-enable all plugins and get to work finding the issue in your theme’s code.

If your theme is from either the official theme repository or an independent theme shop, you should let the author know as soon as possible. If, on the other hand, it’s your own theme, you’ll need to get a developer to help you out, because these bugs can often be very difficult to find — even for seasoned coders.

In some very rare cases, running old software such as PHP 5.3 may cause issues. Before spending hours trying to find a bug, or paying hundreds of dollars to a developer, take a look at step seven.

4. Increase Your Memory Limit

If your website is using too much memory, it’ll definitely throw a fit — quite possibly resulting in a 500 internal server error. In many cases, this is a sign of a badly coded theme or plugin. It can be remedied quickly by increasing the memory limit, but this isn’t a sure-fire way of solving the problem, and won’t get to the root of it.

You can try to manually increase your memory limit. However, keep in mind that your server or your account may have a set amount of memory allocated to it and you won’t be able to increase your memory limit beyond that.

There are a few ways you can go about increasing your limit:

  • wp-config.php file
  • PHP.ini file (if you have access — you may not)
  • .htaccess file

For all of these files, you’ll need to edit them by connecting to your server via FTP and adding a code snippet (or changing the value of an existing code snippet if the snippet already exists). Here’s what to add:

wp-config.php file

Add the following code snippet above the line that says /* That's all, stop editing! Happy blogging. */:

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

PHP.ini

Find the line that says memory_limit = [number]M and change the number to 256. For example, memory_limit = 256M.

.htaccess file

Add the following line:

php_value memory_limit 256M

Alternatively, speak to your host for more specific instructions — some will be more than happy to increase your memory limit with almost no fuss on your part.

5. Debug .htaccess Issues

If your host uses the Apache Server (which most WordPress hosts do, especially on the budget end), the .htaccess file is a configuration file that enables some relatively advanced functionality. Using it, you can enable gzip compression, change the maximum upload size, set up redirects, and do all sorts of other handy things. WordPress also uses this file to manage your site’s permalinks, among other features.

We’ve already written a guide on how to edit the .htaccess file, but it’s worth reiterating that this is a sensitive area that requires caution. A typo, a forgotten space or an unclosed quote, for example, could easily cause a 500 internal server error, grinding your website — including your admin — to a halt.

There’s a simple way to check if this file has errors:

  1. Connect to your server via FTP and find the .htaccess file, which is located in the root folder.
  2. Back up the existing file by downloading it to your computer.
  3. Once you’ve backed up the original file, delete the copy of .htaccess that’s on your server.

If your website comes back online, then the issue is with your .htaccess file. If you don’t have any custom .htaccess rules (e.g. custom redirects), you can force WordPress to generate a new .htaccess file by going to Settings -> Permalinks and clicking Save (you don’t need to change any settings — just click the save button with your existing settings).

If you do have custom rules, you can go through the .htaccess file line by line to see when your site goes down. Once you’ve found the offending line, make sure it doesn’t have any unnecessary text (perhaps an unclosed quote or something similar). If you can’t find the problem, you’ll probably just want to delete the line. Your website being completely down is far worse than a missing .htaccess line — ask around on forums if you need more help.

To save time, you can also use this free .htaccess syntax checker, which can automatically catch many low-level errors/typos.

6. Reinstall WordPress

It’s extremely rare, but you may have some corrupted files in the WordPress core. This isn’t anything to worry about — something may have gone wrong when your server was copying the required files, for example. Re-uploading the WordPress Core files may solve your problem.

Here’s how to reinstall the core WordPress files:

  1. Download a fresh copy of WordPress from WordPress.org.
  2. Extract the ZIP file.
  3. Delete the wp-content folder and the wp-config-sample.php file. Also, make sure there isn’t a wp-config.php file (and delete one if there is). This file shouldn’t be there, but it’s always good to double-check!
  4. Connect to your server via FTP.
  5. Upload the remaining files and folders to the root folder.
  6. When prompted by your FTP program, tell it to overwrite all files.

How to properly re-upload core WordPress files

7. Check for PHP Version Issues

While old PHP versions usually don’t cause the internal server error, it may be worth talking to your host and asking them to give you a newer version before spending valuable time and money. PHP 7 has deprecated some previous features — for example, a plugin may use a function that’s not available in older versions of PHP, and so on.

Ask your host what version of PHP you’re running. As of September 2020, PHP 5.6 no longer receives any updates (not even basic security support) — don’t accept it if your host is running your site on such an old version. You should at least have some variant of PHP 7 running. Ideally, you’ll want to be on PHP 7.3+ as PHP 7.0 also no longer receives updates and even PHP 7.2 will stop receiving security fixes at the end of 2020.

Nothing Working? Test for Compound Problems

While it’s unlikely you’ll have two problems at once, it can happen. You may have a plugin that’s causing an issue, as well as an .htaccess problem. In this case, the problem won’t be resolved when you disable all plugins and it won’t be resolved if you remove your .htaccess file — only if you do both.

If you’ve followed these steps and you’re still getting a 500 internal server error, you should start again and make sure to not undo any changes. Keep your plugins disabled, keep your theme switched to Twenty Twenty, and so on.

Through trial and error, you’ll be able to discover the combination of issues that are causing problems.

Frustrated By Dealing With Errors? Try Managed WordPress Hosting

As you can see, a lot of work goes into troubleshooting common WordPress errors such as the 500 internal server error. If you don’t want to have to deal with these issues yourself (and you’re willing to pay a little more for the convenience), moving your site to managed WordPress hosting could be a good decision.

A high-quality managed WordPress host will proactively monitor for these types of errors and fix them for you to keep your site working. For example, the support staff at Kinsta, one of our recommended managed WordPress hosts, automatically receive notifications if your site is down because of an internal server error. Additionally, because these hosts offer more of a premium product, their support staff will be more willing to invest time in troubleshooting the problem for you.

Of course, the downside is that you’ll definitely pay a bit more than you would for cheap shared hosting. Typically, a quality managed WordPress host starts at around $30 a month. Still, if you value peace of mind, that price may be worth it, especially for a business website where downtime means lost revenue.

Final Thoughts

Because of the vagueness of the internal server error message, resolving it can be difficult, but, by following the steps above, you should be able to eventually figure out what’s going wrong.

If you still can’t solve the problem, contact your host. Link to this article and let them know you’ve tried these steps, as they’ll appreciate the effort and will be able to locate the issue a lot faster!

Seen any edge cases or downright weird things happening in relation to this error? Let us know in the comments!

By Colin Newcomer

Colin Newcomer is a freelance writer and long-time Internet marketer. He specializes in digital marketing and WordPress. He lives a life of danger, riding a scooter through the chaos of Hanoi.
Comments (policy)
  1. Rahul says:

    Great Blog, Your problem solved our issue. 2nd problem found on our website. Really good and explained blog.

    Thanks :)

  2. Chris says:

    Thanks. Very useful post. In the end it helped me pin down that I had been hacked and the htaccess file had been altered to pass any visited pages through a hackers javascript file using the modrewrite rules.

  3. Chris Andrews says:

    Great writeup!

    One thing you might consider adding. If a cacheing plugin is being used, clear the cache before you move on to more complicated things. I just had a site go into 500/internal error – but only when the user wasn’t logged in. That led me to considering the cache as a potential problem. Clearing the cache fixed whatever the issue was.

  4. Ricardo de la Rosa says:

    Thanks for all the explanation Colin.

    It was helpful. I’ve already experienced internal server errors a couple of times, and I’ve to admit it: it’s frustrating.

    And it’s even worse when you’re doing something important and boom, the error appears.

    So yes, thanks for this list. And I’ll definitely think about using Kinsta at some point. I’ve never allowed myself to try a managed WordPress host.

    Does it help with SEO use that type of hosting?

Leave a Reply

Your email address will not be published. Required fields are marked *

All comments are held for moderation. We'll only publish comments that are on topic and adhere to our Commenting Policy.