PHP fatal error stops the site

Symptoms

A page that worked yesterday shows a blank white screen, returns HTTP 500, or errors on certain routes while the homepage loads. In WordPress, a fatal plugin error can blank the whole site including the admin. The common thread: PHP reached a condition it cannot recover from and the request died before the browser got a response body.

How a fatal differs from other errors

• Fatal error: the request stops. An uncaught exception, calling an undefined function (often after a plugin or library removed it), or parsing a file with a syntax error.
• Memory exhaustion: Allowed memory size of N bytes exhausted. The script asked PHP for more memory than the limit allows; PHP aborts. Particularly common on large imports, media processing, and builders with long loops.
• A warning or notice: printed but execution continues. It usually does not take the site down.

The blank screen and the 500 often share the same cause: the handler that would have rendered the error page cannot run because PHP died first.

Find the error

1. Read the PHP error log first. Your host keeps one at a known path, or in cPanel at logs/. With WP_DEBUG_LOG on, WordPress writes a debug.log in wp-content/; without it, PHP writes to the server's error log. The line you want names the file and the line, and often the function.
2. Trigger it once in a controlled way. View the failing URL from a private window after enabling WP_DEBUG_LOG (WordPress), or display_errors = On on a staging copy so the fatal prints to the screen in development only. Do not run display_errors = On on the live site.
3. Isolate by exclusion. Deactivate plugins one at a time (or via WP-CLI wp plugin deactivate --all) and re-test; if the site returns, the fatality is in the last deactivated plugin. Then re-add until it breaks. PHP memory and fatal errors almost always trace to an add-on, a theme function, or a recent deploy.

The fix order

1. Restore the previous code state. If the fatal appeared right after a plugin update or a deploy, roll the file or plugin back and the site works again. A copy of the previous version from a backup or from a staging copy resolves most of them. WordPress rollback is covered by the plugin rollback and restore articles.
2. If memory is the cause, raise the PHP memory limit in the right file (php.ini, .htaccess, or the WordPress WP_MEMORY_LIMIT constant). A limit of 256M is typical for a normal WordPress site. But a memory ceiling is a symptom, not the disease: a runaway loop or an array that never stops growing is the real work. Find what ate the memory and cap the data size before raising the limit.
3. Add a safe handler. register_shutdown_function to log fatal errors, or the site's error handler, catches them and writes the fatal without a blank screen. You then see the actual exception text.
4. Hold the change in staging. A fatal is a great index of the blast radius: the same function that died on the front page dies on the sitemap, the feed, and the admin. Fix and verify on staging, then release.

Prevention

• Commit a minimal error-log procedure: WP_DEBUG_LOG on dev, display_errors off on live.
• Update one add-on at a time and keep the previous version in a versioned folder.
• Monitor the error log after each deploy, not only when something visibly broke.

The blank page article covers the adjacent dead-screen cause, and the error-log-reading guide maps the log lines this article assumes.