SEO-Spam nach einem Hack: Woher die fremden Seiten unter Ihrer Domain kommen und wie Sie sie aus Google bekommen

Woran erkennen Sie, dass Google fremde Seiten unter Ihrer Domain zeigt?

SEO-Spam nach einem Hack finden Sie mit einer Google-Suche nach site: und Ihrer Domain. Die Ergebnisliste zeigt die Seiten, die Google von Ihrer Website indexiert hat, auch die gehackten. Stehen dort Titel mit japanischen Zeichen oder Werbung für Arzneimittel, Glücksspiel oder gefälschte Markenware, hat jemand ohne Ihre Erlaubnis Inhalte unter Ihrer Domain platziert.

Die site:-Abfrage zeigt nur einen Ausschnitt. Wie weit der Befall reicht, sehen Sie dagegen in der Search Console. Wenn Ihre Website dort noch nicht bestätigt ist, erklärt der Ratgeber zur Google Search Console, wie Sie das nachholen. Diese Stellen lohnen den Blick (Bezeichnungen Stand Oktober 2026):

Fremde Seiten sind nur eine Form von SEO-Spam. Die andere ist Text, der in Ihre echten Seiten eingeschleust ist: Suchmaschinen erfassen ihn laut Googles Spam-Richtlinien, Sie und Ihre Besucher erkennen ihn aber kaum (Stand Oktober 2026). Meine passive Prüfung von Firmen-Websites im dritten Quartal 2026 zeigt, wofür solcher Text wirbt: Bei 490 von 1.494 Messungen an Startseiten mit bestätigtem Befall stand ein Spam-Begriff aus meiner Suchliste schon im normalen Abruf, also so, wie ein Browser die Seite lädt.

Dass der Spam im normalen Abruf steht, heißt aber nicht, dass Sie ihn auf der Seite sehen. Bei 286 der 490 Funde aus der Tabelle, also bei 58 %, stand er nur in Elementen, die Besucher nicht zu sehen bekommen. Ein Blick auf die eigene Startseite reicht deshalb nicht. Potenzmittel-Werbung war fast immer versteckt, bei 65 ihrer 76 Funde. Bei der Glücksspiel-Werbung war es etwas mehr als die Hälfte, 213 von 396.

Für mich folgt daraus: Suchen Sie im Quelltext, nicht in der Ansicht, und beginnen Sie mit Wörtern rund um Glücksspiel und Potenzmittel, denn diese beiden Themen machten 470 der 490 Funde aus. Den Quelltext rufen Sie am besten ohne Browser ab; Google nennt dafür Kommandozeilenprogramme wie curl. Bleibt die Suche im Quelltext leer, heißt das aber noch nicht, dass die Seite sauber ist.

Wie kommen die Spam-Seiten auf Ihre Domain, obwohl Sie sie nicht sehen?

Die Spam-Seiten stammen von Code, den ein Angreifer auf Ihrem Server abgelegt hat. Dieser Code legt neue Seiten an oder erzeugt sie automatisch, und er kann sie Google über eigene Sitemaps melden. Mit Cloaking, also unterschiedlichen Inhalten je nach Besucher, zeigt er die Spam-Inhalte womöglich nur Suchmaschinen, während Sie im Browser Ihre gewohnte Website sehen.

Google nennt das in seinen Spam-Richtlinien Einschleusung von Seiten: Hacker fügen über Sicherheitslücken neue Seiten mit Spam hinzu, während die bestehenden unauffällig wirken können. Beim japanischen Keyword-Hack, englisch Japanese Keyword Hack, entstehen laut Googles Anleitung zum japanischen Keyword-Hack in zufällig benannten Verzeichnissen Seiten mit automatisch erzeugtem japanischem Text, die über Affiliate-Links zu Händlern gefälschter Markenprodukte Geld bringen. Dabei trägt sich der Hacker laut Google in der Regel als Inhaber in der Search Console ein, um etwa die Sitemaps zu verändern.

Cloaking nutzen laut Google auch Hacker, damit der Betreiber den Angriff nicht sofort bemerkt. Google warnt sogar davor, dass eine Spam-Adresse Ihnen einen 404-Fehler melden und für Google trotzdem noch Spam liefern kann.

Das System entscheidet mit, wie gut Sie den Spam selbst finden. Bei meiner Prüfung im dritten Quartal 2026 stand auf befallenen Joomla-Startseiten nur bei 32 von 408 Messungen ein Spam-Begriff im normalen Abruf; bei 374 bekam allein der Abruf mit Googlebot-Kennung eine deutlich andere Seite. Bei WordPress fand ich Spam-Begriffe dagegen in 366 von 814 Messungen schon im Quelltext, den jeder Browser lädt. Gezählt sind auch hier Messungen an Startseiten, und die Prüfung unterscheidet nicht, ob die Fassung für den Googlebot Spam-Text, eine Weiterleitung oder eine ganz andere Seite war.

Auf einer Joomla-Seite sagt der eigene Quelltext deshalb wenig; das URL-Prüftool der Search Console zeigt Ihnen, was Google bekommt. Der Ratgeber zur Weiterleitung nach einem WordPress-Hack erklärt, wie Sie mit curl nachstellen, was ein Smartphone oder ein Besucher aus der Google-Suche sieht, ohne die Seite im Browser zu öffnen.

Der Code muss auch nicht dort liegen, wo die Spam-Seiten zu sehen sind. In einer Bereinigung aus meiner Arbeit 2026 stammten die Spam-Seiten nicht aus der eigentlichen Website. Der Angreifer hatte eine komplette zweite WordPress-Installation in einem unauffälligen Unterordner unter wp-content/ abgelegt, mit eigenen Datenbanktabellen, und sie über Umschreibregeln in der .htaccess unter einem eigenen Pfad der Domain erreichbar gemacht. Die zweite Installation hatte eine eigene robots.txt, die auf Sitemaps für die Spam-Seiten verwies.

Einzelne Spam-Seiten zu löschen hätte hier nichts gebracht, denn solange Ordner, Tabellen und Regeln da waren, blieb die ganze Spam-Website erreichbar.

Wie entfernen Sie den Erzeuger der Spam-Seiten?

Suchen Sie den Code, der die Spam-Seiten erzeugt, statt sie einzeln zu löschen. Laut Google müssen Sie die Seiten entfernen oder den Code beseitigen, der sie automatisch generiert. Bevor Sie etwas entfernen, sichern Sie den befallenen Zustand. Prüfen Sie dann die .htaccess, den Webspace, die Kerndateien und die Datenbank, und entfernen Sie alles, was zum Erzeuger gehört, in einem Zug.

Die Schritte gehen von SEO-Spam in WordPress aus; bei einem anderen System gelten sie sinngemäß, nur Pfade und Befehle unterscheiden sich. Dürfen Sie die Spam-Dateien gleich löschen?

„Bevor ich etwas ändere, sichere ich die Website vollständig. So gibt es jederzeit einen Weg zurück, und der befallene Zustand bleibt für die Ursachenanalyse erhalten.“

— Sascha Fix

1. Befallenen Zustand sichern

   Laden Sie alle Dateien des Hosting-Kontos herunter und exportieren Sie die Datenbank. Google rät, die Kopie an einem Ort außerhalb des Servers zu speichern. Ein sauberes Backup aus der Zeit vor dem Befall ist etwas anderes; der Beitrag Website nach einem Hack wiederherstellen zeigt, wie Sie es finden.

2. Umschreibregeln in der .htaccess prüfen

   Öffnen Sie die .htaccess im Hauptverzeichnis und in jedem Unterordner. Laut Google nutzen Hacker .htaccess-Regeln, um sinnlose Spam-Seiten zu erstellen oder eine Bestätigungsdatei für die Search Console vorzutäuschen. Misstrauen Sie jeder Regel, die einen Pfad in einen Unterordner oder auf ein Skript lenkt, das Sie nicht kennen. Googles Anleitung zum japanischen Keyword-Hack zeigt als Beispiel eine Regel, die eine Bestätigungsdatei vortäuscht:

   RewriteEngine On
   RewriteRule ^google(.*)\.html$ dir/file.php?google=$1 [L]
   

3. Webspace nach fremden Ordnern und Dateien durchsuchen

   Suchen Sie im Dateimanager des Hosters oder per SFTP nach Ordnern, die Sie nicht angelegt haben, auch unter wp-content/, nach PHP-Dateien mit fremden Namen und nach Sitemaps oder einer robots.txt in Unterordnern. Sortieren Sie die Dateien dabei nach dem Datum der letzten Änderung, wie Google es empfiehlt. Google nennt außerdem index.php, wp-load.php, 404.php und view.php als Dateien, in die Angreifer Skripte einfügen.

4. Kerndateien mit Prüfsummen abgleichen

   Mit Zugang per Secure Shell (SSH) und dem WordPress Command Line Interface (WP-CLI) vergleichen Sie im WordPress-Verzeichnis die Kerndateien mit den Prüfsummen von WordPress.org (Stand Oktober 2026):

   wp core verify-checksums --include-root
   

   Laut der WP-CLI-Referenz lädt der Befehl dafür WordPress nicht und warnt mit --include-root auch vor fremden Dateien im Hauptverzeichnis; er liest nur. Einen fremden Ordner unter wp-content/ wie in meinem Fall erfasst er nach dieser Beschreibung aber nicht. Auch eine Neuinstallation von WordPress ersetzt nur die Kerndateien: Hintertüren in Plugins, Uploads oder der Datenbank bleiben. Der Ratgeber zur Weiterleitung zeigt, wie Sie die Plugins mit wp plugin verify-checksums abgleichen.

5. Datenbank auf fremde Tabellen und Beiträge durchsehen

   Öffnen Sie die Datenbank, etwa mit phpMyAdmin, und suchen Sie nach Tabellen, die zu keiner Ihrer Erweiterungen gehören, und nach Beiträgen oder Seiten, die Sie nicht angelegt haben. In dem Fall aus meiner Arbeit gehörten neben den eigenen Tabellen der zweiten Installation auch Spam-Beiträge dazu.

6. Erzeuger entfernen und gegenprüfen

   Bevor Sie löschen, suchen Sie nach dem, was Gelöschtes zurückschreiben kann; der Ratgeber zeigt am Beispiel einer Weiterleitung, die nach dem Löschen zurückkommt, welche Mechanismen das sein können. Dann entfernen Sie Ordner, Tabellen, Umschreibregeln, fremde Dateien und Spam-Beiträge zusammen; eine Sitemap, die nur Spam-Adressen enthält, löschen Sie laut Google ganz. Prüfen Sie danach im URL-Prüftool, was Google unter einigen der Spam-Adressen bekommt.

Der Ratgeber Malware erkennen und entfernen beschreibt, wie Sie eine gehackte Website im Ganzen bereinigen, vom Einfallstor bis zu den Zugängen. Ist der Erzeuger weg, bleibt die zweite Hälfte der Arbeit: Google muss die Spam-Adressen noch als gelöscht erkennen.

Was muss Google sehen, damit die Spam-Seiten aus dem Index verschwinden?

Google muss jede Spam-Adresse erneut abrufen und dabei den HTTP-Statuscode 404 oder 410 bekommen; beide behandelt Google gleich. Google entfernt dann bereits indexierte Adressen mit einem solchen Code aus dem Index. Eine Sperre in der robots.txt, eine Weiterleitung auf die Startseite oder eine Fehlerseite mit dem Code 200 senden dieses Signal nicht.

Nach der Bereinigung muss jede Adresse so antworten (Bezeichnungen der Search Console Stand Oktober 2026):

Laut der Dokumentation zu HTTP-Statuscodes behandeln Googles Crawler alle 4xx-Fehler außer 429 gleich (Stand Oktober 2026). Wenn Sie viele alte Adressen auf die Startseite weiterleiten, kann Google das als Soft 404 werten; dasselbe gilt für eine Fehlerseite, die den Code 200 sendet. Was ein Soft 404 ist, erklärt der Ratgeber Seite wird nicht indexiert.

Die robots.txt ist dafür das falsche Werkzeug: Google ruft eine gesperrte Adresse laut seiner Hilfe nicht ab, kann sie aber trotzdem indexieren, wenn andere Seiten auf sie verweisen. Den 404 einer gesperrten Spam-Adresse bekommt Google also nie zu sehen.

Fremde Sitemaps löschen Sie als Datei vom Server. Die Sitemap nur im Bericht „Sitemaps“ zu löschen, genügt nicht, denn Google vergisst dann laut seiner Hilfe weder die Sitemap noch die Adressen darin; eine Sitemap, auf die nur eine robots.txt verweist, steht dort ohnehin nicht.

Einen fremden Inhaber entfernen Sie unter „Nutzer und Berechtigungen“ und danach jedes seiner Bestätigungstokens. Ein solches Token ist laut Google in der Regel eine HTML-Datei im Hauptverzeichnis oder eine Regel in der .htaccess, die eine solche Datei vortäuscht. Bleibt ein Token liegen, kann sich der entfernte Inhaber neu bestätigen.

Geht es schneller? Ja, mit dem Tool zum Entfernen: Es blendet laut Google eine Adresse innerhalb eines Tages aus den Suchergebnissen aus, auf Wunsch einen ganzen Spam-Pfad über das gemeinsame Präfix, aber nur für etwa sechs Monate (Stand Oktober 2026). Dauerhaft wirkt dagegen die Löschung. Nach einem Hack dürfen Sie mit dem Tool die Adressen ausschließen, die der Hacker neu erstellt hat; Google rät aber davon ab, die ganze Website auszuschließen. Für Seiten, die schon mit 404 antworten, brauchen Sie keinen Antrag, denn die Crawler bemerken das beim nächsten Abruf.

In dem Fall mit der zweiten WordPress-Installation habe ich nach der Bereinigung 2026 kontrolliert, dass der frühere Pfad der Spam-Installation und die Adressen der gelöschten Spam-Beiträge mit 404 antworten. Für den Pfad der Spam-Installation habe ich zusätzlich Entfernungsanträge in der Search Console gestellt.

Hat Google im Bericht „Sicherheitsprobleme“ einen Hack gemeldet, beantragen Sie dort nach der Bereinigung eine Überprüfung. Die Überprüfung kann laut Google einige Tage oder mehrere Wochen dauern (Stand Oktober 2026), und ein Antrag vor der vollständigen Bereinigung kann den nächsten verzögern. Wie Sie den Antrag stellen, beschreibt der Beitrag Google-Blacklist nach einem Hack entfernen.

Wann sollten Sie die Bereinigung abgeben?

Sie können die Bereinigung selbst übernehmen, wenn Sie eine Kopie des befallenen Zustands haben, an Dateien und Datenbank herankommen und den Erzeuger gefunden haben. Geben Sie sie ab, wenn der Spam nach dem Löschen zurückkommt, das Einfallstor unbekannt bleibt, ein fremder Inhaber in der Search Console stand oder personenbezogene Daten auf der Website liegen.

Der Unterschied zwischen infiziert und kompromittiert zeigt, warum ein fremder Inhaber eine Grenze ist. Infiziert heißt, auf der Website liegt etwas, das dort nicht hingehört. Kompromittiert heißt, jemand hat einen Schlüssel, etwa ein Konto, ein Token oder eine Webshell, und den nimmt ihm das Löschen der Spam-Seiten nicht ab. Ein Inhaber, den Sie nicht kennen, ist so ein Schlüssel: Laut Google wurde Ihr Konto dann möglicherweise gehackt, und der Hacker kann sein Token nach dem Entfernen wahrscheinlich wieder hinzufügen.

Wie ich bei einer gehackten Website vorgehe, beschreibe ich auf der Seite zur Hilfe bei gehackten WordPress-Seiten; die Erstanalyse ist kostenlos, und den Festpreis für die Bereinigung kennen Sie, bevor ich anfange. Für Websites ohne WordPress ist meine Website-Reparatur gedacht.

Wie merken Sie früh, dass Ihre Domain wieder für Spam missbraucht wird?

Behalten Sie drei Signale der Search Console im Blick: die Benachrichtigung, dass sich jemand als Inhaber bestätigt hat, neue fremde Adressen im Bericht zur Seitenindexierung und auffällige Suchanfragen im Leistungsbericht. Damit Sie von der Benachrichtigung über einen neuen Inhaber erfahren, müssen die Nachrichten der Search Console an eine E-Mail-Adresse gehen, die jemand regelmäßig liest.

Bestätigt sich ein entfernter Inhaber neu, benachrichtigt Google laut seiner Hilfe alle aktuellen Inhaber. Liefert eine alte Spam-Adresse wieder Inhalt statt 404 oder tauchen neue fremde Pfade auf, prüfen Sie sofort, ob der Erzeuger zurück ist. Viele Abrufe auf die alten Adressen sind dagegen noch kein Rückfall, denn Google ruft bekannte Adressen laut seiner Hilfe weiter ab, auch wenn sie 404 liefern, nur immer seltener.

Bei einer anderen Website habe ich 2026 nach einem Einbruch gut acht Wochen Server-Logs ausgewertet, die erst nach dem Entfernen der Spam-Seiten einsetzten; in dieser Zeit kamen mehr als 25.000 Anfragen auf die alten Adressen, Woche für Woche zwischen knapp 2.000 und gut 5.000. 99 % davon bekamen eine 404-Antwort, und nur ein kleiner Teil kam von Google: Weniger als 50 Anfragen trugen die Googlebot-Kennung, die ich nicht nachgeprüft habe. Ein Fall zeigt keine Häufigkeit. Logs zeigen nur, wer anklopft, nicht, was im Index steht. Für mich zählt deshalb die Antwort, die eine alte Adresse bekommt, nicht die Zahl der Anfragen auf sie.

Und reicht es, künftig alles aktuell zu halten?

„Eine Garantie, dass eine Website nie gehackt wird, kann niemand geben, denn eine Lücke, die noch niemand kennt, schließt auch das beste Update nicht.“

— Sascha Fix

Die Signale oben helfen Ihnen deshalb zu merken, wenn Ihre Domain trotzdem wieder für Spam missbraucht wird. Der Ratgeber zur WordPress-Sicherheit ordnet ein, welche Maßnahmen das Einfallstor danach schließen; wie ich Updates, Backups und Überwachung als laufende Pflege übernehme, steht auf der Seite zur WordPress-Wartung.