How to Check a Website for Malware

If you need to check a website for malware — your own or one you are about to trust — the good news is that you can get a reliable read in minutes, for free, without any access to the server. A combination of external scanners (Google Safe Browsing, Sucuri SiteCheck, VirusTotal and urlscan.io) will tell you whether a site is flagged, infected, or behaving suspiciously, and for a site you own, a few server-side checks complete the picture. This guide walks through the tools, the signs of infection, the deeper checks a site owner should run, and exactly what to do if a site turns out to be compromised.

It is closely related to how to tell if a website has been hacked and uses the same external checks as is this website safe?.

Why a normal-looking site can still be infected

Start with the point that trips people up: a site that looks fine in your browser can still be serving malware. Modern website infections are usually built to hide, because their value depends on going unnoticed for as long as possible. They commonly:

• Show malicious behaviour only to some visitors — redirecting people who arrive from a search engine, or only those on mobile, while returning visitors and the logged-in owner see a clean page.
• Serve spam content mainly to search-engine crawlers (the classic "pharma hack" or counterfeit-goods links), poisoning your search listings without changing what you see when you log in.
• Cloak — deliberately showing different content to bots than to humans to evade the owner's notice.

The practical lesson: to check for malware properly you must look at the site the way a stranger, a crawler, and a security scanner do — not the way you do as an admin in your usual browser. That is exactly what the external tools below are for.

The external scanners: tool by tool

These free services inspect a public URL remotely, so they need no server access and work on any site. Their real power is in combination — when several independent tools agree, you can trust the verdict; when they disagree, you know to dig deeper.

Tool	What it checks	Best for
Google Safe Browsing / Transparency Report	Whether Google has blocklisted the URL/site as dangerous (malware, phishing, deceptive)	The blocklist status that drives browser warnings
Sucuri SiteCheck	Known website malware, injected spam, defacement, and blocklist status	A focused website-malware verdict
VirusTotal	The URL checked against dozens of security engines and blocklists at once	A broad, aggregated second opinion
urlscan.io	A sandboxed page load recording every resource, request, redirect and connection	Seeing exactly what a page loads and contacts

Google Safe Browsing. Safe Browsing is the service most browsers use to warn users away from dangerous sites, so it is the most consequential blocklist there is. You can check a specific URL's current status through Google's Safe Browsing site-status tooling, and the Google Transparency Report shows the safety status Google holds for a site. A flag here is why visitors see the red "Dangerous site" or "Deceptive site ahead" warning, so it is the first thing to check — both to confirm a problem and, after cleanup, to confirm it has cleared.

Sucuri SiteCheck. A free remote scanner (sitecheck.sucuri.net) that fetches a public URL and inspects it for known malware signatures, injected spam, defacement and blocklisting across multiple lists. It is purpose-built for website malware, so its report is often the most directly useful for a site owner. Like all remote scanners it sees only what is served to it, so it cannot guarantee a server is clean — but it catches a great deal and explains what it found.

VirusTotal. Submit a URL (or a file) and VirusTotal checks it against dozens of antivirus and security engines and blocklists simultaneously, returning how many flagged it and as what. Because it aggregates many independent sources, it is an excellent broad second opinion: one engine flagging a site might be a false positive, but many flagging it is a strong signal. It also retains useful metadata about the URL and any files it serves.

urlscan.io. This service loads a URL in a sandboxed browser and records everything the page does — every resource it requests, every domain it contacts, every redirect, the page's screenshot, and the technologies it uses. That makes it invaluable for spotting injected scripts and unexpected outbound connections: if a page quietly loads a script from, or sends data to, a domain that has no business being there, urlscan.io exposes it. It is more of an investigative microscope than a simple verdict, and it pairs well with the others.

Beyond these, broader site audits — StackOptic included — record the technology, headers and configuration a site exposes, which helps you establish a baseline and notice when something changes. For reading the raw response a server returns, see how to read a website's HTTP headers.

The signs of infection to look for

Whether the scanners flag something or you are investigating a hunch, these are the symptoms of website malware, grouped by where they appear.

In the page and its code

• Injected <script> tags or hidden iframes referencing unfamiliar domains — the most common payload, often obfuscated (long strings of encoded characters).
• Unexpected redirects, especially ones that fire only for visitors from search engines or only on mobile.
• Pop-ups, adverts or overlays you did not add.
• Defacement — altered pages, strange messages, content you never published.

In search results

• A "This site may be hacked" label under your Google listings.
• Spam keywords, foreign-language text, or pages you never created appearing in site:yourdomain.com searches — a sign of SEO-spam injection.
• A flood of junk pages indexed under your domain.

In the browser and warnings

• A full-page "Dangerous site" or "Deceptive site ahead" warning (driven by Safe Browsing).
• Console errors referencing unknown external scripts or domains.
• Your host or security provider flagging or suspending the account.

Remember the hiding behaviour above: to surface redirects and cloaked content, open the site in a fresh private/incognito window, change your user-agent to a search bot, and use a "fetch as a crawler" style tool, because the malware may be deliberately invisible to you as the admin.

Server-side checks (for sites you own)

External scanners see what a remote visitor sees, which is a lot — but not everything. If you own the site and suspect infection, complement them with server-side checks that external tools cannot perform:

• File-integrity comparison. Compare your site's files against known-good versions — a fresh copy of your CMS core, themes and plugins, or a pre-infection backup. Files that differ, or core files that have been modified, are prime suspects. Many CMS security plugins automate this comparison.
• Hunt for unfamiliar and recently-modified files. Look for files you do not recognise, files with recent modification timestamps you cannot account for, and scripts in unexpected locations (for example, executable code sitting in an uploads or media directory, where it should never be). Backdoors and web shells — small scripts that give an attacker ongoing access — hide this way.
• Review admin users and accounts. Check for admin or user accounts you did not create, a classic sign of compromise and a persistence mechanism.
• Check scheduled tasks (cron jobs). Attackers add scheduled tasks to re-infect a site after cleanup or to run malicious jobs; an unfamiliar cron entry is a red flag.
• Scan server-side. A server-side malware scan (via a security plugin or your host's tooling) inspects files and database content directly and finds far more than a remote scan can.
• Review logs. Server and access logs can reveal the entry point and the attacker's activity — unusual requests, suspicious POSTs to admin endpoints, access from unexpected locations.

Several of these signals together strongly indicate a compromise, and the same detection logic is covered from the symptom side in how to tell if a website has been hacked.

What to do if a site is infected

If the checks confirm malware, work calmly and in order — speed matters, but so does not destroying the evidence you need to find the entry point.

1. Contain. Put the site into maintenance mode or take it offline so it stops harming visitors and spreading. Isolate the account if your host allows.
2. Preserve evidence. Before deleting anything, take a copy/snapshot of the files and database and save the logs — you will need them to find how the attacker got in.
3. Change every credential. Hosting control panel, CMS admin accounts, database, FTP/SSH keys and any API keys. Assume all secrets are exposed, and do this from a clean device.
4. Restore from a known-good backup taken before the infection, if you have one — usually the cleanest route back.
5. Remove the malware and close the entry point. Strip out injected code, backdoors, web shells, rogue admin users and unfamiliar cron jobs, and patch the actual vulnerability — most often an outdated CMS, theme or plugin, or a weak/reused password. If you skip this, you will simply be re-infected.
6. Scan again to confirm clean — both server-side and with the external scanners above — before bringing the site back.
7. Request a review. Clearing the malware does not automatically lift the warnings. Use Google Search Console's Security Issues report to request a review; Google re-scans and removes the "hacked"/"deceptive" label once the site is clean (this can take from a day to longer). For other blocklists (such as those VirusTotal aggregates), submit a re-scan or removal request to each provider.
8. Monitor closely for re-infection over the following weeks, watching files, accounts, logs and search listings.

If the site is business-critical or the infection is stubborn, a professional incident-response or site-cleanup service is money well spent — specialists do this daily and will be faster and more thorough. And once recovered, treat it as a prompt to prevent the next one: patch relentlessly, enforce strong authentication with MFA, and keep tested off-site backups, as set out in how to protect your website from common attacks.

How to request a malware-warning review (the right order)

A frequent and costly mistake is requesting a review before the site is actually clean. The review will fail, and repeated failed reviews can prolong the warning. The correct order is always:

1. Clean the site completely (malware removed, backdoors gone).
2. Patch the entry point so it cannot recur.
3. Verify clean with server-side and external scans.
4. Then request the review in Search Console and submit re-scans to other blocklists.
5. Keep monitoring, because a re-infection restarts the entire process.

Patience here pays: a clean, patched site sails through review, while a rushed request on a still-infected site digs the hole deeper.

A quick malware-check checklist

• Run the URL through Google Safe Browsing, Sucuri SiteCheck, VirusTotal and urlscan.io, and compare results.
• Search site:yourdomain.com and skim for spam pages or foreign keywords.
• Open the site in a private window and as a search bot to reveal hidden redirects and cloaked content.
• For a site you own: compare files against known-good versions and hunt for unfamiliar or recently-modified files.
• Review admin users and scheduled tasks for anything you did not create.
• Run a server-side scan and review access logs for the entry point.
• If infected, follow the response steps in order, then request reviews once genuinely clean.

Go deeper

• The symptom-side companion: how to tell if a website has been hacked.
• Judge a site before you trust it: is this website safe?
• Prevent infection in the first place: how to protect your website from common attacks.
• Read the raw server response: how to read a website's HTTP headers.

Want a fast external read on a site's headers, technology and configuration alongside its safety signals? Analyse any URL with StackOptic — free, no sign-up.