Fix Chrome's "Deceptive Site Ahead" Warning

Originally published on the Bug Circuit blog.

The red "Deceptive site ahead" screen means Google's Safe Browsing system found phishing or social-engineering content on your site — you fix it by removing that content and then filing a review request in Google Search Console.

This is for site owners who've just seen the full-page red Chrome warning (not the small gray "Not Secure" label in the address bar, and not Search Console's "This site may be hacked" message — those are different problems). You'll get: exactly what triggers this specific warning, how it differs from the other two, and the step-by-step review-request process to get it lifted — including what to check first if you run WordPress.

What "Deceptive site ahead" actually means

This warning comes from Google Safe Browsing, a service Chrome (and Firefox, and Safari) checks against before loading a page. It isn't one generic "your site is bad" flag — Safe Browsing has separate categories, and each produces a different warning screen:

• "Deceptive site ahead" — social engineering content: phishing pages, fake login forms, deceptive download buttons, scareware popups
• "The site ahead contains malware" — the site tries to install malicious software on visitors' devices
• "This site is dangerous" — a general catch-all Chrome uses when multiple threat types are detected

Google's own definition of social engineering content is content that "tricks users into doing something dangerous... such as revealing confidential information or downloading software" — for example a page that impersonates a bank, Google, or Microsoft login, or a popup that claims the visitor's device is infected. See Google's social engineering (phishing) content policy for the exact criteria. This is the same category OWASP describes as phishing: tricking a user into handing over credentials or money by impersonating something trustworthy.

Importantly, this often isn't content you put there. It's usually a symptom of a hack: an attacker planted a phishing page or malicious redirect somewhere on your site, and Safe Browsing's crawlers found it.

How this differs from "Not Secure" and "This site may be hacked"

These three warnings look similar but come from completely different systems, and mixing them up leads to the wrong fix.

Fixing a "Not Secure" label means installing or fixing an SSL/TLS certificate — it says nothing about malicious content. Fixing "This site may be hacked" means cleaning spam/injected code Googlebot found in your indexed pages. "Deceptive site ahead" is the most urgent of the three because it actively blocks visitors from reaching your site at all, and it's specifically about content designed to deceive, not just insecure or spammy content. If you're unsure which category your problem falls into, our guide to whether your site is hackable walks through the warning signs for each.

What actually triggers this warning

The content Safe Browsing looks for typically falls into one of these patterns:

• A fake login page planted somewhere on your domain (often in an unused subfolder) mimicking PayPal, Microsoft 365, a bank, or a crypto wallet
• Deceptive popups or overlays — fake "your device is infected" alerts, fake browser update prompts, or "you've won a prize" popups, often injected via a compromised ad network or a malicious script
• Cloaked redirects — a script that sends normal visitors to your real site but redirects search engines or specific referrers to a phishing page, making the problem harder to spot
• A hacked plugin or theme on WordPress, Shopify apps, or similar CMS platforms that silently drops phishing files into an uploads or cache directory
• A compromised third-party embed — an ad unit, widget, or iframe you didn't author, serving deceptive content you don't directly control but that still lives on your page

For a WordPress site specifically, the usual entry point is an outdated plugin or theme with a known vulnerability, a weak admin password, or a leftover admin account nobody remembers creating. If you want a fuller picture of how sites get compromised in the first place, see our guide on what to do when your website is hacked.

Step-by-step: fix it and request removal

1. Confirm what Google found. Go to Search Console's Security Issues report, or check your domain directly with the Safe Browsing site status tool — it will tell you the flagged pages and the date detected.
2. Take the site into maintenance mode if you can, so no visitors hit the deceptive content while you work. This isn't required, but it limits harm and buys you time.
3. Find and remove the malicious content. Check recently modified files (find /path/to/site -mtime -14 -type f on a Linux host is a good start), unfamiliar folders under wp-content/uploads, unexpected .htaccess redirect rules, and any admin users or plugins you don't recognize.
4. Close the entry point. Update WordPress core, every plugin, and every theme. Change all passwords — WP admin, hosting control panel, SFTP/FTP, and database. Remove any admin account you didn't create. If you use WordPress security salts, regenerate them via wp-config.php.
5. Rescan to confirm it's clean. Run the site through the Safe Browsing site status tool again, plus an independent scanner like Sucuri SiteCheck, before you submit anything to Google.
6. Request a review. In Search Console, open the Security Issues report for your verified property and click "Request Review." Briefly describe what was wrong and what you did to fix it — Google's own request-a-review guide covers the exact form fields.
7. Wait it out. Reviews commonly clear within a day or two once the site is genuinely clean, though Google doesn't publish a fixed turnaround time — resist the urge to resubmit repeatedly, which can slow things down rather than speed them up.

Before you hit submit: a quick checklist

• [ ] Your domain is verified in Search Console (Domain or URL-prefix property)
• [ ] The specific flagged pages/files are gone, not just hidden
• [ ] All passwords (WP admin, hosting, FTP, database) have been changed
• [ ] Core, plugins, and themes are fully updated
• [ ] A fresh scan (Safe Browsing status + a second scanner) comes back clean
• [ ] You've noted what caused it, so it doesn't happen again

Skipping any of these is the most common reason a review request gets rejected and the warning reappears a few days later.

Preventing a repeat

Once you're clean, a few habits make this much less likely to happen again:

• Keep plugins/themes updated and delete ones you're not actively using — each one is a potential entry point
• Turn on strong security headers (our security headers checker shows what's missing on your site)
• Use a web application firewall (Wordfence, Sucuri, or Cloudflare's proxy) to block common exploit attempts before they reach your code
• Require two-factor authentication for every admin account
• Run periodic malware scans rather than waiting for Google to tell you something's wrong

A free automated scanner catches known signatures, but the phishing pages and cloaked redirects that trigger Safe Browsing are often hand-placed by an attacker specifically to avoid detection — which is exactly the kind of thing a manual review is built to catch that an automated pass misses. If you want a second set of eyes, our free website security check gives you a fast yes/no read on whether anything critical is currently exposed, no card or login required.

Key takeaways

• "Deceptive site ahead" is a Google Safe Browsing flag for phishing/social-engineering content — different from the address-bar "Not Secure" label (HTTPS issue) and Search Console's "This site may be hacked" (indexed spam)
• The usual cause is a hacked plugin, theme, or third-party embed that planted a fake login page, deceptive popup, or cloaked redirect
• Fix the content, patch the entry point, and rotate every credential before you request review — partial fixes are the top reason review requests fail
• Submit the review through Search Console's Security Issues report; don't resubmit repeatedly while waiting
• Add ongoing scanning and a WAF afterward so the same hole doesn't get exploited again

If you'd rather have a human confirm the site is actually clean before you file the review — or trace exactly how the attacker got in — a Bug Circuit manual audit starts at $49: a real engineer checks the whole site and hands you a written report with evidence and exact fixes, not just a scanner printout.