How to Scan a WordPress Site for Malware Without Fooling Yourself

Decide what question you are actually asking

Scanning is not one activity. Someone who suspects an active compromise needs a different process from someone doing a routine health check, and running the wrong one wastes a day.

If a visitor reported a redirect, Google flagged the site, or the host suspended the account, you are doing incident detection: fast, focused on confirming and scoping the infection. If nothing is obviously wrong and you want to know where you stand, you are doing a security review: broader, slower, and as interested in vulnerable components as in active malware.

The rest of this guide covers the layers that matter in both cases. The order is deliberate, because each layer catches what the previous one misses.

Scan the database, because most scanners will not

This is the layer that separates a real scan from a plugin click. A large share of WordPress infections, including nearly every SEO spam and pharma hack, live entirely in the database, where file scanners never look.

Work through it in this order:

• Users table. Every account with administrator role, checked against the people who should have one, plus registration dates that do not match a real onboarding.
• Options table. Injected script tags, base64 blobs, and autoloaded rows that were not there last month. Autoloaded malicious options are common because they run on every page load.
• Posts and postmeta. Hidden divs, off screen positioning, links to pharmaceutical or gambling domains, and content injected into old posts nobody views.
• Scheduled events. WordPress cron entries pointing at functions or files you do not recognise.

If you find spam content, note whether it is stored as plain text or generated at runtime. Generated spam means there is still code executing somewhere, and deleting the rows will not stop it.

Read the logs, they answer the question scanners cannot

Scanners tell you what is there now. Logs tell you when it arrived and who put it there, which is what you need to fix the root cause rather than the symptom.

Take the earliest modification timestamp among the suspicious files and pull every request in a window around it. You are looking for POST requests to unusual paths, requests to files that should never receive POST, long query strings containing encoded payloads, and successful administrator logins from addresses that do not match your team. Repeated failed logins on wp-login.php or xmlrpc.php before a successful one is a brute force that worked.

Log retention on shared hosting is often only a few days, which is a good argument for pulling them at the first sign of trouble rather than after a week of investigation.

Turn scanning into monitoring

Manual scanning finds a problem after it has had time to do damage. Monitoring finds it while it is happening, and the difference in cost is large.

Continuous file integrity monitoring with alerting is the highest value single addition, because unexpected file changes are the earliest reliable signal. Add uptime and content monitoring so a defacement or redirect is noticed within minutes. Keep Search Console connected and check it, since Google frequently reports a security issue before anyone internally notices. Track failed and successful administrator logins.

Reducing the noise reaching the site in the first place also makes monitoring more useful. Rate limiting and bot controls at the edge cut the volume of automated probing dramatically, which means the alerts you do get are worth reading. The WAF setup guide covers how to do that without blocking real customers.

If a scan has already confirmed an infection, move to the malware removal process rather than deleting files one at a time.

WordPress malware scanning questions