There Has Been a Critical Error on This Website: How to Fix It in cPanel

You open your site and instead of your homepage you see one plain line: “There has been a critical error on this website.” Sometimes a second line adds “Please check your site admin email inbox for instructions.” It looks scary, but the message itself is a safety feature. WordPress caught a PHP fatal error and stopped the page from loading half-broken. Your posts, pages and database are almost always still there.

This guide walks you through the common causes in a fixed order, from the most likely to the least likely, with a quick check and a fix for each one in cPanel. You can do all of it without wp-admin. Only if every cause checks out do you turn on debugging and read the logs, in the last section.

Who it’s for: WordPress site owners on cPanel hosting, including beginners. Not for: sites showing a plain HTTP 500 page with no WordPress message (use our 500 Internal Server Error guide) or a completely blank white page (see the white screen of death guide).

WordPress critical error: what the message really means

Since WordPress 5.2, a feature called fatal error protection watches for PHP errors that stop code from running. When one happens, WordPress shows the friendly critical error message to visitors and, where it can, emails the site admin a special recovery mode link. Behind the message there is always one specific PHP fatal error that names the file and line that failed. The checklist below finds that cause without reading the log first.

Before you start (prerequisites)

• cPanel login for the hosting account (File Manager, MultiPHP Manager, MultiPHP INI Editor, MySQL Databases).
• Access to the site admin email inbox (the address under WordPress Settings > General) for the recovery link.
• A fresh backup. In cPanel > Files > Backup, download a home directory and database backup before editing files. If the site is already down, still back up: it protects you if a rename goes wrong. Our cPanel backup guide walks through it.
• Optional: an FTP/SFTP client such as FileZilla, or SSH/Terminal access, for the fallbacks.
• Note these facts: your domain, the site’s document root (usually public_html), the PHP version shown in cPanel > Software > MultiPHP Manager, and what changed just before the error.

Time and difficulty

Time	Difficulty	Risk	Downtime
10–30 min	Beginner	Low (renaming is reversible)	None extra; the site is already down

Quick answer

Work through the common causes checklist in order and stop at the first check that fails. If you received the recovery email, it already names the failing plugin or theme: jump to cause 5 and rename that folder with -disabled on the end (for example plugin-name-disabled). If all eight checks pass, turn on debugging to read the exact error.

Common causes checklist

Check these in this order. The order is fixed: it runs from the most likely cause on shared hosting to the least likely.

1. Database credentials or DB server
2. .htaccess
3. PHP memory and limits
4. PHP version
5. Plugins and theme
6. File permissions
7. Disk and inode quota
8. Recent changes

1. Database credentials or DB server

Quick check: in cPanel > Files > File Manager, right-click public_html/wp-config.php (full path /home/exampleuser/public_html/wp-config.php in the example) and choose View. Under the Database settings comment, compare DB_NAME, DB_USER and DB_HOST with the database and user listed in cPanel > Databases > Manage My Databases. The user must be listed under Privileged Users for that database. DB_HOST is localhost on ShoHost.

// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'example_wpdb' );

/** Database username */
define( 'DB_USER', 'example_user' );

/** Database password */
define( 'DB_PASSWORD', 'example_password' );

/** Database hostname */
define( 'DB_HOST', 'localhost' );

Fix: if a name is wrong, correct it in wp-config.php (right-click > Edit, then Save Changes). If you are not sure of the password, set a new one for the user in Manage My Databases > Current Users > Change Password and paste the same value into DB_PASSWORD. If the database user is missing from the database, add it under Add User To Database with ALL PRIVILEGES.

Expected result: the site loads. If the names all match and the site still fails, the DB server may be briefly down. Wait a few minutes; if it continues, contact support.

2. .htaccess

Quick check: in File Manager, open Settings, tick Show Hidden Files (dotfiles), then look for public_html/.htaccess. A recent edit, a security plugin rule or a stray AddHandler line can break every page.

Warning: rename, do not delete, so you can restore custom rules (redirects, security rules) later.

Fix: select .htaccess, click Rename in the toolbar and change it to .htaccess.old. Reload the site. If it works, create a new .htaccess with the default WordPress rules, then save permalinks once in Settings > Permalinks.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

This is what the default block looks like in the file editor once it is in place:

Expected result: the homepage loads with the default rules. Copy your custom rules back from .htaccess.old one block at a time.

3. PHP memory and limits

Quick check: in cPanel > Software > MultiPHP INI Editor, choose your domain in Basic Mode and read memory_limit. Heavy page builders and WooCommerce usually need at least 256M. Also check cPanel > Metrics > Resource Usage for warnings that the account hit its limits around the time of the error.

Fix: set memory_limit to 256M and click Apply. Then let WordPress use it by adding this line above /* That's all, stop editing! */ in wp-config.php:

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

Expected result: the page loads. See our memory exhausted guide if it fails again with a bigger value.

4. PHP version

Quick check: did the error start after a PHP change, for example from PHP 7.4 to PHP 8.x? In cPanel > Software > MultiPHP Manager, read the PHP version next to your domain.

Fix: tick your domain, choose the previous version in the PHP Version drop-down and click Apply. Treat this as a short-term fix; update or replace the old plugin or theme soon. Our PHP version guide covers the details.

Expected result: a green success message in MultiPHP Manager, and the site loads after a refresh.

5. Plugins and theme

Quick check: did you just install, update or activate a plugin or theme, or add a snippet to functions.php? Then check the admin inbox for the subject “Your Site is Experiencing a Technical Issue” (check spam too). The email names the plugin or theme that failed and contains a link ending in ?action=enter_recovery_mode.

Fix A: deactivate it in recovery mode

Click the recovery link, log in, then go to Plugins > Installed Plugins. The faulty plugin is marked as paused. Click Deactivate next to it, then click Exit Recovery Mode in the top bar.

Fix B: rename the plugin folder in File Manager

Warning: rename, do not delete. A renamed folder keeps the plugin’s files and settings, so you can undo the change in seconds.

In File Manager, open public_html/wp-content/plugins. Select the folder of the plugin named in the email (or the one you changed last) and click Rename in the toolbar (or right-click it and choose Rename). In the Rename dialog that opens, add -disabled to the end (for example demo-broken-plugin-disabled) and click Rename File. WordPress cannot find the plugin any more, so it deactivates it.

If you do not know which plugin it is, rename the whole plugins folder to plugins-disabled, check the site, then rename it back and disable plugins one at a time until the error returns.

Fix C: switch to a default theme

If the email names your theme, open public_html/wp-content/themes and rename your active theme folder the same way, with -disabled on the end. WordPress falls back to an installed default theme such as Twenty Twenty-Five. Make sure one default theme folder exists; if not, upload it from wordpress.org first.

Fallback: rename over FTP/SFTP

Use this when File Manager will not load.

1. Open FileZilla and connect with your FTP host, username, password and port 21 (or SFTP port from your welcome email).
2. In the right pane, open public_html/wp-content/plugins.
3. Right-click the guilty plugin folder, choose Rename, add -disabled (for example demo-broken-plugin-disabled) and press Enter.

Expected result: the homepage loads. In wp-admin, Plugins shows a notice that the plugin was deactivated because its file does not exist. With a default theme, the site loads with the default design and your content is unchanged.

6. File permissions

Quick check: in File Manager, read the Permissions column for public_html, wp-content, wp-config.php and index.php. Wrong values, often after an upload or a migration, stop PHP reading files.

Folders:        755
Files:          644
wp-config.php:  600 or 640

Fix: select the file or folder, click Permissions in the toolbar, set the value above and click Change Permissions. Do not use 777; the server blocks PHP files that anyone can write. SSH alternative: reset all folders and files at once with the find … chmod commands in debugging Step 5.

Expected result: the Permissions column shows 755 for folders and 644 for files, and the site loads.

7. Disk and inode quota

Quick check: on the cPanel home page, read Disk Usage in the Statistics sidebar, and File Usage (inodes) if your cPanel lists it there. At 100%, WordPress cannot write cache, sessions or uploads, and plugins can fail with a fatal error.

SSH alternative: du -sh ~/public_html and find ~/public_html -type f | wc -l show the size and file (inode) count; see debugging Step 5.

Fix: open cPanel > Files > Disk Usage to find the biggest folders. Download and delete old backup archives, clear plugin cache folders in wp-content/cache, delete large old error_log files and empty spam or trash folders in old mailboxes.

Warning: deleting files cannot be undone. Download anything you might need first.

Expected result: usage is clearly below your limit and the site loads.

8. Recent changes

Quick check: list what changed just before the error: a WordPress core update, a code snippet, an edit to functions.php, a new plugin or a migration. Undo that one change first.

Fix: if you cannot undo the change, restore the last working backup. In cPanel > Files > Backup (or your Softaculous or JetBackup backups, if your plan has them), restore the home directory and database from before the error.

Warning: restoring overwrites newer changes, so download a copy of the current files and database first.

Expected result: the site is back to the state it was in before the change.

If all the above are fine: turn on debugging

Use this only when all eight checks pass. The logs name the exact file and line that failed.

Step 1: Check cPanel Errors

In cPanel > Metrics > Errors, read the newest entries at the top. Look for the words PHP Fatal error and note the file path after in.

Step 2: Open the error_log file in public_html

In File Manager, with hidden files shown, open public_html and look for a file named error_log. Right-click it and choose View. Scroll to the bottom for the newest lines.

A typical fatal error line looks like this:

[14-Oct-2026 05:59:07 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function demo_broken_plugin_get_settings() in /home/USERNAME/public_html/wp-content/plugins/demo-broken-plugin/demo-broken-plugin.php:10

Expected result: you can read the folder name after wp-content/plugins/ or wp-content/themes/. In the example, the culprit is demo-broken-plugin: rename it to demo-broken-plugin-disabled as in cause 5. If there is no error_log or it is empty, do Step 3.

Step 3: Turn on WP_DEBUG_LOG in wp-config.php

In File Manager, right-click public_html/wp-config.php and choose Edit. Find the line /* That's all, stop editing! */. Directly above it, replace any existing WP_DEBUG line with these three lines, then click Save Changes.

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

Reload the broken page once, then open public_html/wp-content/debug.log in File Manager.

Expected result: a new debug.log file with at least one PHP Fatal error line. Our full WordPress error logs guide explains how to read every part of the line.

Step 4: Read the log and fix it with WP-CLI over SSH

Use this when you have SSH or cPanel > Advanced > Terminal. Go to the site folder, list plugins while skipping all plugin and theme code, and read the log:

cd ~/public_html
wp plugin list --skip-plugins --skip-themes
tail -n 20 error_log
tail -n 20 wp-content/debug.log

Deactivate the plugin named in the log (replace PLUGIN-SLUG, for example demo-broken-plugin). If the log names no plugin, deactivate all of them, then reactivate one at a time. You can also switch the theme:

wp plugin deactivate PLUGIN-SLUG --skip-plugins --skip-themes
wp plugin deactivate --all --skip-plugins --skip-themes
wp plugin activate PLUGIN-SLUG --skip-themes   # repeat one by one
wp theme activate twentytwentyfive --skip-plugins --skip-themes

Expected result: WP-CLI prints a success line, for example:

Plugin 'demo-broken-plugin' deactivated.
Success: Deactivated 1 of 1 plugins.

wp plugin list shows demo-broken-plugin as the active plugin to switch off.

$ wp plugin deactivate demo-broken-plugin --skip-plugins --skip-themes
Plugin 'demo-broken-plugin' deactivated.
Success: Deactivated 1 of 1 plugins.
$ wp plugin list
+-----------------------------+----------+--------+---------+----------------+-------------+
| name                        | status   | update | version | update_version | auto_update |
+-----------------------------+----------+--------+---------+----------------+-------------+
| akismet                     | inactive | none   | 5.7.2   |                | off         |
| demo-broken-plugin          | inactive | none   | 1.0     |                | off         |
| hello                       | inactive | none   | 1.7.2   |                | off         |
| sqlite-database-integration | inactive | none   | 3.1.0   |                | off         |
| db.php                      | dropin   |        |         |                | off         |
+-----------------------------+----------+--------+---------+----------------+-------------+

When the site works, turn debugging off again: set WP_DEBUG to false and delete wp-content/debug.log, because it can expose file paths.

Step 5: Fix permissions and check disk use over SSH

Use this as the SSH alternative to causes 6 and 7. The two find commands reset every folder to 755 and every file to 644, and chmod 600 locks down wp-config.php again. du -sh prints the total size of the site folder. The last command counts files; each file uses one inode, so compare the number with your plan’s inode limit.

cd ~/public_html
# set every folder to 755 and every file to 644
find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
# total size of the site folder
du -sh ~/public_html
# number of files (each file uses one inode)
find ~/public_html -type f | wc -l

Two find commands reset permissions; du and wc -l report 62M and 3437 files.

$ find ~/public_html -type d -exec chmod 755 {} \;
$ find ~/public_html -type f -exec chmod 644 {} \;
$ du -sh ~/public_html
62M     /home/exampleuser/public_html
$ find ~/public_html -type f | wc -l
3437

Expected result: the chmod commands print nothing. du prints one line such as 1.2G /home/exampleuser/public_html, and wc -l prints a single number such as 48211.

Verify your WordPress site is fixed

Check the homepage status code from any terminal (replace the domain):

curl -sI https://example.com | head -n 1

Expected result: a 200 status line:

HTTP/2 200

• Open the homepage and wp-admin in a private window.
• Reload once and confirm no new PHP Fatal error line appears at the bottom of error_log or debug.log.
• If you turned debugging on, confirm WP_DEBUG is back to false.

Troubleshooting the WordPress critical error

Symptom / message	Likely cause	Fix
No recovery email arrived	Site mail goes to spam or PHP mail is blocked	Use cause 5, Fix B; then fix mail with our SPF/DKIM guide
No error_log file anywhere	Logging off or hidden files not shown	Tick Show Hidden Files; turn on WP_DEBUG_LOG (debugging, Step 3)
Allowed memory size ... exhausted	PHP memory limit too low	Raise memory_limit in MultiPHP INI Editor (cause 3)
Error returns after renaming one plugin	A second plugin also fails	Rename the whole plugins folder to plugins-disabled, then test one by one
Error mentions wp-includes or wp-admin	Corrupt core files after a failed update	Re-upload fresh core files except wp-content and wp-config.php (cause 8)
Site loads but looks broken	Default theme active	Fix or update your theme, then rename the folder back
Still stuck?	—	WhatsApp support on +91 94880 91432. Send the last 20 lines of error_log and your domain.

Prevent the critical error next time

• Update plugins one at a time and check the site after each one.
• Test big updates on a staging copy first (Softaculous can create one in a few clicks).
• Before upgrading PHP, check each plugin’s “Requires PHP” and “Tested up to” details.
• Keep at least one recent off-site backup.

Get WordPress hosting with real help when errors hit

Critical errors are much less stressful when someone can read the log with you. ShoHost WordPress hosting gives you cPanel with File Manager, MultiPHP Manager and error logs, plus WhatsApp support on +91 94880 91432. Plans include 98.5% uptime and a 7-day refund, and moving is easy: Unlimited free website migration, within your plan’s limits.

WordPress critical error FAQ

Why did activating a plugin crash my site?

The plugin’s code hit a PHP fatal error. The usual reasons are a PHP version it does not support, a conflict with another plugin or theme, or a missing PHP extension. The error log line names the exact file.

I can’t log in to wp-admin. What now?

Rename the plugin folder in cPanel > File Manager > public_html/wp-content/plugins. WordPress deactivates it and you can log in again.

Where is the WordPress error log in cPanel?

Look for error_log files in public_html (and wp-admin), the Metrics > Errors page, and wp-content/debug.log once WP_DEBUG_LOG is on.

Is my content lost after a critical error?

Almost never. Posts and pages live in the database, which the error does not touch.

Can ShoHost help me fix it?

Yes. WhatsApp support on +91 94880 91432.

Can you move my site to ShoHost?

Yes. Unlimited free website migration, within your plan’s limits. Our team copies your files and database for you.

Related guides

• Fix 500 Internal Server Error in cPanel
• Fix the WordPress white screen of death
• Fix a WordPress plugin conflict after an update
• Change the PHP version in cPanel
• WordPress 500 vs 503 errors on shared hosting