Check the homepage, one inner page and the administration login in a separate browser session. Note whether every route fails or only a particular page. Record the time, recent changes and any HTTP status or browser error available.

Preserve unsaved editor work and avoid repeated updates or reinstalls. If orders or submissions may still be arriving, account for that live data before planning a restore.

1. Check the administrator mailbox for a legitimate recovery-mode message.
2. Review the relevant hosting PHP error log around the failure time.
3. If necessary, enable a protected temporary WordPress debug log with public display disabled.
4. Identify the component path and error type, then compare them with the last plugin, theme, PHP or custom-code change.
5. Reproduce the issue on staging where practical before applying a wider live change.

If a specific plugin fails, a deliberate deactivation or verified file replacement may restore access. Review the features that depend on it first. If the active theme fails, use an appropriate known-good recovery route and preserve custom files before changing themes.

A memory error needs an investigation of the workload and limits, not an unlimited-memory setting. An incomplete update may need package verification and a coordinated repair rather than another blind update click.

If the response contains page HTML but the browser shows a blank canvas, inspect JavaScript errors, styles and overlays. That differs from a PHP request that never produced the page. Test a private browser session and a known unaffected route to narrow the scope.

Clear caches after the stored application state is corrected. A cached blank response can persist, but clearing caches alone will not fix a reproducible fatal error underneath.

After recovery, test login, the failed page and any affected forms or checkout. Inspect fresh logs and disable temporary debug output. Confirm that the intended plugins and theme remain in a supported, known state.

If the cause is still unclear, send the domain, timing, failure scope, recent changes and sanitised error excerpt. Do not delete all plugin folders or overwrite the live database simply to make the screen return. A safe resolution restores service while preserving current content and identifies the component or condition that caused the failure.

• Reading a WordPress fatal error and identifying the component
• Using WordPress recovery mode after a plugin error
• Investigating WordPress memory exhausted errors
• Checking WordPress core file integrity with WP-CLI

• WordPress: Common Errors
• WordPress documentation
• WordPress: Debug WordPress