Google marks a site "harmful" or "deceptive" when Safe Browsing finds malware, phishing content, or unwanted software on it. This is different from a plain "Not Secure" warning, which means you're missing HTTPS. A Safe Browsing flag means Google's scanners found something actively bad on your pages, and the fix is to clean the infection first, then ask Google to review it.
Don't confuse the two. If your browser bar just shows "Not Secure" with no red interstitial page, that's an SSL problem, not a malware flag. See My site shows a security warning for how to tell them apart and fix the SSL case. This article is for the red "Deceptive site ahead" or "This site may harm your computer" pages.
Confirm what Google actually flagged
Go to Google Search Console and check Security Issues under the Security & Manual Actions section. If your site is registered there, it will list the specific problem: malware, deceptive pages, harmful downloads, or uploaded resources. If you don't have Search Console set up for the domain yet, add and verify it now. You'll need it anyway to request the review later.
You can also check status directly in Google's Transparency Report by entering your domain. It shows whether Google currently considers the site unsafe and roughly when it was last flagged.
Clean the infection
Almost every Safe Browsing flag traces back to a compromised site serving injected content: hidden scripts, phishing pages planted in a subdirectory, or malicious redirects. Treat this as a hack cleanup, not a false positive, until you've verified the files.
Run a full scan. Full walkthrough in Scanning your website for malware, including WordPress-specific scanners like Wordfence if that's your CMS.
For each infected file, you generally have three options: let the scanner clean it in place, delete it outright, or restore from a backup taken before the infection. If you're not sure how far back the infection goes, restoring a known-clean backup is usually faster and safer than trying to hand-pick every injected line. Once you've identified a clean restore point, replace the compromised files rather than patching around them.
After cleaning, check for the things scanners sometimes miss:
- New admin users or FTP accounts you didn't create
- Scheduled tasks (cron jobs) that weren't there before
- A
.htaccessfile with unfamiliar rewrite rules, especially ones that redirect only search engine crawlers - Unfamiliar files in your uploads or media directories with executable extensions
Change every credential
If your site was compromised, assume the attacker had access to more than the files. Change your hosting account password, your CMS admin passwords, database passwords, and FTP passwords. If you reused any of those passwords elsewhere, change those too. This step is easy to skip when you're in a hurry to get the flag removed, but skipping it is how sites get reinfected within days of being cleared.
Update everything before you ask for review
Most infections come in through an outdated plugin, theme, or CMS core, not through your hosting account itself. Before requesting review, update WordPress core, every plugin, and every theme to current versions. Remove anything inactive that you don't use: unused plugins and themes are a common reinfection vector even when disabled.
If you're not sure what caused the initial infection, check the error and access logs from around when it started. See Enabling error logging for where those logs live and how to read them. A sudden spike in requests to an unfamiliar file, or repeated POST requests to a plugin's endpoint right before the infection appeared, is usually the entry point.
Request the review
Once the site is clean and hardened, go back to Search Console → Security Issues and click Request a review. Describe briefly what was wrong and what you did to fix it: which files were removed, what you updated, what credentials were rotated. Google's automated systems re-crawl the site as part of the review, so the infection needs to be gone before you submit, not only addressed on your end.
Don't resubmit repeatedly while waiting; if it's rejected, the response will usually tell you what's still flagged.
Prevent it happening again
Once you're clear, keep it that way:
- Turn on automatic updates for your CMS core and plugins where the software supports it
- Remove unused plugins, themes, and old installs instead of leaving them dormant
- Use unique, strong passwords for every admin and database account
- Keep a recent backup on hand so a future infection is a quick restore, not a rebuild
When to contact support
If you can't identify the infected files, if the scan comes back clean but Google still shows the warning, or if the same files keep reappearing after you remove them, open a ticket from the portal. A Support PIN may be required for account-sensitive requests.