Some sites that lose traffic during a spam update were never spamming on purpose. An attacker found an outdated plugin, a weak password or an exposed upload folder and quietly added thousands of pages selling counterfeit goods, pharma or gambling. The owner often finds out only when strange titles appear in search results, or when traffic drops during an update.
Google is clear that hacked content counts as spam, whoever put it there. The good news is that hacked-site recovery follows a well-documented path: find the injected content, close the hole, clean up, tell Google, and monitor.
This guide walks through that process in plain steps, explains which Search Console reports to use, and shows how to tell whether your lost traffic came from the hack, a spam update, or both.
Key Takeaways
- Google's spam policies define hacked content as content placed on a site without permission due to security vulnerabilities.
- Common hacks include code injection, content (link) injection, URL (page) injection and malicious redirects.
- Check the Security Issues report and the Manual Actions report in Search Console before anything else.
- Fix the vulnerability, not just the symptoms. Deleting spam pages without closing the hole leads to reinfection.
- When all issues are fixed, request a review. Google says most reviews take several days or weeks.
How hacked content becomes a search problem
“Hacked content is any content placed on a site without permission, due to vulnerabilities in a site's security.”
— Google Search Central, Spam policies for Google web search
Google's hacked content documentation describes several forms: code injection (malicious code added to existing pages), page injection (new pages full of spam), content injection (subtle changes to existing pages) and redirects that send some users to harmful or spammy pages. The documentation says violations are found through automated systems and, where needed, human review that can lead to a manual action, with notices in the Manual actions report and the Search Console message centre.
This is why a hacked site can be hit twice. Its pages may be flagged as a security issue, and the spam it now hosts can be caught by spam systems. Read more about how policies are enforced in our guide to Google spam policies.
Signs your site has been hacked
- Search results for your domain show titles or snippets in foreign languages or about products you do not sell.
- The Page indexing report shows a sudden jump in indexed or discovered URLs you did not create.
- The Performance report shows impressions for unrelated queries (pharma, replica goods, casino terms).
- Visitors from search are redirected to other sites, while you see the normal page when you type the URL directly (attackers often target only search visitors or mobile users).
- Search Console sends a security notice, or browsers show a warning before your site.
- Unknown admin users, new files in upload folders, or modified core files appear on the server.
Hack types and what to look for
| Hack type (Search Console wording) | What it does | Where to look |
|---|---|---|
| Code injection | Adds malicious code (for example redirect scripts) to existing pages | Page source, theme and template files, injected JavaScript |
| Content injection | Adds spammy links or text to your existing pages, often hidden | Rendered HTML via URL Inspection, database content |
| URL injection | Creates new spam pages on your domain | Page indexing report, sitemaps, unknown directories |
| Malicious redirects | Sends some users to spam or harmful pages | .htaccess or server config, JavaScript, test from search on mobile |
| Malware / unwanted software | Serves harmful downloads | Security Issues report, server file scan |
The Security Issues report uses these labels. For example, it describes content injection as follows:
“A hacker has added spammy links or text to your site's pages.”
— Search Console Help, Security issues report
Step-by-step recovery
- Assemble help. Involve your host, developer and, if needed, a security specialist. The web.dev "Help! I've been hacked" series starts with building a support team for this reason.
- Quarantine the site. Consider taking it offline or showing a maintenance page while you work, so visitors are not exposed.
- Check Search Console. Review the Security Issues report and the Manual Actions report, and note every URL sample Google lists.
- Assess the damage. List injected pages, modified files and spam links. Use
site:searches with spam terms, the Page indexing report and server file timestamps. - Find the vulnerability. Common entry points include outdated CMS cores, plugins and themes, weak or reused passwords, and insecure file permissions.
- Clean or restore. Restore from a known-clean backup if you have one, then reapply legitimate changes. Otherwise remove injected files, database entries and rogue users manually.
- Harden. Update everything, remove unused plugins and accounts, change all passwords (CMS, hosting, FTP, database), and turn on two-factor authentication.
- Let spam URLs die. Injected pages should return 404 or 410. Remove any rogue sitemaps the attacker added.
- Request a review. When every issue listed is fixed on every page, use Request Review in the Security Issues report (and the Manual Actions report if there is a manual action). Explain the issue, the steps you took and the outcome.
- Monitor. Watch for new unknown URLs, file changes and spam queries for months, not days.
Google sets expectations for the review itself:
“Most reconsideration reviews can take several days or weeks to complete.”
— Search Console Help, Security issues report
Hack, spam update or both?
If your traffic fell during a spam update, it is tempting to assume the update was the whole story. Separate the threads:
| Observation | Suggests |
|---|---|
| Security Issues report lists hacked content | The hack is a confirmed factor; fix it first |
| Manual action listed | A reviewer has acted; a reconsideration request is required after cleanup |
| Neither report shows anything, but spam pages exist | Google may not have flagged it yet, or spam systems are reacting algorithmically; clean up anyway |
| No hack found, drop matches update dates | Treat it as a normal spam or core update analysis |
| Rankings for your real pages fell but spam pages rank | Injected content may be affecting how the site is assessed; clean up and monitor |
A hack can also distort your data. Injected pages add impressions for odd queries and inflate indexed counts, so compare your legitimate pages only. Our guide on checking crawl stats and indexing after an update explains how to read those reports, and algorithmic demotion versus manual action helps you decide which path you are on.
After cleanup: what to expect
Once a security review succeeds, warnings shown in search and browsers can be removed. Rankings are a different matter. If spam systems demoted the site, Google's spam update documentation says sites that improve may see changes once its systems learn, over a period of months, that the site complies. Do not promise yourself or a client a date. Track your real pages' clicks and impressions using the methods in how to measure update recovery.
If the attacker also built links to the injected pages, those links will point at URLs that now return 404, which is usually enough. Our guide to negative SEO covers cases where an attack continues from outside your site.
Common mistakes
- Deleting spam pages but not patching the hole. Reinfection is common when the original vulnerability remains.
- Requesting review too early. Google asks that all listed issues be fixed on all pages first.
- Redirecting injected URLs to real pages. Let them return 404 or 410 instead.
- Checking only as a logged-in admin. Many hacks hide from admins and show only to search visitors or mobile users.
- Restoring an infected backup. Check the backup date against when the hack began.
- Forgetting HTTPS and certificates. After a rebuild, confirm the site still serves securely; see our guide to HTTPS and SEO.
Related Guides
- Cleaning Up Doorway-Style Location Pages After a Spam Update
- What to Do (and Not Do) While a Core Update Is Rolling Out
- Refocusing an Off-Topic Site After a Quality Demotion
Frequently Asked Questions
Will Google penalise me for content a hacker added?
Google treats hacked content as a spam policy violation regardless of who added it, and may flag it as a security issue or take manual action. Once you clean up and Google reviews the site, warnings can be removed.
Where do I see if Google detected a hack?
Check the Security Issues report and the Manual Actions report in Search Console, plus the Search Console message centre.
How long does a review take?
Google says most reconsideration reviews can take several days or weeks. You receive an email when the request is received and when it is complete.
Should I return 404 or 410 for injected pages?
Either works for removed spam pages. Do not redirect them to legitimate pages.
Can I just use the Removals tool?
The Removals tool hides URLs temporarily. It does not fix the hack. Use it alongside a proper cleanup, not instead of one.
Conclusion
A hacked site caught in a spam update needs a security fix first and an SEO fix second. Close the vulnerability, remove injected content, request a review and then measure recovery calmly. For wider recovery steps, see our spam update recovery guide and user-generated spam cleanup guide. If you want experienced help, our penalty recovery service handles audits and review requests, or you can request a free quote.
