WordPress-SEO-Spam: versteckte Casino- und Pharma-Links finden

Google zeigt für Ihre Domain plötzlich Casino-, Pharma- oder japanischsprachige Treffer, im Browser sieht Ihre Website aber ganz normal aus? Dann sollten Sie auf WordPress-SEO-Spam prüfen. Solche Treffer können auf eine laufende Kompromittierung hinweisen oder auf Spam, der nach einer Bereinigung noch im Index steht. Der Spam steckt entweder versteckt im Markup oder wird nur an Google und an Besucher ausgeliefert, die über die Suche kommen. Diese Anleitung zeigt, wie Sie Ihre Website mit den Augen von Google sehen, wo der Spam gespeichert ist und wie Sie ihn wieder aus dem Google-Index bekommen.

So sieht WordPress-SEO-Spam aus – und deshalb sehen Sie ihn nicht

Sie sehen ihn nicht, weil er nicht für Sie gedacht ist. Angreifer wollen die Reputation Ihrer Domain, nicht die Aufmerksamkeit Ihrer Besucher. Der eingeschleuste Code überspringt deshalb oft eingeloggte Nutzer und alle, die Ihre Adresse direkt eintippen.

Drei Formen kommen häufig vor:

• Hacklinks. Links zu Casino-, Pharma- oder Kreditseiten werden in Ihre Seiten eingefügt. Meist stecken sie in einem Block mit display:none, liegen außerhalb des sichtbaren Bereichs oder tauchen in einem Footer auf, den niemand liest.
• Der japanische Keyword-Hack. Tausende automatisch erzeugte Seiten mit japanischem Text und Shop-Links. Oft bringen sie eine eigene Sitemap mit, damit Google sie schnell findet.
• Bedingte Weiterleitungen und Cloaking. Der Code prüft User-Agent, IP-Adresse oder Referrer. Googlebot bekommt Spam-Inhalte, ein Besucher, der aus der Google-Suche klickt, wird umgeleitet, und Sie sehen die normale Seite.

Auch wenn Sie nichts davon sehen, ist der Schaden real. Rankings können abstürzen, Besucher verlieren das Vertrauen, und Google steckt Crawling-Aufwand womöglich in Spam-Seiten statt in Ihre echten Inhalte. Wenn Sie noch gar nicht sicher sind, ob Ihre Website gehackt wurde, beginnen Sie mit unseren 12 Anzeichen, dass Ihre WordPress-Website gehackt wurde.

Ihre Website so sehen, wie Google sie sieht

Fangen Sie bei Google selbst an. Suchen Sie nach site:example.com, scrollen Sie durch die Treffer und grenzen Sie dann ein:

site:example.com casino
site:example.com viagra OR cialis
site:example.com 激安
site:example.com inurl:.html

Treffer in einer Sprache, in der Sie nicht veröffentlichen, oder URL-Muster, die Ihre Website gar nicht verwendet, sind ein starkes Indiz.

Eine sinnvolle zusätzliche Prüfung ist die URL-Prüfung in der Google Search Console. Fügen Sie eine verdächtige URL (oder Ihre Startseite) ein, klicken Sie auf Live-URL testen und dann auf Getestete Seite ansehen. Der Tab „HTML“ zeigt das gerenderte Markup, das der Google-Crawler erhalten hat, der Screenshot zeigt, was er daraus gerendert hat. Durchsuchen Sie dieses HTML nach casino, href oder display:none. Der Live-Test nutzt allerdings Googles Prüf-Crawler, und den behandeln Angreifer unter Umständen anders als den Indexierungs-Crawler. Cloaking lässt sich damit aufdecken, ein sauberes Ergebnis schließt es aber nicht aus.

Einen groben Vergleich können Sie auch vom eigenen Rechner aus mit curl machen:

curl -s https://example.com/ -o normal.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ -o googlebot.html
diff normal.html googlebot.html
curl -sS -D - -o /dev/null -e "https://www.google.com/" https://example.com/

Der letzte Befehl sendet einen GET-Request mit Google als Referrer und gibt die Response-Header aus. Ein Location:-Header kann eine HTTP-Weiterleitung verraten. JavaScript-Weiterleitungen erkennt der Befehl jedoch nicht, und er bildet auch nicht jede Browser-Sitzung nach. Dazu kommt eine weitere Grenze: Prüft der eingeschleuste Code auf Googles IP-Bereiche, bekommt curl von Ihrem Laptop eine saubere Seite zu sehen. Ein sauberes curl-Ergebnis heißt also nicht, dass die Website sauber ist.

Öffnen Sie zum Schluss in der Search Console Indexierung > Seiten. Ein plötzlicher Anstieg bei indexierten oder gefundenen URLs, die Sie nicht veröffentlicht haben, deutet in der Regel auf generierte Spam-Seiten hin.

Wo sich SEO-Spam in WordPress versteckt

Sichern Sie vor der Untersuchung Dateien und Datenbank. Schützen Sie diese Sicherung gut, denn sie kann personenbezogene Daten und Zugangsdaten enthalten. Arbeiten Sie möglichst mit einer isolierten Kopie mit eingeschränktem Netzwerkzugang und führen Sie die folgenden Befehle in deren WordPress-Stammverzeichnis aus: Viele WP-CLI-Befehle laden WordPress und können dabei kompromittierten Code ausführen. Mit --skip-plugins --skip-themes sinkt dieses Risiko, mu-plugins und eine manipulierte wp-config.php laufen aber trotzdem. Wenn Sie die Kopie nicht sicher isolieren können, lassen Sie Ihren Hoster oder einen Incident-Response-Dienstleister untersuchen.

In der Datenbank

wp db search 'casino' --all-tables
wp db search 'viagra' --all-tables
wp post list --post_type=any --post_status=any --orderby=date --order=DESC --fields=ID,post_type,post_status,post_date,post_title
wp option list --search='widget_*'
wp option list --search='theme_mods_*'
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Prüfen Sie Beiträge und Post-Meta auf Links, die Sie nicht selbst gesetzt haben, und suchen Sie nach neuen Beiträgen oder Seiten mit merkwürdigen Titeln oder Status. In wp_options sollten Sie sich ansehen:

• Text- und HTML-Widgets
• Theme-Mods, in denen oft eigener Footer-Code steckt
• automatisch geladene Optionen (autoload) mit Namen, die Ihnen nichts sagen

Die Tabellennamen mit wp_ gehen vom Standard-Präfix aus; weicht Ihres ab, sehen Sie in der wp-config.php unter $table_prefix nach. Unbekannte Administratoren sind schon für sich genommen ein ernster Befund.

In den Dateien

wp core verify-checksums
wp plugin verify-checksums --all
ls -la wp-content/mu-plugins
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)
find . -type f -name "*.php" -mtime -14
grep -rnE "base64_decode|gzinflate|str_rot13|eval\(" wp-content --include=*.php

wp core verify-checksums vergleicht die Core-Dateien mit WordPress.org. wp plugin verify-checksums --all funktioniert nur für Plugins, die auf WordPress.org gehostet sind. Bei Premium-Plugins besorgen Sie sich eine frische Kopie beim Hersteller und vergleichen dagegen.

Die grep-Suche nach Verschleierungsmerkmalen liefert Fehlalarme, weil auch seriöse Plugins einige dieser Funktionen nutzen. Achten Sie auf lange codierte Zeichenketten und auf Code, der in seinem Umfeld keinen Sinn ergibt.

Prüfen Sie außerdem von Hand:

• die functions.php, header.php und footer.php Ihres Themes
• Plugin-Ordner, die Sie nicht installiert haben (Angreifer wählen gern unauffällige Namen)
• wp-config.php und index.php auf zusätzliche include-Zeilen
• .htaccess auf RewriteCond-Regeln für HTTP_USER_AGENT oder HTTP_REFERER
• das Web-Root auf Sitemap-XML-Dateien und google*.html-Verifizierungsdateien, die nicht von Ihnen stammen

Spuren des Angreifers in der Search Console prüfen

Angreifer bestätigen sich häufig selbst als Inhaber Ihrer Property in der Search Console. Anschließend reichen sie eigene Sitemaps ein, damit Google den Spam schneller indexiert. Solange sie diesen Zugang haben, können sie weiter URLs nachschieben.

Öffnen Sie Einstellungen > Nutzer und Berechtigungen und entfernen Sie alle Inhaber und Nutzer, die Sie nicht kennen. Entfernen Sie danach auch deren Bestätigungsmethode. Das kann eine google*.html-Datei im Web-Root sein, ein Meta-Tag in Ihrem Theme oder in den Header-Einstellungen oder ein TXT-Eintrag im DNS. Lassen Sie diesen Schritt weg, bestätigen sich die Angreifer einfach erneut.

Unter Indexierung > Sitemaps gehen Sie unbekannten Einreichungen nach: Auch legitime Plugins oder andere berechtigte Betreuer der Website können sie eingereicht haben. Sitemaps des Angreifers entfernen Sie aus der Search Console und beseitigen oder deaktivieren zusätzlich ihre Quelle auf der Website. Öffnen Sie dann Sicherheit und manuelle Maßnahmen und lesen Sie beide Berichte, Sicherheitsprobleme und Manuelle Maßnahmen. Die dort aufgeführten Beispiel-URLs zeigen, welchen Spam Google gefunden hat – eine brauchbare Checkliste für Ihre Bereinigung.

Spam entfernen, dann das Einfallstor schließen

Die sichtbaren Links zu löschen ist Kosmetik. Bleibt das Einfallstor offen, kommt der Spam meist zurück, oft schon nach wenigen Tagen.

1. Falls noch nicht geschehen: Sichern Sie den infizierten Zustand (Dateien und Datenbank) und bewahren Sie ihn als Beweismittel auf.
2. Entfernen Sie Spam-Beiträge, -Optionen, -Widgets und -Nutzer aus der Datenbank.
3. Ersetzen Sie veränderte Core-, Plugin- und Theme-Dateien durch frische Kopien aus vertrauenswürdigen Quellen. Infizierte Dateien nicht Zeile für Zeile bearbeiten.
4. Finden Sie das Einfallstor. Häufig sind es ein verwundbares oder „genulltes“ Plugin, ein gestohlenes Admin-Passwort oder geleakte FTP- bzw. Hosting-Zugangsdaten.
5. Schließen Sie es und ändern Sie danach alle Passwörter sowie die Salts in der wp-config.php.

Das vollständige Vorgehen beschreibt unser Plan zur Malware-Entfernung in WordPress. Den häufigsten Weg hinein behandelt der Artikel zu verwundbaren WordPress-Plugins.

Über dieselbe Lücke können auch Kundendaten offengelegt worden sein, etwa Formulareinträge oder Benutzerkonten. Dann können die Pflichten der DSGVO bei einer Datenpanne greifen; siehe die 72-Stunden-Meldepflicht nach DSGVO.

Spam aus Google entfernen: 410, Entfernungen und Überprüfungsantrag

Sind die generierten, reinen Spam-Seiten weg, sollten ihre URLs 404 (Not Found) oder 410 (Gone) zurückgeben; beides ist geeignet. Wurden echte Seiten verändert, stellen Sie diese wieder her, statt ihre URLs zu entfernen. Leiten Sie Spam-URLs nicht auf Ihre Startseite um. Google wertet das womöglich als Soft 404 und crawlt sie weiter.

Folgen die Spam-URLs einem Muster, das keine Ihrer echten Seiten verwendet, können Sie auf Serverebene mit 410 antworten:

RedirectMatch 410 "^/spam-pattern/"

location ~ ^/spam-pattern/ { return 410; }

In dringenden Fällen, etwa wenn bei der Suche nach Ihrem Markennamen Spam erscheint, nutzen Sie in der Search Console das Tool Entfernen (Removals). Es blendet URLs nur vorübergehend aus den Ergebnissen aus und ist keine dauerhafte Lösung. Lassen Sie die reinen Spam-URLs weiter 404/410 liefern und Google diese Antworten crawlen; sperren Sie sie nicht per robots.txt, denn Google muss den Entfernungsstatus sehen können. Details finden Sie in Googles Hilfe zum Tool „Entfernen“. Reichen Sie Ihre echte Sitemap erneut ein, damit Google die wichtigen Seiten neu crawlt.

Ob Sie eine Überprüfung brauchen, hängt von den Berichten ab:

• Führt der Bericht „Sicherheitsprobleme“ oder „Manuelle Maßnahmen“ ein offenes Problem auf, nutzen Sie dort die Option zur Überprüfung, nachdem Sie alle betroffenen Seiten bereinigt haben. Halten Sie den Antrag kurz und sachlich: was Sie gefunden haben, was Sie entfernt haben, wie der Angreifer hineinkam und was Sie geändert haben, um diese Lücke zu schließen.
• Führt keiner der beiden Berichte ein Problem auf, gibt es auch keine Überprüfung zu beantragen. Google muss die bereinigte Website dann neu crawlen.

Bleiben Sie bei den Erwartungen realistisch. Überprüfungen dauern, Spam-URLs verschwinden nach und nach, und Rankings erholen sich womöglich langsam oder nicht vollständig. Einen Zeitplan kann niemand versprechen.

Die nächste Einschleusung früh erkennen

SEO-Spam ist darauf ausgelegt, unbemerkt zu bleiben. Sie brauchen also Prüfungen, die nicht davon abhängen, dass Sie sich die Seite ansehen:

• Halten Sie eine Baseline für die Dateiintegrität vor und gehen Sie jeder Änderung nach, die nicht von Ihnen stammt.
• Führen Sie einmal im Monat eine site:-Suche für Ihre Domain durch.
• Aktivieren Sie E-Mail-Benachrichtigungen in der Search Console, damit Sicherheitsprobleme und manuelle Maßnahmen bei Ihnen ankommen.
• Durchsuchen Sie die Datenbank regelmäßig nach Link-Mustern wie den oben gezeigten.
• Behandeln Sie jedes neue Administratorkonto, das Sie nicht selbst angelegt haben, als Sicherheitsvorfall.

Das Plugin Security Audit & Compliance von secaudit.eu sucht nach verstecktem SEO-Spam und Hacklinks, Spam in der Datenbank, versteckten Administratoren und weiteren Anzeichen einer Kompromittierung. Außerdem vergleicht es Dateien mit einer Baseline. Es erkennt und meldet. Es bereinigt Ihre Website nicht automatisch, und das Einfallstor muss weiterhin ein Mensch schließen. → secaudit.eu

FAQ

Warum sehe ich den Spam nicht, wenn ich meine eigene Website aufrufe?

Der eingeschleuste Code entscheidet, wer was zu sehen bekommt. Meist nimmt er eingeloggte Nutzer aus und prüft User-Agent, IP-Adresse und Referrer. Manche Angriffe zielen auf Googlebot oder auf Besucher aus der Suche; andere zeigen Spam auch normalen Besuchern oder verstecken Links im Markup, das alle erhalten. Nutzen Sie den Live-Test der URL-Prüfung als eine von mehreren Prüfungen, aber denken Sie daran, dass Angreifer dem Prüf-Crawler andere Inhalte ausliefern können als dem Indexierungs-Crawler.

Wird Google meine Website dauerhaft abstrafen?

Garantien gibt es in keine Richtung. Bereinigen Sie gründlich, schließen Sie das Einfallstor und entziehen Sie dem Angreifer den Zugang in der Search Console. Beantragen Sie eine Überprüfung, wenn der Bericht „Sicherheitsprobleme“ oder „Manuelle Maßnahmen“ das verlangt. Die Erholung hängt danach davon ab, dass Google Ihre Website neu crawlt, und das braucht Zeit.

Reicht ein Sicherheits-Plugin, um SEO-Spam zu entfernen?

Ein Plugin kann Ihnen helfen, den Spam und die veränderten Dateien zu finden. Den Spam sauber zu entfernen und herauszufinden, wie der Angreifer hineingekommen ist, erfordert Handarbeit oder professionelle Hilfe. Sonst kommt der Spam in aller Regel zurück.