Facing 500s? Start with logs and service health before touching WordPress code. This sequence helps you confirm Apache and PHP-FPM, then narrow down to the app layer.
Sequence (fast)
- Confirm Apache is healthy
- Confirm PHP-FPM is healthy
- Check whether WordPress, a plugin, or the theme triggered a fatal
Commands
- Apache errors:
sudo tail -n 200 /var/log/apache2/error.log - Apache unit logs:
sudo journalctl -u apache2 -n 200 --no-pager - PHP-FPM status:
sudo systemctl status php*-fpm --no-pager
Common culprits
- Bad
.htaccessrewrite rules - Plugin or theme fatal after an update
- PHP memory or time limits too tight
- PHP-FPM socket mismatch (Apache points to the wrong socket)
FAQ
How do I know if the 500 is Apache, PHP, or WordPress?
Check the Apache error log first. Proxy/FastCGI errors usually point to PHP-FPM (or wrong socket). PHP fatals and plugin names point to WordPress. See Apache log analysis for WordPress for a tighter workflow.
The site was fine until we upgraded PHP.
Plugins and themes often break on new PHP versions. Follow debugging WordPress after a PHP upgrade to isolate the offender.
Related
- Fixing Apache restart failures — when Apache won’t reload
- Debugging WordPress after a PHP upgrade — after PHP version change
- Apache log analysis for WordPress — reading the logs
- Fixing Apache ↔ PHP-FPM socket mismatches — 503/500 from wrong socket