The site ahead contains malware critical
Chrome "The site ahead contains malware" warning
Google Safe Browsing flagged the site as hosting or pushing malware, so Chrome throws a red full-page block before it loads.
What you see
The site ahead contains malware Attackers currently on example.com might attempt to install dangerous programs on your computer that steal or delete your information (for example, photos, passwords, messages, and credit cards). Back to safety
What’s actually happening
The whole viewport goes red and Chrome refuses to render the page — visitors get the interstitial, not your site. A "Details" link expands to a small "visit this unsafe site" link, but almost nobody clicks through. Firefox and Safari usually show their own block at the same time since they pull the same Safe Browsing list. Organic traffic falls off a cliff within hours of the flag landing.
Common causes
- The site was hacked and someone injected malicious JS — commonly a script tag or eval() blob appended to footer.php, header.php, or every .js file
- A compromised plugin/theme or an outdated CMS core serving a drive-by download or a redirect to an exploit kit
- Malvertising: a third-party ad or affiliate script on the page pulls a malicious payload that Google's crawler saw
- Malware sitting in /wp-content/uploads or a fake .php file dropped by an attacker (often base64-encoded)
- A shared host or sketchy ad network where another site on the same IP got flagged and the range got caught
How to fix it
- Confirm the verdict in Search ConsoleOpen Google Search Console → Security & Manual Actions → Security Issues. It names the category (malware/unwanted software) and lists sample infected URLs. No GSC property yet? Verify the domain first — you can't request a review without it. Also paste the URL into transparencyreport.google.com/safe-browsing/search to see Google's status.
- Find and remove the injected codeScan the filesystem, not just the rendered page. SSH in and grep for the usual signatures: grep -rl 'eval(base64_decode' /var/www, grep -rn 'document.write(unescape' . Diff core files against a clean copy (wp core verify-checksums for WordPress). Check recently modified files: find . -name '*.php' -mtime -14. Inspect .htaccess for injected redirects and the database (wp_options, wp_posts) for stored script tags.
- Close the hole that let them inRemoving the payload without patching the entry point gets you reinfected within days. Update CMS core, every plugin/theme, and PHP. Rotate all passwords (admin, DB, FTP/SFTP, hosting panel) and delete unknown admin users. Pull access logs and look for the POST that dropped the file so you know which vuln to close.
- Request a reviewBack in Search Console Security Issues, after the site is clean, click "Request Review," describe what you removed and how you patched it. Malware reviews typically clear in roughly a day; vague or premature requests get rejected and reset the clock. The red screen disappears once Google reverifies and Chrome syncs the updated list.
- Re-scan to confirm it's actually goneRun an external scanner (Sucuri SiteCheck, VirusTotal URL scan) and an authenticated server-side scan. Reinfection usually means a backdoor you missed — a second dropper or a cron job. Don't request the review until both come back clean.
Stop it recurring
Keep CMS/plugins/PHP patched, run a server-side malware scanner on a schedule, and put the site behind a WAF so injection attempts get blocked before they write a file.
Related errors