The website threw a 500 error after an update. Now what?

What a 500 error actually means

“Internal Server Error” is a generic HTTP response. WordPress, PHP, the web server or a hosting rule encountered a fatal problem before it could return a normal page.

After an update, the common causes are a plugin or theme conflict, incompatible PHP code, exhausted memory, corrupted update files or a server configuration problem. The error page alone cannot tell you which one.

The first five minutes

1. Stop changing things. Write down exactly what was updated and when.
2. Check the scope. Is the frontend broken, the admin broken, or both?
3. Check your backup. Confirm that you have a restorable copy of both files and database.
4. Look for the WordPress recovery email. Recovery Mode may identify the plugin or theme that caused a fatal error.
5. Open the hosting error log. It often contains the fatal PHP message even when WordPress cannot display it.

Do not repeatedly run the same update, delete random folders or copy a stranger's .htaccess file from a forum. Those actions destroy evidence and can create a second problem.

Log the error without showing it to visitors

On a controlled troubleshooting session, add these constants to wp-config.php before the line that says WordPress editing should stop:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reproduce the error once, then inspect wp-content/debug.log. Search for the first fatal error and note its file path and line number. A warning printed later may be noise; the first fatal message is usually more valuable.

Isolate the failing layer

1. Plugins

If the log points to a plugin, deactivate it. When the admin is inaccessible, rename only that plugin's folder through FTP. If you have no clue which plugin failed, temporarily rename the entire plugins folder, confirm whether the site returns, then restore the folder name and reactivate plugins one by one.

2. Theme

If the fatal error points to the active theme, switch to a current default WordPress theme. Do this only when you know a default theme is installed and you have a backup.

3. PHP and resource limits

Confirm that the updated plugin or theme supports the PHP version used by the hosting account. Check the fatal message for memory exhaustion, missing PHP extensions or removed PHP functions. Increasing memory may reveal the site, but it does not fix inefficient or incompatible code.

4. WordPress core and server rules

If a core update was interrupted, replace the core files with a clean copy of the same WordPress version while preserving wp-content and wp-config.php. Regenerate rewrite rules only when the evidence points to .htaccess; do not treat it as the universal fix.

Restore service, then investigate properly

For a business website, uptime comes first. If the cause cannot be corrected quickly and a known-good backup exists, roll back the affected plugin, theme or entire site. Record what you restored.

A rollback is not the end of the job. Reproduce the update on staging, check the changelog and compatibility requirements, then decide whether to update the surrounding code, replace the extension or wait for a corrected release.

How to avoid the same mess next time

• Keep automatic, tested backups of files and database.
• Use staging for major WordPress, WooCommerce, theme and PHP updates.
• Update logical groups separately instead of pressing “update all” on a critical site.
• Read changelogs and minimum PHP or WordPress requirements.
• Check forms, checkout, scheduled tasks, login and error logs after deployment.
• Keep a record of what changed so a failure has a clear starting point.