Hacked Site SEO Spam: Find and Clean Injected Spam Pages

Hacked site SEO spam is what you see when an attacker uses your website to advertise something else. New pages appear that you never wrote, selling pills, counterfeit goods or gambling. Hidden links and text show up inside your existing pages. Some visitors are redirected to another site. You may find out from a warning in search results, an email from Google Search Console, or a customer who says your site sent them somewhere odd.

This guide is for site owners and the people who help them. It walks through a calm order of work: confirm what was changed, contain the problem, clean it properly, close the hole the attacker used, and then ask Google to review the result. You do not need to be a security specialist to follow it, but you will need access to your hosting account and the ability to restore from a backup.

It is also honest about limits. Cleaning the pages is the easy half. If the way in is not found and closed, the spam usually comes back.

Before you begin

You need access to Google Search Console for the site (verify both the www and non-www versions, or a Domain property, so that nothing hides on the version you cannot see), your hosting control panel or SSH, your CMS admin, and ideally the most recent backups. If you do not have Search Console yet, set it up first with Set Up Google Search Console: Complete Website Owner Checklist.

Set aside several hours, and expect the search clean-up to take longer than the technical clean-up. The main risk is destroying evidence or making the damage worse. Before you delete anything, make a labeled copy of the infected files and database so you can compare later. Do not rely on the infected copy for anything but comparison.

If your site handled customer data and you think it was exposed, check your legal and contractual duties before you delete logs or files. That decision is outside what a guide can settle.

What Google means by hacked content

Google's spam policies define hacked content as content placed on a site without permission because of security weaknesses. It lists four common forms:

Code injection: malicious code, often JavaScript or an iframe, added to existing pages.
Page injection: new spam or phishing pages added to the site, while your real pages may look untouched.
Content injection: hidden links or text added to existing pages, sometimes shown only to search engines (cloaking).
Redirects: injected code that sends some visitors to harmful pages. The redirect can depend on the referrer, user agent or device, so a link clicked from search results may redirect while the same address typed directly does not.

Search Console's Security Issues report uses similar labels: code injection, content injection, URL injection and malware. Knowing which one you have tells you where to look.

Step-by-step instructions

Step 1: Confirm what Google and visitors see

Open Search Console and look at the Security Issues report. If it lists example URLs, open them. Hacked content is sometimes cloaked: you see a normal page while Google sees spam, so a clean-looking page does not clear you. Use the URL Inspection tool on the example URL to see what Google fetched.

Next, search Google for site:example.com with your own domain. Scroll through the results looking for page titles you did not write. Add words an attacker would use, such as unrelated product names, to find spam pages faster. Also check your server logs and your sitemap for new URLs you do not recognize.

What success looks like: You have a written list of affected URLs, the type of hack (new pages, altered pages, redirects), and screenshots or saved copies as evidence.

Step 2: Contain the site

Stop visitors and crawlers from reaching harmful content while you work. Google's hacked-site guidance suggests taking the site offline, either by stopping the web server or pointing DNS to a static page on a separate server that returns a 503 status. The 503 should come from outside the compromised server, because a 4xx or 5xx from the infected server does not protect visitors; it could still serve harmful content.

A robots.txt disallow is not containment. It only asks crawlers to stay away and does nothing for human visitors. Tell your hosting provider what has happened, since the problem may be broader than your account.

Then secure access. Review the user list in your CMS and server, and note any accounts you do not recognize before you remove them. Change passwords for every login connected to the site: CMS, hosting panel, FTP or SFTP, database and server admin.

What success looks like: Visitors see a maintenance page or nothing, and every old credential no longer works.

Step 3: Choose a cleaning path based on your backups

Your options depend on what you have.

A clean, current backup: restore it, then update everything (operating system, CMS, plugins, themes), remove software you do not use, and fix the vulnerability.
A clean but older backup: keep the infected site as a labeled copy, restore the older backup, update and remove unused software, then compare the two with a tool such as diff and carry over only content you have verified by hand.
No backup: make two labeled copies of the infected site (a file copy and a database dump), clean a copy rather than the live server, delete the compromised and attacker-created files, fix permissions, and remove altered database records.

Google's guide adds that for every server involved, a fresh installation is safer than an upgrade, because leftover infected files can cause reinfection. Restore only content you know is clean.

What success looks like: The site is running from a known-clean base, with current software and nothing the attacker added.

Step 4: Remove the spam and check every layer

Whichever path you took, search for the leftovers.

New files and folders: look for recently modified or oddly named files in the web root and in upload folders. In a CMS, uploads should hold media, not executable scripts.
Existing pages and templates: hidden text and links are often inserted into theme files, footers or database content. Search the database for terms from the spam you found.
Configuration files: check .htaccess or server config for rules that redirect only search visitors or only certain devices.
Accounts: confirm that no administrator user was added.
Sitemap: if your sitemap plugin added spam URLs, regenerate it, and then check it with Find and Fix 404 and 500 Errors in XML Sitemaps.

For hacker-created pages that must never appear in search, you can remove them from the server (so they return a 404) and use Search Console's removal tool for speed. Do not use removal for good pages that were only damaged; clean those and ask Google to recrawl them. For the fuller picture on removals, see Remove URLs From Google Search the Right Way.

What success looks like: A search of the server and database finds none of the spam terms, and the example URLs from Step 1 return the page you intended or a proper not-found response.

Step 5: Find and close the way in

This is the step people skip. Work out how the attacker got in: an outdated CMS or plugin, a weak or reused password, a stolen FTP login, a vulnerable theme, or a compromised computer used to manage the site. Your server logs, the modified-file dates and your host's support team can narrow it down.

Then fix it: update or remove the vulnerable software, use strong unique passwords, remove accounts and plugins you do not use, set up automatic backups, and keep the devices you use for site management updated. Google's maintenance advice also includes vetting the security practices of any plugin before you install it.

Finally, change all passwords again after the clean-up is finished. Google's guide calls for a final password change after the clean installation, once nothing of the attacker remains.

What success looks like: You can name the most likely entry point, and it is patched or removed.

Step 6: Bring the site back and recheck

Before reopening, go through a short list: the site runs the latest software, unused plugins are gone, the attacker's content is removed, and the root cause is fixed. Bring the site online, then repeat the checks from Step 1: the site: search, URL Inspection on example URLs and a test with different devices and referrers to catch conditional redirects.

What success looks like: The Security Issues report still lists the problem (it clears only after review), but no spam appears on your pages from any route you can test.

Step 7: Request a review in Search Console

When every issue in the report is fixed on every affected page, open the Security Issues report and choose Request Review. Google's help page says partial fixes do not earn a partial return, and to describe in your request the specific issue, the steps you took and the results. Do not resubmit before you receive a decision, since premature requests can lengthen the wait or lead to the site being flagged as a repeat offender.

Google's help page says most reviews take several days to several weeks, and Google emails you when the request is received and when it is done. Nobody can promise a date, and a review result is not a promise about where your pages will appear afterwards.

What success looks like: You receive the review-complete email and the warning is removed from the report.

Final verification checklist

Search Console lists no remaining hacked-content issues, or the review request is submitted and pending.
A site: search for your domain shows only pages you recognize.
URL Inspection on the former example URLs shows clean content or a not-found response.
No unknown administrator, FTP or database accounts exist.
All passwords and keys connected to the site have been changed since the clean-up finished.
The CMS, plugins, themes and server software are current, and unused ones are removed.
Backups run automatically and a restore has been tested.
Your sitemap contains only URLs you intend to be indexed.
You know, or have a written best guess for, how the attacker got in.

Common mistakes to avoid

Deleting the visible spam only. Backdoors and altered templates bring it back. Restore from a clean base or reinstall, and compare against the infected copy.
Blocking the spam in robots.txt. That hides nothing from visitors and does not clean the site. Remove the content itself.
Checking only logged-out, desktop views. Cloaking and conditional redirects show different content to Google and to visitors from search. Use URL Inspection and test other devices.
Verifying only one version of the site. Attackers can place pages where you are not looking. Verify www and non-www, or use a Domain property.
Requesting a review too early. Fix every affected page first, then submit once, with a clear description of what you did.
Leaving old credentials active. Change passwords for CMS, hosting, FTP, database and server accounts, and change them again after cleaning.
Skipping the entry point. Without a patch for the real weakness, reinfection is likely.
Using a 4xx or 5xx on the infected server as your holding page. Serve the 503 from outside the compromised server.

Frequently asked questions

How do I know whether my site has SEO spam?

Check the Security Issues report in Search Console, run a site: search on your domain for unfamiliar titles, and inspect suspect URLs with URL Inspection. Cloaked spam may be visible only to search engines, so a normal-looking page in your browser is not proof of safety.

Will Google remove the warning automatically?

The Security Issues report is cleared through a review. Fix everything first, then request one and describe your fixes. Google's help page says most reviews take several days to several weeks.

Should I take the site offline?

Google's guidance suggests it, because harmful content can reach visitors while you clean. If you do, serve a 503 from a separate server or host rather than from the infected one. If you keep the site online, accept that visitors and crawlers may still reach affected pages.

Can I just restore a backup?

A clean, current backup is the fastest path, but you must also update the software and fix the vulnerability, or the site can be hit again. An older backup needs a careful comparison so you do not restore the weakness or lose new content.

Do I need a professional?

Not always, but consider one if you cannot find the entry point, if customer data may have been exposed, or if the spam keeps returning. Your hosting provider's support team is a good first call.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.