Remove Google's 'Site May Be Hacked' Warning (Walkthrough)

Before submitting a review, confirm the warning is still showing and identify which type. Google uses several distinct flags and the recovery procedure differs slightly for each.

Open Google's Transparency Report in a new tab — search for "Google Safe Browsing site status," enter your domain, and read the current status. The report tells you exactly when Google last checked the site and what it found. The four common verdicts: "Some pages on this website install malware" (you have malware), "This site has been hacked to install harmful software" (compromised host), "Deceptive content" (phishing pages), or the green "No unsafe content found" (the warning is gone — you don't need to do anything).

Cross-check in Google Search Console. Property → Security & Manual Actions → Security Issues. If Search Console shows no issues but Safe Browsing still flags the site, the issue is between Google's caches — usually resolves on its own within 24–48 hours, no action needed. If Search Console shows issues that match the Safe Browsing flag, those are what you'll address in the review request.

Note the exact URLs Google lists. Search Console shows specific affected pages under each issue. You'll reference these in your review request — Google wants evidence you addressed the specific pages, not just a generic "I cleaned the site."

If you don't have Search Console set up yet, this is the moment. The verification step (DNS TXT record or HTML file upload) takes 10 minutes and you can't submit a review request without it.

Submitting a review request before the site is genuinely clean wastes one of your three quick reviews — Google starts adding cooldown periods after rejections, and the third rejected review can lock you out of further submissions for 30 days. Don't rush.

Check 1 — re-scan with a security scanner. Run the GuardingWP free scan against your domain. It checks the 11 most common WordPress vulnerabilities — if any flag, address them before submitting. Then run Sucuri's free SiteCheck for an external second opinion: it checks blocklist status across multiple databases and looks for visible defacement.

Check 2 — find what the file-level cleanup missed. The post-cleanup forensics walkthrough lists the exact commands to surface dormant backdoors that don't show up in normal scans — modified-time anomalies, hidden cron jobs, suspect uploads with PHP execution rights. Run all of them, even the paranoid-feeling ones. A single missed backdoor lets attackers re-infect within hours of the warning being lifted, and Google's repeat-offender threshold is harsher than first-flag.

Check 3 — database malware. The fileside scanner won't catch injected post content, planted admin users, or tampered `wp_options` rows. The database-malware detection guide covers the queries to run.

If all three checks come back clean, you're ready to submit. If any of them flag something, do the cleanup pass first and re-check. The cleanup walkthrough has the full sequence.

Open Google Search Console. Select your property (the affected domain). Left sidebar → Security & Manual Actions → Security Issues.

On the Security Issues page, the issue Google detected is listed with a short description and the affected URLs. Click "Request Review" — it's a button on the right side of each issue. If the button is grayed out or missing, it usually means Google hasn't re-confirmed the issue recently — wait 24 hours and check again, or click "I have fixed these issues" if that option is shown.

Google opens a text-area for the review request. This is where most people fail. The request needs three specific elements, in this order:

Element 1 — exactly what was wrong. Specific. "Malware was injected into wp-content/themes/twentytwentyfour/functions.php starting on 2026-04-22, redirecting traffic to a phishing domain." Not "my site got hacked." Google's reviewer is looking for evidence you understood the actual problem.

Element 2 — exactly what you did to fix it. List the specific actions: which files you removed or replaced, which database rows you cleaned, which plugins you updated or removed, what you changed in the configuration. "I replaced WordPress core, removed the modified theme files, deleted three planted admin users from the database, updated WP-Members from 2.4.1 to 2.4.7 (the entry-point CVE), and rotated all admin passwords." Concrete actions, not generic categories.

Element 3 — what you did to prevent recurrence. "I enabled two-factor authentication on all admin accounts, blocked XML-RPC, set up weekly automated vulnerability scans." Show that you fixed the *cause*, not just the symptom. Google rejects reviews where the site is clean today but the underlying vulnerability is still open — they expect you'll be re-infected and don't want to flag-then-unflag-then-flag-again.

Submit. Google sends a confirmation email to the address on the Search Console account. Save the timestamp.

Google's processing time is 1–3 days for first-time reviews on most issue types, up to a week for repeat reviews or complex cases. The review involves both an automated re-crawl of the affected URLs and (sometimes) a human reviewer for borderline cases.

The warning won't disappear instantly when Google approves the review — it disappears when Google's Safe Browsing cache updates, which is usually within hours of approval but can take up to 24 hours. Different browsers also pull from the cache at different rates: Chrome updates fastest (uses Safe Browsing API directly); Firefox and Safari can lag a few extra hours.

While you wait: don't change anything material on the site. Don't redeploy theme or plugin updates, don't add new content. Google will recrawl and any code-level change can re-trigger detection. You can keep the site live and accepting traffic — the warning will be in front of visitors during this period, which is unavoidable.

Search Console will show the issue status as "Pending review" while Google processes. Refresh once a day, no more — there's no benefit to checking obsessively.

When the review completes, Search Console updates the issue status ("Reviewed: passed" or "Reviewed: failed") and sends an email. If passed, the warning lifts on Google's cache schedule. If failed, see §6 below.

Search traffic recovery is not instant, but it's faster than people expect — most sites see 70–90% of pre-flag traffic within 2–4 weeks once the warning is lifted. Heavily affected sites (where Google removed many URLs from the index) can take longer.

Two things to do immediately after the warning lifts: first, check Search Console's Coverage report — see if any URLs were removed from the index. If yes, request re-indexing for the most important ones (homepage, top revenue pages). Second, scan the site once more, ideally with a different scanner than the one you used pre-submission, to catch anything that crept back in.

Set up monitoring for the next 30 days, more closely than usual. Re-flag risk is highest in the first month after a clean — attackers who exploited the same vulnerability are still trying. Weekly automated scans catch new vulnerabilities in your plugins as they're disclosed (which is the most common cause of repeat infections — a CVE drops on a plugin you have installed, gets exploited within hours). GuardingWP Pro does this; comparable Wordfence and Sucuri tiers do too.

Update Search Console's notification settings if you haven't: Property → Settings → Users and Permissions → make sure your email gets all property notifications, not just owner-only. Future Safe Browsing alerts arrive 24–72 hours faster this way than discovering the warning yourself.

Rejected reviews are common — about 30% of first reviews on serious malware cases come back failed. Don't panic, don't immediately resubmit. Each rejection adds friction to the next submission and after three failures you may hit a 30-day cooldown.

Read Google's rejection email carefully. It almost always names the specific reason: malware still detected on a specific URL, a different malware pattern appeared after submission, the underlying vulnerability is still open and Google's reviewer found a re-infection during the review window. Address that specific finding before resubmitting.

Common rejection reasons and the fix:

Reason 1 — "We still detect malicious content." Google's automated re-crawl found something. Re-run the file scan and database scan, focusing on the URLs Google named in the email. The post-cleanup forensics walkthrough is built for exactly this scenario.

Reason 2 — "New issues detected during review." The site got re-infected between your cleanup and Google's check. The entry point is still open. Run a vulnerability scan, identify the open door, close it, and full re-scan before resubmitting.

Reason 3 — "Issue persists at [URL]." Google found the same content at the same URL it flagged before. The cleanup didn't actually remove it — possibly cached, possibly served from a CDN that wasn't purged, possibly persisted by an injected scheduled task. Purge all caches (server-side, CDN, browser-level proxies), check for persistence mechanisms, then re-submit.

If after two rejections you genuinely can't identify what Google sees that you don't, that's the threshold for professional cleanup. The Forensic Toolkit covers the deep diagnostic queries that find dormant artifacts; the Fix service handles the cleanup outright. Don't keep hammering the review submission button — every failed review extends the warning window.