An ExpressionEngine site that suddenly returns a blank page or a generic HTTP ERROR 500 is rarely broken at random. The response you see in the browser is the symptom; the actual fault lives in a PHP log line, a template tag that references a missing add-on, or a configuration constant that was changed during a migration or PHP upgrade. On a managed shared platform running LiteSpeed on CloudLinux, you cannot read the server-wide error stream, so the entire diagnostic process depends on the logs and debug facilities that belong to your own account. The good news is that ExpressionEngine exposes enough of these facilities that nearly every 500 can be identified from the hosting dashboard alone.

Before changing anything, understand what each error type signals. A true white screen (no text, HTTP 200) almost always means PHP hit a fatal error with display disabled. A 500 status usually points at either a PHP fatal error with LiteSpeed intercepting the output, or a malformed .htaccess rule. A styled ExpressionEngine error page that mentions a database or template problem is the application itself reporting, which is the easiest case because EE has already caught the exception for you.

Locate the error log before touching configuration

The single most valuable artifact is the PHP error_log. On this platform PHP runs per-account, so errors are written into a file inside your own directory tree rather than a system path you cannot reach. Open cPanel > File Manager (or DirectAdmin > File Manager), enable Show Hidden Files from the settings, and look for a file named error_log in your document root (/home/USER/public_html/) and inside the ExpressionEngine system directory. LiteSpeed and CloudLinux also surface recent fatal errors in cPanel > Metrics > Errors, which captures the last several hundred entries without you opening a file at all.

Read the log from the bottom up, because the newest entries are appended last. A genuine ExpressionEngine fatal error looks like a stack reference into the system path, for example:

PHP Fatal error:  Uncaught Error: Class "EllisLab\ExpressionEngine\Core" not found in /home/USER/public_html/system/ee/legacy/libraries/Core.php:142

That line tells you the failing file, the class, and the line number, which is enough to separate a corrupt core upload from a missing add-on. If the log shows Allowed memory size of X bytes exhausted, you have a resource limit rather than a code fault, which is handled differently and covered below. If no error_log exists anywhere, PHP logging is simply not writing yet, so the next step forces it on.

Create or edit a .user.ini file in your document root to guarantee logging and to temporarily surface errors while you investigate. On LiteSpeed the .user.ini file is honored per-directory and takes effect within a few minutes:

; /home/USER/public_html/.user.ini
display_errors = Off
log_errors = On
error_log = /home/USER/public_html/ee_php_errors.log
error_reporting = E_ALL
memory_limit = 256M
max_execution_time = 120

Keep display_errors set to Off on a live site so visitors never see raw paths, and rely on the dedicated log file instead. Reload the failing page once, then open ee_php_errors.log in File Manager to capture the fresh trace.

Turn on ExpressionEngine debug output and template errors

When the PHP log is silent but the page is still blank, the fault is often inside the application layer, where ExpressionEngine has caught the problem and suppressed it. EE controls this through config.php and database settings you can reach safely. Open File Manager and edit /home/USER/public_html/system/user/config/config.php, adding these overrides inside the $config array so they win over the database values:

$config['debug'] = 2;
$config['show_profiler'] = 'n';
$config['template_debugging'] = 'y';
$config['is_system_on'] = 'y';

A debug value of 2 shows PHP and database errors to everyone, which is acceptable for a short diagnostic window but must be returned to 0 or 1 afterward. The template_debugging flag makes EE print the exact tag or embed that failed to parse, which is the fastest way to catch a 500 caused by a missing fieldtype or a channel entries tag referencing a deleted channel.

If the control panel itself loads but a front-end page throws the error, check CP > Developer > Add-On Manager. A 500 that appeared right after an EE or PHP version change is frequently a third-party add-on calling a function that no longer exists. Disable suspect extensions one at a time from that screen; if the panel is also down, you can neutralize an add-on by renaming its folder under /home/USER/public_html/system/user/addons/ through File Manager, which prevents EE from loading it on the next request.

Resolve PHP version mismatches and broken rewrite rules

A large share of ExpressionEngine 500s trace back to the PHP runtime. EE 6 and 7 require PHP 7.4 through 8.2 depending on the point release, and a shared host will occasionally shift the default handler during maintenance. Open cPanel > MultiPHP Manager (or DirectAdmin > Select PHP Version) and confirm the domain is pinned to a version your EE build supports. If you switched recently and the site died, a missing PHP extension is the usual culprit. Use cPanel > Select PHP Version > Extensions (the CloudLinux PHP Selector) to verify that gd, mbstring, curl, intl, pdo_mysql, and zip are enabled, since EE throws a fatal error during bootstrap when one of these is absent.

The other common 500 source is .htaccess. ExpressionEngine installs ship with rewrite rules to remove index.php from URLs, and an invalid directive produces an immediate 500 before PHP even runs. Test this by temporarily renaming .htaccess to .htaccess.bak in File Manager and reloading. If the site returns, the fault is in your rules. A clean, LiteSpeed-compatible ruleset for removing index.php looks like this:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /index.php/$1 [L]
</IfModule>

Avoid pasting rules that reference Apache modules your account does not load, and never add php_value lines to .htaccess on LiteSpeed, because PHP settings belong in .user.ini instead. For memory exhaustion errors, raise memory_limit in .user.ini as shown earlier rather than editing any global file.

When the log points at a database exception such as Unable to connect to your database server, the fault is in credentials rather than code. Verify the host, user, and database name in config.php against cPanel > MySQL Databases, and confirm the account is still assigned to the database with full privileges. If the connection works but EE reports a missing or corrupt table, open phpMyAdmin, select the EE database, choose the affected tables, and run Repair table from the With selected dropdown. The approach to tracing exceptions through account logs is similar across PHP applications, so the same workflow applies if you also run a billing panel like FOSSBilling on the same account.

Once the page renders again, reverse every diagnostic change: set $config['debug'] back to 1, confirm display_errors is Off, and delete the temporary log file so it does not grow unbounded. Keeping these facilities tight protects both your path structure and your disk quota.