Hacked Website SEO: Spotting and Removing Spam Pages

"Hacked website SEO" almost always means one specific problem: someone got into the site, planted their own content or links, and now rankings, indexed pages, or search snippets look wrong because of material the site owner never wrote. That's a different failure than a slow page or a bad backlink profile picked up naturally. Google's systems are reacting correctly to spam that genuinely lives on the domain, planted by an attacker rather than the site's owner.

The fix isn't a disavow file or a content refresh. It's finding exactly what was planted, removing all of it, closing the door it came through, and telling Google the site is clean again before rankings can settle back to normal. This covers the three SEO-spam hack patterns that actually generate a Search Console flag — the Japanese keyword hack, cloaked pharma and gambling injections, and injected link spam — how to tell which one is present, and the path from a Security Issues warning back to recovered rankings. A padlock warning or certificate error is a separate TLS problem, not this one, and the fix for it doesn't touch any of the steps below.

How an SEO-Spam Hack Actually Shows Up

The symptoms overlap with several unrelated problems, so it's worth confirming the diagnosis before doing anything else. A few signals point specifically at a spam hack rather than, say, a bad migration or a Core Web Vitals drop.

Any one of these alone could be a false alarm. Two or more together, especially a Security Issues entry plus unfamiliar indexed URLs, means the site itself has been altered.

• A Security Issues entry appears in Search Console, usually naming a specific category such as hacked content or cloaked content.
• Running a site: search for the domain turns up pages nobody on the team wrote, often with titles that don't match the site's language or subject.
• Search results for the domain show foreign-language titles, drug or gambling brand names, or garbled auto-generated text in the snippet.
• The Performance report shows a burst of impressions for queries that have nothing to do with the business, frequently in Japanese, Chinese, or Korean.
• Analytics shows sessions landing on URLs that were never built, often with no referrer and a bounce pattern that looks automated rather than human.

The Japanese Keyword Hack

This is the most common SEO-spam hack because it's the most profitable to run at scale, and it gets its name from the language the injected pages are usually written in. An attacker exploits an outdated plugin, an unpatched theme, or a stolen admin login, then plants a script that auto-generates thousands of pages stuffed with Japanese text and affiliate links to counterfeit branded goods. Those pages get indexed under the compromised domain's existing authority, which is the entire point: a ten-year-old site with real backlinks ranks new spam pages far faster than a brand-new domain would.

The pages usually live somewhere the owner never looks — a subfolder under the uploads directory, a directory made to look like a plugin's own folder, or rewrite rules quietly added to .htaccess that route arbitrary paths to a single spam-generating script. Some variants also create a hidden administrator account so the pages regenerate even after the visible files are deleted, which is why a plain file deletion often looks successful for a few days before the same pages come back.

To confirm this specific variant, filter the Performance report's queries for anything using non-Latin scripts and check whether impressions for those queries exist at all — a clean site should show zero. Comparing the indexed-pages count in the Pages report against the actual number of real pages the CMS holds is the other fast check; a gap of thousands of pages the content team never published is the signature of this hack, not a reporting quirk.

Cloaked Spam and Pharma Injections

Cloaking is what makes this variant hard to catch by just browsing the site: the injected code checks the visitor's user agent or referrer, then serves ordinary-looking content to a human and a completely different page — usually stuffed with pharmaceutical, gambling, or replica-goods keywords — to a search engine crawler. An owner who opens the flagged URL in a normal browser often sees nothing wrong, concludes the report is a false positive, and moves on, while Google keeps crawling and indexing the spam version.

The injection typically sits in a theme's functions file or a fake plugin rather than as new standalone pages, which is part of why it's harder to spot than the Japanese keyword hack's obvious new URLs. Some variants go further and only trigger the redirect when the referrer is a search results page, so a visitor who clicks a Google result for a drug-brand query lands on the spam content while the same URL typed directly into a browser shows the real site.

Confirming cloaking means comparing what a crawler sees to what a browser sees, not just loading the page normally. Requesting the URL with a spoofed Googlebot user agent, or using the URL Inspection tool's "view crawled page" option in Search Console, shows the version actually being indexed. Search Console's Security Issues report is usually specific here too — it labels this category as cloaked content, distinct from the more generic hacked content label, which is a useful clue about which mechanism to look for first.

Injected Link Spam

This variant doesn't create new pages at all — it edits pages that already exist. A common pattern adds hidden links to a footer widget, a sidebar include, or directly into stored post content in the database, pointing to unrelated commercial sites such as gambling operators, essay-writing services, or replica-goods sellers. The goal isn't traffic to those links; it's laundering the compromised domain's authority through them, which is why the injected anchor text is often completely unrelated to anything the site publishes.

Because no new URLs get created, this variant is easy to miss in a site: search. The tell is usually in the source code of pages that already rank: a hidden div with display:none or visibility:hidden, text positioned off-screen with a large negative margin, or a cluster of unfamiliar outbound links at the very bottom of the page template. A backlink or outbound-link audit tool that lists a site's own outgoing links will often surface the same anchors faster than viewing source on every template by hand.

A related but distinct mechanism is comment or guestbook spam, where the injected links live in unmoderated comment fields rather than template code. It's cleaned up differently — moderation and comment-form hardening rather than a file-level fix — but it produces the same symptom: a site quietly linking out to a spam network it never intended to join.

Confirming Scope Before Touching Anything

Cleaning file by file without first mapping the full extent of the problem is the single most common mistake in a hack recovery, because it fixes the visible symptom while leaving whatever caused it untouched. The hack usually reappears within days, and a second occurrence during a review window is worse for the domain than the first ever was.

The reason this ordering matters: some variants of these hacks plant a backdoor that is entirely separate from the visible spam pages, specifically so the pages can be recreated after a cleanup. Deleting only what's obviously wrong, without locating that backdoor, is why a site can look fixed on Monday and be re-infected by Friday.

• Read the full Security Issues report in Search Console, but treat its example URLs as a sample, not the complete list.
• Run a site: search combined with known hack terms and non-Latin scripts to surface indexed spam the report didn't list as an example.
• Compare the indexed-page count in the Pages report against the CMS's real published-post count to size the problem.
• Check server access logs for newly created PHP files, unusual POST requests, or a spike in requests from non-browser user agents around the time the symptoms began.
• Where a recent clean backup exists, diff the current file tree against it rather than reading every file by hand — the difference points straight at what was added.

Cleaning Up and Removing the Backdoor

Removing the spam pages or injected code is necessary but not sufficient. The entry point that let the attacker in has to be closed, or the same access gets used again regardless of how thoroughly the visible mess was cleaned.

When there's no clean backup and the platform is old and heavily customized, a security-focused rebuild from fresh core files with only vetted, updated plugins is usually faster and more reliable than an exhaustive manual audit of every template file looking for one injected line.

• Update or replace the vulnerable plugin or theme that was the original entry point, rather than assuming a patched version of the same install is automatically safe.
• Rotate every admin password, plus any API keys or database credentials the injected code could plausibly have read from a config file.
• Review the full list of user and admin accounts for anything unfamiliar — a hidden second administrator account is a common way these hacks survive a cleanup.
• Look for a scheduled task or cron job the attacker added, since some variants use one to regenerate spam pages on a timer rather than relying on a visitor triggering the script.
• Restore from a backup that predates the compromise when one exists, rather than hand-removing every affected file, since manual removal reliably misses at least one artifact.

Telling Google the Site Is Clean

Once the cleanup is genuinely complete, Search Console's Security Issues report has a "Request a Review" action. The review is read by a person, not resolved automatically, so a submission that lists specifically what was found and specifically what was fixed carries more weight than a one-line "issue resolved."

Spam URLs frequently stay indexed for a while even after the underlying files are gone, so they need separate handling. The Removals tool gives a fast temporary hide, but the URLs also need to actually return a 404 or 410 status permanently, or they can resurface later instead of dropping out of the index for good. The sitemap should be resubmitted once it reflects only real content, since a sitemap still listing spam paths undermines the review.

The review itself isn't instant — it can take days rather than hours, and rushing it before every backdoor is confirmed closed tends to produce a second flag, which is treated more seriously than the first. It's worth rechecking systematically against the scope found earlier rather than submitting as soon as the obvious spam is gone.

Why Rankings Take Time to Recover

Even after the Security Issues flag clears, legitimate rankings rarely snap back immediately. Google has to recrawl the affected URLs and reprocess the site at its own pace, and any authority that was briefly spread across thousands of spam pages needs to reconsolidate onto the real ones — a recrawl and reprocessing timeline, not a punishment that has to expire.

That's also a genuinely different situation from a manual action, which shows as its own distinct message separate from the automated Security Issues flag. Severe or repeated cases can trigger a manual action in addition to the security flag, and if that happens it needs its own separate reconsideration request filed after the security issue is cleared — the two queues don't move together, and resolving one does not resolve the other.

The most reliable sign that recovery is actually complete is watching the Performance report for those foreign-language or pharma-related query impressions to drop to zero, rather than watching only the site's own keyword rankings. A single leftover corner of spam, even a handful of pages, can keep suppressing trust signals on the rest of the domain long after the obvious mess has been cleared away.