The server encountered an internal unspecified error that prevented it from fulfilling the request

If have an upload control on my site defined as:

<dx:ASPxUploadControl ID="ucStatement" runat="server" Width="200px" 
ClientInstanceName="ucStatement" ClientVisible="true" AutoStartUpload="True" 
OnFileUploadComplete="ucStatement_FileUploadComplete" 
OnInit="ucStatement_Init"></dx:ASPxUploadControl>

ucStatement_FileUploadComplete is defined as below, when ms is used later:

MemoryStream ms;

protected void ucStatement_FileUploadComplete(object sender, FileUploadCompleteEventArgs e)
{
    if (!e.UploadedFile.IsValid)
        return;

    ms = new MemoryStream();

    e.UploadedFile.FileContent.CopyTo(ms);
}

On the server it DID work, but since our security technician changed the web config to comply with some security considerations, it throws the error:

The server encountered an internal unspecified error that prevented it
from fulfilling the request.

The web config changes are obviously high up on the list as to why this function isn’t working anymore, but they are very minor changes that shouldn’t impact this.

Looking in to this from various postings on the DevExpress site there are a number of reasons why they say it could be thrown and how to mitigate it. The most relevant post being https://www.devexpress.com/Support/Center/Question/Details/KA18611

Addressing the issues raised there:

1.1 This issue usually occurs when the total request length exceeds the maximum allowed via the «system.web > httpRuntime > maxRequestLength» Web.config key

I am only trying to upload a ~4kb file and I have set in the web config as advised:

<system.web>
    <httpRuntime maxRequestLength="4096" />
    ...
</system.web>

And

<system.webServer>
    ...
    <security>
        <requestFiltering>
            <requestLimits maxAllowedContentLength="30000000" />
        </requestFiltering>
    </security>
</system.webServer>

I also won’t change the UploadMode to Advanced as I don’t want to enforce Silverlight.

EDIT: Further investigation shows a method in DXR.axd called GetFakeIframeDocument throwing the error which I can only find referenced by DevEx staff when they say the request length is greater than maxRequestLength but this is certainly not the case. Is there anything you can see in the web.config at the bottom of this post that would negate this setting? Or not allow any uploads at all?

1.2 This situation can also occur when a web server returns unexpected response/code.

They advise to change FileUploadMode to OnPageLoad. Doing so here gives the same error.

1.3 The «The server encountered an internal unspecified error that prevented it from fulfilling the request» error can also be caused by enabling tracing in the Web.config file.

Tracing is not set up in the web.config

1.4 Is it possible to customize/override the «The server encountered an internal unspecified error that prevented it from fulfilling the request» error message?

They advise capturing the error by capturing all CallBack errors. I already do this as such:

void Application_Start(object sender, EventArgs e) {
    DevExpress.Web.ASPxWebControl.CallbackError += new EventHandler(Application_Error);
}

void Application_Error(object sender, EventArgs e)
{
    HttpServerUtility server = HttpContext.Current.Server;
    Exception ex = server.GetLastError();

    if (ex is HttpUnhandledException)
        ex = ex.InnerException;

    ProcessException(ex)
}

ProcessException does a number of different things, writes to the event log, writes to an error log file and inserts into a SQL database.

All of the these functions work if an error is thrown by any other part of the application. When the Upload Control throws the error, nothing is logged.

So, what could possibly be causing this? Why might this error not hit the Application_Error function? What should I do?

Below is the web.config for full disclosure:

<configuration>
  <configSections>
    <sectionGroup name="devExpress">
      <section name="themes" type="DevExpress.Web.ThemesConfigurationSection, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" requirePermission="false" />
      <section name="compression" type="DevExpress.Web.CompressionConfigurationSection, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" requirePermission="false" />
      <section name="settings" type="DevExpress.Web.SettingsConfigurationSection, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" requirePermission="false" />
      <section name="errors" type="DevExpress.Web.ErrorsConfigurationSection, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <connectionStrings>
    <add connectionString="xxxxx" name="myConnectionString" providerName="System.Data.SqlClient" />
  </connectionStrings>
  <system.web>
    <httpCookies httpOnlyCookies="true" requireSSL="true"/>
    <compilation debug="false" targetFramework="4.5">
      <assemblies>
        <add assembly="DevExpress.Data.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.ASPxHtmlEditor.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.ASPxSpellChecker.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.ASPxTreeList.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.ASPxThemes.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.ASPxPivotGrid.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Utils.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Office.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.RichEdit.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.SpellChecker.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Charts.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.XtraCharts.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.XtraGauges.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.XtraGauges.v14.2.Presets, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.ASPxGauges.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.XtraCharts.v14.2.Web, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Printing.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.XtraReports.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.XtraReports.v14.2.Web, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.XtraPivotGrid.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.PivotGrid.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.XtraScheduler.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.ASPxScheduler.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Spreadsheet.v14.2.Core, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
        <add assembly="DevExpress.Web.ASPxSpreadsheet.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
      </assemblies>
    </compilation>
    <authentication mode="Windows" />
    <profile>
      <providers>
        <clear />
        <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="ApplicationServices" applicationName="/" />
      </providers>
    </profile>
    <roleManager enabled="false">
      <providers>
        <clear />
        <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="ApplicationServices" applicationName="/" />
        <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
      </providers>
    </roleManager>
    <sessionState timeout="5"></sessionState>
    <httpHandlers>
      <add type="DevExpress.Web.ASPxUploadProgressHttpHandler, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" verb="GET,POST" path="ASPxUploadProgressHandlerPage.ashx" validate="false" />
      <add type="DevExpress.Web.ASPxHttpHandlerModule, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" verb="GET,POST" path="DX.ashx" validate="false" />
    </httpHandlers>
    <httpModules>
      <add type="DevExpress.Web.ASPxHttpHandlerModule, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" name="ASPxHttpHandlerModule" />
    </httpModules>
    <globalization culture="" uiCulture="" />
    <httpRuntime maxRequestLength="4096" requestValidationMode="4.0" executionTimeout="110" />
    <pages validateRequest="true" clientIDMode="AutoID">
      <controls>
        <add tagPrefix="dx" namespace="DevExpress.Web" assembly="DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" />
      </controls>
    </pages>
        <authorization>
            <allow users="*" />
        </authorization>
        <machineKey decryption="AES" validation="AES" />
        <trust level="Full" />
  </system.web>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      <add type="DevExpress.Web.ASPxHttpHandlerModule, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" name="ASPxHttpHandlerModule" />
    </modules>
    <handlers>
      <add type="DevExpress.Web.ASPxUploadProgressHttpHandler, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" verb="GET,POST" path="ASPxUploadProgressHandlerPage.ashx" name="ASPxUploadProgressHandler" preCondition="integratedMode" />
      <add type="DevExpress.Web.ASPxHttpHandlerModule, DevExpress.Web.v14.2, Version=14.2.7.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" verb="GET,POST" path="DX.ashx" name="ASPxHttpHandlerModule" preCondition="integratedMode" />
    </handlers>
    <validation validateIntegratedModeConfiguration="false" />
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="30000000" />
                <fileExtensions allowUnlisted="true">
                </fileExtensions>
      </requestFiltering>
    </security>
        <httpErrors errorMode="Custom" />
    <httpProtocol>
      <customHeaders>
        <add name="X-Frame-Options" value="DENY" />
        <add name="X-Content-Type-Options" value="no sniff"/>
      </customHeaders>
    </httpProtocol>
  </system.webServer>
  <devExpress>
    <themes enableThemesAssembly="true" styleSheetTheme="" theme="Metropolis" customThemeAssemblies="" />
    <compression enableHtmlCompression="false" enableCallbackCompression="true" enableResourceCompression="true" enableResourceMerging="true" />
    <settings doctypeMode="Html5" rightToLeft="false" embedRequiredClientLibraries="true" ieCompatibilityVersion="edge" />
    <errors callbackErrorRedirectUrl=""/>
  </devExpress>
</configuration>

The dreaded 500 internal server error. It always seems to come at the most inopportune time and you’re suddenly left scrambling to figure out how to get your WordPress site back online. Trust us, we’ve all been there. Other errors that behave similarly that you might have also seen include the frightening error establishing a database connection and the dreaded white screen of death. But from the moment your site goes down, you’re losing visitors and customers. Not to mention it simply looks bad for your brand.

Today we’re going to dive into the 500 internal server error and walk you through some ways to get your site back online quickly. Read more below about what causes this error and what you can do to prevent it in the future.

• What is a 500 internal server error?
• How to fix the 500 internal server error

Check Out Our Ultimate Guide to Fixing the 500 Internal Server Error

What is a 500 Internal Server Error?

The Internet Engineering Task Force (IETF) defines the 500 Internal Server Error as:

The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

When you visit a website your browser sends a request over to the server where the site is hosted. The server takes this request, processes it, and sends back the requested resources (PHP, HTML, CSS, etc.) along with an HTTP header. The HTTP also includes what they call an HTTP status code. A status code is a way to notify you about the status of the request. It could be a 200 status code which means “Everything is OK” or a 500 status code which means something has gone wrong.

There are a lot of different types of 500 status error codes (500, 501, 502, 503, 504, etc.) and they all mean something different. In this case, a 500 internal server error indicates that the server encountered an unexpected condition that prevented it from fulfilling the request (RFC 7231, section 6.6.1).

500 Internal Server Error Variations

Due to the various web servers, operating systems, and browsers, a 500 internal server error can present itself in a number of different ways. But they are all communicating the same thing. Below are just a couple of the many different variations you might see on the web:

• • “500 Internal Server Error”
  • “HTTP 500”
  • “Internal Server Error”
  • “HTTP 500 – Internal Server Error”
  • “500 Error”
  • “HTTP Error 500”
  • “500 – Internal Server Error”
  • “500 Internal Server Error. Sorry something went wrong.”
  • “500. That’s an error. There was an error. Please try again later. That’s all we know.”
  • “The website cannot display the page – HTTP 500.”
  • “Is currently unable to handle this request. HTTP ERROR 500.”

You might also see this message accompanying it:

The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [email protected] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log.

Other times, you might simply see a blank white screen. When dealing with 500 internal server errors, this is actually quite common in browsers like Firefox and Safari.

Bigger brands might even have their own custom 500 internal server error messages, such as this one from Airbnb.

Here is another creative 500 server error example from the folks over at readme.

Even the mighty YouTube isn’t safe from 500 internal server errors.

If it’s an IIS 7.0 (Windows) or higher server, they have additional HTTP status codes to more closely indicate the cause of the 500 error:

• 500.0 – Module or ISAPI error occurred.
• 500.11 – Application is shutting down on the web server.
• 500.12 – Application is busy restarting on the web server.
• 500.13 – Web server is too busy.
• 500.15 – Direct requests for global.asax are not allowed.
• 500.19 – Configuration data is invalid.
• 500.21 – Module not recognized.
• 500.22 – An ASP.NET httpModules configuration does not apply in Managed Pipeline mode.
• 500.23 – An ASP.NET httpHandlers configuration does not apply in Managed Pipeline mode.
• 500.24 – An ASP.NET impersonation configuration does not apply in Managed Pipeline mode.
• 500.50 – A rewrite error occurred during RQ_BEGIN_REQUEST notification handling. A configuration or inbound rule execution error occurred.
• 500.51 – A rewrite error occurred during GL_PRE_BEGIN_REQUEST notification handling. A global configuration or global rule execution error occurred.
• 500.52 – A rewrite error occurred during RQ_SEND_RESPONSE notification handling. An outbound rule execution occurred.
• 500.53 – A rewrite error occurred during RQ_RELEASE_REQUEST_STATE notification handling. An outbound rule execution error occurred. The rule is configured to be executed before the output user cache gets updated.
  500.100 – Internal ASP error.

500 Errors Impact on SEO

Unlike 503 errors, which are used for WordPress maintenance mode and tell Google to check back at a later time, a 500 error can have a negative impact on SEO if not fixed right away. If your site is only down for say 10 minutes and it’s being crawled consistently a lot of times the crawler will simply get the page delivered from cache. Or Google might not even have a chance to re-crawl it before it’s back up. In this scenario, you’re completely fine.

However, if the site is down for an extended period of time, say 6+ hours, then Google might see the 500 error as a site level issue that needs to be addressed. This could impact your rankings. If you’re worried about repeat 500 errors you should figure out why they are happening to begin with. Some of the solutions below can help.

How to Fix the 500 Internal Server Error

Where should you start troubleshooting when you see a 500 internal server error on your WordPress site? Sometimes you might not even know where to begin. Typically 500 errors are on the server itself, but from our experience, these errors originate from two things, the first is user error (client-side issue), and the second is that there is a problem with the server. So we’ll dive into a little of both.

This is never not annoying 😖 pic.twitter.com/pPKxbkvI9K

— Dare Obasanjo 🐀 (@Carnage4Life) September 26, 2019

Check out these common causes and ways to fix the 500 internal server error and get back up and running in no time.

1. Try Reloading the Page

This might seem a little obvious to some, but one of the easiest and first things you should try when encountering a 500 internal server error is to simply wait a minute or so and reload the page (F5 or Ctrl + F5). It could be that the host or server is simply overloaded and the site will come right back. While you’re waiting, you could also quickly try a different browser to rule that out as an issue.

Another thing you can do is to paste the website into downforeveryoneorjustme.com. This website will tell you if the site is down or if it’s a problem on your side. A tool like this checks the HTTP status code that is returned from the server. If it’s anything other than a 200 “Everything is OK” then it will return a down indication.

We’ve also noticed that sometimes this can occur immediately after you update a plugin or theme on your WordPress site. Typically this is on hosts that aren’t set up properly. What happens is they experience a temporary timeout right afterward. However, things usually resolve themselves in a couple of seconds and therefore refreshing is all you need to do.

2. Clear Your Browser Cache

Clearing your browser cache is always another good troubleshooting step before diving into deeper debugging on your site. Below are instructions on how to clear cache in the various browsers:

• How to Force Refresh a Single Page for All Browsers
• How to Clear Browser Cache for Google Chrome
• How to Clear Browser Cache for Mozilla Firefox
• How to Clear Browser Cache for Safari
• How to Clear Browser Cache for Internet Explorer
• How to Clear Browser Cache for Microsoft Edge
• How to Clear Browser Cache for Opera

3. Check Your Server Logs

You should also take advantage of your error logs. If you’re a Kinsta client, you can easily see errors in the log viewer in the MyKinsta dashboard. This can help you quickly narrow down the issue, especially if it’s resulting from a plugin on your site.

If your host doesn’t have a logging tool, you can also enable WordPress debugging mode by adding the following code to your wp-config.php file to enable logging:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

The logs are typically located in the /wp-content directory. Others, like here at Kinsta might have a dedicated folder called “logs”.

You can also check the log files in Apache and Nginx, which are commonly located here:

• Apache: /var/log/apache2/error.log
• Nginx: /var/log/nginx/error.log

If you’re a Kinsta client you can also take advantage of our analytics tool to get a breakdown of the total number of 500 errors and see how often and when they are occurring. This can help you troubleshoot if this is an ongoing issue, or perhaps something that has resolved itself.

If the 500 error is displaying because of a fatal PHP error, you can also try enabling PHP error reporting. Simply add the following code to the file throwing the error. Typically you can narrow down the file in the console tab of Google Chrome DevTools.

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

And you might need to also modify your php.ini file with the following:

display_errors = on

4. Error Establishing a Database Connection

500 internal server errors can also occur from a database connection error. Depending upon your browser you might see different errors. But both will generate a 500 HTTP status code regardless in your server logs.

Below is an example of what an “error establishing a database connection” message looks like your browser. The entire page is blank because no data can be retrieved to render the page, as the connection is not working properly. Not only does this break the front-end of your site, but it will also prevent you from accessing your WordPress dashboard.

So why exactly does this happen? Well, here are a few common reasons below.

• The most common issue is that your database login credentials are incorrect. Your WordPress site uses separate login information to connect to its MySQL database.
• Your WordPress database is corrupted. With so many moving parts with themes, plugins, and users constantly deleting and installing them, sometimes databases get corrupted. This can be due to a missing or individually corrupted table, or perhaps some information was deleted by accident.
• You may have corrupt files in your WordPress installation. This can even happen sometimes due to hackers.
• Issues with your database server. A number of things could be wrong on the web hosts end, such as the database being overloaded from a traffic spike or unresponsive from too many concurrent connections. This is actually quite common with shared hosts as they are utilizing the same resources for a lot of users on the same servers.

Check out our in-depth post on how to fix the error establishing a database connection in WordPress.

5. Check Your Plugins and Themes

Third-party plugins and themes can easily cause 500 internal server errors. We’ve seen all types cause them here at Kinsta, from slider plugins to ad rotator plugins. A lot of times you should see the error immediately after installing something new or running an update. This is one reason why we always recommend utilizing a staging environment for updates or at least running updates one by one. Otherwise, if you encounter a 500 internal server error you’re suddenly scrambling to figure out which one caused it.

A few ways you can troubleshoot this is by deactivating all your plugins. Remember, you won’t lose any data if you simply deactivate a plugin. If you can still access your admin, a quick way to do this is to browse to “Plugins” and select “Deactivate” from the bulk actions menu. This will disable all of your plugins.

If this fixes the issue you’ll need to find the culprit. Start activating them one by one, reloading the site after each activation. When you see the 500 internal server error return, you’ve found the misbehaving plugin. You can then reach out to the plugin developer for help or post a support ticket in the WordPress repository.

If you can’t login to WordPress admin you can FTP into your server and rename your plugins folder to something like plugins_old. Then check your site again. If it works, then you will need to test each plugin one by one. Rename your plugin folder back to “plugins” and then rename each plugin folder inside of if it, one by one, until you find it. You could also try to replicate this on a staging site first.

Always makes sure your plugins, themes, and WordPress core are up to date. And check to ensure you are running a supported version of PHP. If it turns out to be a conflict with bad code in a plugin, you might need to bring in a WordPress developer to fix the issue.

6. Reinstall WordPress Core

Sometimes WordPress core files can get corrupted, especially on older sites. It’s actually quite easy to re-upload just the core of WordPress without impacting your plugins or themes. We have an in-depth guide with 5 different ways to reinstall WordPress. And of course, make sure to take a backup before proceeding. Skip to one of the sections below:

• How to reinstall WordPress from the WordPress dashboard while preserving existing content
• How to manually reinstall WordPress via FTP while preserving existing content
• How to manually reinstall WordPress via WP-CLI while preserving existing content

7. Permissions Error

A permissions error with a file or folder on your server can also cause a 500 internal server error to occur. Here are some typical recommendations for permissions when it comes to file and folder permissions in WordPress:

• All files should be 644 (-rw-r–r–) or 640.
• All directories should be 755 (drwxr-xr-x) or 750.
• No directories should ever be given 777, even upload directories.
• Hardening: wp-config.php could also be set to 440 or 400 to prevent other users on the server from reading it.

See the WordPress Codex article on changing file permissions for a more in-depth explanation.

You can easily see your file permissions with an FTP client (as seen below). You could also reach out to your WordPress host support team and ask them to quickly GREP file permissions on your folders and files to ensure they’re setup properly.

8. PHP Memory Limit

A 500 internal server error could also be caused by exhausting the PHP memory limit on your server. You could try increasing the limit. Follow the instructions below on how to change this limit in cPanel, Apache, your php.ini file, and wp-config.php file.

Increase PHP Memory Limit in cPanel

If you’re running on a host that uses cPanel, you can easily change this from the UI. Under Software click on “Select PHP Version.”

Click on “Switch to PHP Options.”

You can then click on the memory_limit attribute and change its value. Then click on “Save.”

Increase PHP Memory Limit in Apache

The .htaccess file is a special hidden file that contains various settings you can use to modify the server behavior, right down to a directory specific level. First login to your site via FTP or SSH, take a look at your root directory and see if there is a .htaccess file there.

If there is you can edit that file to add the necessary code for increasing the PHP memory limit. Most likely it is set at 64M or below, you can try increasing this value.

php_value memory_limit 128M

Increase PHP Memory Limit in php.ini File

If the above doesn’t work for you might try editing your php.ini file. Log in to your site via FTP or SSH, go to your site’s root directory and open or create a php.ini file.

If the file was already there, search for the three settings and modify them if necessary. If you just created the file, or the settings are nowhere to be found you can paste the code below. You can modify of course the values to meet your needs.

memory_limit = 128M

Some shared hosts might also require that you add the suPHP directive in your .htaccess file for the above php.ini file settings to work. To do this, edit your .htaccess file, also located at the root of your site, and add the following code towards the top of the file:

<IfModule mod_suphp.c> 
suPHP_ConfigPath /home/yourusername/public_html
</IfModule>

If the above didn’t work for you, it could be that your host has the global settings locked down and instead have it configured to utilize .user.ini files. To edit your .user.ini file, login to your site via FTP or SSH, go to your site’s root directory and open or create a .user.ini file. You can then paste in the following code:

memory_limit = 128M

Increase PHP Memory Limit in wp-config.php

The last option is not one we are fans of, but if all else fails you can give it a go. First, log in to your site via FTP or SSH, and locate your wp-config.php file, which is typically in the root of your site.

Add the following code to the top of your wp-config.php file:

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

You can also ask your host if you’re running into memory limit issues. We utilize the Kinsta APM tool and other troubleshooting methods here at Kinsta to help clients narrow down what plugin, query, or script might be exhausting the limit. You can also use your own custom New Relic key from your own license.

9. Problem With Your .htaccess File

Kinsta only uses Nginx, but if you’re using a WordPress host that is running Apache, it could very well be that your .htaccess file has a problem or has become corrupted. Follow the steps below to recreate a new one from scratch.

First, log in to your site via FTP or SSH, and rename your .htaccess file to .htaccess_old.

Normally to recreate this file you can simply re-save your permalinks in WordPress. However, if you’re in the middle of a 500 internal server error you most likely can’t access your WordPress admin, so this isn’t an option. Therefore you can create a new .htaccess file and input the following contents. Then upload it to your server.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

See the WordPress Codex for more examples, such as a default .htaccess file for multisite.

10. Coding or Syntax Errors in Your CGI/Perl Script

500 errors being caused by errors in CGI and Perl is a lot less common than it used to be. Although it’s still worth mentioning, especially for those using cPanel where there are a lot of one-click CGI scripts still being used. As AEM on Stack Overflow says:

CGI has been replaced by a vast variety of web programming technologies, including PHP, various Apache extensions like mod_perl, Java of various flavors and frameworks including Java EE, Struts, Spring, etc, Python-based frameworks like Django, Ruby on Rails and many other Ruby frameworks, and various Microsoft technologies.

Here are a few tips when working with CGI scripts:

• When editing, always used a plain text editor, such as Atom, Sublime, or Notepad++. This ensures they remain in ASCII format.
• Ensure correct permissions of chmod 755 are used on CGI scripts and directories.
• Upload your CGI scripts in ASCII mode (which you can select in your FTP editor) into the cgi-bin directory on your server.
• Confirm that the Perl modules you require for your script are installed and supported.

11. Server Issue (Check With Your Host)

Finally, because 500 internal server errors can also occur from PHP timing out or fatal PHP errors with third-party plugins, you can always check with your WordPress host. Sometimes these errors can be difficult to troubleshoot without an expert. Here are just a few common examples of some errors that trigger 500 HTTP status codes on the server that might have you scratching your head.

PHP message: PHP Fatal error: Uncaught Error: Call to undefined function mysql_error()...

PHP message: PHP Fatal error: Uncaught Error: Cannot use object of type WP_Error as array in /www/folder/web/shared/content/plugins/plugin/functions.php:525

We monitor all client’s sites here at Kinsta and are automatically notified when these types of errors occur. This allows us to be pro-active and start fixing the issue right away. We also utilize LXD managed hosts and orchestrated LXC software containers for each site. This means that every WordPress site is housed in its own isolated container, which has all of the software resources required to run it (Linux, Nginx, PHP, MySQL). The resources are 100% private and are not shared with anyone else or even your own sites.

PHP timeouts could also occur from the lack of PHP workers, although typically these cause 504 errors, not 500 errors. These determine how many simultaneous requests your site can handle at a given time. To put it simply, each uncached request for your website is handled by a PHP Worker.

When PHP workers are already busy on a site, they start to build up a queue. Once you’ve reached your limit of PHP workers, the queue starts to push out older requests which could result in 500 errors or incomplete requests. Read our in-depth article about PHP workers.

Monitor Your Site

If you’re worried about these types of errors happening on your site in the future, you can also utilize a tool like updown.io to monitor and notify you immediately if they occur. It periodically sends an HTTP HEAD request to the URL of your choice. You can simply use your homepage. The tool allows you to set check frequencies of:

• 15 seconds
• 30 seconds
• 1 minute
• 2 minutes
• 5 minutes
• 10 minutes

It will send you an email if and when your site goes down. Here is an example below.

This can be especially useful if you’re trying to debug a faulty plugin or are on a shared host, who tend to overcrowd their servers. This can give you proof of how often your site might actually be doing down (even during the middle of the night).

That’s why we always recommend going with an application, database, and managed WordPress host (like Kinsta).

Make sure to check out our post that explores the top 9 reasons to choose managed WordPress hosting.

Summary

500 internal server errors are always frustrating, but hopefully, now you know a few additional ways to troubleshoot them to quickly get your site back up and running. Remember, typically these types of errors are caused by third-party plugins, fatal PHP errors, database connection issues, problems with your .htaccess file or PHP memory limits, and sometimes PHP timeouts.

Was there anything we missed? Perhaps you have another tip on troubleshooting 500 internal server errors. If so, let us know below in the comments.

The internet for the frontend users may look simple, but it has complex environment at the backend. As a user, you may not be worrying much about the process happens at the backend. But if you have noticed, there are many error messages shown on the browser whenever there are problems in accessing a website. These are called HTTP status codes indicating the technical representation of the problem in the connectivity. A simple example is a “404 Page Not Found” error indicating the page you are trying to open is not available.

Similarly if you’ve found yourself confronted with a “500 Internal Server Error”, you’re probably wondering what it is and how to fix it.

Plainly speaking, an internal server error typically means that something, somewhere, has gone wrong on the web server. The formal definition of 500 internal server error is as below:

The 500 HTTP status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

Like most internet based errors, they can be seen on any browser, operating system or device that has access to the internet. The error message is shown differently on the browser based on the type of web server. Below is an example from the Apache server.

On other servers it may show messages like:

500 Internal Server Error

Sorry, something went wrong.

A team of highly trained monkeys has been dispatched to deal with this situation. Please report this incident to customer service.

Also, please include the following information in your error report:

Usually, the problem has something to do with the web page, or the coding behind it, and is typically not on your end. However there are always couple of things that can be tried to fix this error.

How to Fix 500 Internal Server Error?

We have divided this article for two different group of users:

• For an internet user
• For a website owner

Let us explain the steps for both groups, you can follow depending upon your situation.

Fixing 500 Internal Server Error for an User

1. Reload the Webpage

The first possible solution to the problem is just to simply reload the page on your browser. You can do this by clicking on the refresh button on the address bar.

Remember refreshing the webpage will try to resend the data to webserver. Hence, don’t refresh the page if you have filled up some forms like payment form. This is to avoid the form is submitted double time and the payment is also done double time.

2. Check the URL

Accessing inappropriate URL may also result in internal server error. So ensure to check the spelling of your URL is correct.

If you are accessing subdirectories, try going to the base URL of the site and see if you can go to where you were again. For example, if you were stuck on a page called “www.site.com/options/”, the base URL for the address would be “www.site.com”.

3. Clear Browser’s Cache

Failing that, you could attempt to clear the browser cache. A browser cache is essentially a storage place for all the related web data that you may have accumulated whilst visiting websites. Often when webpages are loaded frequently, or have been done so recently, the webpage will load back off of the browser cache, giving the semblance of having loaded again. For this reason, clearing the cache might cause the webpage to fully reload and potentially resolve the problem. Clearing browser’s cache or history may differ based on the browser you use. Generally this can be done through the browser’s settings page.

If you are using Google Chrome, go to the URL “chrome://settings/clearBrowserData”. Choose “Cached images and files” and click on the “Clear Browsing Data” button.

4. Clear Browser Cookies

Cookies are essentially little pockets of data that might relate to certain functions in a website. They are stored by the browser and used when required. Sometimes corrupted cookies can also cause the problem and result in internal server error. Though this is rate situation, no harm in trying to open the page after clearing the cookies on your browser.

While clearing your browser cache, ensure to choose the checkbox “Cookies and other site data”. Remember clearing cookies will sign out you form the logged in sites. You should log into those sites again.

5. Check the Site is Up

If the above still hasn’t done anything to fix the problem, then the problem could be that the site itself is down. Use one of the site up or down services and check the site you are trying to access is really down.

6. Contact Your ISP

If the site is up and only you get 500 internal server error, then probably some misconfiguration at your ISP could cause that. Check out with your service provider that everything is fine from his end.

7. Contact Site Owner or Administrator

If the site is down then it’s a good idea to inform the site owner about it. Generally the site owner’s email would be something like “[email protected]” or “[email protected]”. If you could not remember the site owner’s email, just send email to “[email protected]”. Most of the professional site owners use catch all email id. This means whatsoever the address you mentioned, all the emails will be forwarded to a specific id of their choice.

Note: Sometimes the server may not interpret the problem correctly and treat “504 Gateway Error” as “500 Internal Server Error”. So try out the fixes for 504 Gateway Timeout error also, it could help just in case.

Beyond these options, you have to wait and just try to open the page later.

If You are a Website Owner or Administrator:

1. Check Plugins and Themes

As a site owner, you need to update plugins and themes of your website to keep them in a latest and secured version. This is especially true when you content management systems like WordPress.

There are many possibilities the PHP code on these plugins are resulting in a conflict and show 500 internal server error on the browser. So the first action you should do is to revert back the last action and downgrade the plugin or theme to it’s previous version. You should test the latest version in development site before applying the changes in production version.

2. Check Server Log

The web server will have a log file to record all the activities carried out by different users. This log file will be located in the root of your website with the name like “logs” or “error_log”. When you see internal server error, open the log file and try to understand what exactly is causing the error.

If you can’t access the error log or can’t understand the content, request your hosting company to analyze the error log file for you. It is important to get the root cause so that it will not repeat again affecting the live users.

3. Check File Permissions

Remember the correct file permission is important for a website to load properly on the browser. Generally file permission is applied at directory level which will be applied to all files in that directory. In this case, the directory with wrong file permission will lead to internal server error.

Let us take an example, we store images in a separate folder classified with yearly and then monthly. The folder 2017 has correct permission for read, write and execute. When the year ends, the new folder is created by default for 2018 which does not have execute permission for normal users. This resulted in the pages with the images from 2018 folder will show 500 internal server error while other pages will load normally.

If you could not guess or identify the file permission yourself ask help from the hosting company. Content management systems like WordPress has security plugins to check and apply correct file permissions for the complete site with a single click.

4. Check CDN and Caching

The other important aspect of websites is using content delivery network (CDN) and caching plugins in order to improve the page loading speed. Caching has different steps like combining scripts and stylesheets, passing the traffic to CDN servers or redirecting the traffic through different nameservers.

In all cases, there are lot of possibilities something can go wrong and the caching will result in server error. So if you have caching enabled and getting the 500 HTTP error then disable caching and then check the site is working fine.

5. 500 Internal Error Due to Scripts

The web server can only handle certain amount of load in terms of CPU and memory. You will see internal server error or one of the 5xx HTTP error codes, whenever the requested resource is triggering a script in the backend trying to overload the server.

Let us take an example, you have a dynamic XML Sitemap on your site triggered with PHP script. This Sitemap has thousands of URLs in a single file. Most of the servers will not have capability to show thousands of URLs in a single XML Sitemap file. This will result in showing server error when you try to open the Sitemap on the browser. Here you should split the Sitemap by reducing the number of URLs to avoid the error.

6. Due to Wrong Directives and Configurations

Ensure to play around with the backend files on your site with care. Leaving a single additional dot in those files will result in server configuration errors like internal server error. Below are some of the commonly accessed files where you can check for errors:

• Wrong directive entry in your .htaccess file
• Mistakes in theme’s functions file
• Error in server configuration file

Conclusion

We have explained the possible fixes for 500 internal server error both from the end user as well as site owner perspective. Most of the time, merely refreshing the page or loading after few minutes will resolve the problem. But if the problem persist users can’t do much as the error is originating from the web server. If you are a site owner then get in tough with your hosting company to resolve the issue.

The “HTTP 500 Internal Server” error is quite general as it can be caused by a broad range of issues. Because of that, you may stumble upon it quite often.

This article will explain the “HTTP Error 500” and how to troubleshoot it.

What does “HTTP 500 Internal Server Error” mean?

The HTTP status code “500 – Internal Server Error” is one of the many 5.X.X. HTTP error codes (500, 502, 503, 504, etc.). Each of them specifies a different problem but the common denominator they share is that they tell you something is wrong with the website’s server.

The HTTP 500 error, in particular, indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

In other words, the hosting server can’t determine the exact problem and display a more specific message. Instead, it responds with the error “500 Internal Server Error” which means that it’s not clear what’s wrong.

You may see different message variations since many websites and web servers customize the error page.

Some examples of the error message include:

• 500 Internal Server Error
• Internal Server Error 500
• HTTP Error 500
• HTTP Status 500 – Internal Server Error
• Error 500 Internal Server Error
• 500 Error
• 500. That’s an error

Apart from the text, the page’s look may vary for different websites. Below you can see a generic version of the “Internal Server Error” page.

Other times, the page may have a customized design, as seen in the following image.

These are only a few examples of the error page and you can see it in countless variations. Regardless of how the page looks, it always has the same meaning – there is a problem that the server can’t pinpoint, and it prevents you from loading the website.

What are the common problems that can cause HTTP 500 Internal Server Error?

Although the error definition states the issue is from the server, that’s not always the case. Some of the common problems that can cause the error are:

• Corrupted browser cache
• Temporary connectivity issues
• Syntax errors or incorrect rules in the website’s .htaccess file
• Incorrect file and folder permissions
• Wrong PHP version for the website
• Corrupted .htaccess file
• Corrupted website’s database
• Problems with WordPress themes and plugins
• Exhausted PHP memory limit on the website
• Corrupted WordPress core files
• Large files on your website
• Problems with the MySQL server

How to Fix the “500 Internal Server” Error?

As you can see from the list above, the error’s origins are quite diverse. Since the error page will not clearly indicate the problem, you may need to troubleshoot a few of the possible causes until you find the culprit.

We will go over most of the eventual problems and their solutions.

How to Fix the “HTTP Error 500” as a visitor?

As a visitor, the only thing you can do is check if a connectivity issue from your end causes the error. You can also apply the following actions as a website owner since these are the quickest checks. If the error is caused by a local problem from your end, the steps below can save you a lot of time from troubleshooting.

Reload the page

The “HTTP Error 500” may be visible only for you, in case there was a brief connectivity problem. The website itself may be working fine, but you might have tried to access it when there was a momentary downtime, or your network failed to establish a connection to the website’s server.

Try reloading the page in the same browser with the Reload button or by pressing the keyboard shortcut Command+R for Mac, or F5 (Control+F5) for Windows.

If the website loads correctly, the issue was only temporary, and you can stop troubleshooting.

Clear your browser cache and cookies

When the website doesn’t open after reloading, your browser might be keeping expired or corrupted cache files and cookies. Reloading the page will not delete them, so you must clear them manually.

Read this guide on clearing cache and cookies in desktop browsers for detailed instructions.

Check these articles on deleting the cache on an Android phone or iPhone, if you use a mobile device.

Alternatively, you can test opening the page from another browser. For instance, if you use Chrome, try Firefox or vice versa.

After clearing the browser’s cache, reload the page to see if that solved the problem. If not, proceed with the next step.

Visit the website using another network

The connectivity problems causing the “HTTP 500 Error” may happen across your entire network. In this case, you will probably see the error on any device on this network.

To test if this is the problem, switch to another network. For instance, if you use a mobile phone connected to Wi-Fi, switch to mobile data.

How to Fix the HTTP 500 Internal Server Error from the website?

In the best-case scenario, the steps mentioned above will fix the problem. However, if the error persists, you may need to dig deeper into the issue since the error stems from the website itself.

As a site owner or webmaster, there are several checks you can do that can solve the “500 Internal Server Error.”

Check the Error Logs of the Website

In many cases, misconfigured files or scripts are the sources of the website’s errors. The error logs can help you identify them easier.

Typically, you should have such logs in your hosting’s control panel. SiteGround users can find the Error log in the website’s Site Tools.

To access it, navigate to the Websites section in your Client Area. Open the Site Tools of the respective site, select Statistics and click on Error Log.

You will see the most recent errors on your website that the server detected. Each error will be recorded with a few key pieces of information:

• The date and time of the error.
• Description of the error.
• Information about which folder or file is possibly generating the error.

Below, you can see an error log indicating a problem with the .htaccess file.

This record indicates that the problem is from the .htaccess file located in the root folder of the website. It also specifies that the error is related to an <IfModule> missing arguments, which means there is a syntax error.

Using this information, you can navigate to the specified folder from File Manager, edit the .htaccess file and correct the syntax error.

Keep in mind that the Error log records errors related to the server configuration. Errors caused by PHP misconfiguration and scripts are not recorded, as they happen on application-level.

PHP errors are recorded in php_errorlog. It is generated automatically in the folder of the offending PHP file. On SiteGround’s hosting, the PHP error log is active by default. If you have previously deactivated it or your hosting hasn’t enabled it, read this guide on how to enable error reporting in a PHP script.

To inspect the PHP error log, you can use File Manager or FTP client. Navigate to the root folder, if the error is caused by a script located in the root folder. Open the file php_errorlog, where you can examine the errors.

The php_errorlog shows general PHP errors. However, you may need a more detailed log of the problem. If you have a WordPress website, you can also enable the debug log for WordPress that can show more information. For detailed steps on how to enable the WordPress debug log, see this guide.

Reset File and Folder Permissions

Another common problem that can cause the “HTTP 500 Error” are incorrect file and folder permissions on your website. If the permissions prevent visitors from opening the critical website’s files and folders, they may see the error page.

The standard permissions are 644 for files and 755 for folders. You can change them from the File Manager in your hosting panel or from an FTP Client.

For setting the permissions for WordPress sites, SiteGround clients can use the Reset Permissions tool for WordPress in Site Tools.

If your website is using another type of application, read this guide on how to change permissions for files and folders from File Manager.

Alternatively, if your hosting’s panel doesn’t have similar tools, you can change permissions from SSH or from an FTP Client.

Change the PHP version

An incorrect PHP version on your website may cause PHP scripts to time out or produce fatal errors. As a result, the website may return the “HTTP 500 Error.”

Test switching the PHP version to an older or later version. If the error disappears, it’s an indication that the previous version was wrong. Keep the site on the newly selected one.

SiteGround users can easily switch the PHP version with only a few clicks on Site Tools. For detailed steps, check this guide on how to switch to a different PHP version in Site Tools.

Inspect or regenerate the .htaccess file

A common cause of the “Internal Server Error” is a problem within the .htaccess file. If the file is corrupted, it defines an incorrect root folder or contains syntax errors, the usual result is the “HTTP 500 Error” page.

Fix the syntax error in .htaccess

As an example of a syntax error, we can use the previously mentioned error from the error log.

<2022-05-17 14:32:40 UTC [apache][core:alert] [pid 68451] [client 35.214.177.225:57966] /home/user/www/sg-testing.com/public_html/.htaccess: <IfModule> directive requires additional arguments

To inspect the file, open the Site Tools of the website. Then, select the section Site and open File Manager.

Navigate to the website’s root folder, which is the site name/public_html. In our example, the name is sg-testing.com, so the folder path is sg-testing.com/public_html.

In this folder, you can find the .htaccess file. Select the file and then press Edit to open the code editor.

Now, you can inspect its code. As the error log points, the problem is from the <IfModule>. The issue is a syntax error because the module is missing a forward slash in the closing tag </IfModule>.

Add the slash and then save the changes with the Save button. Reload the website and it should now load properly.

Wrong website’s root folder defined in .htaccess

Another common error in .htaccess is incorrectly defined root folder for the website. Usually, this is a result from one of the following cases:

• You transferred the website from another hosting provider where it resided on a subfolder.
• You developed the website on a subfolder and then moved it to the main domain folder in the same hosting.
• For a WordPress website, you installed a plugin that has changed the RewriteBase in .htaccess. The plugin may need extra configuration to work with the modified code but currently, the website is inaccessible due to the “500 Internal Error”.

To illustrate the problem better, we can use the following example.

Notice the /dev path in RewriteBase. This code instructs the server to load the website from a folder named public_html/dev. Since the folder is non-existent, when you load a page from the website, it will produce the “Internal Server Error” screen.

To fix the problem, simply remove the subfolder path from RewriteBase so the code would look like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_URI} !/(wp-content/uploads/.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

This is the default WordPress code defining the root folder for the website. Confirm the change in File Manager with the Save button and reload the website. The error shouldn’t appear anymore.

Regenerate the .htaccess file

Another standard troubleshooting scenario is to replace the .htaccess file with a new copy. To replace the file with a new copy, open File Manager, navigate to public_html, select the file .htaccess and choose Rename.

You can choose any name for the file. For example, you can name it htaccess-old and create a new .htaccess file.

If the website is WordPress, access the WordPress dashboard, navigate to the section Settings, and open Permalinks. Just click on the button Save Changes, and your website will generate a new .htaccess file with the default WordPress code.

If your website is not WordPress, find the default .htaccess code for your specific application. Use the button New File in File manager and name the new file .htaccess. Paste the default code into .htaccess and save the changes.

After the new .htaccess file is set, reload the website again to see if the error is gone.

Repair the database or fix the database credentials

Another common problem that can cause the “500 Internal Server Error” is a corrupted database of your website. You may consider restoring the database from a backup or repairing it.

For WordPress, the error may occur if the website fails to connect to the database. Make sure that the credentials are set correctly in the wp-config.php file.

For detailed steps, read this guide on how to fix the error ‘Establishing a Database Connection’ in WordPress.

Disable plugins for your WordPress website

A misconfigured plugin can also trigger the “HTTP 500 Error” in WordPress. The standard procedure is to disable the plugins one by one until you find the culprit.

If the error is only on the front-end, but you still have access to the WordPress admin dashboard, you can disable the plugins from the section Plugins. Then choose Installed plugins. From the drop-down Bulk actions menu, select Deactivate. Check the box Plugin and press Apply to deactivate all plugins.

In many cases, the error prevents you from logging into the WordPress dashboard so you may need to use an alternative way.

A popular suggestion you’ll find online is to rename the wp-content/plugins folder. We don’t recommend this method as it may fix the “HTTP 500 Error”, but cause other complications.

It is safer and more efficient to disable all plugins from Site Tools (if you are a SiteGround user) or from the database.

Read the following guides for detailed steps:

• How to disable all plugins from Site Tools
• How to disable all plugins from the website’s database

After the plugins are disabled, reload the website. If the website is fixed, it is a strong indication that the error is caused by one of the plugins.

Proceed by activating the plugins one by one. When the faulty plugin is reactivated, the error will return. You can then disable the plugins again to access the dashboard and activate all plugins apart from the problematic one.

You may consider replacing this plugin with another one or contacting its developers to report the problem.

Change the theme for your WordPress website

A badly configured theme can also cause the “500 Internal Server Error” in WordPress. To check if the theme is the problem, you will need to replace it with another one.

Usually, you can change the theme from the website’s WordPress dashboard. However, in many cases, the ongoing “HTTP 500 Error” prevents you from logging in.

Read this guide on how to change the WordPress theme from the database for more information.

Increase the PHP Memory Limit of the Website

The “HTTP 500 Error” may also be caused by PHP scripts that exceeded the memory limit of your website. By default the limit on all SiteGround plans is set to 512M. However, your WordPress website may be set to a lower value. To increase the memory limit, follow the steps from this guide on how to increase WP Memory Limit.

Restore a Backup of the Website

If none of the solutions helped solve the issue or you find them challenging to implement, you may consider restoring the website from a backup. Restoring the website will revert all changes that caused the error in the first place.

SiteGround users can check this detailed tutorial for the Website Backup Tool.

Check if your website contains large files

Another common reason for this error is having a very large file as a part of your website. On SiteGround’s shared hosting servers there is a size limit for files that can be opened through the web. The limit is 8GB, and if your website includes a larger file, this will result in the above error.

Check your website’s files either via SSH, FTP, or File Manager to locate the one causing the problem. Very often, these are logs with PHP errors.

On SiteGround’s servers, a log file is created automatically if your site’s PHP scripts produce any non-critical errors or warnings during their execution. The log file’s name is php_errorlog, and it is located in the same directory as the script that produced the errors. Usually, this would be your website’s root folder.

Contact the web hosting provider

Ultimately, the “500 Internal Server Error” may not be caused by your website configuration. The MySQL server may be down, or the server may be overloaded. Contact your web hosting’s support team so they can check the server’s status and help further with the problem.

Summary

The HTTP “500 Internal Server Error” can be very frustrating to deal with because of its unclear nature. The problem may originate from a local issue or an error on the website or the server.

This guide can help you narrow down the causes to fix the error more efficiently.

The “HTTP 500 Error” is one of the many error codes. Read this guide to find out more about the different error codes.

For more information about fixing other 5.X.X. status codes, read the following articles:

• How to fix the “HTTP 502 Bad Gateway Error”?
• How to fix the “HTTP 503 Service Temporarily Unavailable” error?
• What is “HTTP 504 Error” and how to fix it?