WordPress shows a critical error or a white page

What you see

Visitors see WordPress’s “critical error” page, or a white page.
The Site health row on the site’s WordPress tab reads HTTP <code> — visitors see WordPress's "critical error" page.
A scan or check reports Couldn't read plugins and themes — not a clean result, or a sentence such as “the plugin <slug> stops WordPress loading: Parse error: …”.
A WordPress update fails and the site is left in a broken state.

Cause

1. One plugin or theme cannot run

A plugin written for another PHP version, a broken update, or a file that no longer parses stops WordPress at start. When the cause is a plugin or theme, Hyperion names it, as in “the plugin <slug> stops WordPress loading: …”. Because WordPress cannot start, wp-cli based fixes fail too, and the Site health row offers a fix that renames the folder instead.

Check: on the WordPress tab, read Site health, see Repair a broken WordPress site.

2. The PHP version no longer fits the site

A site switched to a newer PHP version can break plugins that are not ready for it. Check the version on Settings & limits, see PHP versions and limits, and switch back to confirm.

3. A Redis object-cache drop-in is in the way

When wp-content/object-cache.php exists and Redis is not working, WordPress cannot start. The Site health row shows Redis object-cache drop-in is active with a Park object-cache.php button.

4. A core update did not finish

A core update takes a full backup first. If the update failed, the job page shows “WordPress <version> did not install” and says the backup is kept. See Update WordPress, plugins and themes.

5. Core files were changed

If the site misbehaves without an error naming a plugin, check the files against wordpress.org, see Check WordPress files for tampering and malware.

Fix

For a named plugin or theme: click Disable <slug> (rename folder) and confirm. From a shell:
Terminal window
```
hctl wp disable-plugin example.com <slug>
```
For the drop-in: click Park object-cache.php and confirm.
For a broken update: restore the backup taken before it from the site’s Backups tab, labelled before update. A restore overwrites the live files and database, so use the newest ok entry.
With no culprit named: enable WordPress debug mode and read wp-content/debug.log, or follow Repair or reinstall WordPress.

Check that it is fixed

Click Check again on Site health. It reads Front page answers HTTP 200, no fatal error, and the page loads in a browser.