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
Compare browsers and networks
Open the address privately, on another device and through a different network. If only one view fails, examine browser cache and extensions. DNS failures, TLS problems and WordPress errors need different next steps.
02
Identify the symptom
HTTP 500 means server-side processing failed. 502, 503 and 504 may involve upstream services or resources. For database errors, check availability with the host rather than replacing credentials on a hunch.
03
Review updates and recent changes
Timing is a clue, not proof. If the dashboard works, test a specifically suspected extension in a controlled way. Further bulk updates obscure the cause. Use a copy for extensive conflict tests and check after each step.
04
When login also fails
Check the administrator mailbox and spam for a recovery link. Recovery Mode pauses certain components for your session; it does not automatically repair the public website. Arrange further file-level investigation if safe access is unavailable.
05
Check hosting and caches against evidence
Ask the host for PHP and server logs at the exact time and checks of storage, domain, DNS and certificate. Clearing cache may remove an old error page but does not repair a PHP error or broken database.
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.