Do this first
- Change the password on your hosting account and your email.
- Do not delete files that look suspicious. They are evidence, and random deletion can take the site down without removing a backdoor.
- Do not restore an old backup yet. Restoring can destroy evidence and overwrite newer orders or submissions.
Therefore the first hour is about preserving information, not about tidying up.
What a compromise can look like
- Search results show pages and text you did not write.
- Visitors are redirected somewhere else, sometimes only on mobile or from search.
- A browser or host warns that the site is unsafe.
- Administrator accounts exist that nobody created.
- The host has suspended the account for sending spam.
Notably, some of these appear only to search engines or only to visitors arriving from Google. In other words, a site that looks fine when you log in can still be serving something else to everyone else.
Why cleaning alone keeps failing
Most reinfections are not new break-ins. Instead, the original entry point stayed open, or a persistence mechanism survived the clean. That is why a hacked WordPress site often returns to the same state days later.
Attackers rarely leave one file. They add scheduled tasks, extra administrator accounts, modified core files, injected database rows, and code that rewrites itself when it is removed. Consequently a scan that deletes the visible payload can leave the machinery that puts it back.
How hacked WordPress site recovery is approached
- Contain. Limit damage and preserve evidence.
- Assess. Confirm whether files, database, users, scheduled tasks, or neighbouring sites are affected.
- Clean. Remove malicious code and persistence mechanisms, not only the visible symptom.
- Close the way in. Identify the entry point where evidence allows it, and address it.
- Rotate. Change credentials in the correct order.
- Harden and verify. Reduce repeat risk and check the result.
- Document. Record what was found, changed, and left undetermined.
Cleaning or rebuilding: how the call is made
Cleaning is usually right when the damage is bounded, the codebase is standard, and a trustworthy reference exists for the files that matter. However, rebuilding becomes the honest answer in several situations.
- The compromise is old, so no backup predates it.
- Core, theme and plugin files have been modified widely and no clean reference exists.
- The site runs abandoned or encrypted commercial code that cannot be verified.
- The same site has been reinfected repeatedly and the route was never established.
We say which of these applies before the work starts, because a rebuild discovered halfway through is how a recovery budget disappears.
How they got in
Common routes include outdated vulnerable code, reused or stolen passwords, compromised shared hosting, or accounts that were never removed. The actual route matters because it determines what has to change afterwards. For background on the standard containment steps, the WordPress guidance on a hacked site covers the same ground in general terms.
Sometimes the evidence simply does not survive. In that case we say the route is undetermined rather than naming a plausible one, and we harden against the realistic candidates instead.
What no provider can promise
Nobody can guarantee that a compromise will never recur, and nobody can recover content that no longer exists anywhere. Similarly, no provider can prove a negative: “completely clean” is a judgement based on what was examined, not a certificate.
What can be promised is method: preserve evidence, remove persistence, close what can be closed, and write down what remains unknown.
What happens after the site is clean
Recovery is not finished when the malicious code is gone. Afterwards, credentials need rotating in the right order, search engines may need the warning reviewed, and the reason the site was reachable in the first place still needs addressing.
That last part is preventive work rather than incident work. It is covered in security services, and it is the reason ongoing maintenance plans exist.
Prepare for a fit check
Before contact, write down what you can see, when it started, who has access, and what changed recently. Do not include passwords. Then read the service scope to confirm the work is something DuePress takes on, and see the wider WordPress support options if the problem turns out to be something else.