Rewrite rules
A .htaccess rule that sends unknown paths or search-referred visitors to a generator script. See how to read malicious rewrite rules in the .htaccess guide.
Guide · Google search label
“This site may be hacked” under your Google result means Google found content you did not publish.
A line of grey text under your search listing is warning everyone who searches for you. Clicking through still opens your site — there is no red interstitial — but fewer people click, and the label stays until Google is satisfied the hacked content is gone. It is removed by finding what Google saw, cleaning the cause, and then asking for a review, in that order.
Published Last reviewed
- Where it shows
- Beneath your listing in Google search results
- Usual cause
- Spam pages, injected links, or altered content added by a third party
- Who decides
- Google Search — separate from the Safe Browsing browser warning
- Removal path
- Verified cleanup, then a review request in Search Console
What the label means
A search label, not a browser block
Google adds “This site may be hacked” to a result when it believes a third party has changed pages on the site or added new ones — typically spam pages for pharmacy, casino or counterfeit goods, URLs injected into the site under its own domain, or outbound spam links hidden in otherwise normal pages. The label is about what Google indexed, and it is shown to people searching, not to people already on your site.
That is the difference from the full-page “Deceptive site ahead” warning. That one comes from Google Safe Browsing, appears in the browser itself, and blocks visitors in Chrome, Firefox, Safari and other browsers before the page loads. A site can carry one without the other, or both at once, and each is cleared through its own review.
The content behind the label is very often cloaked: served to Googlebot and to visitors arriving from search, and hidden from the owner who types the address directly or is logged in. Seeing nothing wrong when you open the site is normal for this class of infection and is not evidence that the label is a mistake.
Figure 1 · Four Google warnings compared
Four different warnings, four different audiences — and one thing that clears each of them.
| Warning | Where it appears | Who sees it | What clears it |
|---|---|---|---|
| “This site may be hacked” | Under the search result | Searchers on Google | Cleanup, then a review |
| “Deceptive site ahead” | Full-page browser warning | Every visitor in most browsers | Cleanup, then a review |
| Security Issues entry | Search Console only | Verified owners | Cleanup, then a review |
| Ads “Compromised site” | Ads policy status | The advertiser | Clean site, then an appeal |
Find what Google saw
Start from Search Console, then confirm from outside
Every check here reads; none of them changes the site. Write down what you find — it becomes the evidence trail and, later, the content of the review request.
- 01
Open the Security Issues report
If Search Console lists a hacked-content issue for the property, it names the type — URL injection, content injection or code injection — and often gives sample URLs. Those samples are the most direct evidence you will get of what Google indexed.
No property yet? Verify the domain first; the review request can only be sent from Search Console.
- 02
Search the index for pages you never published
A site: search shows what Google holds for the domain. Add the words spam usually carries — product names, gambling or adult terms, Japanese characters — and look for titles and paths that are not yours.
- 03
See the page as Google sees it
URL Inspection’s live test fetches a sample URL as Googlebot and shows the HTML it received. Compare that with what your own browser receives; injected links or a different page entirely is cloaking.
- 04
Compare a crawler request with a normal one
From a shell, fetch the same URL with Googlebot’s user agent and then a desktop one, and compare the two hashes. A difference means the site answers crawlers differently:
curl -s -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' https://example.com/ | sha256sum curl -s -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)' https://example.com/ | sha256sumIdentical hashes do not clear the site: some cloaking checks Google’s IP ranges rather than the user agent, which only the URL Inspection live test reproduces. Dynamic pages can also differ for innocent reasons, so read the two responses before drawing conclusions.
- 05
Look for the spam URLs in your own logs
The access log shows which unfamiliar paths crawlers have been requesting and whether the site answered them with content:
grep -i 'googlebot' /path/to/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head -50A long tail of 200 responses for paths that do not exist in WordPress — numbered pages, keyword slugs, .html files — is the generated spam.
Where it usually lives
The flagged URLs are output; the generator is elsewhere
Spam pages under your domain are rarely static files you can simply delete. Something on the site produces them on request, decides who sees them, and often recreates them after removal.
Core and theme includes
An include or require added to index.php, wp-blog-header.php or a theme file that loads the spam engine before WordPress renders the page.
The database
Autoloaded options holding encoded payloads, or thousands of injected posts. Content injection often lives entirely in wp_options and wp_posts.
Drop-ins and mu-plugins
advanced-cache.php, object-cache.php and must-use plugins load early and do not appear in the normal plugins list.
Your own sitemap and verification files
Spam sitemaps submitted through a hijacked Search Console ownership, and google*.html verification files nobody on your team created.
Neighbouring sites
On a shared hosting account, the generator can sit in another site entirely and still write into yours.
Removing it
Clean the cause, then let Google see the spam is gone
- 01
Preserve before you change anything
Copy the suspicious files, export the database, and keep the access logs. The cleanup will destroy the only record of how the spam was served and how the site was entered.
- 02
Remove the generator and every persistence layer
Files, database rows, rewrite rules, drop-ins, scheduled tasks and rogue administrator accounts. Removing the spam pages while the generator survives brings them back.
- 03
Make the spam URLs return 404 or 410
Once the generator is gone, the injected URLs should answer “not found”. Do not block them in robots.txt: Google then cannot recrawl them to see that they are gone, and they linger in the index.
- 04
Remove rogue Search Console owners and sitemaps
Revoke owners and users you did not add, delete their verification files or meta tags so they cannot re-verify, and remove sitemaps you did not submit.
- 05
Close the way in and rotate access
Update or remove the vulnerable component, and change control-panel, SFTP, database and WordPress administrator credentials from a device that is not part of the incident.
- 06
Verify, then request the review
Re-run URL Inspection’s live test on the sample URLs and recheck the site: search. When every sample is clean, request a review from the Security Issues report and describe what was found and removed.
Index cleanup
Getting the spam out of the results after the site is clean
A clean site does not instantly mean a clean index. Spam URLs drop out as Google recrawls them and receives a 404 or 410, which for a large injection can take a while. A sitemap of your legitimate URLs helps Google recrawl what matters; it does not need to list the spam.
Search Console’s Removals tool can hide specific URLs from results quickly, but the removal is temporary and does not delete anything from the index permanently. Use it for the handful of spam URLs causing real harm in branded searches, not as a substitute for the 404s.
Watch the site: search, the Security Issues report and the Pages report in the weeks afterwards. New spam URLs appearing after the cleanup means a layer survived — treat it as a reinfection, not as Google being slow.
Common questions
Common questions about “This site may be hacked”
My site looks completely normal. Why does Google say it may be hacked?
Because the hacked content is usually cloaked. It is served to Googlebot and to visitors arriving from search results, and hidden from direct visits and logged-in administrators. URL Inspection’s live test in Search Console shows what Google actually receives.
Is this the same as the red “Deceptive site ahead” warning?
No. “This site may be hacked” is a label in Google’s search results. “Deceptive site ahead” is a Safe Browsing warning shown by the browser before the page opens. They have different causes, are seen by different people, and each has its own review.
Can I remove the label without a Search Console review?
The label can also clear when Google recrawls the site and finds the hacked content gone, but a review request after a verified cleanup is the direct route and the only one you can act on. It needs a verified Search Console property.
Should I block the spam URLs in robots.txt?
No. Blocking them stops Google from recrawling them, so it never sees that they now return 404 or 410, and they can stay in the index longer. Let them return “not found” instead.
Someone I do not know is an owner of my Search Console property. What does that mean?
Very likely that the attacker verified ownership — through a verification file or meta tag they placed on the site — to submit spam sitemaps. Remove the owner and the verification token they used, and treat it as confirmation of a compromise.
How long does the review take?
It varies, and Google does not commit to a fixed time. Its guidance suggests hacked-spam reviews can take considerably longer than malware or phishing reviews, potentially weeks. The variable you control is whether the site is genuinely clean when you ask.