HTTP 500 means the server could not complete the request but chose not to expose the underlying error. After an update, common causes are a PHP fatal, incomplete package extraction, wrong permissions, a broken rewrite directive or incompatible code.
The update timing is useful evidence, not proof that the newest package itself is defective. Preserve logs before undoing several components at once.
Identify which requests return 500
Test the homepage, a static asset, wp-login.php, administrator and the original failing page. Record time, host, status and whether the response came from a proxy or origin.
Compare:
HTML/PHP request status
CSS/image status
admin versus public
logged-in versus anonymous
origin versus CDN responseDo not run repeated update or database actions during diagnosis.
Check web server and PHP logs
Match the request timestamp with Apache/Nginx, PHP-FPM and WordPress logs. A proxy-generated 500 may have different evidence from a PHP application failure.
Capture the first fatal and call path. Later warnings can be consequences.
Protect logs because they may reveal filesystem paths, query data and credentials accidentally printed by extensions.
Look for incomplete updates
Check whether WordPress left .maintenance, whether the plugin/theme directory contains partial files and whether disk/inode limits were reached during extraction.
Compare the installed version with the update package and official checksums where available. Reinstall the exact trusted version rather than copying individual files from another site.
Preserve wp-content, configuration and uploads when reinstalling WordPress core.
Inspect permissions and ownership
An update executed under a different user can leave PHP unable to read files or write expected directories. Compare ownership with neighbouring known-good files.
Typical permission numbers vary by hosting and handler, so use cPanel/Plesk or host documentation. Do not solve an access error with recursive 777; it creates a security problem.
Review the specific “permission denied” log line before changing anything broadly.
Test rewrite configuration
An update or security plugin may modify .htaccess or server directives. Rename only the suspect file after backing it up, then test a direct PHP entry point.
For Apache, regenerate standard WordPress permalink rules through Settings > Permalinks after access returns. On Nginx, configuration is outside WordPress and requires the host/server configuration.
Do not paste Apache directives into Nginx or vice versa.
Isolate the updated component
If logs point to one plugin, rename its directory. For a theme fatal, switch only after confirming a default theme is installed.
Reproduce on staging with the previous and new versions. Read changelogs and PHP/WordPress requirements.
Avoid disabling all plugins on a live business site unless the 500 provides no usable evidence and a documented reactivation sequence exists.
Roll back without losing data
Roll back files for the implicated component from a trusted package or backup. Do not restore the whole database simply to reverse code; new posts, settings or orders may be lost.
If the update included a database migration, check vendor guidance before downgrading. Some schemas are not backward-compatible.
Keep the security implications of an older version documented and prepare a tested forward fix.
Verify and monitor
Test public and administrator routes, editor/save operations, cron and the original feature. Clear OPcache and page cache only where needed, then recheck after cache warm-up.
Inspect CDN and browser cache headers to ensure a stored 500 response is not being replayed after the origin has recovered.
Test both cache states.
Monitor 500 rate and PHP fatals after reopening. Recurring maintenance should stage high-risk updates, verify free disk/inodes and retain rollback packages so the next update does not become an emergency.