Japanese Keyword Hack: japanische Seiten in Google erkennen und entfernen

Der Japanese Keyword Hack ist eine Infektion, bei der ein Angreifer auf deiner Website neue Seiten mit automatisch erzeugtem japanischem Text anlegt, meist in Verzeichnissen mit Zufallsnamen wie /ltjmnjp/341.html. Die Seiten verdienen über Partnerlinks zu Shops mit gefälschter Markenware Geld und werden in der Google-Suche angezeigt, oft unter deinem Domainnamen mit japanischem Titel. So beschreibt es Google in der Anleitung Hacking durch japanische Keywords beheben. Sucuri zählte 2024 bei Fernscans 117.393 befallene Websites allein mit dieser Spam-Art.

Dass du im Browser nichts siehst, heißt nicht, dass die Seite sauber ist. Die Angreifer liefern die Spam-Seiten nur an Googlebot und an Besucher aus der Suche aus; wer die Adresse direkt aufruft, bekommt oft einen 404. Google warnt in der Anleitung ausdrücklich davor, sich davon täuschen zu lassen. Das nennt sich Cloaking, und es ist der Grund, warum die meisten Betroffenen den Befall erst durch Kunden erfahren, die bei Google etwas Japanisches unter dem Firmennamen gefunden haben.

Woran du den Befall erkennst#

Vier Prüfungen, zusammen zehn Minuten:

1. site:-Abfrage. Bei Google site:deine-domain.at eingeben und ein paar Ergebnisseiten durchblättern. Japanische Titel, fremde Verzeichnisse, Produktnamen, die mit dir nichts zu tun haben: Das ist der Befund. Google empfiehlt, dieselbe Abfrage auch in einer zweiten Suchmaschine zu machen, weil nicht jede dasselbe zeigt.
2. Search Console, Bericht „Sicherheitsprobleme“. Dort steht die Kategorie, meist „Gehackt: URL-Einschleusung“ (neue Seiten mit Spam) oder „Gehackt: Inhalt-Einschleusung“ (Spam-Links auf bestehenden Seiten), mit Beispieladressen. Im Suchergebnis kann in dieser Zeit „Diese Website wurde möglicherweise gehackt“ stehen.
3. Search Console, Nutzer und Berechtigungen. Google schreibt, dass sich Angreifer bei diesem Hack typischerweise selbst als Inhaber eintragen, um Sitemaps und Ländereinstellungen zu manipulieren. Eine Benachrichtigung, dass jemand Unbekanntes deine Website bestätigt hat, ist laut Google ein starkes Zeichen für einen Hack. Dazu den Bericht „Sitemaps“ öffnen: fremde Sitemap-Dateien, die du nie eingereicht hast, gehören zum Muster.
4. URL-Prüfung statt Browser. Eine der Spam-Adressen in die URL-Prüfung der Search Console eingeben und das indexierte HTML ansehen. Steht dort japanischer Text, während der Browser 404 zeigt, ist das Cloaking belegt. Das frühere „Abruf wie durch Google“, das die Anleitung noch nennt, ist in der URL-Prüfung aufgegangen.

Von außen zeigt der Security-Scan ohne Anmeldung, welche Dateien im Webroot offen liegen und welche fremden Skripte die Seite lädt. Den Befall selbst findet er nicht; dafür sind die Prüfungen oben da.

Wo die Dateien liegen#

Die Seiten, die du bei Google siehst, sind die Nutzlast. Entfernt werden muss der Code, der sie erzeugt, und der sitzt in der Regel an mehreren Stellen:

Mit WP-CLI geht die Suche nach Fremdkörpern in drei Befehlen:

wp core verify-checksums --include-root
wp plugin verify-checksums --all
wp user list --role=administrator --format=csv
wp option get siteurl && wp option get home

Der erste meldet jede Kerndatei, die nicht der Prüfsumme von WordPress.org entspricht, und mit --include-root auch Dateien im Webroot, die nicht zu WordPress gehören. Der zweite prüft Plugins aus dem offiziellen Verzeichnis. Ein Administrator, den niemand kennt, und eine siteurl, die auf eine fremde Adresse zeigt, sind zwei weitere Befunde.

Bereinigen: die Reihenfolge#

Die Bereinigung folgt der Neun-Schritte-Liste aus WordPress gehackt – was tun: Seite vom Netz, befallenen Zustand sichern, eigenen Rechner prüfen, alle Zugänge wechseln, Ausmaß feststellen, sauberen Stand herstellen, Lücke schließen, Google informieren, DSGVO prüfen, härten. Für diesen Hack kommen vier Dinge dazu, die Google in der Anleitung eigens nennt:

1. Fremde Inhaber aus der Search Console entfernen, samt Bestätigungsdatei. Der Zugriff bleibt bestehen, solange das Token da ist: eine HTML-Datei google…html im Webroot, ein Meta-Tag google-site-verification im Theme, ein DNS-Eintrag oder die oben genannte Rewrite-Regel, die so eine Datei nur vortäuscht. Google beschreibt die Probe: Eine erfundene Adresse wie /google1234.html aufrufen; antwortet sie nicht mit 404, erzeugt die .htaccess die Datei noch. Die Search Console hat dafür den Punkt „Nicht verwendete Bestätigungstokens“.
2. .htaccess ersetzen, nicht reparieren. Google rät, alle .htaccess-Dateien durch eine saubere Standardfassung zu ersetzen, außer es gibt bewusst eigene Regeln. Die Standardfassung von WordPress steht in WordPress-Sicherheit prüfen.
3. Kern, Themes und Plugins aus frischen Dateien neu aufsetzen, nicht drüberinstallieren. WordPress.org weist darauf hin, dass Installer meist nur bestehende Dateien überschreiben und Hacks oft neue Dateien hinzufügen; wp-admin und wp-includes werden deshalb komplett gelöscht und neu hochgeladen.
4. Sitemaps prüfen. Eigene Sitemap auf fremde Adressen durchsehen, alle unbekannten Sitemap-Dateien löschen und in der Search Console entfernen. Der Fall mit der spamurl.txt zeigt, dass Google eine eingetragene Spam-Sitemap weiter abruft, auch wenn alle Adressen darin längst 404 liefern.

Danach wp config shuffle-salts, neue Passwörter für WordPress, Datenbank, SFTP und Hoster-Konto, und ein zweiter Lauf der WP-CLI-Befehle oben. Google nennt in der Anleitung eine Studie, nach der 20 % der gehackten Seiten innerhalb eines Tages erneut gehackt werden; wer die Lücke nicht findet, macht die Arbeit zweimal.

Aus dem Index: was Google braucht#

Die Spam-Adressen sollen 404 oder 410 antworten. Google behandelt beide gleich: Der Inhalt existiert nicht, die Adresse wird beim nächsten Abruf aus dem Index entfernt, die Abrufhäufigkeit sinkt. Eine Weiterleitung der Spam-Adressen auf die Startseite ist falsch; sie macht aus tausend Spam-Seiten tausend Verweise auf die Startseite.

Das Entfernen-Werkzeug der Search Console hilft kurzfristig. Ein erfolgreicher Antrag blendet die Adresse etwa sechs Monate aus; bei tausenden Adressen reicht ein Präfix-Antrag auf das Spam-Verzeichnis. Dauerhaft verschwinden die Seiten nur, wenn sie 404 liefern.

Die Überprüfung erst anfordern, wenn alles sauber ist. Im Bericht „Sicherheitsprobleme“ heißt die Schaltfläche „Überprüfung anfordern“. Google schreibt, dass das Beheben auf nur einigen Seiten keine teilweise Rückkehr in die Suche bringt, und nennt für die Dauer mehrere Tage bis Wochen. Eine abgelehnte Anfrage verlängert die Zeit mit der Warnung.

Die Rankings kommen langsam zurück. Google muss die Seite neu abrufen und bewerten. Wie lange das dauert und was die Statusmeldungen im Bericht „Seiten“ bedeuten, steht in Warum Google deine Seiten nicht indexiert.

Was nicht hilft#

Nur die japanischen Seiten löschen. Sie werden aus der .htaccess oder einem Must-Use-Plugin neu erzeugt, oft innerhalb von Stunden.

Ein Sicherheitsplugin im befallenen WordPress laufen lassen und auf „Bereinigen“ klicken. Es läuft im selben Code wie die Schadsoftware. Als Hinweisgeber brauchbar, als Bereinigung nicht.

Den fremden Inhaber aus der Search Console werfen und die Bestätigungsdatei lassen. Er bestätigt sich fünf Minuten später neu.

Die Spam-Adressen per robots.txt sperren. Google rät ausdrücklich davon ab: Gesperrte Adressen bleiben im Index, wenn andere Seiten auf sie verweisen, und Google sieht nie, dass sie weg sind.

Die Überprüfung sofort anfordern. Ist die Seite noch nicht sauber, wird sie abgelehnt, und die Warnung bleibt länger stehen.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Die Bereinigung hat keinen Festpreis, weil niemand vorher weiß, wie viele Stellen betroffen sind; ich rechne sie nach Aufwand ab, 60 € pro Stunde, mit abgesprochenem Rahmen, und die Search Console gehört dazu. Danach hält die WordPress-Wartung für 49 € im Monat Kern und Plugins aktuell, sichert täglich außerhalb des Servers und überwacht die Seite, damit der nächste Versuch auffällt, bevor Google ihn indexiert. Wer wissen will, wie es um eine Seite steht, die noch nicht befallen ist, bekommt mit dem Sicherheits-Check für 290 € einen Bericht nach Dringlichkeit, Plugin-Stand inklusive.

Häufige Fragen#

Stand 11.10.2026. Google-Anleitung, Search-Console-Hilfe, Sucuri-Berichte und WP-CLI-Dokumentation an diesem Tag gelesen; die Google-Anleitung nennt noch Werkzeuge, die inzwischen in der URL-Prüfung aufgegangen sind.