Short answer: Google detected content or behaviour consistent with a compromise and is warning searchers before they click. The label disappears only after the underlying problem is genuinely resolved and Google re-evaluates the site — usually within days of a clean review.
Why it is commercially urgent
Unlike a broken page, this failure is visible in the search results themselves. Your listing still ranks, but with a warning attached, so click-through collapses. Every day it stays visible costs traffic you already earned.
First steps, in order
- Open Search Console › Security Issues. It states the category — malware, spam URLs, deceptive content — and gives example URLs.
- Inspect those URLs with “Test live URL”, not your browser, since payloads are conditional.
- Back up the current (compromised) state as evidence before changing anything.
- Tell your host, especially if other sites share the account.
What actually removes the warning
Cleaning the visible spam is not enough — Google re-checks. The cleanup must cover the payload, the persistence and the entry point: reinstall core and plugins from clean sources, grep for obfuscated code, audit wp_users, wp_options and the cron array, update the vulnerable component and rotate all credentials. Submitting a reconsideration request while a backdoor is still active makes the warning return, and repeated failed reviews slow the next one.
After the review
Once it clears, keep watching indexed pages and Search Console for several weeks. Confirm your backups now predate the reinfection rather than containing it, and that the exploited component is patched.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
A search warning is the public consequence of a security finding. Recovery requires cleaning the site, closing the entry point and giving Google a consistently clean result to re-evaluate.
- 1
Read the exact Security Issues category and sample URLs in Search Console.
- 2
Preserve the compromised state and server logs before cleanup.
- 3
Inspect samples as Google sees them and map payload, persistence and entry point.
- 4
Only request review after clean verification across representative routes and shared hosting neighbours.
What must be verified
- Search Console reports no active security issue.
- Sample and random URLs show clean content to live inspection.
- Monitoring detects no reinfection or return of spam pages.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
How long does the 'This site may be hacked' warning usually stay after I fix the problem?+
It typically clears within days of a clean review, once Google re-evaluates the site and confirms the underlying issue is genuinely resolved. Cleaning the visible symptoms alone doesn't trigger removal automatically — the site needs to actually pass re-inspection.
Should I submit a reconsideration request as soon as I've removed the spam content I found?+
Not yet. If a backdoor or the original entry point is still active, the warning simply returns after review, and repeated failed requests slow down your next one. The cleanup needs to cover the payload, the persistence mechanism, and the entry point before you request review.
Does my site still show up in Google search results while this warning is active?+
Yes, the listing still ranks, but with a warning attached that collapses click-through, since this failure is visible directly in the search results rather than only on your own site. That's what makes it commercially urgent compared to an outage only your visitors would notice.
Where do I actually find out what triggered the warning instead of guessing?+
Open Search Console under Security Issues — it states the specific category, such as malware, spam URLs, or deceptive content, and gives example URLs. Inspect those exact URLs using the 'Test live URL' feature rather than your own browser, since the malicious payload is often served conditionally.