Cloaking erkennen: Wenn Googlebot etwas anderes sieht

Was Cloaking technisch bedeutet

Technisch ist Cloaking eine Fallunterscheidung im Auslieferungsweg. Der Server oder ein vorgelagertes Skript liest ein Merkmal der Anfrage, meist den User-Agent, manchmal die Adresse der Gegenstelle, den Referrer oder das Gerät, und liefert je nach Ergebnis eine andere Antwort aus. Google nennt als Beispiel das Einfügen von Text oder Schlüsselwörtern in eine Seite, das nur dann geschieht, wenn die anfragende Kennung zu einer Suchmaschine gehört und nicht zu einem menschlichen Besucher (Google Search Central). Ein zweites Muster ist die Weiterleitung, deren Ziel vom Referrer, vom User-Agent oder vom Gerät abhängt (Google Search Central) und die sich deshalb mit denselben Mitteln aufdecken lässt wie eine unsaubere Weiterleitungskette. Beide Muster haben gemeinsam, dass sie im normalen Seitenaufruf unsichtbar bleiben: Der Browser des Betreibers erfüllt die Bedingung nicht, unter der die abweichende Antwort überhaupt entsteht.

Nicht jede Antwort, die sich je nach Anfrage unterscheidet, ist Cloaking. Eine Sprachweiche nach Accept-Language, eine mobile Fassung, eine Bezahlschranke oder ein laufender A/B-Test verändern die Antwort ebenfalls und sind trotzdem zulässig, solange sie Suchmaschine und Besucher gleich behandeln. Der Unterschied liegt im Adressaten: Zulässige Anpassung richtet sich nach dem, was der Besucher braucht, Cloaking richtet sich danach, wer fragt. Für die Messung folgt daraus eine strenge Vorgabe. Sie vergleichen nicht zwei beliebige Abrufe, sondern zwei Abrufe, die sich ausschließlich im Kennzeichen des Anfragenden unterscheiden. Alles andere, also Sprache, Gerätebreite, Einstiegspfad und Uhrzeit, halten Sie konstant. Sonst messen Sie die eigene Testanordnung mit und erklären am Ende einen Unterschied, den Sie selbst erzeugt haben.

• Gleiches Kennzeichen, gleiche Antwort: Zwei Abrufe mit demselben User-Agent, derselben Sprache und derselben Region liefern denselben Rumpf. Weicht er trotzdem ab, liegt die Ursache nicht beim Besucher, sondern im Dokument.
• Unterschiedliches Kennzeichen, gleiche Substanz: Eine mobile Fassung darf anders aussehen, muss aber dieselben Aussagen, Verweise und Preise tragen.
• Deklarierte Abhängigkeit: Hängt die Antwort tatsächlich von einem Anfragefeld ab, gehört das in den Vary-Kopf. RFC 9110 beschreibt dessen Wert als Platzhalter oder als Liste der Anfragefelder, die bei der Auswahl der ausgelieferten Repräsentation eine Rolle gespielt haben können (RFC 9110).
• Kein Sonderweg für Suchmaschinen: Eine Regel, die ausschließlich für die Kennung eines Crawlers greift, ist der Kern des Problems, unabhängig davon, ob sie jemand absichtlich gesetzt oder untergeschoben hat.

Warum ein Einbruch ausgerechnet so aussieht

Der häufigste Weg zu einer cloakenden Website führt nicht über eine Entscheidung im Marketing, sondern über eine fremde Datei im Verzeichnis. Google beschreibt das Ziel solcher Einschleusungen deutlich: Es gehe darum, Inhalte hinzuzufügen, die Suchmaschinen sehen können, die für Betreiber und Besucher aber schwerer zu bemerken sind (Google Search Central). Dieselbe Dokumentation hält fest, dass ein Angreifer nach einem Einbruch typischerweise Cloaking einsetzt, um die Entdeckung zu erschweren (Google Search Central). Die Search Console beschreibt denselben Vorgang aus der anderen Richtung: Im Bericht zu Sicherheitsproblemen heißt es, Angreifer könnten die Spam-Inhalte mit Cloaking-Techniken verbergen, um von Seitenbetreibern nicht bemerkt zu werden (Google Search Console-Hilfe).

Aus dieser Bauart folgt ein Messproblem, das viele Betriebe erst nach Wochen bemerken. Die Startseite bleibt unauffällig, weil sie beobachtet wird. Betroffen sind stattdessen tief liegende Adressen, oft neu angelegte Verzeichnisse, die niemand im Menü verlinkt. Der Aufruf im eigenen Browser liefert dort eine leere Seite oder einen Fehler, erst der Abruf mit einer Crawler-Kennung fördert die eingeschleusten Verweise zutage. Wer den Bestand nur an der Oberfläche prüft, sieht davon nichts, während sich der Index weiter füllt. Dieselbe Blindstelle kennt jeder, der schon einmal eine Verunstaltung einer Website untersucht hat: Der sichtbare Teil ist selten der Teil, an dem der Schaden entsteht.

Vier Abrufe, die den Unterschied zeigen

Die Messung selbst ist unspektakulär. Sie holen dieselbe Adresse mehrfach, verändern dabei genau ein Merkmal und vergleichen die Antworten. Vier Abrufe reichen in der Regel, um den typischen Fall zu erfassen. Wichtiger als die Zahl ist die Reihenfolge der Fragen. Zuerst: Unterscheidet sich überhaupt etwas? Erst danach: Woran liegt es? Wer beide Fragen mischt, landet erfahrungsgemäß schnell bei einer sauberen Erklärung für einen Unterschied, den es gar nicht gibt.

Zwei Punkte an dieser Aufstellung werden regelmäßig übersehen. Erstens ist der Vergleich nur dann aussagekräftig, wenn er den Rumpf betrifft und nicht die Kopfzeilen: Ein abweichendes Set-Cookie oder ein anderer Date-Wert bedeutet nichts. Zweitens ersetzt kein Abruf den Blick ins Serverprotokoll. Dort steht, welche Antwort ein tatsächlich verifizierter Crawler bekommen hat, und nur dort lässt sich eine Weiche erkennen, die an der Herkunftsadresse hängt statt am Kennzeichen. Wie man diese Adresse hinter Proxys und Lastverteilern überhaupt korrekt ausliest, ist ein eigenes Thema und im Beitrag zur echten Besucher-IP beschrieben.

Warum das Kennzeichen allein nichts belegt

Ein User-Agent ist ein frei wählbarer Textblock. Google weist ausdrücklich darauf hin, dass die von Googlebot verwendete Kennung häufig von anderen Crawlern nachgeahmt wird, und empfiehlt, eine auffällige Anfrage über eine Rückwärtsauflösung der Quelladresse oder über den Abgleich mit den veröffentlichten Adressbereichen zu prüfen (Google Search Central). Daraus folgen zwei Dinge. Für die Messung heißt es: Ihr eigener Abruf mit Googlebot-Kennung ist ein Test der Weiche, kein Abruf durch Google. Für den Betrieb heißt es: Bevor Sie eine Anfrage im Protokoll als Crawler verbuchen, gehört sie verifiziert, sonst schreiben Sie Fremdverkehr einer Suchmaschine zu. Wie stark dieser Anteil inzwischen wiegt und wie er sich aus den Auswertungen heraushalten lässt, zeigt der Beitrag zum Filtern von Bot-Verkehr.

Der offizielle Weg besteht aus zwei Schritten mit je einer Prüfung. Zuerst eine Rückwärtsauflösung der zugreifenden Adresse aus dem Protokoll; der zurückgegebene Name muss auf googlebot.com, google.com oder googleusercontent.com enden (Google). Danach eine Vorwärtsauflösung dieses Namens, deren Ergebnis wieder dieselbe Adresse sein muss (Google). Wer das nicht bei jeder Anfrage rechnen möchte, nimmt die veröffentlichte Liste: Die Datei mit den Adressbereichen der allgemeinen Google-Crawler führte am 4. September 2026 genau 317 Präfixe, davon 170 in IPv4 und 147 in IPv6 (Google). Diese Liste ändert sich, deshalb gehört sie geholt und nicht abgeschrieben.

1. Rückwärtsauflösung der zugreifenden Adresse aus dem Serverprotokoll ausführen.
2. Prüfen, ob der zurückgegebene Name auf googlebot.com, google.com oder googleusercontent.com endet (Google).
3. Vorwärtsauflösung genau dieses Namens ausführen.
4. Prüfen, ob das Ergebnis wieder die ursprünglich zugreifende Adresse ist (Google). Erst dann ist die Anfrage zugeordnet, vorher ist sie eine Behauptung.

Die Search Console sieht nicht dasselbe

Der naheliegende Reflex ist die URL-Prüfung in der Search Console. Sie ist nützlich, beantwortet aber eine andere Frage als erwartet. Der Bericht zur indexierten Fassung zeigt nach Angabe der Hilfe ausdrücklich nicht den Live-Stand, sondern die zuletzt indexierte Version einer Seite (Google Search Console-Hilfe). Die Live-Prüfung daneben holt die Adresse tatsächlich in Echtzeit (Google Search Console-Hilfe), allerdings mit einer eigenen Kennung. Genau dieser Unterschied entscheidet darüber, ob Sie eine cloakende Weiche zu sehen bekommen oder nicht.

Diese Kennung heißt Google-InspectionTool. Google führt dazu zwei Zeichenfolgen: eine Desktop-Variante Mozilla/5.0 (compatible; Google-InspectionTool/1.0) und eine Mobil-Variante, die mit Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) beginnt und ebenfalls auf (compatible; Google-InspectionTool/1.0) endet (Google). Für eine Weiche, die Zeichenketten vergleicht, ist der Unterschied erheblich: Ein Muster auf Mozilla/5.0 (compatible; trifft nur die Desktop-Variante. Google hält dazu fest, dass Crawling-Vorgaben an diese Kennung die Testwerkzeuge der Suche betreffen und keine Wirkung auf die Google-Suche oder andere Produkte haben (Google). Für die Cloaking-Frage ist das der entscheidende Punkt: Eine Weiche, die auf die Zeichenfolge Googlebot prüft, greift bei der Live-Prüfung nicht. Das Werkzeug meldet eine saubere Seite, während der eigentliche Crawl etwas anderes bekommt. Die Hilfe grenzt den Anspruch zusätzlich selbst ein, denn die Live-Prüfung prüft nicht, ob eine Seite den Qualitäts- und Sicherheitsrichtlinien entspricht, und deckt manuelle Maßnahmen, Entfernungen oder vorübergehend gesperrte Adressen nicht ab (Google Search Console-Hilfe).

• Was die indexierte Fassung zeigt: den Stand, den Google zuletzt aufgenommen hat, samt kanonischer Adresse und Indexierungsentscheidung (Google Search Console-Hilfe).
• Was die Live-Prüfung zeigt: ob die Adresse in diesem Moment erreichbar und darstellbar ist (Google Search Console-Hilfe).
• Was beide nicht zeigen: ob die Antwort für die Kennung Googlebot anders ausfällt als für die Kennung des Prüfwerkzeugs.
• Woran das liegt: Die Live-Prüfung bestätigt, dass Google-InspectionTool auf die Seite zugreifen kann, und nicht mehr (Google Search Console-Hilfe). Ein sauberer Befund dort ist eine Teilaussage, keine Entlastung.

Auch als Dauerbeobachtung taugt dieser Weg nur begrenzt. Die URL-Prüfung über die Schnittstelle ist je Website auf 2000 Abfragen pro Tag und 600 Abfragen pro Minute gedeckelt (Google). Für eine Handvoll Adressen reicht das bequem, für einen Bestand mit mehreren tausend Seiten ist es eine Stichprobe mit Kappungsgrenze. Die laufende Beobachtung gehört deshalb auf den eigenen Server, wo Sie Takt, Umfang und Vergleichsverfahren selbst bestimmen. Wie leise eine solche Abweichung im Index wirkt, zeigt der Beitrag über eine versehentlich ausgelieferte noindex-Angabe: Sichtbar wurde sie erst, als die Positionen fielen.

Vergleichen ohne Fehlalarm

Ein belastbarer Vergleich besteht aus drei Teilen: Normalisierung, Prüfsumme und Schwelle. Die Normalisierung entfernt alles, was sich zwischen zwei Abrufen ohnehin ändert. Die Prüfsumme macht aus dem Rest einen Wert, den man speichern, vergleichen und in eine Meldung schreiben kann. Die Schwelle entscheidet, ab welchem Unterschied ein Alarm gerechtfertigt ist. Fehlt einer der drei Teile, entsteht entweder ein Dauerbefund oder ein blinder Fleck. Und ein Prüfer, der kein einziges Mal anschlägt, ist keine Entwarnung, sondern eine Stelle, an der nichts gemessen wurde. Dasselbe Muster beschreibt der Beitrag zum Erkennen von Inhaltsänderungen für den einfacheren Fall ohne Kennzeichenwechsel.

import hashlib
import re

RAUSCHEN = [
    re.compile(r'name="csrf[-_]token"\s+content="[^"]*"', re.I),
    re.compile(r'nonce="[^"]*"', re.I),
    re.compile(r'\b\d{2}\.\d{2}\.\d{4},\s*\d{2}:\d{2}\b'),
    re.compile(r'<!--.*?-->', re.S),
]

def normalisieren(rumpf: str) -> str:
    """Entfernt alles, was sich zwischen zwei Abrufen ohnehin ändert."""
    for muster in RAUSCHEN:
        rumpf = muster.sub("", rumpf)
    return re.sub(r"\s+", " ", rumpf).strip()

def hashwert(rumpf: str) -> str:
    return hashlib.sha256(normalisieren(rumpf).encode("utf-8")).hexdigest()

def vergleich(abrufe: dict) -> dict:
    """abrufe: {kennzeichen: rumpf oder None}. None heißt: nicht gemessen."""
    summen = {}
    for kennzeichen, rumpf in abrufe.items():
        if rumpf is None:
            summen[kennzeichen] = {"gemessen": False, "grund": "Abruf fehlgeschlagen"}
        else:
            summen[kennzeichen] = {"gemessen": True, "summe": hashwert(rumpf)}
    werte = [e["summe"] for e in summen.values() if e["gemessen"]]
    return {
        "summen": summen,
        "abweichung": len(set(werte)) > 1 if len(werte) > 1 else None,
    }

Zwei Details in diesem Gerüst wiegen schwerer als der Rest. Ein fehlgeschlagener Abruf bekommt kein Ergebnis, sondern das Feld gemessen: false mit einem Grund. Ein Zeitüberlauf, der als „keine Abweichung“ verbucht wird, ist die teuerste Art, sich in Sicherheit zu wiegen, weil sie sich in jedem Bericht wie ein grünes Ergebnis liest. Und der Rückgabewert für die Abweichung bleibt leer, solange weniger als zwei Abrufe gelungen sind: Ein Vergleich mit einem einzigen Wert ist kein Vergleich, sondern eine Zahl mit Zeitstempel.

Zum Vergleich gehört ein Blick auf den Vary-Kopf. Wenn Ihre Antwort tatsächlich vom User-Agent abhängt, muss dieses Feld dort stehen, sonst liefert der nächste Zwischenspeicher eine Kopie an den falschen Empfänger. Steht dort nichts und die Antworten unterscheiden sich trotzdem, haben Sie entweder eine undeklarierte Weiche oder einen Fehlalarm aus der eigenen Normalisierung. Beides ist einen Blick wert, aber nur eines davon ist ein Vorfall. Wer diesen Abgleich nicht von Hand fahren will, findet die Bausteine dafür im Beitrag über automatisiertes technisches SEO-Monitoring.

Was in den Alarm gehört

Ein Alarm, der nur meldet, dass sich Inhalt geändert habe, wird nach der dritten Meldung weggeklickt. Nützlich wird er erst, wenn er den Unterschied benennt und die Lage im Dokument mitliefert. Die Frage, die eine Meldung beantworten muss, lautet nicht „hat sich etwas geändert“, sondern „welcher Abruf weicht wovon ab, an welcher Stelle, und seit wann“. Damit wird aus einer Benachrichtigung eine Entscheidungsgrundlage, und der Empfänger kann in derselben Minute beurteilen, ob er nachts aufstehen muss oder morgens nachsieht.

• Welche Adresse: vollständig, mit Protokoll und etwaigen Parametern, nicht nur der Pfad.
• Welche zwei Abrufe: jeweils mit dem gesetzten Kennzeichen im Klartext, damit die Messung nachvollziehbar bleibt.
• Was sich unterscheidet: Anzahl geänderter Zeilen, neue ausgehende Verweise mit Zielhost, veränderte Meta-Angaben, veränderte Indexierungsregeln.
• Seit wann: der letzte Zeitpunkt, zu dem beide Abrufe übereinstimmten. Ohne diesen Wert lässt sich der Vorfall zeitlich nicht eingrenzen.
• Was nicht gemessen wurde: fehlgeschlagene Abrufe, Zeitüberläufe, abgewiesene Anfragen. Eine Meldung ohne diesen Abschnitt liest sich wie Vollständigkeit, ohne eine zu sein.

Der Weg, auf dem diese Meldung ankommt, entscheidet über ihren Wert. Ein Befund in einem Dachbericht, den jemand am Monatsende öffnet, hilft bei einem laufenden Einbruch nicht. Deshalb gehören solche Abweichungen auf den Kanal, der bei Ihnen tatsächlich gelesen wird, sei es Postfach, Team-Chat oder Bereitschaftsweg. In XICTRAQ übernehmen das die Benachrichtigungen, die denselben Befund über mehrere Wege ausspielen und dabei mehrfache Meldungen zum selben Vorfall zusammenfassen.

Ein Prüfer, der kein einziges Mal anschlägt, ist keine Entwarnung. Er ist eine Stelle, an der nichts gemessen wurde. Der Unterschied zwischen beidem entscheidet, ob ein Bericht eine Grundlage ist oder eine Beruhigung.

— XICTRAQ

Wenn der Befund echt ist

Bestätigt sich eine Abweichung, ändert sich die Reihenfolge der Arbeit. Zuerst wird der Zustand gesichert, dann wird geräumt, nicht umgekehrt. Wer die eingeschleuste Datei sofort löscht, verliert die Spur, die erklärt, wie sie hineinkam, und findet den zweiten Zugang nicht. Erfahrungsgemäß ist genau dieser zweite Zugang der Grund, warum dieselbe Website nach vier Wochen wieder auffällt.

1. Beide Abrufe unverändert sichern, mit Kopfzeilen, Zeitstempel und Prüfsumme.
2. Serverprotokolle des betroffenen Zeitraums kopieren, bevor die Rotation sie überschreibt.
3. Zugänge prüfen und erneuern: Anwendungskonten, Datenbankzugänge, Bereitstellungsschlüssel, Erweiterungen mit Schreibrechten.
4. Den Auslöser der Weiche suchen, nicht nur die Ausgabe: meist eine eingeschleuste Datei, ein veränderter Anwendungscode oder eine Regel in der Serverkonfiguration.
5. Aus einem als sauber bekannten Stand zurückspielen und den ausgelieferten Stand danach erneut mit allen vier Kennzeichen vergleichen.
6. Erst zum Schluss in der Search Console prüfen, ob eine Sicherheitsmeldung oder eine manuelle Maßnahme vorliegt, und gegebenenfalls die erneute Überprüfung beantragen.

Für den letzten Punkt lohnt der Blick in die Liste der manuellen Maßnahmen. Dort gibt es einen eigenen Eintrag für Cloaking und irreführende Weiterleitungen; die Hilfe beschreibt den Anlass so, dass eine Website Nutzern andere Seiten zeigen könnte, als Google sie sieht, oder Nutzer auf eine andere Seite weiterleitet, als Google gesehen hat (Google Search Console-Hilfe). Eine solche Maßnahme trifft Sie auch dann, wenn die Ursache ein Einbruch war. Deshalb gehört die Beseitigung der Ursache vor den Antrag auf erneute Überprüfung und nicht danach. Welche Kopfzeilen, Skripte und Zugänge dabei mitzuprüfen sind, deckt der Security-Scan in einem Durchlauf ab.

Laufend messen statt einmal prüfen

Eine einmalige Prüfung beantwortet die Frage für den Moment des Abrufs. Cloaking ist aber ein Zustand mit Datum: Es beginnt, wenn eine Regel gesetzt wird, und endet, wenn sie verschwindet. Dazwischen liegen die Wochen, in denen sich der Index füllt. Auch der Crawl selbst läuft in einem Takt, den Sie nicht bestimmen. Google gibt als Größenordnung an, dass Googlebot eine Website in der Regel nicht häufiger als etwa einmal alle paar Sekunden abruft (Google Search Central), und liest dabei je Datei eines unterstützten Typs die ersten 2 MB, bei einer PDF-Datei die ersten 64 MB (Google Search Central). Was danach im Dokument steht, fließt nicht in die Indexierung ein. Eine eingeschleuste Verweisliste ganz unten kann damit je nach Dateigröße sichtbar sein oder nicht, was die Beurteilung eines Einzelbefunds zusätzlich erschwert.

Die zweite Zeitachse ist die robots.txt. RFC 9309 empfiehlt, eine zwischengespeicherte Fassung nicht länger als 24 Stunden zu verwenden, sofern die Datei erreichbar ist (RFC 9309), und schreibt eine Auswertungsgrenze von mindestens 500 Kibibyte vor (RFC 9309). Wer eine Regel ändert, sieht die Wirkung also frühestens am Folgetag, und wer die Datei nur einmal im Quartal ansieht, bemerkt eine untergeschobene Zeile erst, wenn der Schaden im Index steht. Zur Einordnung: In der Auswertung des Web Almanac 2024 sprechen 76,6 Prozent der im Desktop-Durchlauf gefundenen robots.txt-Dateien die Sammelkennung * an, während 5,9 Prozent eine eigene Regel für Googlebot führen (Web Almanac 2024). Eine gezielte Ausnahme für eine einzelne Crawler-Kennung ist damit selten genug, um aufzufallen, sofern jemand hinsieht. Welche Fehler in dieser Datei am häufigsten vorkommen, steht im Beitrag zu Fehlern in der robots.txt.

Genau dafür ist ein Beobachtungssystem da. XICTRAQ ruft überwachte Adressen in festem Takt ab, hält den ausgelieferten Stand fest und meldet Abweichungen. Das SEO-Monitoring verfolgt dabei Titel, Beschreibung, kanonische Adresse und Indexierungsregeln, die Erreichbarkeitsprüfung liefert den Takt und den Statuscode dazu. Besonders vor Zeiträumen mit erhöhtem Verkehr lohnt es sich, beides vorher scharf zu stellen statt mittendrin, wie der Beitrag zu Lastspitzen im vierten Quartal zeigt.

Der organisatorische Gewinn ist dabei größer als der technische. Wer jederzeit sagen kann, welcher Stand unter welchem Kennzeichen ausgeliefert wurde und wann er sich zuletzt geändert hat, beantwortet Rückfragen aus dem Bestand statt aus der Erinnerung. Das gilt gegenüber Kunden ebenso wie gegenüber einer Suchmaschine, bei der eine erneute Überprüfung beantragt wird. Was ein solches Konto kostet und welche Mindestlaufzeit dabei gilt, steht auf der Preisübersicht; wer den Ablauf zuerst ansehen möchte, findet ihn in der Live-Demo ohne Anmeldung.