AI-crawlers

AI-crawlertracking toont welke AI-engines je site daadwerkelijk bezoeken: GPTBot, ClaudeBot, PerplexityBot, Bingbot en meer. Het vult GEO-audits aan: audits vertellen of bots een pagina kunnen bereiken; crawlertracking vertelt of ze het doen.

Waarom server-side registratie

AI-trainingscrawlers draaien geen JavaScript, dus een Google Tag Manager- of JavaScript-pixel ziet GPTBot of ClaudeBot nooit. Citlyze registreert crawlerbezoeken server-side, waar de echte request-User-Agent zichtbaar is, zodat ook niet-JavaScript-crawlers worden geteld.

De menselijke helft is anders: bezoekers die vanuit AI-antwoorden doorklikken draaien wél JavaScript, dus voor AI-verkeer volstaat een browsersnippet of Tag Manager-installatie (zie AI-verkeertracking installeren). De server-side installaties op deze pagina leggen beide soorten tegelijk vast.

Tracking installeren

Ga naar AI-crawlers → Tracking installeren en genereer een sitesleutel. De sleutel heeft twee delen, een sleutel-ID en een signeergeheim, die eenmalig worden getoond; kopieer beide. Voeg daarna het passende snippet toe voor je platform (voor klik-voor-klik-instructies bij elke optie, zie AI-crawlertracking installeren):

• Cloudflare (aanbevolen): plak het Worker-snippet vóór je site.
• Vercel / reverse proxy: voeg het middleware-snippet toe.
• WordPress: download AI Crawler Tracker by Citlyze, upload hem in wp-admin → Plugins en vul in de instellingen alle drie de velden in: Tracker base URL (https://app.citlyze.com), Key ID en Signing secret. Controleer de bezorging met Testgebeurtenis versturen (“Send test event”). De plugin rapporteert niets zolang de tracker-basis-URL leeg is.
• Eigen server / Node: voor zelf gehoste sites (AWS, GCP, Azure, bare metal, containers): voeg het Express-achtige middleware-snippet toe (Node 20+). Het is aan te passen aan Fastify, Koa of kaal http, en andere talen kunnen het signed-beacon-protocol direct implementeren.

Elk event wordt met je geheim gesigneerd zodat de tracker vervalste beacons kan weigeren. Die handtekening bewijst dat de melding van jouw site kwam; ze zegt niets over wie de bezoeker was. Bevestigen dat een bezoeker echt GPTBot was is een aparte stap, beschreven in Hoe verificatie werkt.

Standaard Shopify-winkels kunnen geen server-side registratie draaien, en Shopify ondersteunt niet dat je een proxy (zoals Cloudflare) voor een winkel zet, dus volledige crawlertracking is op standaard Shopify niet beschikbaar. Headless Hydrogen- of Oxygen-storefronts draaien server-side code en kunnen het snippet voor eigen servers gebruiken. Webflow-hosting kan evenmin servercode draaien; op Webflow Enterprise kan een zelfbeheerde reverse proxy de Cloudflare-Worker of het snippet voor eigen servers op de proxylaag draaien.

De Cloudflare-Worker en de middleware voor eigen servers rapporteren de HTTP-status van elk gecrawld verzoek, wat de foutinzichten hieronder voedt. De WordPress-plugin draait voordat de pagina wordt weergegeven en onderscheidt daarom alleen 404's van de rest; en Vercel-middleware draait voordat het antwoord bestaat en kan dus helemaal geen status rapporteren.

WordPress-paginacaches en CDN's kunnen antwoorden zonder de plugin uit te voeren. Gebruik voor zwaar gecachte sites de Cloudflare-Worker.

Eigen servers en andere talen

Het tabblad "Eigen server" levert een Node-middleware, maar elke stack kan rapporteren: een beacon is één gesigneerde HTTPS-POST naar https://app.citlyze.com/api/track met een JSON-body (maximaal 32 KB) en Content-Type: application/json.

Vereiste headers:

De handtekening berekenen:

1. Leid de signeersleutel af: de 64 tekens lange hex-SHA-256 in kleine letters van je signeergeheim (de volledige ctk_...-string). Gebruik de UTF-8-bytes van die hexstring als HMAC-sleutel; hex-decodeer hem niet.
2. Bouw het bericht: "2\n" + timestamp + "\n" + nonce + "\n" + bodyDigest, waarbij bodyDigest de hex-SHA-256 in kleine letters is van exact de body-bytes die je verstuurt. Elke herserialisatie na het signeren maakt de handtekening ongeldig.
3. x-aeo-signature is de hex-HMAC-SHA256 in kleine letters van dat bericht met de signeersleutel uit stap 1.

Body-velden (alle vereist tenzij anders vermeld):

• userAgent: de User-Agent van de bezoeker, maximaal 1024 tekens.
• path: het requestpad met een leidende / en zonder querystring of fragment, maximaal 2048 tekens.
• visitorIp: het client-IP zoals je server het ziet. Achter een load balancer of reverse proxy haal je het uit de forwarding-header die je eigen proxy zet; dit veld is wat de verificatie van de crawleridentiteit controleert.
• referrer: een lege string, of een https://-referrer-URL waarvan query en fragment zijn verwijderd. Alleen relevant voor menselijke bezoeken vanuit AI-antwoorden.
• status: de driecijferige HTTP-status van het antwoord, of unknown als je rapporteert voordat het antwoord bestaat.
• method: de HTTP-methode in hoofdletters.

Rapporteer alleen verzoeken waarvan de user agent geautomatiseerd oogt of waarvan de referrer een AI-antwoordengine is, en verstuur het beacon na het antwoord, fire-and-forget; een storing van de tracker mag je site nooit vertragen.

Om je integratie te controleren stuur je een beacon met "test": true, een userAgent die begint met citlyze-connection-test/ en "path": "/citlyze-test". Een correct gesigneerd testevent geeft HTTP 200 terug en slaat niets op; echte events geven altijd 204 terug, of het bezoek nu in je rapporten belandt of niet.

Een sleutel vernieuwen of intrekken

Als een signeergeheim gelekt kan zijn (bijvoorbeeld gecommit in een repo of gedeeld in een screenshot), gebruik dan Vernieuwen naast de sleutel. Vernieuwen geeft een nieuw geheim uit voor dezelfde sleutel: de sleutel-ID, naam, het domein en de volledige geschiedenis blijven behouden, maar het oude geheim werkt direct niet meer, dus werk je snippet of plugin meteen bij met het nieuwe geheim. Intrekken is iets anders: dat schakelt de sleutel permanent uit en stopt de tracking voor die site.

De analytics lezen

De pagina AI-crawlers → Analytics toont, voor het gekozen tijdvak:

• koptegels: totale crawlerhits, verschillende crawlers, topcrawler en trend
• crawlerbezoeken in de tijd (dagtotalen)
• crawlertrends in de tijd (één lijn per crawler)
• per crawler-uitsplitsing met organisatie, doel, hits en trend
• menselijke bezoeken vanuit AI-antwoorden: bezoekers die doorklikten vanaf ChatGPT, Perplexity, Gemini, Copilot en anderen, met hun belangrijkste landingspagina's; het volledige referralrapport, inclusief conversies, staat op AI-verkeer
• meest gecrawlde pagina's (top 10, met link naar de volledige lijst)
• niet-herkende bots: bot-achtige user agents die met geen enkele bekende AI-crawler matchen, gegroepeerd onder "Onbekende bot" zodat nieuwe crawlers vroeg opvallen

Gebruik de voorinstellingen (7/30/90 dagen), het aangepaste datumbereik en het crawlerfilter om de weergave te verfijnen. Werkruimtes die meer dan één site volgen krijgen ook een sitefilter.

Hoe verificatie werkt

Elke client kan GPTBot in zijn user agent zetten. Een user agent is dus een bewering, geen bewijs, en Citlyze behandelt dat zo: de belangrijkste crawlercijfers tellen alleen verkeer dat we onafhankelijk konden bevestigen.

Elk bezoek krijgt een van drie betrouwbaarheidsniveaus:

• Geverifieerd: we bevestigden de netwerkidentiteit van de bezoeker tegen iets dat de operator publiceert. Alleen deze tellen mee in je totalen.
• Waarschijnlijk: ondersteunende aanwijzingen, zoals je CDN dat het verzoek markeert als bekende bot, maar geen onafhankelijke bevestiging.
• Niet geverifieerd: de user agent noemde een crawler en niets sprak dat tegen, maar we konden het niet bevestigen. Apart getoond, nooit bij je totalen opgeteld.

Verificatie gebruikt wat de operator ondersteunt:

Operators die niets controleerbaars publiceren kunnen alleen niet geverifieerd bereiken. Dat is een eigenschap van de crawler, geen probleem met je installatie, en daarom bestaan er aparte weergaven in plaats van één gemengd getal.

Twee dingen om te weten:

• Agentverkeer telt apart. Tools die mensen zelf aansturen, zoals ChatGPT Agent, verschijnen onder agentactiviteit in plaats van in de crawlertotalen: één persoon die klikt is niet hetzelfde signaal als een crawler die je indexeert.
• Soms kunnen we niet controleren: de IP-lijst van een operator kan tijdelijk onbereikbaar zijn. Die bezoeken blijven niet geverifieerd in plaats van meegeteld te worden, zodat je totalen nooit iets onbevestigds bevatten.

Gecrawlde pagina's

AI-crawlers → Gecrawlde pagina's is de volledige detailweergave: elke pagina die AI-crawlers in het gekozen tijdvak ophaalden, met zoeken, sorteren en paginering. Elke rij toont hits, aandeel in al het crawlerverkeer, trend ten opzichte van het vorige tijdvak, fouten, de topcrawler en het laatste bezoek; klap een rij uit voor de uitsplitsing per crawler.

Twee inzichten verschijnen boven de tabel wanneer ze relevant zijn:

• Gecrawld maar nooit geciteerd: pagina's die AI-engines ophalen maar nooit citeren in je gevolgde antwoorden; kandidaten voor duidelijkere, beter citeerbare content.
• Pagina's met fouten: pagina's die crawlers met 4xx/5xx beantwoordden. Kapotte pagina's kunnen niet gelezen of geciteerd worden. Het volledige bereik vereist de installatie via Cloudflare of een eigen server; een WordPress-installatie registreert 404's, maar geen 5xx.

De tabel is te downloaden als CSV op plannen met data-export.

Data via API en MCP

Crawlerbezoeken zijn programmatisch beschikbaar zodra tracking is geïnstalleerd:

• REST: GET /api/v1/crawler-events; zie de AI Crawler Events-resource.
• MCP: de tool list_crawler_events; zie de MCP-toolsreferentie.

Beide zijn read-only en beperkt tot je werkruimte. De REST-resource filtert op crawler_id, gevolgde site en exact path; menselijke bezoeken vanuit AI-antwoorden vind je op GET /api/v1/ai-referrals.