How to Scan a Website for Malware, and What 69 Remote Scans Showed

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

Three different checks all get called a website malware scan, and they answer different questions. On 22 October 2026 I ran Sucuri’s free SiteCheck scanner against 69 well-known sites. 48 came back with no warnings at all, 7 refused the scanner outright, and two large sites were flagged for malware on pages where the quoted code is ordinary page-rendering script. This site’s scan reported no warnings. Its sister site’s scan reported three timeouts that I could not reproduce. Neither scan could name a single one of the 25 plugins each site has installed.

This guide explains what a free scan can and cannot tell you, how to run the three useful checks in a few minutes, and what to do when a result looks bad.

Three things people mean by “scan for malware”

• A remote scan. A service requests your public pages like a visitor would and looks for known bad code, hidden redirects and outdated software, and checks whether security vendors list your domain. Sucuri SiteCheck is the best-known free one. Its own page says plainly that a remote scanner only sees what is visible at the browser level and that results are not guaranteed.
• A reputation check. Whether Google itself has flagged the site. Google reports this to verified owners in the Security issues report in Search Console.
• A server-side scan. A tool that runs where your files live and reads them: your host’s scanner, a security plugin, or a command that compares WordPress’s own files with the official copies.

Only the third can find a malicious file that no page links to. The first two are quick and free, and they catch the infections that show up in the pages visitors load.

How to run the three checks

1. Remote scan. Open sitecheck.sucuri.net, enter your domain and read the result. It reports malware it recognises, blacklist status, outdated software and some configuration notes. Treat a clean result as “nothing visible from outside”, not as “the site is clean”.
2. Google’s view. Sign in to Search Console, open the Security issues report and look for a count at the top. Google’s help page groups issues into hacked content (code injection, content injection, URL injection and malware), malware and unwanted software, and social engineering. If you have never verified your site there, this check is not available to you yet, and verifying is worth doing for this reason alone.
3. Core files. If your host gives you SSH or WP-CLI, run wp core verify-checksums. The WP-CLI documentation describes it as comparing your installed files with the checksums published by WordPress.org. It says nothing about plugins or themes, so treat it as a core-files check only. A modified core file is a classic sign of an injected backdoor.

Many hosts also run their own scanner and show the result in the control panel, and security plugins read files from inside WordPress. Reviews of the free versions describe basic malware scanning in some of them, but I did not test any, so I can only say they exist and work from the server side.

What 69 real remote scans showed

I sent the 69 domains from my earlier surveys (online stores, hosting companies, WordPress and tooling sites, news and software companies) through SiteCheck’s public API and read the raw results. The sample skews large and well-resourced, so read the numbers as how a free scanner treats popular sites, not as how often small sites are infected. Each site ended in exactly one of these outcomes:

Outcome	Sites (of 69)
No warnings at all	48
Scan failed: the site refused the scanner (six times) or did not resolve (once)	7
The scanner’s own test requests were refused or errored (403, 429, 404, 400, 406)	11
Flagged as malware or an anomaly	2
Flagged as running outdated software	1

• I found no evidence that any of the 69 was infected. That is what you would expect from large, monitored sites, and it is a useful baseline: a flag on one of them says more about the scanner than about the site.
• The overall letter mixes hygiene and outcome. One site scored A (github.com), 57 scored B and 11 scored C. The 11 Cs were the 7 sites that refused the scan, the 2 malware flags, the outdated-software flag and one site with a mixed-content note. In other words, a site that blocks the scanner gets the same low letter as a site with a finding.
• It recommended a firewall for 24 of the 69. The vendor sells one, so read that as a standard upsell line, not a diagnosis.
• It found little about the software. It named a content management system on only 14 of 69 sites: WordPress on 10, with a version number on just 5. Across all 71 scans, including my two sites, it never listed a single plugin.
• It is fast, and cached. The average scan took about two seconds. Two took around 20. Repeating a request for the same domain minutes later returned the identical stored result (same duration, same scan timestamp), so a re-scan right after you fix something can show the old answer.

The two malware flags, and why I read them as false alarms

huel.com was reported as “Known malware” and shopify.com as “Anomaly behavior detected (possible malware)”, each on seven pages. The report quotes the code it matched. On huel.com it begins $RC=function(a,b){if(b=document.getElementById(b))... and on shopify.com it is window.__reactRouterContext.streamController.close(). Community write-ups of React’s streaming server rendering describe exactly this kind of small inline script, which moves streamed content into place on the page. I did not contact either company and cannot prove the match is wrong, so this is my reading, not a verdict. The point is practical: a remote flag shows you the snippet it matched, and you can compare that snippet with what your theme or framework normally outputs before you panic.

The other direction matters too. Six sites answered the scanner with a refusal, including four hosting and domain companies, and one domain did not resolve. A site that blocks bots cannot be scanned this way, and a clean result from such a scanner says nothing about the pages it never saw.

What the scanner knew about this site, and what it missed

For veravix.com the scan returned the WordPress version, the PHP version (taken from a response header that every visitor can read), the server layer and a handful of minor recommendations: no HSTS header, a leaked PHP version, no stapled OCSP and the standard firewall suggestion. I removed the leaked PHP version header from both sites the same day, so a fresh scan should no longer report it, although the service can return its stored result for a while. The overall letter was B. It listed no plugins, although the admin screen showed 25 installed and 24 active when I counted on 21 October 2026. My guide to finding a site’s theme and plugins shows how little page source gives away, and the scanner sees the same page source.

The sister site repairpicks.com scored B as well, but its report listed three “Timeout reached” notes, on a cookie policy page, the theme folder and a deliberate 404 probe. A second request returned the stored copy, so I tested those addresses myself. The cookie page and theme folder answered 200 in under 0.6 seconds, and the 404 probe answered 404 in under a second, the same as on this site. I could not reproduce the timeouts, so I treat them as a transient hiccup on the scanner’s side or the host’s. That is the other lesson: a remote scan can report a problem that is not there, and it can only be checked by looking yourself.

The last gap is the one that matters most. A backdoor file that no page links to is invisible to any remote scan. Sucuri’s own page says the free scanner has limited access and that scanning every file in a site’s directory takes its paid platform. That is a fair description of the whole category, and it is why the third check in the list above exists.

If a scan or Google says the site is hacked

1. Write down what was flagged and where before you change anything: the page, the quoted code, the Search Console issue type.
2. Check whether it is real. Compare the flagged snippet with what your theme or a framework outputs, open the page in a private window, and see whether Search Console reports the same issue. A single remote flag with no Search Console issue deserves a closer look before a rebuild.
3. Ask your host. Most can show the last clean backup and run a server-side scan. If you are not sure who your host is, this guide shows how to find out.
4. Verify core files with wp core verify-checksums if you have access.
5. Restore from a clean backup rather than deleting suspicious files by hand. My guide to restoring a WordPress backup covers choosing the route before you overwrite anything.
6. Change every credential and update everything: WordPress users, hosting, database, FTP or SSH, then core, plugins and themes. A restored site that keeps the same weak password gets reinfected.
7. Scan again and wait for the stored result to expire so you are not reading yesterday’s answer, then check Search Console again.

Cutting the number of ways in helps before any of this happens. Fewer plugins, prompt updates and the response headers covered in my guide to checking your website’s security headers narrow the gaps a scan would otherwise report.

Checked for accuracy on 22 October 2026. The survey sent one SiteCheck API request per domain on 22 October 2026 (the free public endpoint, results as returned, some cached by the service) and counted each site once by its first result. Scanner output changes with its signature database, and large sites can answer a scanner differently by location and time, so another run can give different counts. Search Console issue types were checked against Google’s help page and WP-CLI behaviour against its documentation.