Website Malware Scanning Explained: What Can a Scanner Actually Detect?

How website malware scanning works

Most website scanners follow the same broad steps. They fetch a page the way a visitor would, parse the HTML, collect the scripts, iframes and links it references, fetch some of those files, and then analyse the content. The analysis uses a mix of techniques:

• Signature matching: looking for code fragments or domains that match known malware or known-bad hosts.
• Heuristics: flagging patterns that are often malicious, such as heavily obfuscated code that decodes and runs itself, or a hidden iframe loading another domain.
• Reputation lookups: checking domains and URLs against threat-intelligence lists maintained by security vendors.
• Change detection: comparing today's scripts with a previous scan to notice new ones that appeared unexpectedly.
• Configuration checks: looking at security-related HTTP headers and transport security.

A responsible scanner reads this content as text. It does not need to run your site's JavaScript on its own servers, and it should not.

Public URL scanning versus server-side file scanning

The distinction matters because many serious infections live where a public scan cannot look. A backdoor script sitting in an uploads folder may never appear in a page's HTML, yet it gives an attacker control. Conversely, a public scan can catch the malicious script an attacker injected into your pages, which is what visitors actually encounter.

Be sceptical of any product that claims to inspect your server files from a URL alone. It cannot — it needs authorised access to the server, or the files themselves.

Suspicious scripts and injected links

Two of the most common things a public scan reports are worth understanding.

Suspicious scripts

Malicious scripts are often loaded from an unfamiliar domain, or hidden inside long encoded strings that are decoded and executed in the browser. Their purposes range from redirecting visitors, to displaying unwanted ads, to stealing form data, to using the visitor's device to mine cryptocurrency. Legitimate scripts — analytics, chat widgets, payment forms — also come from external domains, which is why a scanner needs an allowlist of well-known services and a way to weigh the evidence.

Injected links

SEO-spam attacks add hidden links to your pages — pointing at gambling, pharmaceutical or counterfeit-goods sites — often hidden with CSS so you never see them while search engines do. They can damage your reputation and search visibility long before anyone notices.

Known malware signatures

Signatures are fast and precise for malware that has been seen before. The weakness is that attackers change code constantly. A new or modified variant, or custom malware written for a single site, will not match anything. A signature hit is therefore strong evidence; a signature miss is weak evidence of safety.

False positives and how scanners reduce them

Not everything unusual is malicious. Minified or bundled code can look obfuscated. A marketing tag loaded from a service the scanner has not seen before looks like an unknown third party. A legitimate redirect to a payment page looks like a redirect to another domain.

Good scanners reduce noise by allowlisting well-known services, grouping duplicates, and attaching a confidence level to each finding, so a low-confidence heuristic does not look as alarming as a confirmed known-bad domain. As a user, read the evidence, check whether you or your developer added that script, and use any option to dismiss or report a false positive so it does not keep returning.

The limitations of public scanning

• It cannot see files and databases that are not served publicly.
• Malware can behave differently for scanners than for real visitors — for example serving clean pages to automated requests or only to visitors arriving from search engines.
• It sees a limited number of pages; an infection on a deep page can be missed.
• Scripts loaded only after user actions, or behind logins, may not be reached.
• Threat-intelligence lists lag behind new attacks.

What to do when a scan detects a possible threat

1. Don't panic and don't just delete the line. Capture the evidence first: the URL, the flagged code and the time.
2. Check whether it is legitimate. Did you or a developer recently add a plugin, tag or widget? If yes, it may be a false positive.
3. Compare with a clean copy. A backup or a fresh download of your theme or plugin shows whether a file was modified.
4. If it is not yours, assume compromise. Put the site in maintenance mode if visitors are at risk.
5. Find the way in. Outdated plugins and themes, weak or reused passwords, and exposed admin accounts are common entry points. Removing the symptom without closing the entry lets the infection return.
6. Restore and rotate. Restore from a known-clean backup if possible, update everything, and change passwords and keys for the site, hosting, database and email.
7. Re-scan and monitor afterwards, and watch for repeat infections over the following weeks.

When professional incident response is required

Bring in an experienced professional — your host's security team or a specialist — if any of these apply:

• You find files you did not create, unknown admin users or modified core files.
• The infection returns after cleaning.
• The site handles payments or personal data, which may bring legal notification duties.
• Your host has suspended the account or you have been listed as unsafe by a browser or search engine.
• You cannot establish how the attacker got in.

A maintenance plan that covers updates and backups lowers the chance and cost of these situations.

Safe preventive practices

• Keep your CMS, themes and plugins updated and remove ones you no longer use.
• Use unique, strong passwords and two-factor sign-in for admin and hosting accounts.
• Limit who has admin access, and remove former staff and agencies promptly.
• Take regular backups and test restoring one.
• Serve the site over HTTPS and set sensible security headers.
• Review third-party scripts periodically and remove what you don't use.
• Monitor for unexpected changes, and watch uptime — see why websites go down.

Questions to ask a security provider

• Does the scan check only public pages, or server files too — and what access does that require?
• Which threat-intelligence sources do you use, and under what terms?
• How do you handle false positives, and can I dismiss or report them?
• What will you do with my data, and are scan reports private to my account?
• Do you claim to find all malware? (If so, be cautious.)
• What help do you give after a finding — and do you offer incident response?

SiteShield is Xigmapro's public-website scanner. It checks pages, linked scripts and selected security headers, shows evidence, severity and confidence for each finding, and says plainly what it cannot see.