A WordPress malware cleanup should establish what changed, preserve the available evidence and investigate how unwanted code or access can return. A scanner result is one input to that assessment. The scope and the available records determine which conclusions can be supported.
Step 1 — Preserve evidence before you touch it
Preserve a labelled copy of the affected files and database before replacement or cleanup. It records the state you received and may help investigate the timeline; a snapshot alone does not prove the entry route. Agree how it will be stored, accessed and separated from any recovery copy.
Step 2 — Find the injected and modified files
Compare affected core, plugin and theme files with verified sources before choosing replacements. Record relevant differences and preserve the originals. Functions such as base64_decode can occur in legitimate code; a search match or an unfamiliar filename is an indicator to investigate, not sufficient proof to delete a component. Review unexpected PHP in writable upload directories against the site’s intended design and the surrounding evidence.
Is your website affected right now?
Send the URL and the symptom you can see. Jordi Ensenyat reviews the case personally and defines the scope and quote before anything is changed. This form never asks for passwords.
Step 3 — Clean the database, not just files
Review relevant options, content, accounts and scheduled work against the expected configuration. A stored value or cron entry needs code that reads or executes it to produce an effect. Trace the responsible component and callback, preserving legitimate settings and tasks. A recurring file change may involve database content, a scheduled callback, compromised access or another site; the investigation must distinguish them.
Step 4 — Close the entry point
Investigate vulnerable components, exposed access and deployment paths using the records available. Apply supported corrections to the route identified; document a suspected or unknown entry route as such. Review affected credentials and sessions after securing the relevant access points, with the account owner responsible for the agreed changes.
Step 5 — Check the neighbours
On shared hosting, one infected WordPress install can reinfect the others in the same account. Scan every site under the account, not just the one you noticed.
What cannot be promised
The close-out should record confirmed changes, preserved evidence, the routes reviewed, the correction applied and the checks completed. It must also name unresolved causes and any limits on observation. For recurring malware or a business-critical site, send the public URL and the symptom so the first assessment can define the work without requesting credentials.
Commission a recurring-malware investigation
If files or users return after a cleanup, agree the investigation before buying another file-only replacement. The brief should identify the affected sites, previous interventions, recurrence times and which hosting, application and deployment records are available.
- A recurrence register with affected paths or accounts, timestamps and supporting observations.
- The stored value, callback, task or access route supported by the evidence, with unknowns kept visible.
- A proposed correction, the legitimate function it must preserve and the person able to approve it.
- Acceptance checks, recovery arrangements and an agreed observation window; unresolved routes are recorded.
Database cleanup, callback repair and hosting-level containment can be separate workstreams. A proposal should identify who owns each dependency and whether another supplier needs to participate. An interval without a visible recurrence is an observation to record, not proof of permanent immunity.
database-driven file regeneration · scheduled-task reinfection
Send the public URL, the previous cleanup date and when the symptom returned. Describe the evidence available; keep credentials, customer exports and database dumps out of the initial request. Request a reinfection investigation assessment.
EVIDENCE-LED WORDPRESS RECOVERY
Malware cleanup that addresses persistence, not only symptoms
In WordPress malware cleanup and reinfection prevention, the visible symptom may be far from the cause. The objective is to remove malicious persistence, close evidenced entry points and verify the behaviour that triggered the alert. A hacked site can look normal while backdoors, scheduled tasks or database payloads keep access open. Cleanup therefore covers the WordPress files, database, users and server-level persistence relevant to the incident, followed by checks that the malicious behaviour no longer reproduces.
What we verify
- The complete journey, not only the screen where the error appears
- External dependencies, logs and evidence before configuration changes
- Unexpected administrators, modified core files and executable uploads
- Injected database content, JavaScript, redirects and SEO spam
- Backdoors, cron jobs, server rules and stolen access paths
- Public pages, search results, security warnings and host feedback after cleanup
What a verified outcome means
Close-out documents the cause found, the change applied and the tests performed. The result must be observable and repeatable—not a feeling that it “seems to work”.
BEFORE THE ASSESSMENT
Common questions about this WordPress incident
How do you verify that the problem is genuinely resolved?+
The affected journey is reproduced, its dependencies are checked and post-change evidence is recorded.
Does malware removal include the WordPress database?+
Yes. File-only cleanup can miss injected options, posts, users or scheduled payloads, so relevant database areas are reviewed as well.
Can you guarantee that a hacked site will never be compromised again?+
No responsible provider can guarantee that. The work removes identified malware, closes evidenced entry points and documents remaining risks and monitoring needs.
Should I restore the oldest available backup?+
Not automatically. A backup may already be infected or may lose valuable data. Its date, integrity and business impact should be assessed first.