AIVisiScanAIVisiScan
Alle onderzoeksnotities
Onderzoeksnotitie 006Hosting, serverbeveiliging en crawler-toegang

Uw website is er, maar een AI-crawler kan er niet altijd in: hoe serverbeveiliging AI-crawlers kan tegenhouden

Bij twee scans op rij werd niet de website zelf het probleem, maar de beveiligingslaag van de hostingprovider. Die onderschept verdachte bezoekers met een challenge vóór de pagina laadt, en AI-crawlers kunnen daar tegenaan lopen. Deze notitie beschrijft wat we waarnamen, welk mechanisme dat het meest waarschijnlijk verklaart, wat het voor een ondernemer betekent en waar de grens van ons bewijs ligt.

Gepubliceerd 31 augustus 2026 Twee praktijkwaarnemingen en eigen scannerlogica

We wilden een scan draaien voor een ondernemer in Noord-Brabant. De scan kwam er niet doorheen. Niet omdat de website slecht was gebouwd, en niet omdat er te weinig inhoud stond, maar omdat de beveiligingslaag van de hostingprovider onze scanner tegenhield voordat de pagina überhaupt laadde. Een paar weken later gebeurde bij een tweede, losstaande website precies hetzelfde. In beide gevallen was niet de site het probleem, maar de server ervoor. Dat maakte een vraag urgent die veel ondernemers nooit stellen: komt een AI-model eigenlijk wel bij mijn website?

De aanleiding

AIVisiScan haalt tijdens een scan de openbare broncode van een homepage op om technische controles te doen: is er een titel, een duidelijke H1, machineleesbare gegevens, een leesbare tekststructuur. Onze scanner meldt zich daarbij netjes met een herkenbare naam: AIVisiScan/1.0 (GEO Audit; +https://aivisiscan.nl). Normaal krijgt die een gewone pagina terug.

Bij twee recente scans gebeurde iets anders. In plaats van de pagina kwam er een tussenscherm terug van een beveiligingssysteem dat vóór de website draait. Dat scherm vraagt bezoekers om te bewijzen dat ze een mens zijn met een browser. Onze scanner kreeg dus niet de inhoud van de site, maar een controlepagina te zien. Voor onze meting is dat een blokkade. Dat betekent dat andere geautomatiseerde crawlers mogelijk tegen dezelfde beveiligingslaag kunnen lopen. Of dat daadwerkelijk gebeurt, hangt af van de identiteit, herkomst en uitzonderingsregels die de hostingprovider voor die crawler hanteert.

De onderzoeksvraag

De vraag in deze notitie is niet of één specifieke hostingprovider «goed» of «slecht» is. De vraag is principiëler:

Kan een beveiligingslaag die bedoeld is om schadelijke bots tegen te houden, er onbedoeld voor zorgen dat legitieme AI-crawlers een website niet meer kunnen lezen, en daarmee dat een direct toegangspunt voor AI-systemen wegvalt?

We onderscheiden daarbij drie deelvragen: (1) wát namen we precies waar, (2) welk technisch mechanisme verklaart dat het meest waarschijnlijk, en (3) wat mogen we daar wél en niet uit afleiden.

Onderzoeksopzet

Dit is geen gecontroleerd experiment met herhaalde metingen over veel domeinen. Het zijn twee concrete waarnemingen uit onze eigen scanpraktijk in augustus 2026, aangevuld met de openbare documentatie van hostingproviders en met de logica die in onze eigen scanner is ingebouwd. De betrokken bedrijven worden hier niet bij naam genoemd; het gaat om het patroon, niet om de partijen.

Onze scanner doet een homepage-ophaalpoging meerdere keren achter elkaar (vier pogingen met oplopende wachttijd) voordat hij een bron als onbruikbaar bestempelt. Pas als álle pogingen op een beveiligingscontrole stuiten, markeert de scan de bron als «geblokkeerd». Dat maakt een toevallige, eenmalige hapering onwaarschijnlijk als verklaring.

Wat we precies waarnamen

Bij beide websites kwam de server niet met de normale pagina terug, maar met twee herkenbare signalen tegelijk:

  • een HTTP-statuscode 202 in plaats van de gebruikelijke 200, vergezeld van een herkenbare beveiligingschallenge. In deze specifieke situatie gebruikte de beveiligingslaag die respons kennelijk als onderdeel van haar challenge-flow;
  • een tussenpagina die de bezoeker eerst een controle liet doorlopen (het type «even controleren of u een mens bent») voordat de echte site werd vrijgegeven.

Onze scanner herkent dit patroon expliciet. In de technische controle zit een lijst met handtekeningen van bekende beveiligings- en robotchallenges; zodra een respons zo'n handtekening bevat of statuscode 202 teruggeeft, wordt de bron geclassificeerd als «geblokkeerd» met de reden dat er een «robot- of beveiligingschallenge» is aangetroffen. Dat is geen interpretatie achteraf; het is vastgelegde meetlogica die bij deze twee scans aansloeg.

Belangrijk: dit zegt op zichzelf niets negatiefs over de kwaliteit of de inhoud van de betrokken websites. Ze waren waarschijnlijk prima gebouwd. Het probleem zat een laag daarvóór.

Het mechanisme, zo goed als we het kunnen reconstrueren

Veel hostingproviders draaien tegenwoordig een beveiligingslaag op serverniveau die verdacht verkeer opvangt vóórdat het de website bereikt. Zo'n laag beoordeelt onder meer vanaf welk IP-adres een bezoeker komt en hoe die zich gedraagt. Ziet het systeem een patroon dat het als «geautomatiseerd» of «verdacht» inschat, dan krijgt de bezoeker geen pagina maar een challenge: een controlescherm dat pas doorgang geeft na een test die een gewone browser met JavaScript kan doorlopen.

Voor kwaadwillende bots werkt dat goed. Het probleem is dat legitieme AI-crawlers per ongeluk in hetzelfde net belanden. Daar zijn twee redenen voor:

  1. Ze maken gebruik van datacenter-infrastructuur. Crawlers als GPTBot en OAI-SearchBot (OpenAI), ClaudeBot (Anthropic) en PerplexityBot draaien in datacenters met veel, steeds veranderende IP-adressen. Voor sommige botmitigation-systemen kunnen kenmerken als datacenter-IP's, requestfrequentie, user-agent en ander verkeersgedrag bijdragen aan de beoordeling of verkeer geautomatiseerd of verdacht is.
  2. Ze lossen de challenge niet op. Een controlescherm dat leunt op JavaScript en cookies gaat ervan uit dat er een echte browser aan de andere kant zit. De meeste AI-crawlers zijn eenvoudige ophalers zonder volledige browseromgeving. Ze krijgen het controlescherm, kunnen dat niet doorlopen en gaan verder. De echte inhoud zien ze nooit.

Het netto-effect: de challenge die bedoeld is om schadelijke bots buiten te houden, houdt ook de AI-crawlers buiten. En omdat sommige van die controleschermen zelf een instructie meekrijgen om niet geïndexeerd te worden, kan een aanhoudende blokkade op termijn zelfs de gewone vindbaarheid raken.

Drie soorten AI-crawlers: een cruciaal onderscheid

Niet alle AI-crawlers gedragen zich hetzelfde. Er zijn drie typen met een fundamenteel verschillend doel en gedrag:

  1. Training-crawlers verzamelen grote hoeveelheden data om AI-modellen te verbeteren. Bekende voorbeelden: GPTBot (OpenAI), ClaudeBot in trainingsmodus (Anthropic), CCBot (Common Crawl). Deze bots crawlen proactief en massaal. Ze komen van datacenter-IP's, hebben geen JavaScript-omgeving, en worden door veel beveiligingslagen als verdacht aangemerkt.
  2. Zoekindex-crawlers bouwen en onderhouden de zoekindex die AI-assistenten gebruiken om actuele resultaten te tonen. Bekende voorbeelden: OAI-SearchBot (OpenAI), Claude-SearchBot (Anthropic). Ze gedragen zich vergelijkbaar met traditionele zoekmachinecrawlers en bezoeken pagina's regelmatig om hun index actueel te houden.
  3. On-demand ophalers halen content op wanneer een gebruiker op dát moment een vraag stelt aan een AI-assistent. Bekende voorbeelden: ChatGPT-User (OpenAI), Claude-User (Anthropic), Perplexity-User (Perplexity). Deze bots handelen reactief en gericht. Sommige hostingproviders maken voor deze crawlers expliciete uitzonderingen. SiteGround publiceert bijvoorbeeld een allowlist waarin onder meer OAI-SearchBot, ChatGPT-User, Claude-User, Claude-SearchBot, PerplexityBot en Perplexity-User als toegestane crawlers worden genoemd.

Onze scanner (AIVisiScan/1.0) komt met geen van die toegestane namen overeen en gedraagt zich technisch als een training-crawler: datacenter-IP, geen JavaScript, geen bekende identiteit uit een van de drie bovenstaande categorieën. Dat onze scanner geblokkeerd werd, bewijst dus niet dat een klant die op dát moment via ChatGPT naar het bedrijf zoekt ook tegengehouden wordt. Het bewijst alleen dat een onbekende audit-tool niet doorgelaten werd.

Deze nuance is belangrijk. De beveiligingslaag kan nog steeds een probleem zijn, als de provider de zoekindex-crawlers of on-demand ophalers niet correct heeft toegevoegd aan de uitzondering, of als de challenge zo breed is dat ook zij vastlopen. Maar het is geen automatisch gevolg van onze waarneming. AIVisiScan test sinds deze observatie met twee user-agents (audit-crawler én browser-identiteit) om dit onderscheid te kunnen maken.

Waarom dit lastig te repareren is

Je zou denken: zet die crawlers dan op een witte lijst. In de praktijk is dat vaak niet zo eenvoudig als het klinkt.

  • Niet elke hostingprovider biedt de mogelijkheid om bezoekers op naam (user-agent) door te laten. Waar dat wel kan, is het vaak beperkt.
  • Doorlaten op IP-adres werkt slecht, omdat de crawlers juist vanaf grote, veranderende reeksen adressen komen. Een korte lijst met vaste IP's dekt dat niet.
  • De instelling zit meestal niet in de website zelf, maar in het beheerpaneel van de hosting. Een ondernemer die alleen zijn site beheert, ziet dit knelpunt daardoor vaak niet en kan het niet zelf verhelpen.

Er zijn wél oplossingsrichtingen, denk aan het aanpassen van de beveiligingsinstellingen bij de provider, het via de klantenservice laten doorlaten van bekende AI-crawlers, of het plaatsen van een tussenlaag (zoals een CDN) die de inhoud aan legitieme bots serveert. Welke route past, hangt af van de provider en de opzet. Het punt van deze notitie is niet om één oplossing voor te schrijven, maar om het probleem zichtbaar te maken.

Wat deze waarneming wél en niet aantoont

Wat we wel hebben vastgesteld

  • Bij twee losstaande websites (met enkele weken ertussen) kreeg onze scanner geen pagina, maar een beveiligingschallenge (statuscode 202 plus een controlescherm) terug.
  • Onze scanner herkende dit als een blokkade op basis van vooraf vastgelegde meetlogica, na meerdere ophaalpogingen.
  • Het knelpunt zat in de laag vóór de website (de serverbeveiliging van de hosting) en niet in de inhoud of bouw van de site zelf.

Wat we hieruit niet mogen concluderen

  • Dat elke website bij deze of een vergelijkbare hostingprovider dit probleem heeft. Instellingen verschillen per pakket en per domein.
  • Dat elke AI-crawler op elk moment op precies dezelfde manier wordt tegengehouden. Wij hebben onze eigen scanner gemeten, niet de crawlers van OpenAI, Anthropic of Perplexity rechtstreeks.
  • Dat zoekindex-crawlers (OAI-SearchBot, Claude-SearchBot) of on-demand ophalers (ChatGPT-User, Claude-User, Perplexity-User) ook geblokkeerd werden. Onze scanner gedroeg zich technisch als een training-crawler; het is een aparte empirische vraag of de overige crawlertypen doorgelaten worden.
  • Dat het probleem permanent is. Providers passen hun beveiliging aan en bieden soms uitzonderingen; de situatie kan per moment verschillen.
  • Dat een geblokkeerde crawler automatisch betekent dat een bedrijf nergens in AI-antwoorden voorkomt. Een geblokkeerde crawler vermindert de directe toegankelijkheid voor AI-systemen, maar modellen kunnen ook putten uit andere, onafhankelijke bronnen over een bedrijf.

We beschrijven het mechanisme daarom nadrukkelijk als de meest waarschijnlijke verklaring voor wat we zagen, onderbouwd met openbare documentatie, niet als een bewezen wetmatigheid voor alle websites en alle crawlers.

Waarom dit relevant is voor een ondernemer

De meeste discussies over AI-zichtbaarheid gaan over de inhoud: de juiste teksten, machineleesbare gegevens, consistente vermeldingen. Dat is terecht. Maar die hele laag doet er pas toe als een AI-crawler de pagina überhaupt kan ophalen. Zit er een dichte deur vóór de website, dan maakt het niet uit hoe goed het huis erachter is ingericht: de bezoeker komt niet binnen.

Het venijnige is dat dit knelpunt onzichtbaar is voor de ondernemer. De site laadt in zijn eigen browser prima; hij doorloopt de controle immers als mens zonder het te merken. Alleen een geautomatiseerde bezoeker loopt tegen de muur. Zonder een test die zich als zo'n bezoeker gedraagt, blijft het probleem verborgen.

Wat dit betekent voor AIVisiScan

Deze twee waarnemingen bevestigen waarom een scan meer moet doen dan de teksten en de structuur beoordelen. AIVisiScan controleert daarom expliciet of de bron overhaupt bereikbaar is, herkent beveiligingschallenges als een aparte uitkomst, en meldt een blokkade als zodanig in plaats van te doen alsof de pagina leeg of slecht is. Dat onderscheid («niet bereikbaar» versus «bereikbaar maar zwak») is voor de ondernemer een compleet ander gesprek.

Loopt een scan op een blokkade, dan hoeft dat het rapport niet te stoppen: de bron kan handmatig worden aangeleverd, zodat de inhoudelijke controles alsnog draaien terwijl de blokkade als apart aandachtspunt zichtbaar blijft. Zo blijft de melding eerlijk: het echte probleem is de toegang, en dat los je niet op met een betere alineatekst.

Praktische les

Controleer niet alleen wát er op uw website staat, maar of een geautomatiseerde bezoeker er binnenkomt. Laadt de site voor u prima, maar krijgt een crawler een controlescherm, dan is de eerste winst niet inhoudelijk maar technisch: zorg dat bekende, legitieme AI-crawlers worden doorgelaten door de beveiligingslaag van uw hosting. Weet u niet of dat het geval is, vraag het dan na bij uw hostingpartij, of laat het meten. Hoe een AI vervolgens tot een antwoord komt zodra de deur wél openstaat, beschrijven we in hoe een AI tot een antwoord komt; de volledige werkwijze van onze scan staat op de methodologiepagina.

Bronnen en methode

  • Twee eigen scanwaarnemingen uit augustus 2026, waarbij de homepage-ophaalpoging na meerdere pogingen op een beveiligingschallenge (HTTP 202 plus controlescherm) stuitte.
  • De vastgelegde meetlogica van AIVisiScan die beveiligings- en robotchallenges herkent en de bron als «geblokkeerd» classificeert.
  • Openbare documentatie en toelichtingen van hostingproviders over serverbeveiliging tegen bots en over de toegang van AI-crawlers, geraadpleegd in augustus 2026.
  • Openbare informatie over het gedrag van AI-crawlers (onder meer GPTBot, OAI-SearchBot, ClaudeBot en PerplexityBot) en hun herkomst vanuit datacenter-IP-ranges.