Security

Gehackte Website erkennen, bevor Google sie abstraft

· 3 Min. Lesezeit

Der Auftritt sieht aus wie immer. Du klickst dich durch, alles normal. Trotzdem sind die Zugriffe eingebrochen, oder in der Suche steht unter deinem Namen etwas, das du nie geschrieben hast.

Das ist der Normalfall bei einem Angriff auf eine Website: Wer sie übernimmt, will sie nicht kaputtmachen — er will sie benutzen. Ein sichtbar verunstalteter Auftritt wird sofort repariert. Einer, der nur für Google und nur für Besucher aus der Suche anders aussieht, bleibt Monate unentdeckt.

Warum du es selbst nicht siehst#

Die verbreitete Technik ist einfach: Der Server liefert unterschiedliche Inhalte, je nachdem wer fragt.

Ein angemeldeter Redakteur bekommt die echte Seite. Wer die Adresse direkt eintippt, ebenfalls. Wer aber aus der Google-Suche kommt oder sich als Suchmaschinen-Crawler ausweist, bekommt etwas anderes: eingeschobene Verweise, fremdsprachige Unterseiten, Weiterleitungen auf Verkaufsangebote.

Deshalb bringt es nichts, den eigenen Auftritt anzusehen. Man muss ihn so ansehen, wie Google ihn sieht.

Die sechs Prüfungen#

1. Suche nach dir selbst, eingeschränkt auf die Domain. Der site:-Operator in der Google-Suche listet, was tatsächlich im Index steht. Tauchen dort Seiten auf, die du nie angelegt hast — oft mit Begriffen aus ganz anderen Branchen oder in fremder Sprache —, ist das der eindeutigste Befund, den es gibt.

2. Search Console, Abschnitt Sicherheitsprobleme. Google meldet dort erkannte Schadsoftware und Täuschungsversuche. Ein leerer Bericht ist kein Freispruch, ein voller ist ein Alarm. Sieh im selben Zug unter „Manuelle Maßnahmen" nach.

3. Die Seite ohne Browser abrufen. Ein direkter Abruf zeigt das ausgelieferte Markup, bevor ein Skript es verändern konnte. Vergleich, was dort steht, mit dem, was du im Browser siehst. Fremde Verweise am Ende des Markups sind ein klassisches Muster.

4. Die URL-Prüfung in der Search Console. Sie zeigt unter „Gecrawlte Seite anzeigen", was Google tatsächlich bekommen hat. Das ist der direkteste Weg, eine Täuschung zu entlarven: Was dort steht und was du siehst, muss dasselbe sein.

5. Nach Änderungen im Dateibestand suchen. Dateien mit einem Änderungsdatum, an dem niemand gearbeitet hat. Neue Dateien in Verzeichnissen, in denen es keine geben sollte — besonders in Upload-Ordnern, wo eigentlich nur Bilder liegen.

6. Die Benutzerliste. Ein zusätzliches Administratorkonto, das niemand angelegt hat, ist selten ein Versehen.

Woran man den Zeitpunkt festmacht#

Wenn die Zugriffe eingebrochen sind, hilft die Search Console beim Datieren: Der Verlauf der Impressionen zeigt oft einen scharfen Knick. Der liegt selten am Tag des Angriffs — er liegt an dem Tag, an dem Google die veränderten Seiten neu bewertet hat.

Das ist für die Aufräumarbeit wichtig: Eine Sicherung von vor dem Knick kann bereits kompromittiert sein.

Was danach zu tun ist, in dieser Reihenfolge#

Passwörter zuerst, und zwar alle: Redaktionssystem, Datenbank, Dateizugang, Hoster-Konto. Wer nur das Loch stopft und die Zugangsdaten stehen lässt, hat den Angreifer in einer Woche wieder drin.

Dann aufräumen, dann zurückspielen. Eine Sicherung ist nur so gut wie ihr Alter. Wenn unklar ist, wann es passiert ist, ist ein sauberer Neuaufbau mit übernommenen Inhalten oft schneller als die Suche nach der letzten unbelasteten Fassung.

Danach die Lücke schließen. Ein Angriff kommt selten über ein geknacktes Passwort, sondern über eine veraltete Erweiterung. Alles aktualisieren; was nicht mehr gepflegt wird, ersetzen.

Zuletzt Google Bescheid geben. Liegt eine manuelle Maßnahme vor, gibt es einen Antrag auf erneute Prüfung. Der wird abgelehnt, wenn noch Reste da sind — also erst prüfen, dann beantragen.

Und die Zeit danach#

Der Schaden bei der Sichtbarkeit verschwindet nicht mit dem Aufräumen. Google muss die Seiten neu abrufen und neu bewerten, und das dauert Wochen. In dieser Zeit sieht es so aus, als hätte das Aufräumen nichts gebracht.

Was vorbeugt und zehn Minuten kostet: eine Content-Security-Policy, die fremde Skripte gar nicht erst zulässt, und ein regelmäßiger Blick auf die ausgelieferten Kopfzeilen. Der Security-Scan prüft beides, und der Tech-Stack-Checker zeigt, welche Bausteine überhaupt im Einsatz sind — einschließlich der, von denen niemand mehr wusste, dass sie noch laufen.