cPanel Error 500: How to Fix Internal Server Errors

Overview

A cPanel error 500 — officially an HTTP 500 Internal Server Error — means the server hit an unexpected condition it couldn’t recover from. The browser gets a generic error page, and you get no useful information about what actually broke. That’s the real frustration here.

You’ll typically see this after editing a .htaccess file, installing a plugin, switching PHP versions, or deploying new code. It affects sites on Shared Hosting, VPS, and dedicated servers equally — the cause just varies by environment.

This article covers the most common causes and how to fix each one. Start with Step 1 (check the error log) before doing anything else — it’ll tell you which section to jump to.

Prerequisites

• cPanel login credentials (your hosting account username and password)
• File Manager access or FTP/SFTP client (FileZilla, WinSCP, Cyberduck)
• SSH access if you’re on a VPS or dedicated server (optional but useful)
• Basic familiarity with navigating cPanel’s interface
• Know your domain’s document root — usually /home/username/public_html/

Step-by-Step Instructions

Step 1: Check the Error Log First

Don’t guess. The error log almost always tells you exactly what failed and on which line. Skip this step and you’re troubleshooting blind.

1. Log into cPanel.
2. Scroll to the Metrics section and click Errors.
3. You’ll see the last 300 lines of your error log. Look for entries timestamped around when the 500 error started.

If you have SSH access, you can pull the log directly:

tail -n 50 /home/username/logs/error_log

The error message will typically point to a specific file, line number, or module. Use that to jump to the relevant section below.

📝 Note: On some shared hosting accounts, the error log path may be /home/username/public_html/error_log depending on your server configuration. If the cPanel Errors viewer shows nothing useful, check both locations.

Step 2: Rename or Reset Your .htaccess File

A corrupted or invalid .htaccess file is the single most common cause of a 500 error on Apache-based hosting. One bad directive — even a trailing space after a backslash — kills the whole site.

1. In cPanel, open File Manager.
2. Navigate to public_html (or your domain’s document root).
3. Make sure hidden files are visible: click Settings in the top-right and check Show Hidden Files (dotfiles).
4. Find .htaccess, right-click it, and select Rename. Rename it to .htaccess_backup.
5. Reload your site in a browser.

If the site loads, the .htaccess was the problem. You can generate a clean one (for WordPress, use Settings → Permalinks → Save Changes to regenerate it), or review your backup copy line by line to find the bad rule.

⚠ Warning: Don’t just delete the original .htaccess — rename it. Deleting it before confirming the fix means you lose your existing rules with no recovery option.

Step 3: Check File and Directory Permissions

Apache needs specific permissions to read and execute your files. If something set your PHP files to 777 or your directories to 600, you’ll get a 500 error — sometimes only on certain pages.

Correct permissions for most cPanel setups:

• Directories: 755
• PHP and HTML files: 644
• Configuration files containing passwords (e.g. wp-config.php): 600 or 640

To fix permissions recursively via SSH:

# Fix directories
find /home/username/public_html -type d -exec chmod 755 {} ;

# Fix files
find /home/username/public_html -type f -exec chmod 644 {} ;

📝 Note: If you’re on shared hosting without SSH, you can set permissions in File Manager by right-clicking a file or folder and selecting Change Permissions.

Step 4: Check Your PHP Version and Configuration

A mismatch between your PHP version and your application’s requirements is a very common 500 trigger — especially after cPanel auto-updates or when migrating between servers.

1. In cPanel, go to Software → MultiPHP Manager.
2. Check which PHP version is assigned to your domain.
3. Compare it against your application’s requirements. WordPress 6.x requires PHP 7.4 minimum; PHP 8.1 or 8.2 is recommended as of 2026.
4. To change it, select your domain in MultiPHP Manager, choose the correct version from the dropdown, and click Apply.

Also check your php.ini or .user.ini for syntax errors. A malformed custom PHP config file will cause a 500 on every page load.

If you have SSH access, test the PHP config directly:

php -l /home/username/public_html/wp-config.php

This checks PHP file syntax without executing it. If the output says No syntax errors detected, the file itself isn’t the problem.

Step 5: Check for Script or Application Errors

If the above steps haven’t resolved it, the error is likely inside your application code itself — a broken plugin, a failed database connection, or a syntax error in a custom script.

Enable PHP error display temporarily to see the actual error on screen. Add these lines to the top of your index.php or main entry file:

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

⚠ Warning: Never leave error display enabled in production. It exposes internal file paths and configuration details to anyone visiting your site. Remove these lines as soon as you’ve identified the problem.

For WordPress specifically, enable debug mode in wp-config.php:

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

This writes errors to /wp-content/debug.log without showing them publicly. Much safer for production environments.

Common Issues & Troubleshooting

Error log shows: “Options not allowed here”

Cause: A directive in your .htaccess is using an option that’s been disabled at the server level by the hosting provider. This is common on shared hosting where AllowOverride is restricted.

Fix: Remove or comment out the offending line in .htaccess. If you need that option enabled, you’ll need a VPS or dedicated server where you control the Apache config, or contact Host & Tech support to check whether it can be enabled for your account.

Error log shows: “Premature end of script headers”

Cause: A CGI or PHP script is outputting something before the HTTP headers are sent — usually caused by a whitespace or BOM character before the opening <?php tag, or a syntax error that triggers output before headers.

Fix: Open the file flagged in the error log in a proper code editor (VS Code, not Notepad). Check for any characters before <?php. Also confirm the file is saved as UTF-8 without BOM.

Site returns 500 only on specific pages, not the whole site

Cause: A per-directory .htaccess file in a subdirectory, a broken plugin affecting specific routes, or a missing file that’s being included conditionally. Whole-site 500s usually mean .htaccess or PHP config; partial 500s usually mean application-level errors.

Fix: Check for .htaccess files in subdirectories, not just public_html. For WordPress, try deactivating plugins by renaming the plugins folder temporarily:

mv /home/username/public_html/wp-content/plugins /home/username/public_html/wp-content/plugins_disabled

If the error clears, rename it back and reactivate plugins one at a time to find the culprit.

500 error appeared immediately after a cPanel PHP upgrade

Cause: Functions deprecated or removed in the new PHP version are being called by your application or a plugin. PHP 8.0 removed several functions that were only deprecated in PHP 7.x, so this is common when jumping major versions.

Fix: Roll back the PHP version in MultiPHP Manager to restore access, then update your application and plugins to versions compatible with the target PHP version before upgrading again. I’d recommend testing PHP version changes on a staging environment first — it’s the kind of thing that’s obvious in hindsight.

Error log shows: “Internal Server Error” with no further detail

Cause: This happens when Apache catches an error but the server’s error logging is too brief. Often a suEXEC or mod_security issue, or a custom error document that itself is triggering a secondary error.

Fix: Check the Apache suEXEC log (VPS/dedicated only) at /usr/local/apache/logs/suexec_log. On shared hosting, contact Host & Tech support and ask them to check the WHM-level error logs for your account — there’s almost always more detail at that level that cPanel’s user-facing logs don’t expose.

FAQ