WordPress hacked again after cleanup: why it happens and how to prevent recurrence

WordPress hacked again after cleanup: why it happens and how to prevent recurrence

Your WordPress site was cleaned, but the redirects, suspicious files or unfamiliar accounts have returned. Before buying the same intervention again, ask what the first one established: which entry point was identified, which access was revoked, and how was recovery tested? A normal-looking homepage does not answer those questions.

A repeat incident may be a continuation of the original compromise or a separate intrusion. The task is to distinguish those possibilities using evidence, then close the paths that remain available. If visitors are currently at risk, start with our guide to regaining control of a hacked WordPress site. This article focuses on what needs to change after an initial cleanup.

1. Establish whether the infection has actually returned

A warning that still appears is not, by itself, proof that malicious code has returned. A cache may retain an old page, and an external security warning can remain after remediation. Conversely, a clean homepage does not establish that every page is safe. Record the affected URL, time and time zone, browser and journey that triggered the symptom.

Compare those observations with the previous recovery report. A file recreated after its documented removal, a new unauthorised administrator or unexplained changes are evidence to investigate. A modification timestamp alone is insufficient: a legitimate update can change files too. Preserve available logs and a snapshot before making further corrections, restricting access to that material.

The official WordPress hacked-site FAQ recommends documenting symptoms and keeping a copy before cleanup. That baseline matters particularly after recurrence. Without it, establishing what was genuinely removed becomes much harder. Ask the previous provider for its findings rather than relying on an invoice that simply says “malware removal”.

2. Separate the visible consequence from the cause

A redirect, spam page or infected file often describes a consequence. The cause might be a vulnerable plugin, a compromised account or access to the hosting environment. Removing the visible consequence does not necessarily prevent its return. The incident report should distinguish removed material, a confirmed entry point and hypotheses that remain unresolved.

Build a timeline. If symptoms return without a known application change, investigate retained access and persistence. If they follow a restore, examine the backup and settings reintroduced. If they follow a deployment, review what changed. These relationships guide the investigation; they do not automatically prove that a particular component or supplier caused the incident.

Sometimes the cause cannot be confirmed because the necessary logs do not exist. Record that limitation, identify the paths that were checked and agree on closer observation. “Everything is secure” would conceal the uncertainty. A useful conclusion records what was examined, what changed and what remains outside the evidence available.

3. Investigate what survived the first cleanup

Persistence means a way of retaining or recovering access after the intervention. The authorised investigation should not stop at files flagged by one scanner. Its scope may include application files, the database, user accounts, scheduled tasks and hosting configuration. Automatically loaded extensions and custom code also need identification, without blindly removing everything that looks unfamiliar.

Reinstallation that only overwrites recognised files can leave added files behind. WordPress documentation explicitly highlights that limitation. For affected components, the professional should compare the installation with trusted distributions while preserving legitimate custom work. A customised component with no reliable reference requires investigation, not automatic deletion.

A scanner reporting no findings provides evidence within that scanner’s coverage. Combine it with component comparisons, access review and observations of the public site. Ask for a clear list of areas actually checked. “Examined with no anomaly identified” is materially different from “not accessible during the intervention”, especially when deciding whether to reopen sensitive functionality.

4. Revoke compromised access and replace exposed secrets

Changing the WordPress administrator password does not revoke every route into the site. Review other privileged accounts, active sessions, SFTP or SSH access, the hosting control panel, deployment accounts and secrets stored in the environment. A secret is information that grants access to a service, such as a password, key or token.

Coordinate replacement from a trusted device after bringing the environment under control. Otherwise, newly issued credentials may immediately become exposed again. Revoke obsolete sessions and access; reconfigure and test legitimate integrations that depend on replaced credentials. WordPress also recommends changing passwords again after the site has been cleaned.

A compromised mailbox used for password resets may allow access to be recovered. The investigation therefore needs to follow the site’s actual dependencies. Multifactor authentication reduces certain account-access risks, but it does not fix a vulnerable plugin or undo exposure of a service secret. Record which credentials were replaced without putting confidential values in the incident report. Someone must also own the follow-up checks: a broken integration is not an acceptable unnoticed side effect.

5. Check the backup and the hosting neighbourhood

A backup taken before discovery is not necessarily a backup taken before compromise. The first visible symptom may appear much later than the intrusion. Before restoring, inspect the candidate copy in an isolated environment and examine the period it represents. An older copy can also reintroduce a vulnerable plugin or access that should have been removed.

Agree with the business how to preserve orders, enquiries and content created since that backup. After restoration, observe essential journeys: browsing, signing in, submitting a form and, where relevant, ordering and receiving payment confirmation. A site that loads but silently loses enquiries has not passed recovery acceptance. Keep the test results and dates without exposing customers’ personal information.

The official WordPress hardening guide also discusses shared-hosting risks. Multiple sites within one account, or excessively broad permissions, can make containment harder. Ask the host which accounts, directories and databases are actually isolated and whether neighbouring sites require investigation. Shared hosting is not automatically the cause: establish the boundary problem rather than inferring it from the product label.

6. Distinguish the original incident from a new vulnerability

A correctly completed cleanup does not freeze the software in time. A new vulnerability may be disclosed later, and an abandoned plugin may never receive a fix. Compare dates, versions and observed changes before concluding that the original intervention failed. That distinction affects both the technical response and the responsibilities to discuss.

The maintenance agreement should identify who tracks WordPress, plugins, the theme and server components, and who approves updates with compatibility risks. Incompatibility is not a reason to retain an exposed component indefinitely. Plan replacement, deactivation or an agreed risk-reduction measure. Test business functions after changes and retain a controlled recovery option if a legitimate update causes a failure.

A one-off cleanup addresses a defined incident. Monitoring, backups, restore tests and updates are continuing responsibilities only where included in the relevant agreement. Hosting alone does not necessarily include maintenance of every installed plugin. Ask which layers are covered and what happens when a component falls outside support; a gap between suppliers should not become an unowned security decision.

7. Request before-and-after evidence and an owner for follow-up

To avoid paying for a second cleanup without learning from the first, request a short, verifiable handover:

• Before: dated symptoms, accessible scope, versions and preserved evidence.
• Remediation: removed material, confirmed cause or remaining hypotheses, patched components and revoked access.
• After: technical and public checks, tested business journeys and explicitly identified remaining anomalies.
• Follow-up: a named owner, monitored signals, alert recipients and a recovery procedure.

Agree on an observation period suited to the risk without treating it as a guarantee that compromise is impossible. If a file or account reappears, comparison with the baseline should trigger investigation, not an automatic deletion that destroys fresh evidence. A Google warning has a separate process: request the relevant review only after fixing the identified security issues. Google controls its decision; a clean scanner result does not guarantee warning removal or a deadline.

For help defining incident deliverables, ownership and maintenance responsibilities, see Say Digital’s IT governance service. An infrastructure change is a separate project covered by the cloud and VPS hosting offering: moving a site does not replace treatment of compromised access. To discuss the scope, book a conversation, without sending passwords in your initial message. Confirm deliverables and any continuing obligations in writing rather than assuming that cleanup includes indefinite monitoring.

FAQ: WordPress reinfection after cleanup

Does recurrence prove the cleanup was poor?

No. It can indicate overlooked persistence, retained access, a contaminated backup or a new vulnerability. The timeline and the original intervention’s evidence help distinguish them. The appearance of the website alone cannot establish which explanation applies or allocate responsibility fairly.

Should we move to a different host immediately?

First examine isolation and access. Moving may be appropriate if the current environment cannot support adequate containment. Copying the same files, accounts and secrets, however, can move the problem rather than solve it. Agree on what will be checked before and after migration.

Does a maintenance agreement automatically cover reinfection?

No. Check covered components, included interventions, exclusions, recovery conditions and responsibilities. Define treatment of the current incident separately from recurring maintenance. Do not infer a warranty, unlimited incident response or a particular response time from the word “maintenance”.

Follow the symptoms you observe

If the recurring symptom is a redirect, revisit the redirect journey diagnosis. If a Google warning remains after remediation, distinguish technical recurrence from the Google security review process.

Sources

• WordPress: FAQ My site was hacked, documentation, preservation, access and cleanup.
• WordPress: Hardening WordPress, backups, updates, logging and hosting.
• Google Search Console: Security issues report, remediation and review.