Website Security Checker / Virus / Malware Scanner

Nobody hacks a site to make it look hacked. That was true twenty years ago, when defacements were the point. It isn’t true now. A compromised site in 2026 usually looks exactly like it did the day before, because the whole business model depends on nobody noticing.

The malware is there to redirect mobile visitors to a scam page while desktop users see nothing wrong. Or to inject spam links that only appear to Googlebot. Or to sit quietly in a checkout page skimming card numbers. In every one of those cases, the owner’s homepage loads fine and the owner has no idea.

That’s the reason to scan rather than assume. A security checker looks at what your site actually serves to the outside world, not what you think it serves.

The gap between “my site works” and “my site is clean”

Uptime tells you the server responded. It says nothing about what’s in the response.

You can watch this in your own logs if you have a compromised site. Traffic looks normal. Response times look normal. Status codes are 200 across the board. Meanwhile, a script in your footer is fingerprinting each visitor and only firing the malicious payload for people arriving from Google on an Android phone. You, the owner, arrive by typing the domain directly on a desktop, so you never see it.

Modern website malware is built specifically to hide from the person most likely to remove it. Conditional loading based on user agent, referrer, or IP. Payloads that skip anyone who has ever logged into wp-admin. Obfuscated code buried in a legitimate-looking file. Backdoors scattered across a dozen locations so cleaning one accomplishes nothing.

Sucuri’s remediation data has consistently found backdoors on around half of the compromised sites their team cleans, and their reports have repeatedly shown that a majority of infected sites carry more than one. Which explains why “I deleted the weird file” is rarely the end of the story.

What a scan is actually looking for

An external scanner requests your pages the way a visitor would and examines what comes back. The common findings:

Malicious JavaScript injections. Usually appended to a legitimate file or dropped into the header and footer of your theme. Often base64 encoded or otherwise obfuscated, which is itself a signal, because normal code doesn’t need to hide.

Hidden redirects. Traffic sent to a different domain based on device, referrer, or geography. Mobile-only redirects are the most common variant because mobile users are less likely to notice or report them.

SEO spam. Injected links and pages selling pharmaceuticals, counterfeit goods, gambling, or replica products. Frequently served only to search engine crawlers, so it’s invisible in your browser and highly visible in your search results. If you’ve ever seen unfamiliar Japanese or pharmaceutical text in your own site’s Google listings, this is what happened.

Defacement. Rare now, but it still happens, usually from hacktivist groups rather than commercial operators.

Blacklist status. Whether Google Safe Browsing or the major anti-virus and domain reputation lists have already flagged your domain. This is the one with immediate business consequences, since a flagged domain triggers a full-page browser warning and shreds your click-through rate.

Certificate and header problems. An expired or misconfigured SSL certificate, or missing security headers. Not malware, but both are visible signals of a site nobody is maintaining.

Reputation checks are also useful in the opposite direction, when you’re the one deciding whether to trust an unfamiliar shop or download page. That use case is covered in more depth in our guide to checking whether a website is secure before you use it.

What a remote scan cannot see

This part gets glossed over in most articles on the subject, and it matters.

An external scanner sees what’s publicly served. It can’t read your server’s file system, so a backdoor sitting in a PHP file that never renders to a visitor stays invisible. It can’t inspect your database, where malicious admin users and injected content often live. It can’t see anything behind a login. And it can’t detect malware that’s currently dormant, or that’s cloaked well enough to serve clean content to anything that looks like a scanner.

There’s also a broader limitation with reputation-based detection: it’s reactive by design. Norn Labs tested 254 confirmed phishing sites in February 2026 and found Google Safe Browsing had flagged only 41 of them, roughly 16%. Blocklists depend on a URL being reported and confirmed first, so anything new gets a free window before detection catches up.

None of this makes scanning useless. It makes it the first step rather than the only one. A clean external scan means the obvious stuff isn’t happening in public. It doesn’t mean nobody is in your server. If you have real reason to suspect a compromise, a remote scan needs backing up with file integrity monitoring, log review, and a look at your database and user accounts.

How sites get in trouble in the first place

Seldom through a dramatic zero-day. The mundane causes dominate:

An outdated plugin or theme with a publicly disclosed vulnerability. This is the single largest category on WordPress, and the exploit code is usually published within days of the patch. The window between “patch released” and “you applied it” is the attack window.

A weak or reused admin password, found in a credential dump and tried against your login page by a bot that tries thousands of sites an hour.

An abandoned plugin nobody has updated in three years, still active because it’s still working.

A shared hosting account where a neighbouring site got compromised and permissions allowed lateral movement.

A stolen FTP or hosting credential, often taken by malware on the developer’s own laptop rather than from the server at all.

The pattern is unglamorous. Most compromised sites are compromised by automated scanning that found a known hole, not by anyone who had a specific interest in that site.

The practical routine

For a site you own:

1. Scan the public pages. Do this monthly at minimum, weekly if you take payments.
2. Check your blacklist status specifically. Being flagged is a separate emergency from being infected, and it needs a separate remediation request once you’re clean.
3. Search your own domain on Google with site:yourdomain.com and read the results. Injected spam pages show up here long before they show up anywhere you’d normally look.
4. Look at your admin user list. An unfamiliar administrator account is one of the clearest signs of a real compromise.
5. Keep everything updated. Boring, and it prevents more incidents than anything else on this list.
6. Take backups you have actually tested restoring. An untested backup is a hope, not a plan.
   
   

For a site you’re just visiting: check the domain’s reputation before you enter a card number or download anything. HTTPS proves the connection is encrypted, nothing more. Phishing operations run valid certificates as a matter of routine, and the padlock has been useless as a trust signal for years. Running an unfamiliar URL through a free online virus scanner takes a few seconds and covers the obvious cases.

If a scan comes back dirty

Don’t start deleting files immediately. You’ll lose evidence of how they got in, and if you don’t close the entry point the malware comes back within days. That reinfection loop is the most common outcome of a rushed cleanup.

A better order:

Take the site offline or into maintenance mode if it’s actively serving malware to visitors. Then take a full backup of the compromised state, so you can investigate it later. Change every password: hosting, database, FTP, all CMS admin accounts. Look for the entry point in your access logs around the time of the earliest suspicious file. Then clean, restore from a known-good backup if you have one from before the compromise, update everything, and rescan.

If any of that is beyond what you want to take on, hiring a remediation service is a reasonable call. A botched cleanup that leaves one backdoor in place costs more than doing it properly. The wider case for running these checks routinely is mostly that finding an infection in week one is a maintenance task, and finding it in month six is an incident.