A 500 Internal Server error can be caused by many things, including but not limited to invalid permissions, invalid ownership, bad lines in your php.ini or .htaccess file, invalid requests in the script, and others not mentioned here.

Example of Server 500 Error

A Server 500 error will generally look something like this:

Internal Server Error

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.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

Bad permissions, Writable by group

A bad permissions error may look something like this:

[Sun Jun 05 12:03:22 2012] [error] [client 66.249.72.82]

SoftException in Application.cpp:601: Directory "/home/exampleuser/public_html" is writeable by group

In this instance, the folder had permissions for a folder set too high. To correct this, the permissions need to be changed from "777" to "755".

Once inside File Manager, click on Permissions from the upper right side of your screen.

And you will be prompted to edit it in a window that will look like these:

Directories and folders should be 755. For example, executable scripts within the cgi-bin folder must be 755. Images, media, and text files like HTML should be 644.

• Files - 644
• CGI Scripts - 755
• Directories - 755

To know more about these, please see Setting File and User Permissions and Changing File Permissions.

Accessing File Manager

Bluerock

1. Log in to your Bluehost control panel.
2. Click the Advanced tab from the side navigation menu to the left.
   
3. Under the Files section, click File Manager. 
   

Legacy

1. Log in to your Bluehost control panel.
2. Under the files category, locate the File Manager icon.
   
3. A dialogue box will appear. In the pop-up, select Web Root (public_html/www) and check the box next to Show Hidden Files (dotfiles). (this will place you in the folder for your web content and show you all the files and folders present).
   
4. The File Manager will now load in a new window and show your files. Double click on a folder to open it, and click Up One Level to go back to a folder. 

Other options are using an FTP client or using the chmod command in SSH/Bash.

Bad .htaccess, Invalid code, command, or syntax

In the .htaccess file ("dot htaccess"), you may have added lines that are either worded badly or conflicting. The best way to troubleshoot this is to comment out the lines in the .htaccess.

You can comment out a line in the .htaccess by adding # to the beginning. You are wise to save an original copy of any file before you make changes.

For example, if the .htaccess looks like this:

DirectoryIndex default.html

AddType application/x-httpd-php5 php

Then try something like this:

DirectoryIndex default.html

#AddType application/x-httpd-php5 php

Broken lines and lines that start with php_flag are the most common mistakes. If you cannot determine which line is the problem, then comment out every line.

Other common .htaccess errors

FollowSymlinks:

An error may look like the following:

[Sun Jun 05 12:07:10 2011] [alert] [client 66.249.72.82]

/home1/examplec/public_html/.htaccess: Option FollowSymlinks not allowed here

In this example, the error is simple to fix; in the file specified, use a permitted directive--in this case, use "SymlinksIfOwnerMatches" instead of "FollowSymlinks," or remove the line entirely.

Syntax Not Closed:

An error may look like the following:

[Sun Jun 05 12:11:38 2011] [alert] [client 66.249.72.82]

/home1/examplec/public_html/.htaccess: /home1/examplec/public_html/.htaccess:3: <IfModule>ExampleRule/Module> was not closed.

Again, the solution is to fix the syntax or remove it simply. In this case, close the ending "</IfModule>"; directive properly and put the rules on their own line to resolve the problem.

These are just a few common examples that bad .htaccess parameters can cause. What you encounter will likely vary. However, generally, the error message is descriptive enough to determine an error from it without further investigation.

Improperly configured php.ini

ForceType

When you are using files with (or without) an extension different than the normal extension for that filetype you can use ForceType in your .htaccess file to make it clear to the server how to handle that file (or all the files in the folder) (this works on servers without phpsuexec).

An example: When you have a file called "item" (like Nucleus uses for FancyURL's) and want it to be parsed by the server as PHP, you use the following code in your .htaccess file:

ForceType application/x-httpd-php

However, because our servers use phpsuexec, this will result in an internal server error. To solve this, you can simply use SetHandler instead of ForceTypeSo your .htaccess-file becomes:

SetHandler application/x-httpd-php

php_value

On a server without phpsuexec, it is possible to use the php_value statement in a .htaccess file to change the settings of php (actually overwrite the settings from php.ini). On a server with phpsuexec, this will also result in a server error. To solve this, you can use a php.ini file which you put in the same folder as where you would have put your .htaccess file. In that php.ini file, you can change all the php values. You only have to put the values you want to modify in that file. For example, if you want to set them short_open_tag to Off, you would have used short_open_tag? = off in your .htaccess file. Using a php.ini file results in the following:

[PHP]

short_open_tag = Off

Troubleshooting

Please see all possible troubleshooting below for fixing the 500 Internal Server Error.

Check Error Logs

1. Open the File Manager.
2. Locate the error logs within the problem website's assigned folder.
   /home/cpanel_user/public_html/error_log for the Primary Domain.
   • If you are unfamiliar with reading error logs, please see Error Logs.
   • If there are no errors to troubleshoot, see this WordPress Codex article on how to enable debugging in WordPress.

Troubleshooting Index Files

If there are no error messages in the error_logs, there may be multiple index files in the domain's root folder.

1. To check, open the file manager.
2. Choose the folder the domain you are working on is pointed to.
3. Locate any additional index files besides index.php.
4. If other index files are present, temporarily rename them (so they are not recognized as index files).

Troubleshooting the .htaccess

If you have ruled out both the Theme and Plugins, you can move on to the .htaccess.

1. To access this, open the file manager and add &showhidden=all to the end of the URL.
2. Choose the folder the domain you are working on is pointed to.
3. Rename the current .htaccess to .htaccess(currentdate). This disables the current .htaccess.
4. Next, you will need to create a new default .htaccess file.
5. Click New File from the main File Manager toolbar (far left-hand side).
6. Name the new file .htaccess.
7. Open the code editor and add the following code below:

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

8. Click the Save changes button once done.
   • If the .htaccess is responsible for the error, replacing it with a generic .htaccess (code from step number 6) should bring the site back.
   • If the site is still down after replacing the .htaccess, delete the file you created, and rename the original file back to .htaccess.