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
Document the indicators
Unexpected redirects, unknown administrators and malware warnings matter. Record URLs and times and preserve screenshots and host messages. Slowness or downtime alone does not prove compromise. Do not spread suspicious warning links.
02
Isolate reliably with your host
Agree how to remove public access while preserving evidence. A maintenance plugin inside a compromised website may be insufficient. Restrict affected forms and shops; do not bypass browser warnings.
03
Preserve the infected state securely
Protect files, database and available logs before cleanup. This copy can contain malware and private data and is not a clean restore backup. Keep older backups: first visible symptoms may appear after the attack began.
04
Secure access and the entry point together
Review hosting, WordPress, SSH/SFTP, database, email, user rights and active sessions. Plan credential changes from a trusted device and recheck after cleanup. Changing a password does not remove malicious code or backdoors.
05
Verify cleanup and reopening
Have files, database, configuration and other installations in the hosting account investigated. A clean external scan alone is not clearance. Close the entry point, check trusted sources and test restoration in isolation. Involve responsible staff early if customer data is affected.
06
Plan monitoring and warning reviews
After technical clearance, check functions, redirects and logged-out views. Arrange follow-up checks. Review Search Console security issues and unexpected owners; request review only after fixing the problems. Warnings may not disappear immediately.
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.