If your WordPress site shows a white screen, a 500 error or a broken layout after a PHP version change, start by capturing the exact error. A PHP upgrade can expose code that is incompatible with the new runtime, but the timing alone does not prove PHP is the root cause. A plugin, theme, custom snippet, extension, permissions change or unrelated update may be involved.
The PHP project advises testing compatibility changes before moving a production site to a new minor version. Its PHP 8.4-to-8.5 migration guide links to specific backward-incompatible changes. That guidance is a reason to test—not evidence that WordPress or every plugin is incompatible with PHP 8.5.
First, record what changed
Write down the previous and current PHP versions, the time the change was made, the WordPress version and any plugin or theme updates made around the same time. Note whether only the public site fails, whether the admin dashboard also fails, and whether the error appears on every page or only one feature.
Check the hosting PHP and web-server logs for the fatal error and file path. If the dashboard is available, WordPress Recovery Mode may pause a plugin or theme that triggers a fatal error and let an administrator deactivate it. See the official Recovery Mode guide.
For deeper diagnosis, use a staging copy. WordPress's debugging guide explains how to log errors without showing them to visitors. Do not leave debug output enabled on a public production site; logs may contain file paths or sensitive details, so restrict access and remove or secure them after troubleshooting.
Isolate the cause methodically
On staging, test the site with the new PHP version and the same extensions as production. If the problem continues, temporarily disable non-bundled plugins and use a standard theme, then reactivate components one at a time while checking the error log. Include custom snippets, must-use plugins, drop-ins and PHP extensions in the investigation; ordinary plugin switches may not isolate those components.
Compare the same code and database snapshot under the previous and new PHP runtimes. If the error appears only under the new runtime and the trace points to a removed or changed PHP behavior, that is useful evidence of a compatibility issue. If it also fails under the old runtime, investigate other changes instead of blaming PHP.
Check the affected component's current version, PHP requirements and changelog. Update the component in staging if a compatible release exists, then retest important journeys: login, forms, checkout, uploads, cron jobs and integrations. A PHP compatibility checker can help screen for potential problems, but it cannot guarantee that every path works.
Should I roll back PHP?
If the production site is down, ask your host whether it can temporarily switch back to the previous working runtime. Treat that as a recovery step while you fix the incompatibility—not as a permanent reason to run an unsupported PHP branch. Before manual changes, make and verify a full file-and-database backup. A WordPress database or plugin may have changed during the same maintenance window, so switching PHP back alone may not undo every change.
After applying the fix, retest the site, clear relevant caches and monitor the logs. Keep the PHP runtime on a supported branch with enough support runway, and test future upgrades on staging when possible.
If this incident is also affecting staff email, PCs or Macs, Engage24's IT Support service describes the current workplace IT assistance available. For ongoing WordPress security monitoring and hardening, the site's Website Security service is the more direct fit.
Did a PHP update break your WordPress site?
If a PHP version change has left your site down or a key feature broken, book time with Engage24 to discuss the error and safe next steps.