WordPress security
Why does your WordPress website keep getting hacked after cleanup?
A recurring infection needs a wider investigation into access, vulnerable software and the hosting account. Here is what a useful recovery should cover.
The warning disappears, the site looks normal, and a few days later the redirects return. If that sounds familiar, another scan alone is unlikely to explain what happened. A repeat infection can mean malicious code survived the cleanup, the original entry point stayed open, or an account with access was compromised again.
Start by asking what was checked and what changed. A useful recovery should give you a documented explanation, a working website and a plan for watching the areas that were affected. The exact scope depends on the evidence available.
Keep a record before changing more files
Save the warning, affected URLs and the time you noticed the problem. Ask your host to preserve available access and error logs. Record recent plugin installs, account changes and recovery work. A dated copy of the affected files and database can help an investigator compare what happened, provided it is isolated and clearly marked as potentially infected.
Avoid repeatedly restoring backups or deleting suspicious files before someone has captured the evidence. Those changes can remove clues. If visitors are being redirected or exposed to harmful content, ask your host to restrict the affected site while the investigation proceeds. WordPress recommends documenting the compromise as an early recovery step. Its hacked-site guidance explains why.
Check how the attacker got access
Ask the person handling recovery to review the installed software, privileged users and available logs together. Possible causes include an exploitable plugin, an abandoned theme, stolen credentials or a compromised hosting account. Finding an old plugin is a reason to investigate; it does not establish that the plugin caused this particular incident.
The report should distinguish a confirmed cause from a likely explanation and say when the logs are insufficient. That distinction matters. Otherwise you may pay for a repair based on a guess and leave the actual access route available. Remove unnecessary software and update supported components through a controlled recovery process.
Recovery needs four checks
- Preserve
Record symptoms and keep evidence.
- Investigate
Review access and the entry point.
- Repair
Remove the cause and verify the site.
- Monitor
Watch affected areas after recovery.
Look beyond the files that triggered the alert
A scanner may identify one malicious file while another part of the installation still provides access. Review the full WordPress installation, the database, administrator accounts and scheduled tasks. On a hosting account with several sites, ask whether the other installations and account-level access were examined too.
Security work also needs a trusted baseline. Replace modified distributable software from its legitimate source where appropriate, and review custom code separately. A clean checksum result for WordPress core does not cover every plugin, upload or database record. The WordPress hardening handbook describes the broader layers involved in securing an installation.
Review credentials and the people who hold them
Changing the WordPress administrator password covers only one route into the site. Review hosting access, file-transfer accounts, database credentials, application passwords and any additional administrators. Rotate affected credentials from a trusted device as part of the recovery plan, and revoke access that is no longer needed.
Give each person their own account and the permissions their work requires. Agree who owns hosting and domain access, who receives security notices, and who can act if something happens again. Keep those recovery details private, away from the public website and ordinary support screenshots.
Check the business functions after cleanup
A site can be free of a known infection and still have a broken enquiry form, checkout or search function. Test the paths customers use, including mobile navigation and the actual receipt of a controlled form submission. Check important pages for unexpected scripts, redirects and content changes.
If you restore a backup, first establish whether it predates the compromise. Older copies may reintroduce vulnerable software or remove newer enquiries and orders. Plan that tradeoff before restoring a production database. WordPress backup guidance covers the files and database needed for a full recovery.
Ask for a handover you can use
Before closing the work, request a short record of the affected areas, evidence found, actions taken and checks completed. It should also list anything that remains uncertain, any unavailable logs, and the agreed monitoring period. Avoid accepting a promise that a website can never be compromised again.
- What access route was confirmed, suspected or left unexplained?
- Which files, accounts and other sites were reviewed?
- Which business functions were tested after recovery?
- What happens if the same symptoms return during the agreed support period?
If the work ends with only a green scan result, ask for the missing context. It is the context that helps you decide whether the recurring problem has actually been addressed.
For ongoing care after recovery, use our WordPress maintenance checklist to agree who checks what.
Sources and further reading
Technical references used for this guide. The checklists and examples are our practical recommendations, adapted to the subject.
WordPress development, website care and practical web integrations. Meet the agency.
