In short: SEO spam in the Google index almost always means that foreign code is running on your server, generating or serving spam pages. First find out whether the pages come from files, database entries or code that was injected and generates them dynamically. After the cleanup, every spam URL must permanently return 404 or 410; the removal tool in Search Console only hides them temporarily.
When your domain suddenly ranks for something foreign
The discovery is often accidental. An employee searches for the company name and sees entries in a foreign language below it. Or Search Console shows queries about pharmaceuticals, gambling or branded goods, with clicks on pages nobody created.
A reputable company domain is valuable to attackers. Search engines trust it, and spam pages under that address rank more easily than on freshly registered domains. You, as the operator, bear the consequences: your reputation suffers, Google may display warnings, and your real content loses visibility.
SEO spam is the symptom of a break-in, not a marketing problem. After PHP2Shell, the vulnerabilities CVE-2026-109618 and CVE-2026-109619 in PHP itself, this matters all the more: an update to a fixed PHP version closes the vulnerability but does not remove injected code. If Google is already showing a warning, the guide Removing a Google warning describes the path to a review. This article concentrates on the spam pages themselves.
Recognizing SEO spam: what Search Console shows
Google Search Console offers several reports that make SEO spam visible, even before a warning appears:
- Performance: queries and pages that do not fit your offering, often in foreign languages or scripts.
- Page indexing: a sudden rise in indexed or discovered pages, although your team has not published any content.
- Sitemaps: submitted sitemaps that nobody on the team knows.
- Users and permissions: additional owners through whom attackers can submit sitemaps.
Note down example URLs and their pattern: are they in a subfolder, do they have their own extension, do they contain random-looking strings? The pattern is the most important clue to where the pages are created on the server.
Where the spam pages come from
Spam pages can come about in three ways. The type determines where you search and how you clean up:
| Origin | Typical traces | Where to look |
|---|---|---|
| Static files | many HTML or PHP files in a new folder | file system, by modification date |
| Database entries | spam posts or products in the CMS, often unpublished or hidden | content tables of the database |
| Generated dynamically | no files, the URLs exist only when requested | rewrite rules, entry files, included code |
The third variant is the hardest to find. A small piece of code in an entry file or in an .htaccess intercepts requests that follow a certain pattern and generates the spam page from a template or fetches it from a foreign server. Often only search engines see the spam content, while normal visitors get an error page or the home page.
A read-only request shows what the server actually delivers. Insert a spam URL from Search Console:
# Response for a normal browser
curl -s -o /dev/null -w '%{http_code}\n' "https://www.ihre-domain.de/spam-url"
# Response for a request with a Googlebot identifier
curl -s -o /dev/null -w '%{http_code}\n' -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "https://www.ihre-domain.de/spam-url"
If the status codes differ, the server evaluates the caller's identifier. Real checks by Google may also depend on the fetcher's address; the URL inspection in Search Console therefore shows more reliably what Google sees. If the spam content is in the database, the article Checking the database for injected code helps.
Cleaning up the index for good
Cleaning the server comes first. Only once the generating code has been removed and the entry point closed is it worth working on the index. Google's help pages name clear paths:
- Answer spam URLs with 404 or 410: the pages must actually be gone. Spot-check with the commands above that no variant still delivers content.
- Do not redirect to the home page: a blanket redirect keeps the URLs alive and muddies the cleanup.
- Do not block via robots.txt: according to Google's help pages this is not a suitable way to remove pages, because Google then can no longer fetch the deleted pages.
- Remove foreign sitemaps and owners: delete spam sitemaps submitted in Search Console and remove unknown owners.
- Hide temporarily if needed: according to Google's help pages, the temporary removal hides particularly harmful URLs for about six months. It does not replace the permanent solution.
Also think of other search engines. The spam pages were reachable for all crawlers, not only Google. The permanently correct 404 or 410 response works there just as well. If you use the webmaster tools of other search engines, check sitemaps and authorized users there too. Also keep the list of known spam URLs as part of the incident documentation.
If new spam URLs appear after the cleanup, a backdoor has been overlooked. In that case, do not just delete the new pages, but resume the search on the server.
Preventing a recurrence
SEO spam often comes back because only the visible pages were removed. Watch Search Console in the weeks after the cleanup and have the email notifications go to an address that is read regularly. File monitoring that reports new PHP files and changes to .htaccess complements this on the server side. If visitors are being redirected to foreign offers instead of seeing spam pages, the article The website redirects to foreign sites helps.
How does PHP SOS help?
- We use the Search Console data and the server responses to determine how the spam pages are created.
- We remove the generating code, spam content and backdoors as part of malware removal and close the entry point.
- We check that all known spam URLs permanently return 404 or 410, and clean up sitemaps and owners in Search Console.
- We set up monitoring that makes new files and unusual index figures visible early.
Frequently asked questions
Why do foreign pages show up under my domain on Google?
Usually attackers have placed code on the server that generates or serves spam pages. They exploit the trust search engines place in your domain to push their own offers up the rankings. This is a sign of a break-in, not of an SEO mistake.
Is it enough to hide the spam URLs with the removal tool?
No. According to Google's help pages, a temporary removal hides a URL for only about six months and does not stop crawling. The pages disappear for good only when the server returns 404 or 410 for them.
Should I block spam URLs with robots.txt?
No. Google's help pages expressly advise against blocking pages via robots.txt in order to remove them. Google cannot fetch blocked URLs and therefore does not notice that they have been deleted.
How long do the spam pages stay in the index after the cleanup?
That depends on when Google fetches the URLs again. No reliable timeframe can be given. What matters is that every known spam URL permanently returns 404 or 410 and no new ones appear.