KI-Crawler

KI-Crawler-Tracking zeigt, welche KI-Engines Ihre Website wirklich besuchen: GPTBot, ClaudeBot, PerplexityBot, Bingbot und mehr. Es ergänzt GEO-Audits: Audits sagen, ob Bots eine Seite erreichen können; Crawler-Tracking sagt, ob sie es tun.

Warum serverseitige Erfassung

KI-Trainings-Crawler führen kein JavaScript aus. Ein Google-Tag-Manager- oder JavaScript-Pixel sieht GPTBot oder ClaudeBot daher nie. Citlyze erfasst Crawler-Besuche serverseitig, wo der echte Request-User-Agent sichtbar ist, sodass auch Nicht-JavaScript-Crawler gezählt werden.

Die menschliche Hälfte ist anders: Besucher aus KI-Antworten führen JavaScript aus, daher genügt für KI-Traffic ein Browser-Snippet oder eine Tag-Manager-Installation (siehe KI-Traffic-Tracking installieren). Die serverseitigen Installationen auf dieser Seite erfassen beide Arten auf einmal.

Tracking installieren

Gehen Sie zu Einstellungen → Verbindungen → Website-Tracking und erzeugen Sie einen Site-Key. Der Key hat zwei Teile, Key-ID und Signiergeheimnis, die einmal angezeigt werden; kopieren Sie beide. Fügen Sie dann das passende Snippet für Ihre Plattform hinzu (Klick-für-Klick-Anleitungen zu jeder Option finden Sie unter KI-Crawler-Tracking installieren):

• Cloudflare (empfohlen): Worker-Snippet vor Ihre Site setzen.
• Vercel / Reverse Proxy: Middleware-Snippet ergänzen.
• WordPress: AI Crawler Control by Citlyze herunterladen, in wp-admin → Plugins hochladen, dann in den Einstellungen alle drei Felder ausfüllen: Tracker base URL (https://app.citlyze.com), Key ID und Signing secret. Prüfen Sie die Zustellung mit Send test event. Das Plugin meldet nichts, solange die Tracker-Basis-URL leer ist.
• Eigener Server / Node: für selbst gehostete Sites (AWS, GCP, Azure, Bare Metal, Container): das Express-artige Middleware-Snippet ergänzen (Node 20+). Es lässt sich an Fastify, Koa oder pures http anpassen, und andere Sprachen können das Signed-Beacon-Protokoll direkt implementieren.

Die Snippets für Cloudflare, Vercel und eigene Server lesen das Signiergeheimnis aus einer Umgebungsvariable, CITLYZE_SIGNING_SECRET (bei Cloudflare ein verschlüsseltes Worker-Secret), sodass es nie in Code steht, den Sie committen oder teilen. Das WordPress-Plugin speichert es stattdessen in seinen Einstellungen.

Jedes Ereignis wird mit Ihrem Geheimnis signiert, damit der Tracker gefälschte Beacons ablehnen kann.

Diese Signatur belegt, dass die Meldung von Ihrer Website stammt; sie sagt nichts darüber aus, wer der Besucher war. Zu bestätigen, dass ein Besucher wirklich GPTBot war, ist ein eigener Schritt, siehe So funktioniert die Verifizierung.

Standard-Shopify-Shops können keine serverseitige Erfassung ausführen, und Shopify unterstützt es nicht, einen Proxy (etwa Cloudflare) vor einen Shop zu setzen. Vollständiges Crawler-Tracking ist auf Standard-Shopify daher nicht verfügbar. Headless-Storefronts mit Hydrogen oder Oxygen führen serverseitigen Code aus und können das Snippet für eigene Server nutzen. Auch Webflow-Hosting kann keinen Servercode ausführen; auf Webflow Enterprise kann ein selbst verwalteter Reverse Proxy den Cloudflare-Worker oder das Snippet für eigene Server auf Proxy-Ebene ausführen.

Die Collectors melden, was mit jeder Anfrage passiert ist:

• Der Cloudflare Worker, die Middleware für eigene Server und das WordPress-Plugin senden den genauen HTTP-Status (200, 301, 404, 410, 500 usw.), auf dem die Fehler- und Weiterleitungs-Hinweise unten beruhen. Vercel-Middleware läuft, bevor die Antwort existiert, und kann ihn daher nicht senden; für Statuscodes auf Vercel nutzen Sie statt der Middleware den Vercel-Log-Drain unter Website-Tracking → Server-Logs.
• Bei einer Weiterleitung senden dieselben drei Collectors auch das Ziel: den Pfad bei einer Seite Ihrer eigenen Website, bei jeder anderen Website nur die Domain.
• Bei Crawler-Besuchen wird auch der Query-String gesendet (zum Beispiel ?page=2). Der Query-String menschlicher Besucher verlässt Ihre Website nie.

Ereignisse werden in signierten Batches übertragen. Ist Citlyze kurz nicht erreichbar, versuchen es der Cloudflare Worker und die Middleware für eigene Server einmal erneut, und das WordPress-Plugin bewahrt nicht zugestellte Ereignisse bis zu einen Tag in Ihrer WordPress-Datenbank auf und versucht es weiter. Eine Wiederholung wird nie doppelt gezählt. Jeder installierte Collector aktualisiert außerdem mindestens einmal täglich seine Liste bekannter Crawler, damit ein neuer Crawler ohne Update des Snippets oder Plugins erkannt wird. Die Seite Website-Tracking zeigt an, wenn eine neuere Version Ihres Snippets oder Plugins verfügbar ist.

Das WordPress-Plugin sieht jede Anfrage, die WordPress erreicht, auch Anfragen, die ein anderes Plugin weiterleitet, bevor die Seite gerendert wird. Nicht sehen kann es, was WordPress nie erreicht: Seiten aus einem Full-Page-Cache, Weiterleitungen Ihres Webservers oder CDNs und Anfragen, die eine Firewall blockiert, bevor WordPress lädt. Die Einstellungsseite des Plugins zeigt an, wenn es einen Seiten-Cache erkennt. Für stark gecachte Websites nutzen Sie den Cloudflare Worker oder laden Ihre Server-Logs hoch. Läuft WordPress hinter einem anderen Proxy oder Load Balancer als Cloudflare, tragen Sie in den Plugin-Einstellungen den Client-IP-Header und die Adressen des Proxys ein, damit Crawler anhand ihrer echten Adresse verifiziert werden können.

Verwenden Sie einen Collector pro Website. Melden ein Website-Collector und eine Server-Log-Quelle dieselbe Domain, wird jeder Besuch doppelt gezählt; die Seite Website-Tracking warnt Sie in diesem Fall.

Eigene Server und andere Sprachen

Der Tab für eigene Server liefert eine Node-Middleware, aber jeder Stack kann melden: Senden Sie signierte HTTPS-POST-Anfragen an https://app.citlyze.com/api/track mit einem JSON-Body (höchstens 256 KB) und Content-Type: application/json. Jede Anfrage enthält einen Batch mit 1 bis 50 Ereignissen.

Erforderliche Header:

Signatur berechnen:

1. Leiten Sie den Signaturschlüssel ab: den 64-stelligen SHA-256-Hexwert in Kleinbuchstaben Ihres Signatur-Secrets (die vollständige Zeichenkette ctk_...). Verwenden Sie die UTF-8-Bytes dieser Hex-Zeichenkette als HMAC-Schlüssel; dekodieren Sie sie nicht als Hex.
2. Bauen Sie die Nachricht: "3\n" + timestamp + "\n" + nonce + "\n" + bodyDigest, wobei bodyDigest der SHA-256-Hexwert in Kleinbuchstaben genau der gesendeten Body-Bytes ist. Jede erneute Serialisierung nach dem Signieren macht die Signatur ungültig.
3. x-aeo-signature ist der HMAC-SHA256 dieser Nachricht in Kleinbuchstaben-Hex, mit dem Schlüssel aus Schritt 1.

Bewahren Sie das Signiergeheimnis in einer Umgebungsvariable oder im Secret-Speicher Ihrer Plattform auf, nie im Quellcode.

Body-Felder:

• collector: ein kurzer Name für Ihre Integration, zum Beispiel my-app/1.0 (Buchstaben, Ziffern, ., _, / und -, bis zu 64 Zeichen).
• events: die Liste der Ereignisse. Jedes Ereignis hat diese Felder (Pflicht, sofern nicht anders angegeben):
  • occurredAt: Zeitpunkt der Anfrage in Millisekunden seit der Unix-Epoche. Ereignisse, die älter als 48 Stunden sind, werden ignoriert.
  • host: der Hostname der Anfrage ohne Port oder eine leere Zeichenkette. Ereignisse für einen Host, der weder die Domain Ihres Site-Keys noch eine ihrer Subdomains ist, werden ignoriert.
  • userAgent: der User-Agent des Besuchers, bis zu 1024 Zeichen.
  • path: der Anfragepfad mit führendem /, ohne Query-String oder Fragment, bis zu 2048 Zeichen.
  • query (optional): der Query-String ohne ?, nur für Crawler-Anfragen.
  • visitorIp: die Client-IP, wie Ihr Server sie sieht. Hinter einem Load Balancer oder Reverse Proxy nehmen Sie sie aus dem Forwarding-Header, den Ihr eigener Proxy setzt; dieses Feld prüft die Crawler-Verifizierung.
  • referrer: eine leere Zeichenkette oder eine https://-Referrer-URL ohne Query und Fragment. Nur relevant für menschliche Besuche aus KI-Antworten.
  • utmSource (optional): der Wert von utm_source, wenn ein Besuch aus einer KI-Antwort ohne Referrer ankommt.
  • status: der dreistellige HTTP-Status der Antwort oder unknown, wenn Sie melden, bevor die Antwort existiert.
  • method: die HTTP-Methode in Großbuchstaben.
  • redirectTarget (optional): bei einer 3xx-Antwort die Location, auf die sie verwies.

Melden Sie nur Anfragen, deren User-Agent automatisiert wirkt oder deren Referrer eine KI-Antwortmaschine ist, und senden Sie Batches nach der Antwort, nie während ein Besucher wartet. Scheitert ein Batch mit einem Netzwerkfehler, einem 429 oder einem 5xx, wiederholen Sie ihn mit derselben Nonce und demselben Body und einem neuen Zeitstempel: Ein bereits angekommener Batch wird an seiner Nonce erkannt und einmal gezählt. Ein 429 enthält einen Retry-After-Header. Jeder andere 4xx bedeutet, dass der Batch selbst ungültig ist; wiederholen Sie ihn nicht.

Optional können Sie einmal täglich die aktuelle Liste bekannter Crawler-Kennungen und KI-Referrer-Hosts von GET https://app.citlyze.com/api/track/registry abrufen, mit Ihrer Key-ID im Header x-aeo-key-id. Der Antwort-Header x-aeo-registry-signature ist der HMAC-SHA256 in Kleinbuchstaben-Hex von "citlyze-registry-1\n" + bodyDigest mit dem Schlüssel aus Schritt 1; verwenden Sie die Liste nur, wenn er übereinstimmt.

Um Ihre Integration zu prüfen, senden Sie einen Batch mit "test": true und einem einzigen Ereignis, dessen userAgent mit citlyze-connection-test/ beginnt und dessen path /citlyze-test ist. Ein korrekt signierter Test liefert HTTP 200 und speichert nichts; echte Batches liefern 204, egal ob die Besuche in Ihren Berichten landen.

Key erneuern oder widerrufen

Wenn ein Signiergeheimnis geleakt sein könnte (z. B. in ein Repo committet oder in einem Screenshot geteilt), nutzen Sie Erneuern neben dem Key. Die Erneuerung stellt ein neues Geheimnis für denselben Key aus: Key-ID, Name, Domain und die gesamte Historie bleiben erhalten, aber das alte Geheimnis funktioniert sofort nicht mehr; aktualisieren Sie daher umgehend CITLYZE_SIGNING_SECRET (oder die Plugin-Einstellung). Widerrufen ist etwas anderes: Der Key wird dauerhaft deaktiviert und das Tracking für diese Site stoppt.

Analytics lesen

Die Seite Analysieren → KI-Crawler-Aktivität → Überblick zeigt für den gewählten Zeitraum:

• Kopfkacheln: Crawler-Treffer gesamt, verschiedene Crawler, Top-Crawler und Trend
• Crawler-Besuche über die Zeit (Tagessummen)
• Wann Crawler kommen: Treffer nach Tageszeit
• Crawler-Trends über die Zeit (eine Linie je Crawler)
• Aufschlüsselung je Crawler mit Organisation, Zweck, Treffern und Trend
• meistgecrawlte Seiten (Top 10, mit Link zur vollständigen Liste)
• nicht erkannte Bots: Bot-artige User Agents, die keinem bekannten KI-Crawler zugeordnet werden konnten, gruppiert unter „Unbekannter Bot", damit neue Crawler früh auffallen

Tage und Stunden richten sich nach der Zeitzone Ihres Browsers: Ein Besuch um 21 Uhr in New York zählt zu diesem Tag, nicht zum nächsten. Die Tabelle pro Seite verwendet UTC-Tage.

Trends vergleichen nur vollständige Tage. Solange der heutige Tag läuft, bleibt er beim Vergleich außen vor, und jeder vollständige Tag wird mit dem entsprechenden Tag einen Zeitraum früher verglichen. Ein Crawler ohne Besuche im früheren Zeitraum zeigt Neu statt eines Prozentwerts, und wenn das Tracking erst nach Beginn des früheren Zeitraums startete, wird noch kein Trend angezeigt.

Nutzen Sie die Voreinstellungen (7/30/90 Tage), den eigenen Datumsbereich und den Crawler-Filter, um die Ansicht zu fokussieren. Workspaces mit mehreren getrackten Sites erhalten zusätzlich einen Site-Filter. Menschen, die über KI-Antworten kamen, finden Sie unter KI-Traffic.

So funktioniert die Verifizierung

Jeder Client kann GPTBot in seinen User-Agent schreiben. Ein User-Agent ist daher eine Behauptung, kein Beweis, und Citlyze behandelt ihn so: In die Crawler-Kennzahlen fließt nur Traffic ein, den wir unabhängig bestätigen konnten.

Jeder Besuch erhält eine von drei Konfidenzstufen:

• Verifiziert: Wir haben die Netzwerkidentität des Besuchers gegen etwas geprüft, das der Betreiber veröffentlicht. Nur diese zählen zu Ihren Summen.
• Wahrscheinlich: unterstützende Hinweise, etwa dass Ihr CDN die Anfrage als bekannten Bot markiert, aber keine unabhängige Bestätigung.
• Nicht verifiziert: Der User-Agent nannte einen Crawler und nichts sprach dagegen, wir konnten es aber nicht bestätigen. Wird separat ausgewiesen und nie zu Ihren Summen addiert.

Die Verifizierung nutzt jeweils das, was der Betreiber unterstützt:

Betreiber, die nichts Prüfbares veröffentlichen, können nur nicht verifiziert erreichen. Das ist eine Eigenschaft des Crawlers und kein Problem Ihrer Einrichtung, und genau deshalb gibt es getrennte Ansichten statt einer vermischten Zahl.

Zwei Dinge sind wichtig:

• Agent-Traffic wird getrennt gezählt. Werkzeuge, die Menschen selbst steuern, etwa ChatGPT Agent, erscheinen unter Agent-Aktivität statt in den Crawler-Summen: Ein Mensch, der klickt, ist nicht dasselbe Signal wie ein Crawler, der Sie indexiert.
• Manchmal können wir nicht prüfen: Die IP-Liste eines Betreibers kann vorübergehend nicht erreichbar sein. Solche Besuche bleiben nicht verifiziert, statt gezählt zu werden. So enthalten Ihre Summen nie etwas Unbestätigtes.

Gecrawlte Seiten

Analysieren → KI-Crawler-Aktivität → Gecrawlte Seiten ist die vollständige Detailansicht: jede Seite, die KI-Crawler im gewählten Zeitraum abgerufen haben, mit Suche, Sortierung und Seitenwechsel. Jede Zeile zeigt Zugriffe, Anteil am gesamten Crawler-Traffic, Trend gegenüber dem vorherigen Zeitraum, Fehler, Weiterleitungen, den Top-Crawler und das Datum des letzten Besuchs; klappen Sie eine Zeile auf, um die Aufteilung nach Crawler und die genauen Statuscodes zu sehen, die Crawler erhielten.

Über der Tabelle erscheinen bei Bedarf Hinweise:

• Gecrawlt, aber nie zitiert: Seiten, die KI-Engines abrufen, aber in Ihren verfolgten Antworten nie zitieren; Kandidaten für klarere, besser zitierbare Inhalte.
• Seiten mit Fehlern: Seiten, die Crawlern mit 4xx/5xx geantwortet haben. Defekte Seiten können weder gelesen noch zitiert werden.
• Weiterleitende Seiten: alte URLs, die Crawler weiter anfragen und von denen sie weitergeleitet werden. Verweisen Sie interne Links und Ihre Sitemap auf die endgültigen URLs.
• Zum ersten Mal abgerufene Seiten: Seiten, die seit Beginn des Trackings vor diesem Zeitraum kein KI-Crawler abgerufen hatte. Neue Inhalte, die hier erscheinen, haben Crawler gefunden.

Statuscodes und Weiterleitungen setzen einen Collector voraus, der sie meldet: den Cloudflare Worker, die Middleware für eigene Server, das WordPress-Plugin oder Server-Logs.

Die Tabelle lässt sich in Tarifen mit Datenexport als CSV herunterladen.

Crawl-Protokoll

Analysieren → KI-Crawler-Aktivität → Crawl-Protokoll listet jede Anfrage verifizierter KI-Crawler und signierter Agenten an Ihre Website auf, Tag für Tag und in der richtigen Reihenfolge, gruppiert in Crawl-Sitzungen (die Anfragen eines Crawlers ohne Lücke von mehr als 30 Minuten). Zu jeder Anfrage sehen Sie Uhrzeit, Seite und Query-String, den Statuscode und bei Weiterleitungen das Ziel sowie, ob der Crawler ihr in derselben Sitzung gefolgt ist. Seiten, die in einer Sitzung mehrfach abgerufen wurden, sind markiert.

Das Crawl-Protokoll enthält nur Anfragen verifizierter Crawler und signierter Agenten, nie andere Besucher, und speichert nie eine IP-Adresse oder einen User-Agent. Werte von Query-Parametern, die Zugangsdaten oder personenbezogene Daten enthalten könnten (etwa token oder email), werden durch redacted ersetzt. Wie viele Tage Sie zurückblicken können, hängt von Ihrem Tarif ab; siehe Tarife und Limits. Das Protokoll eines Tages lässt sich in Tarifen mit Datenexport als CSV herunterladen.

Daten über API und MCP abrufen

Crawler-Besuche sind nach der Installation programmatisch verfügbar:

• REST: GET /api/v1/crawler-events; siehe die AI-Crawler-Events-Ressource.
• MCP: das Tool list_crawler_events; siehe die MCP-Tool-Referenz.

Beides ist read-only und auf Ihren Workspace begrenzt. Die REST-Ressource filtert nach crawler_id, getrackter Site und exaktem path; menschliche Besuche aus KI-Antworten liefert GET /api/v1/ai-referrals.