June 22, 2026

How to get Google's "Deceptive Site" warning removed: a step-by-step guide

You opened your website this morning and instead of your homepage, visitors see a full-screen red warning telling them your site is dangerous. Phones aren't ringing. Sales stopped. You have no idea what happened or how to fix it.

This guide walks you through the actual process — what to do first, what not to do, and the mistakes that drag a 3-day cleanup into a 3-week nightmare.

What the warning actually means

Google Safe Browsing is the system behind that red interstitial. Chrome, Firefox, and Safari all use it. When it flags your site, every major browser starts blocking access. Search results show "This site may be hacked" next to your listing. Email links to your domain get filtered. The damage compounds by the hour.

There are a few specific reasons Google flags a site:

Malware: your site is serving malicious code to visitors — usually JavaScript that redirects them, steals form data, or tries to install something on their machine.
Phishing: someone planted a fake login page on your domain (Microsoft 365, banking, PayPal clones are common).
Deceptive content: fake "your computer is infected" popups, tech support scams, fake giveaways.
Social engineering: tricking visitors into doing something harmful — downloading a file, calling a number, entering credentials.
Unwanted software: your site is pushing browser extensions or downloads that misbehave.

The flag isn't an accusation that you did something wrong. In almost every SMB case I see, the owner had no idea anything was happening. An attacker exploited a vulnerable plugin, an outdated theme, or a compromised admin password and used the site as a vehicle to attack visitors.

Step 1: Don't panic-delete anything

This is the single biggest mistake I see. Owner sees the red warning, logs into their host's file manager, finds a weird-looking PHP file in /wp-content/uploads/, and deletes it. Then deletes another. Then disables a plugin. Then changes the admin password.

By the time I get the call, the evidence is gone, the attacker's entry point is unknown, and the backdoor is still there — just somewhere else.

Here's why this fails:

You don't know what the malware is doing yet. Some infections have self-healing components. Delete one file, another rewrites it on the next page load. I cleaned a contractor's WordPress site in Southern California where a previous "fix" by another vendor had touched dozens of files but missed the actual persistence mechanism — every removal just triggered the backdoor to re-deploy. The site got re-flagged twice before they called me.
You destroy the forensic trail. File timestamps, modified-date patterns, and access logs are how you figure out how the attacker got in. Without that, you'll harden the wrong things and get hit again.
Google won't lift the flag if the root cause is still there. Their scanners will revisit, find the same malicious behavior or its remnants, and the warning stays up — or comes back within days.

What to do instead: take a snapshot. Most hosts have a one-click backup. Download a full copy of the site files and database before you change anything. Yes, the backup contains the malware. That's the point. You need it for diagnosis.

Step 2: Confirm what Google actually flagged

Log into Google Search Console. If you don't have it set up, this is the moment to do that — verify your domain, then look at the Security Issues report in the left sidebar.

Google will tell you:

The category (malware, social engineering, etc.)
Example URLs where they detected the problem
Sometimes a sample of the malicious code or behavior

Write this down. Screenshot it. Those example URLs are your starting point — they tell you which directories or pages the attacker is using.

Also check VirusTotal (paste your URL in) and Sucuri SiteCheck (free scanner). These give you a second opinion and often catch things Google's summary skips, like specific malware family names or injected domains.

Step 3: Find the root cause before you start cleaning

The instinct is to start cleaning files. Resist it for another hour. You need to know how the attacker got in, because if you don't fix that, you're cleaning the same site again next week.

Common entry points for WordPress sites (which is what 80% of these flagged-site calls turn out to be):

Vulnerable plugin or theme — especially anything nulled, abandoned, or not updated in 6+ months
Outdated WordPress core
Weak or reused admin password (often exposed in a credential dump)
No 2FA on admin accounts
Compromised hosting account (cPanel, FTP) — sometimes the WordPress install is fine and the attacker had server-level access
Stolen API keys or webhook URLs in committed code

Pull your access logs from the host. Look for:

POST requests to xmlrpc.php or wp-login.php at unusual times
Repeated 200 responses to obscure PHP files in /uploads/ or /cache/
Admin actions from IPs that don't match your normal locations
File modifications in core WordPress directories (wp-includes/, wp-admin/) — those should almost never change

If you can correlate a file modification time with a suspicious log entry, you've found your entry point.

Step 4: Eradicate persistence

Persistence is the attacker's insurance policy. They don't just drop one malicious file — they drop several, in different formats, in different locations, so that cleaning one doesn't kill the infection.

Typical persistence I find on flagged WordPress sites:

Backdoor PHP files in /wp-content/uploads/ (often disguised as images: logo.php.jpg.php or similar)
Modified wp-config.php with extra includes pointing to malicious files
Injected code at the top of legitimate plugin files
Rogue admin users created by the attacker
Scheduled tasks (WP-Cron entries) that re-inject the malware on a timer
Database-stored malicious code in wp_options (look for _transient_ entries with base64 blobs)
Modified .htaccess redirecting some traffic to malicious sites

A real cleanup means:

Replace WordPress core files with fresh copies from wordpress.org
Reinstall every plugin and theme from official sources (don't trust the existing files)
Diff your wp-config.php against a clean template
Audit every admin user — delete anything you don't recognize
Clear WP-Cron of unfamiliar scheduled tasks
Search the database for base64-encoded content, suspicious eval() calls, and unfamiliar URLs in wp_options
Reset all passwords — admin users, database, FTP/SSH, hosting control panel

The contractor site I mentioned earlier had 115+ spam blog posts injected into the database in addition to the file-level backdoor. Those weren't visible on the front-end menu, but Google's crawler found them, and they were the trigger for the flag. Database cleanup is not optional.

Step 5: Harden before you ask for a review

This is where most people get impatient and submit the review request too early. Google's reviewers (or rather, their automated re-scanners) will check the site. If they find any residual indicator, the flag stays — and the clock resets.

Before submitting, do these:

Update WordPress core, all plugins, all themes
Remove any plugin or theme you're not actively using
Install a security plugin (Wordfence and Sucuri both have free tiers that work well)
Enable 2FA on every admin account
Add file integrity monitoring
Restrict access to wp-admin and wp-login.php by IP if possible, or at minimum add a rate limit
Disable file editing in the WordPress dashboard:

// Add to wp-config.php
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);

Lock down .htaccess for the uploads directory to block PHP execution:

# /wp-content/uploads/.htaccess
<Files *.php>
deny from all
</Files>

Verify your site is clean with a fresh scan (Sucuri SiteCheck, VirusTotal, and a logged-in scan with Wordfence)

Only when all of that is done do you move to the review step.

Step 6: Submit the review request

In Google Search Console, go back to the Security Issues report. There's a "Request Review" button.

When you click it, Google asks you to describe what you did to fix the problem. Be specific. Vague answers ("I cleaned the malware") get slower reviews and more rejections. A good description looks like:

Identified entry point as an outdated [plugin name] (CVE-XXXX-XXXXX). Removed the plugin entirely. Restored all WordPress core files from clean copies. Reinstalled all remaining plugins and themes from official sources. Audited and removed 3 unauthorized admin users. Cleaned 115 spam posts injected into the database. Reset all admin passwords and enabled 2FA. Implemented file integrity monitoring and PHP execution blocks in /wp-content/uploads/. Confirmed clean via Wordfence, Sucuri SiteCheck, and VirusTotal scans.

Submit it. Then wait.

Google's timeline and the clock-reset mistake

Google's stated turnaround is 1 to 3 business days for most reviews. In my experience that's accurate for a clean site. Phishing reviews can be faster (sometimes under 24 hours); complex malware cases sometimes take longer.

The thing nobody tells you: if you submit a review request before the site is actually clean, and Google's re-scan finds anything, the clock resets. You don't get a partial credit. You go to the back of the queue. I've seen owners submit three review requests in a week, frustrated that nothing's happening, and the actual problem is that there's still a backdoor on the site re-injecting malware between submissions.

Submit once. Submit when you're done. Not before.

What happens after approval

When Google clears the flag, the red warning disappears within hours across Chrome, Firefox, and Safari. The "This site may be hacked" label in search results takes a few days to clear as Google re-crawls. Your traffic should recover within a week or two for direct/branded traffic; SEO recovery from any ranking dip can take longer depending on how long the flag was up.

A few things to do in the days after:

Keep monitoring. Reinfection within 30 days is common if the root cause wasn't truly fixed.
Check your email deliverability — some inbox providers temporarily flagged your domain too, and you may need to warm it back up.
If you collect customer data, think carefully about disclosure obligations. Depending on what was exposed and your state/industry, you may have a legal duty to notify customers.

When to call someone

Honest answer: if you're comfortable in a terminal, reading PHP, and reading server logs, you can do most of this yourself. If "log into cPanel" is already stretching your comfort zone, you're going to spend 40 hours doing what a specialist does in 4, and you'll probably miss the persistence mechanism on the first pass.

Every day the warning is up is a day of lost sales and lost trust. If your business depends on the site, the math usually favors getting help fast.

If your site is currently flagged and you'd rather not learn forensic malware analysis this week, that's what the Malware Removal & Incident Response service is for — root-cause diagnosis, full cleanup, hardening, and the review submission, handled end to end. You can read the full case study of the Southern California contractor cleanup, or reach out directly and we'll triage it today.