Bot-Erkennung: IP-Listen und kryptografische Signaturen im Vergleich

Eine HTTP-Anfrage mit dem User-Agent-Namen Applebot oder Googlebot ist dadurch noch nicht authentifiziert. Zwei hilfreiche Prüfungen sind der Abgleich einer Adresse mit veröffentlichten Crawler-Angaben und eine gültige HTTP-Nachrichtensignatur mit vertrauenswürdig zugeordneter Agentenkennung. Beide Verfahren brauchen Pflege; keines erteilt automatisch Zugriff.

Apple veröffentlicht eine CIDR-Liste für Applebot und beschreibt die DNS-Prüfung. Ein CIDR-Präfix bezeichnet einen Adressbereich. Nach einer Erweiterung kann eine gespeicherte Liste neue Bereiche übersehen. Der Quellenstand und die letzte erfolgreiche Aktualisierung gehören deshalb ins Prüfprotokoll.

Was eine IP-Prüfung belegt

Ein Treffer ordnet die beobachtete Absenderadresse einem für den Crawler veröffentlichten Bereich zu. Das gesamte Netz eines Hostinganbieters ist keine gleichwertige Freigabeliste. Umgekehrt kann auch gemietete Infrastruktur eine Adressprüfung ermöglichen, sofern der Crawler-Anbieter hinreichend konkrete Bereiche veröffentlicht.

Eine abgeschlossene TCP-Verbindung erschwert das einfache Fälschen der Quelladresse durch Außenstehende ohne Zugriff auf den Kommunikationsweg. Daraus folgt keine uneingeschränkte Identitätsgarantie: Ein Proxy verändert den sichtbaren Verbindungspartner, Infrastruktur kann kompromittiert sein, und HTTP/3 verwendet QUIC statt TCP. Aussagekräftig ist der Netzwerkendpunkt zusammen mit verlässlichen Anbieterangaben.

DNS-Prüfung ohne eigene Bereichsliste

Vorwärtsbestätigtes Reverse DNS verbindet Rückwärtsauflösung, anbieterspezifische Hostnamenprüfung und Vorwärtsauflösung. Ein Rückwärtseintrag allein reicht nicht. Der folgende Ablauf ist ein Schema; für die Beispieladresse wird keine echte DNS-Auflösung behauptet.

Beobachtete Client-IP: 192.0.2.10 (Dokumentationsadresse)
1. PTR-Abfrage liefert einen Hostnamen.
2. Normalisierter Hostname endet genau auf .applebot.apple.com
   mit mindestens einem Host-Label vor dieser Endung.
3. A/AAAA-Abfrage enthält die ursprüngliche Client-IP.
4. Erst dann: Adressprüfung bestanden.

Abgelehnt: fakeapplebot.apple.com
Abgelehnt: host.applebot.apple.com.attacker.example
Zeitüberschreitung oder Abweichung: nicht verifiziert.

Die erlaubte Domain stammt aus der Dokumentation des jeweiligen Crawlers, nicht aus einer beliebigen Angabe in der Anfrage. Groß-/Kleinschreibung, abschließender DNS-Punkt und exakte Domain-Grenzen müssen berücksichtigt werden. DNS-Caches brauchen begrenzte Gültigkeit; für Ausfälle und negative Antworten ist eine ausdrückliche Regel nötig. Das Verfahren spart die eigene CIDR-Kopie, bleibt aber von korrektem und erreichbarem DNS abhängig. Die Zahl der Netzabfragen hängt von Cache und Auflösung ab.

Pflege und Fehlerbehandlung

Bereichslisten brauchen eine maßgebliche HTTPS-Quelle, eine Prüfung der gelieferten CIDRs, einen atomaren Austausch und eine Überwachung von Alter und Abruffehlern. Ein leerer Download darf nicht ungeprüft eine gültige Liste ersetzen. Auch das Behalten des letzten gültigen Standes hat Grenzen: Neue oder entfernte Bereiche bleiben bis zur Aktualisierung unberücksichtigt. Die zulässige Überalterung gehört zur Zugriffsregel.

Eine veraltete Liste kann Crawler blockieren oder Traffic falsch einordnen. Beides tritt nicht zwangsläufig ein; eine konkrete Auswirkung auf die Indexierung muss auch nicht binnen eines Tages sichtbar werden. Eine fehlgeschlagene Prüfung bedeutet „nicht verifiziert“, nicht „menschlich“ oder zwangsläufig „bösartig“.

Was eine Signatur ergänzt

RFC 9421 definiert Signaturen über ausgewählte Bestandteile einer HTTP-Nachricht. Web Bot Auth ergänzt das Auffinden und Zuordnen von Prüfschlüsseln für automatisierten Traffic. Stand 24. Oktober 2026 bleibt das betreffende IETF-Protokoll ein Internet-Draft, kein fertiger RFC. Implementierungen können unterschiedliche Profile verwenden; Googles experimentelle und Cloudflares dokumentierte Integration sind nicht ohne Weiteres austauschbar.

Eine erfolgreiche Prüfung bindet die signierten Inhalte an einen Schlüssel zur akzeptierten Agentenkennung. Ein selbst veröffentlichter Schlüssel belegt für sich weder die rechtliche Identität eines Unternehmens noch die Berechtigung zum Lesen geschützter Inhalte. Vertrauen in die Kennung und Zugriffsregeln bleiben eigene Entscheidungen. Ein gestohlener Schlüssel widerlegt zudem die Annahme, dass ausschließlich der beabsichtigte Agent signieren kann.

Signaturen können einen Wechsel von Hosting oder Quell-IP überstehen. Schlüsselwechsel, Widerruf, Cache-Ablauf, sicherer Schlüsselabruf und kompatible Prüfung erfordern dennoch Arbeit auf beiden Seiten. Google weist ausdrücklich darauf hin, dass nicht jede Anfrage teilnehmender Agenten signiert ist. Eine fehlende Signatur belegt daher allein keine Täuschung.

Den Prüfweg festlegen

Eine allgemeine Pflicht zur IP-Prüfung vor der Signaturprüfung besteht nicht. Anbieter, verfügbare Nachweise, Antwortzeit und Zugriffsregeln bestimmen die Reihenfolge. Sinnvoll sind getrennte Ergebnisse: Adresse bestätigt, Signatur bestätigt, Prüfung fehlgeschlagen oder nicht verfügbar sowie Zugriff erlaubt oder abgelehnt. Authentifizierung liefert einen Baustein der Entscheidung; Abruflimits und Inhaltsbeschränkungen gelten weiterhin.

Praxisprüfung: GA4-Traffic-Gruppen untersuchen

Der GA4-Traffic-Prüfer gruppiert gemeldete Daten nach Browser, Betriebssystem, Land und Sitzungsquelle/-medium. Statt einer Bot-Wahrscheinlichkeit erscheinen konkrete Hinweise: keine Sitzungen mit Interaktion, durchschnittliche Dauer null, fehlende Dimensionen oder ein Automationsbegriff im Browsernamen. Eine veränderbare Mindestzahl nimmt kleine Gruppen von diesen Regeln aus; ihre Zeilen bleiben sichtbar.

Diese Beobachtungen bestätigen keine Crawler-Identität. Kampagnen, Einwilligungsverhalten, unvollständige Erfassung oder interne Tests können ähnliche Muster erzeugen. Land und Direct-Traffic beweisen keine Automation. Der CSV-Export unterstützt den Vergleich mit Server- oder CDN-Protokollen; dieser Bericht enthält jedoch weder Client-IP-Adressen noch geprüfte Signaturen. Es werden keine Daten ausgeschlossen oder verändert.

Google schließt bekannte Bots automatisch aus und zeigt deren ausgeschlossene Anzahl in GA4 nicht an. Ein Ergebnis ohne passende Regeln bedeutet daher nur, dass die gewählten Prüfungen in den gelieferten Zeilen nichts fanden. Quellen: Googles Ausschluss bekannter Bots und Data-API-Schema.