This guide is for owners of self-hosted WordPress websites. Changes require appropriate access and a safe rollback path. If files, databases and hosting are unfamiliar, coordinate the investigation with your host or maintenance provider.
Record the evidence
Record the affected URL, exact message, first observed time with timezone and latest change. Compare home page, another page and login. Keep a record of previous tests; one failed request does not prove the entire website is down.
Backup and rollback
Before making changes, preserve the current files and database where possible, and retain older backups. Check dates and restoration options. A broken or infected snapshot can matter for investigation; protect it separately and never treat it as a verified clean backup.
Change one thing at a time and repeat the same request. Prefer staging for extensive plugin, theme and configuration tests. Deactivation is not deletion: shop, form and security functions may be affected. Document the starting state, change and rollback.
Focused diagnosis
01
Identify the affected area
Is the whole site blank, only one page or just the editor? Test login, a private window and another device. Record recent changes and check whether an HTTP 500 response also occurs.
02
Understand Recovery Mode
For certain fatal PHP errors, WordPress may send a link to the administrator address. Check spam too. It pauses components for your session and is not an automatic repair for all visitors. Treat the link as confidential.
03
Test plugins and themes carefully
If the dashboard works, test the recently changed suspected extension. Deactivation may affect critical functions. Prefer staging for a compatible theme switch or extensive conflict tests; do not delete the original theme.
04
Use PHP logs before blind debugging
The host can check the relevant PHP log. File, line and message provide clues. Use WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY with expertise, temporarily and preferably on staging. Hide public error output and protect logs.
05
Check memory and custom code against evidence
Memory errors require examining consumption and allowed limits. PHP changes must suit plugins and theme. Compare recently edited code with a known working version in a controlled way rather than running more bulk updates.
Consider restoration carefully
A backup may help but does not replace finding the cause. Examine it in isolation first where possible. Restoring can lose newer orders, enquiries and content. Agree what will be restored; after an attack, do not copy current files into a clean installation without checking them.
Test after the fix
Test the originally affected URL, home page, other pages and login. Check important forms and shop functions in an appropriate test environment without unintended live orders. Clear only relevant cache layers after a targeted fix. Record the result and cause.
When to get support
Stop making changes when the cause remains unclear, rollback is unreliable or business-critical functions are affected. Malware indicators require a security investigation. Full logs, recovery links, passwords and keys do not belong in public forums or unencrypted emails.
Agree scope and costs →Maintenance after repair
WordPress core, plugins and themes are updated weekly, so essential updates do not get left behind in a busy working day. Monthly, daily or hourly: the backup interval depends on your plan. Backups are stored on EU servers.
Repairs and cleaning already hacked websites are separate services. Paid plugin licences are not included.