Malware was found on your site. You installed a security plugin, ran a scan, and it reported "threats removed". Three days later the same redirects are back. This article explains why that happens and what a correct cleanup looks like.
The short answer: a scanner finds the malicious patterns it knows about. It usually cannot see a custom back door, a legitimate-looking admin account, or code buried in the database. Cleanup is not about deleting files — it is about closing the entry point.
Where Malware Hides
- Executable files deep in the uploads directory. A code file inside an image folder is abnormal on its own; no legitimate plugin puts code there.
- A single line appended to the end of theme files, usually a long, unreadable encoded block.
- Imitations of legitimate filenames, sitting in the right folders with names very close to real system files. Visual inspection will not catch them.
- Content fields in the database — redirect code embedded in posts, pages, even settings rows.
- Scheduled tasks that recreate the malicious file at intervals after cleanup. This is the number one cause of "I deleted it and it came back".
- Newly created admin accounts — or an existing user quietly promoted, so no new name appears in the user list.
Why a Scanner Alone Is Not Enough
First, it is signature-based. It looks for known patterns. Code written specifically for you, or something new, simply reads as "clean".
Second, telling legitimate from malicious code is hard. Some plugins also obfuscate their code or talk to remote servers. Scanners either flag those by mistake or miss genuine threats that look similar.
Third, it does not look at the open door. A scanner cleans files but does not close the way in — an outdated plugin, a weak password, a neglected site on the same server. While the door stays open, cleanup repeats.
The Correct Order of Cleanup
- Back up the compromised state. Copy before you delete; the entry point can only be found in those files.
- Investigate in isolation. Work on a copy, not the live site — visitors stay unaffected and nobody makes a rushed decision.
- Replace rather than clean. Reinstall core, theme and plugins from official sources. Manual extraction is slow and always incomplete.
- Audit your own code. The uploads directory and custom development get reviewed piece by piece — this is the part that takes real time.
- Audit the database for embedded code, suspicious settings rows and user privileges.
- Clear scheduled tasks. Leave the regeneration mechanism in place and the cleanup will not hold.
- Reset access. Change every password and terminate open sessions. A password change alone is not enough.
- Close the hole and harden: updates, file permissions, login attempt limits, removing unnecessary entry points.
- Monitor. Track file changes and login attempts for the first month.
The Google Warning Afterwards
If a warning appeared in search results or browsers started blocking the site, you must submit a review request in Search Console once cleanup is complete. Skip it and the warning stays for weeks on a clean site while your traffic does not return. Likewise, if the attack generated hundreds of spam pages, they need removing properly and answering with the correct status code.
Rescue or Rebuild?
Sometimes the honest answer is "do not rescue this one". We weigh the site's age and how current its stack is, the volume of custom development, the value of the content, and how deep the compromise went. On a very old stack with untracked source code, rescue can cost more than a rebuild. That judgement belongs after the investigation, not before it.
How We Handle It
We run recovery in three stages: diagnosis, repair, hardening. The difference sits in stage two — we do not stop at cleaning files, we keep going until the entry point is found, because an unfound hole sends the same invoice again a few weeks later. We listed the first-24-hours steps in a separate article.
Most of these cases never happen on sites under real maintenance. Tested updates, backups verified by restore and monitored login attempts shrink the attack surface substantially — all standard items in our maintenance subscription.
The First Month After Cleanup: What to Watch
- File changes. An unexpected new file or a modified system file is the first signal.
- Failed login attempts. Attempts concentrated on one username mean the attacker is still interested.
- New users and privilege changes. Promotions are sneakier than new accounts.
- Outbound mail volume. A spike means the site is being used as a spam relay again.
- Appearance in search results. Check weekly how your titles and descriptions look in Google; a hidden injection shows up there first.
This monitoring can and should be automated. Nothing checked manually is still being checked in week three.
Hardening: So It Does Not Happen Again
- Block code execution in the uploads directory. One of the single most effective measures; it removes file upload as an attack surface.
- Login attempt limits and two-factor authentication effectively end password guessing attacks.
- Correct file permissions. The web server should not be able to write where it has no business writing; most installations leave this loose.
- Delete unused plugins and themes. A deactivated plugin still carries its vulnerability while it sits on the server. Deleting is not the same as disabling.
- Remove old, forgotten installations — a test site from years ago can bring down the live site beside it.
- Restore-test your backups. A backup that has never been restored is not a backup.
These are not a one-off task but a routine to sustain, which is exactly what a maintenance subscription is for.
What Would It Cost If We Fixed It?
You do not have to guess, and you do not have to ask us. Tick the items you need in the calculator on our site and the total appears instantly. No forms, no waiting for a quote.
