Een firewall kan crawlers weigeren buiten robots.txt om, maar welke crawler dat is kun je niet raden: dat staat alleen in je accesslog. Op zeven sites die ik beheer kwamen alle AI-crawlers gewoon binnen, terwijl ModSecurity-regel 77999907 de Facebook-crawler 402 keer weigerde en daarmee elke linkpreview stukmaakte.

Ik was er vrij zeker van dat mijn hostingpartij AI-crawlers blokkeerde. Ik had er al een artikel over klaarliggen, met de conclusie er alvast in. Het enige dat nog ontbrak was het bewijs, dus ik trok de serverlogs erbij. Daar stond iets heel anders.

Waarom ik dacht dat het de AI-crawlers waren

Er wordt veel geschreven over content en llms.txt, en weinig over de laag eronder: het filter dat bepaalt welke bots je server binnenkomen. Dat filter bestaat echt, en het kan je onzichtbaar maken zonder dat je robots.txt er iets over zegt.

Sinds 2026 gebruikt OpenAI drie aparte crawlers. GPTBot verzamelt materiaal voor training. OAI-SearchBot bepaalt of je in ChatGPT-zoekantwoorden verschijnt. ChatGPT-User haalt een pagina op als een gebruiker daar zelf om vraagt. Voor zichtbaarheid telt alleen OAI-SearchBot.

Het addertje dat de meeste checklists missen: robots.txt is een crawl-instructie, geen firewallregel. Dat staat zo in RFC 9309. Je robots.txt kan Allow zeggen, maar als je firewall de bot een 403 teruggeeft, wint de firewall. Altijd.

Mijn sites draaien op gedeelde hosting met een serverbrede firewall waar ik zelf niet bij kan. Externe SEO-tools kregen soms niets terug. De conclusie leek me duidelijk. Ik had alleen nog de logs nodig om het hard te maken.

Wat er werkelijk in de logs stond

Ik heb de accesslogs van een hele maand getrokken voor zeven domeinen en gefilterd op user-agent en statuscode. Dit kwam eruit voor de AI-crawlers:

Geen enkele 403. Niet één, over 824 verzoeken. De crawler die er voor zichtbaarheid het meest toe doet, OAI-SearchBot, kwam overal probleemloos binnen. Mijn aanname was gewoon fout.

Twee dingen vielen wel op. De 429's bij GPTBot zijn rate-limiting: op één dag kreeg die een uur lang elke minuut een 429 omdat hij te snel achter elkaar opvroeg. Vervelend, maar dat raakt alleen de trainingscrawler en niet je vindbaarheid. En die 83 keer 404 bij OAI-SearchBot bleek één site zonder robots.txt te zijn, waar de crawler ruim tachtig keer vergeefs naar vroeg. Ook dat had ik nooit gezien zonder het log.

En toen zag ik de regel eronder staan.

De crawler die wel geweigerd werd

facebookexternalhit, 403. Niet één keer, maar 402 keer, verdeeld over alle zeven sites. Op mijn eigen site 165 van de 202 verzoeken geweigerd, inclusief het bestand og-image.png.

Dat is de crawler die de linkpreview bouwt zodra iemand je site deelt op Facebook, Instagram of WhatsApp. Geen afbeelding, geen titel, geen omschrijving. Een kale blauwe link. Bij mij, en bij zes klanten.

De verzoeken kwamen van 2a03:2880::/32, het officiële IPv6-blok van Meta. Er was dus niets verdachts aan. De firewall weigerde een volstrekt legitieme crawler.

Ik had het al gezien zonder het te zien

Als ik een klantsite opgeleverd heb, stuur ik de link altijd even door via WhatsApp. Klaar, kijk maar. En dan kwam er een kale blauwe link tevoorschijn, zonder plaatje, zonder titel.

Ik dacht elke keer hetzelfde: WhatsApp doet moeilijk, de cache moet nog bijtrekken, het komt vanzelf goed. Dat heb ik een half jaar lang gedacht. Bij zes verschillende klanten.

Het was geen cache. Het was mijn eigen server die de deur dichthield, elke keer opnieuw, en ik had er een verklaring bij bedacht zodat ik er niet naar hoefde te kijken.

Dat is wat me van deze middag het meest is bijgebleven. Niet de regel die het deed, en niet dat mijn aanname over AI-crawlers fout was. Maar dat ik een signaal dat ik letterlijk in mijn hand had, maandenlang heb wegverklaard omdat mijn verklaring makkelijker was dan kijken.

De oorzaak, en hoe je hem zelf test

Mijn hostingpartij kon het exact aanwijzen: ModSecurity-regel 77999907, serverbreed actief. Die regel matcht op de user-agent en niet op het IP-adres, en dat betekent dat je hem zelf kunt testen zonder toegang tot de server:

curl -s -o /dev/null -w "%{http_code}" \
  -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" \
  https://jouwdomein.nl/

Krijg je een 403 terwijl een gewone browser een 200 krijgt, dan heb je hem te pakken.

Uitzetten kan in DirectAdmin onder Advanced Features, Web Application Firewall, bij Disabled Rules. Eén ding om te weten: dat werkt alleen per domein. Account-breed of automatisch voor nieuwe domeinen kan niet. Beheer je meerdere sites, dan is dit dus een handeling die bij elke oplevering opnieuw moet. Bij mij stond het na acht keer klikken goed, en gaf dezelfde curl overal een 200 terug.

De stelling

Elke GEO-checklist begint bij content en robots.txt. Geen enkele die ik ben tegengekomen begint bij het accesslog. Dat is de verkeerde volgorde.

Je kunt maanden aan content optimaliseren die een crawler nooit ophaalt, en je merkt het niet. Een geweigerde crawler stuurt je namelijk geen bericht. Er komt geen melding, geen foutscherm, geen mailtje. Er gebeurt alleen niets, en niets voelt precies hetzelfde als langzaam op gang komen.

Wat je zelf kunt doen in drie minuten

  1. Draai de curl hierboven op je eigen domein met de user-agent van facebookexternalhit. Krijg je 403 en een gewone browser 200, dan zijn je linkpreviews stuk.
  2. Herhaal het voor OAI-SearchBot, GPTBot, ClaudeBot en PerplexityBot.
  3. Wil je zekerheid over een langere periode, pak dan je accesslog erbij. In DirectAdmin staan die per domein onder logs, als daglogs per maand. Filter op de user-agent en kijk naar de statuscode.
  4. 200 betekent binnen. 403 betekent geweigerd. 429 betekent afgeremd, meestal onschuldig. Zie je een bot helemaal niet in je logs staan, dan wordt hij mogelijk geblokkeerd voordat het verzoek gelogd wordt, en moet je bij je host zijn.

Raad niet welke bot buiten staat. Dat deed ik ook, en ik zat er een half jaar naast.

Tot slot

Content en structuur zijn het makkelijke deel. De onzichtbare laag eronder, wie je server binnenkomt, is waar sites het stilletjes verliezen.

Bij FayLux Media hoort een crawler-toegangscontrole op serverniveau daarom bij het werk, en sinds deze week staat de firewallcheck als eerste stap in mijn opleverchecklist. Niet als extraatje, maar omdat een perfecte pagina die de crawler nooit bereikt nul waard is.