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 KI-Crawler → Tracking installieren 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 Tracker 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.

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.

Der Cloudflare-Worker und die Middleware für eigene Server melden den HTTP-Status jeder gecrawlten Anfrage; das speist die Fehler-Insights weiter unten. Das WordPress-Plugin läuft, bevor die Seite gerendert wird, und unterscheidet daher nur 404 von allem anderen; die Vercel-Middleware läuft, bevor die Antwort existiert, und kann gar keinen Status melden.

WordPress-Ganzseiten-Caches und CDNs können antworten, ohne das Plugin auszuführen. Nutzen Sie für stark gecachte Sites den Cloudflare-Worker.

Eigene Server und andere Sprachen

Der Tab „Eigener Server" liefert eine Node-Middleware, aber jeder Stack kann melden: Ein Beacon ist ein einzelner signierter HTTPS-POST an https://app.citlyze.com/api/track mit einem JSON-Body (höchstens 32 KB) und Content-Type: application/json.

Erforderliche Header:

Die Signatur berechnen:

1. Signierschlüssel ableiten: der kleingeschriebene 64-Zeichen-Hex-SHA-256 Ihres Signiergeheimnisses (der vollständige ctk_...-String). Verwenden Sie die UTF-8-Bytes dieses Hex-Strings als HMAC-Schlüssel; hex-dekodieren Sie ihn nicht.
2. Nachricht bauen: "2\n" + timestamp + "\n" + nonce + "\n" + bodyDigest, wobei bodyDigest der kleingeschriebene Hex-SHA-256 exakt der Body-Bytes ist, die Sie senden. Jede erneute Serialisierung nach dem Signieren macht die Signatur ungültig.
3. x-aeo-signature ist der kleingeschriebene Hex-HMAC-SHA256 dieser Nachricht mit dem Signierschlüssel aus Schritt 1.

Body-Felder (alle erforderlich, sofern nicht anders vermerkt):

• userAgent: der User-Agent des Besuchers, bis zu 1024 Zeichen.
• path: der Anfragepfad mit führendem /, ohne Query-String und Fragment, bis zu 2048 Zeichen.
• 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; genau dieses Feld prüft die Verifizierung der Crawler-Identität.
• referrer: ein leerer String oder eine https://-Referrer-URL ohne Query und Fragment. Nur relevant für menschliche Besuche aus KI-Antworten.
• status: der dreistellige HTTP-Status der Antwort, oder unknown, wenn Sie melden, bevor die Antwort existiert.
• method: die HTTP-Methode in Großbuchstaben.

Melden Sie nur Anfragen, deren User-Agent automatisiert aussieht oder deren Referrer eine KI-Antwort-Engine ist, und senden Sie das Beacon nach der Antwort, fire-and-forget; ein Ausfall des Trackers darf Ihre Site nie verlangsamen.

Zum Prüfen Ihrer Integration senden Sie ein Beacon mit "test": true, einem userAgent, der mit citlyze-connection-test/ beginnt, und "path": "/citlyze-test". Ein korrekt signiertes Testereignis liefert HTTP 200 zurück und speichert nichts; echte Ereignisse liefern immer 204, unabhängig davon, ob der Besuch am Ende in Ihren Berichten landet.

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 Ihr Snippet oder Plugin daher umgehend. Widerrufen ist etwas anderes: Der Key wird dauerhaft deaktiviert und das Tracking für diese Site stoppt.

Analytics lesen

Die Seite KI-Crawler → Analytics zeigt für den gewählten Zeitraum:

• Kopfkacheln: Crawler-Treffer gesamt, verschiedene Crawler, Top-Crawler und Trend
• Crawler-Besuche über die Zeit (Tagessummen)
• Crawler-Trends über die Zeit (eine Linie je Crawler)
• Aufschlüsselung je Crawler mit Organisation, Zweck, Treffern und Trend
• menschliche Besuche aus KI-Antworten: Besucher, die von ChatGPT, Perplexity, Gemini, Copilot und anderen durchgeklickt haben, samt ihrer wichtigsten Landingpages; der vollständige Referral-Bericht, einschließlich Conversions, liegt unter KI-Traffic
• 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

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.

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

KI-Crawler → Gecrawlte Seiten ist die vollständige Detailansicht: jede Seite, die KI-Crawler im gewählten Zeitraum abgerufen haben, mit Suche, Sortierung und Paginierung. Jede Zeile zeigt Treffer, Anteil am gesamten Crawler-Traffic, Trend gegenüber dem Vorzeitraum, Fehler, Top-Crawler und den letzten Besuch; klappen Sie eine Zeile auf für die Aufteilung je Crawler.

Zwei Insights erscheinen über der Tabelle, wenn sie relevant sind:

• Gecrawlt, aber nie zitiert: Seiten, die KI-Engines abrufen, aber nie in Ihren getrackten Antworten zitieren; Kandidaten für klarere, besser zitierbare Inhalte.
• Seiten mit Fehlern: Seiten, die Crawlern mit 4xx/5xx geantwortet haben. Kaputte Seiten können weder gelesen noch zitiert werden. Der volle Bereich erfordert die Installation über Cloudflare oder einen eigenen Server; eine WordPress-Installation erfasst 404, aber keine 5xx.

Die Tabelle lässt sich auf Plänen 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.