iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If WordPress malware returns after cleanup, deleting the visible files is not enough: another infected file, database change, account, or hosting-level access path may still be restoring it. Contain access, preserve a snapshot, investigate the whole site, and choose a restore or cleanup only after checking the evidence. Without access to the affected site, its logs, and its backups, no one can identify its specific backdoor or certify it clean.
How can you tell whether a WordPress site may still be infected?
Treat symptoms as indicators to investigate, not a complete explanation of what changed. WordPress documentation lists blacklisting, suspension by a hosting provider, malware-distribution flags, and antivirus warnings from visitors among signs that a site may have been hacked. Redirects, injected content, unfamiliar administrator accounts, or repeated changes to files are also worth documenting when they appear.
Record affected URLs, what visitors see, when symptoms began, alerts received, and any host notifications. Note suspicious file changes and unfamiliar accounts before altering the site. A timestamp or alert can help establish a timeline, but it does not by itself prove when an attacker entered or which systems they reached.
What should you do before trying to remove the malware?
Contain access
Restrict access to the site while you investigate if you can do so without destroying evidence or making essential services unavailable. Reset or disable suspicious administrative access, and review who can reach the hosting account and related systems. An attacker may have more than one way in, so a password change alone is not a complete response.
After preserving a snapshot, replace the WordPress secret keys in wp-config.php to invalidate active login sessions. Coordinate any access changes with the hosting provider if you are unsure how to isolate the site safely.
Preserve the current state and a recovery point
Before destructive cleanup, save a fresh copy of the site as it is now, even if you believe it is infected. Keep suspicious files and relevant logs intact for reference; deleting them immediately can remove clues about persistence or the entry point. Store this snapshot separately from any earlier backup you may use for recovery.
Check that a candidate recovery backup includes both site files and the database, and establish whether it predates the suspected compromise. Keep it separate from the infected copy. WordPress Developer Resources recommends regular complete backups and a tested recovery plan. As its Hardening WordPress guidance puts it: “Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.”
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchHow do you find the full scope of a persistent infection?
Investigate the installation and the hosting environment, not just the file that first triggered an alert. Work from the indicators you recorded and build a list of what is affected. Ask the host about account isolation, retained logs and backups, and whether other sites on the same account may be involved. WordPress warns that an infection can extend beyond one site, particularly on shared hosting; the actual scope depends on evidence from your installation and host.
- List affected pages, redirects, injected content, and alerts or warnings.
- Review unfamiliar administrator accounts and suspicious changes to files or site content.
- Check available hosting logs and notifications for relevant activity.
- Ask whether other sites, databases, or account-level services could share the same access or hosting environment.
WordPress’s Site Health screen can provide diagnostic information and flag critical issues, but it is not a malware certification. A reassuring result there does not establish that a backdoor is gone.
How should you inspect files and other persistence paths?
Compare code with trusted originals
Compare WordPress core files against the corresponding official WordPress release, and plugins and themes against trusted originals from WordPress.org or their publishers. WordPress documentation calls out index.php, header.php, footer.php, and function.php as common targets, but those examples are not an exhaustive list and do not diagnose a particular site. Inspect the relevant code more broadly, and account for legitimate customizations before replacing anything.
Rank #3
Use clean downloads from WordPress.org or the plugin or theme’s trusted publisher. WordPress cautions against obtaining releases from other sites. Preserve suspicious material before removing it if it could help explain how the compromise happened.
Follow evidence beyond the obvious files
Depending on the indicators, investigate uploads and unusual executable files, configuration files and drop-ins, database content, scheduled tasks, and unauthorized users. These are areas to examine when evidence points to them, not a guaranteed checklist of every infection. A changed file may be legitimate, while a clean-looking code directory does not rule out a database or account-level persistence path.
Can a malware scanner or file repair prove the site is clean?
No. Scanners and file comparison tools can help find modified files and speed up parts of cleanup, but a clean scan is not proof that every persistence mechanism is gone. Wordfence documents comparing compromised core, theme, and plugin files with originals and offering repair or deletion options. Its hacked-site guidance also says its plugin is not a complete or automatic restoration solution.
Review flagged results rather than accepting repairs blindly. Check database and account state where the evidence warrants it, and continue investigating any recurring changes or symptoms. A scanner is an assistant in the response, not a substitute for establishing scope and validating recovery.
Should you restore a backup, clean the site in place, or get specialist help?
There is no universally best choice. The decision depends on whether a backup is intact and predates the compromise, how much unique content or configuration could be lost, whether you can preserve evidence and identify an entry point, what logs and host support are available, and whether you can isolate the site while work proceeds.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Restore or rebuild from a backup: Consider this when you can establish that the backup is intact and from before the suspected compromise. A restore point that already contains the backdoor can reintroduce it, so check its date and coverage first.
- Clean in place: This may be necessary when no trustworthy recovery point exists or preserving unique content is important. Replace known-good core and extension files where practical, while taking care not to overwrite legitimate customizations or unique content without a recovery copy.
- Escalate to the host or an incident responder: Seek help if you cannot establish the scope or backup integrity, the site is repeatedly reinfected, or business-critical systems are involved. The host may have logs, isolation options, or account-level context you cannot access yourself.
WordPress.org’s Hacked or Malware forum is a noncommercial community option if you need help interpreting the issue. Avoid treating any cleanup route as complete until you have checked the site and its relevant access paths after remediation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should you verify and harden after cleanup?
Once cleanup is complete, update WordPress, plugins, and themes, and remove components you do not use. WordPress advises changing passwords again after the site is clean. Review database credentials and make sure the corresponding values in wp-config.php match if you change them.
- Confirm that the recovered site behaves as expected at the URLs that showed symptoms.
- Review administrator accounts and other access relevant to the incident.
- Monitor file integrity and retain separate, tested backups so you can recover without relying on the infected snapshot.
- Review hosting-level weaknesses and the owner’s workstation as possible parts of the incident.
If suspicious activity returns, treat it as evidence that the entry point or persistence mechanism may remain unidentified. Revisit the scope with your host or a qualified responder rather than repeating file deletion alone.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
