HTTP-statuscodes en AI-crawlers: wat je moet weten

De taal die servers en crawlers spreken

Elke keer dat een AI-crawler je website bezoekt, vindt er een gesprek plaats in HTTP-statuscodes. Je server antwoordt met een driecijferig getal dat de crawler vertelt of het verzoek is geslaagd, of de content is verhuisd, of er een fout is opgetreden. Voor traditionele zoekmachines zoals Google zijn deze codes al decennialang cruciaal. Voor AI-crawlers van Perplexity, OpenAI en Anthropic zijn ze minstens zo belangrijk, maar de gevolgen van een verkeerde configuratie zijn anders.

AI-crawlers hebben doorgaans een beperkter crawlbudget dan Googlebot en zijn minder vergevingsgezind bij onverwachte responses. Een verkeerde statuscode kan ervoor zorgen dat je content permanent uit de kennisbasis van een AI-model verdwijnt. In dit artikel bespreken we alle relevante HTTP-statuscodes, hoe AI-crawlers ze interpreteren en wat je kunt doen om je zichtbaarheid te beschermen. Als je nog niet vertrouwd bent met hoe AI-crawlers je site benaderen, lees dan eerst ons artikel over robots.txt voor AI.

2xx statuscodes: alles is in orde

De 200-reeks statuscodes geeft aan dat het verzoek succesvol is verwerkt. Dit is wat je wilt dat AI-crawlers zien bij het bezoeken van je belangrijkste pagina's.

• 200 OK: de standaard succesresponse. De server levert de gevraagde content. Dit is de ideale statuscode voor al je indexeerbare pagina's.
• 201 Created: wordt voornamelijk gebruikt bij API-responses na het aanmaken van een resource. Niet relevant voor contentpagina's.
• 204 No Content: de server heeft het verzoek succesvol verwerkt maar stuurt geen body terug. AI-crawlers kunnen hier niets mee; vermijd dit voor contentpagina's.

Het belangrijkste punt bij 200 responses is dat de body daadwerkelijk de content bevat die de crawler verwacht. Een veelvoorkomend probleem is de zogenaamde "soft 404": een pagina die een 200 statuscode retourneert maar in werkelijkheid een foutpagina toont. AI-crawlers kunnen deze situatie soms detecteren door de content te analyseren, maar niet altijd. Gebruik altijd een echte 404 statuscode voor niet-bestaande pagina's.

3xx redirects: de weg wijzen zonder te verdwalen

Redirects vertellen crawlers dat content is verplaatst naar een nieuwe locatie. Correct gebruik van redirects is essentieel voor het behouden van je AI-zichtbaarheid bij URL-wijzigingen.

# Nginx redirect configuratie\n\n# 301 Permanent Redirect: gebruik bij definitieve verhuizingen\nserver {\n    # Oude URL permanent doorsturen naar nieuwe URL\n    location = /oude-pagina {\n        return 301 /nieuwe-pagina;\n    }\n\n    # Hele domein redirecten (www naar non-www)\n    server_name www.example.nl;\n    return 301 https://example.nl$request_uri;\n}\n\n# 302 Temporary Redirect: gebruik bij tijdelijke verhuizingen\nlocation = /actie {\n    return 302 /tijdelijke-actie-pagina;\n}

301 versus 302: een cruciaal verschil voor AI

Het verschil tussen een 301 (Moved Permanently) en een 302 (Found/Temporary Redirect) is voor AI-crawlers significant. Bij een 301 redirect zal een AI-crawler de oude URL uit zijn index verwijderen en vervangen door de nieuwe. Bij een 302 behoudt de crawler de oude URL in zijn index en controleert hij deze periodiek opnieuw.

1. Gebruik 301 bij definitieve URL-wijzigingen: domeinmigratie, herstructurering van URL-paden, samenvoeging van pagina's.
2. Gebruik 302 bij tijdelijke situaties: A/B tests, seizoensgebonden content, tijdelijke onderhoudspagina's.
3. Vermijd redirect-ketens (A naar B naar C). Elke extra redirect kost crawlbudget en verhoogt de kans dat de crawler afhaakt.
4. Limiteer het totale aantal redirects op je site. Meer dan 10% van je URL's die redirecten is een signaal van slechte URL-hygiene.

Een veelgemaakte fout is het gebruik van een 302 redirect waar een 301 bedoeld is. Dit zorgt ervoor dat AI-crawlers de oude URL in hun index houden en de nieuwe URL minder prioriteit geven. Na een domeinmigratie of permanente herstructurering moet je altijd 301 redirects gebruiken. Dit sluit aan bij het belang van een correcte canonical URL-structuur.

4xx clientfouten: je deur staat op slot

De 400-reeks statuscodes geven aan dat het verzoek van de client (de crawler) niet kan worden verwerkt. Dit zijn de codes die je AI-zichtbaarheid het snelst kunnen schaden.

• 401 Unauthorized: de crawler heeft geldige authenticatie nodig. AI-crawlers kunnen zich niet authenticeren, dus content achter een 401 is onzichtbaar.
• 403 Forbidden: de server weigert het verzoek. Dit is wat een AI-crawler ziet wanneer je robots.txt de crawler blokkeert of wanneer je server specifieke user-agents weigert.
• 404 Not Found: de gevraagde resource bestaat niet. Na herhaalde 404 responses verwijdert een AI-crawler de URL permanent uit zijn index.
• 410 Gone: de resource is permanent verwijderd. Sterker signaal dan 404; AI-crawlers verwijderen de URL sneller en definitiever uit hun index.
• 429 Too Many Requests: de crawler stuurt te veel verzoeken. De crawler verlaagt zijn crawlsnelheid of stopt tijdelijk.

# Laravel middleware voor gedifferentieerde rate limiting per crawler\n// app/Http/Middleware/AiCrawlerRateLimit.php\n\nuse Closure;\nuse Illuminate\Http\Request;\nuse Illuminate\Support\Facades\RateLimiter;\n\npublic function handle(Request $request, Closure $next)\n{\n    $userAgent = strtolower($request->userAgent() ?? '');\n    $aiCrawlers = ['gptbot', 'perplexitybot', 'claudebot', 'anthropic-ai'];\n    \n    $isAiCrawler = false;\n    foreach ($aiCrawlers as $crawler) {\n        if (str_contains($userAgent, $crawler)) {\n            $isAiCrawler = true;\n            break;\n        }\n    }\n    \n    if ($isAiCrawler) {\n        $key = 'ai-crawler:' . $request->ip();\n        if (RateLimiter::tooManyAttempts($key, 60)) {\n            return response('Too Many Requests', 429)\n                ->header('Retry-After', 60);\n        }\n        RateLimiter::hit($key, 60);\n    }\n    \n    return $next($request);\n}

5xx serverfouten: je server laat het afweten

De 500-reeks statuscodes geven aan dat er een fout is opgetreden aan de serverzijde. Deze codes zijn het meest schadelijk voor je AI-zichtbaarheid, omdat ze aangeven dat je website onbetrouwbaar is.

• 500 Internal Server Error: een algemene serverfout. AI-crawlers zullen de URL later opnieuw proberen, maar na herhaalde 500 fouten verlagen ze de crawlfrequentie.
• 502 Bad Gateway: de server fungeerde als gateway en ontving een ongeldige response van de upstream server. Vaak een teken van overbelasting.
• 503 Service Unavailable: de server is tijdelijk niet beschikbaar, meestal door onderhoud of overbelasting. Stuur altijd een Retry-After header mee.
• 504 Gateway Timeout: de upstream server reageerde niet op tijd. AI-crawlers met een beperkt tijdsbudget zullen snel afhaken.

# Correct gebruik van 503 tijdens gepland onderhoud\n# Nginx configuratie\nlocation / {\n    if (-f /var/www/maintenance.flag) {\n        return 503;\n    }\n    # Normale configuratie...\n}\n\nerror_page 503 @maintenance;\nlocation @maintenance {\n    add_header Retry-After 3600 always;\n    add_header Content-Type "text/html" always;\n    root /var/www/maintenance;\n    try_files /index.html =503;\n}

Het verschil tussen een 503 met Retry-After header en een 500 zonder verdere informatie is enorm. Een 503 vertelt AI-crawlers expliciet dat de situatie tijdelijk is en wanneer ze terug kunnen komen. Een 500 geeft geen indicatie en kan na herhaalde voorvallen leiden tot een permanente verlaging van je crawlfrequentie. Dit principe geldt evenzeer voor de manier waarop je je HTTPS-configuratie en beveiligingsheaders inricht: consistentie en duidelijkheid bouwen vertrouwen.

Monitoring en alerting voor statuscode-problemen

Het grootste risico bij statuscode-problemen is dat je ze niet opmerkt. Een kapotte redirect of een intermitterende 500 fout kan weken ongemerkt je AI-zichtbaarheid ondermijnen. Stel daarom monitoring in die je waarschuwt bij afwijkende patronen.

1. Monitor je serverlogboeken op 4xx en 5xx responses specifiek voor AI-crawler user-agents.
2. Stel alerting in wanneer het percentage 5xx responses boven de 1% komt.
3. Gebruik tools zoals Google Search Console om crawlfouten te detecteren die Google's crawler tegenkomt.
4. Controleer je redirects periodiek met tools als Screaming Frog of Sitebulb om redirect-ketens en -loops te detecteren.
5. Log de Retry-After headers die je server verstuurt en controleer of AI-crawlers deze respecteren.

Een AI-crawler die drie keer achter elkaar een 500 fout krijgt, komt mogelijk niet meer terug. Investeer in monitoring voordat je zichtbaarheid verliest die je niet terugwint.

Samenvatting

• HTTP-statuscodes zijn de basistaal waarmee je server communiceert met AI-crawlers. Verkeerde codes leiden direct tot verlies van AI-zichtbaarheid.
• Gebruik 301 voor permanente en 302 voor tijdelijke redirects. Vermijd redirect-ketens en limiteer het totale aantal redirects.
• Soft 404's (200 statuscode op foutpagina's) zijn bijzonder schadelijk: gebruik altijd echte 404 of 410 statuscodes voor niet-bestaande content.
• Stuur altijd een Retry-After header mee bij 429 en 503 responses zodat AI-crawlers weten wanneer ze terug kunnen komen.
• Monitor statuscode-patronen specifiek voor AI-crawler user-agents en stel alerting in bij afwijkingen.

Veelgestelde vragen

HTTP-statuscodes zijn het verschil tussen een AI-crawler die je content vindt en indexeert, en een die afhaakt en niet meer terugkomt. Behandel elke response als een kans om vertrouwen op te bouwen.