Uw website is er — maar de AI komt er niet in: hoe serverbeveiliging bij de hosting AI-crawlers buitensluit

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. Enkele 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. En wat voor onze scanner een blokkade is, is dat waarschijnlijk ook voor de crawlers van AI-bedrijven.

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 het bedrijf onzichtbaar wordt in AI-antwoorden?

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 — technisch «verzoek geaccepteerd, maar nog niet verwerkt», wat hier het uitstel naar een controlescherm betekent;
• een beveiligingschallenge in de respons: een tussenpagina die de bezoeker eerst een controle laat doorlopen (het type «even controleren of u een mens bent») voordat de echte site wordt 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 komen van grote, wisselende cloud-IP-ranges. Crawlers als GPTBot en OAI-SearchBot (OpenAI), ClaudeBot (Anthropic) en PerplexityBot draaien in datacenters met veel, steeds veranderende IP-adressen. Precies dat profiel — veel verkeer vanaf datacenter-IP's — is wat een beveiligingssysteem als verdacht kan aanmerken.
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.

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 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. 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.