Drie lagen van AI search visibility: ophalen, lezen, kiezen

2026-05-06ai-search10 min leestijd

Rob Hoeijmakers schreef onlangs over caching, en hoe AI-tooling hem hielp om eindelijk grip te krijgen op iets waar hij dertig jaar omheen had gewerkt. Een helder stuk over technische infrastructuur. Maar wat me het meest bijbleef was niet de caching-strategie zelf. Het was een observatie die hij bijna terloops maakte: "the audience had already changed."

Zijn publiek, de bezoekers van zijn site, zijn niet meer overwegend mensen in browsers. Een groeiend deel is machines. Crawlers van OpenAI, Anthropic, Perplexity, Amazon. Rob trok daaruit een technische conclusie: caching is geen performance-optimalisatie meer voor menselijke bezoekers, maar "infrastructure for machine readership." In een vervolgstuk ging hij dieper: "On any given day, humans are a minority."

Die observatie is correct. En het is een onderwerp op zichzelf. Wie zijn die machine-lezers precies? Wat doen ze op je site? En vooral: hoe meet je of wat ze lezen ook terugkomt in hun antwoorden?

De afgelopen maanden heb ik een framework ontwikkeld dat die vragen structureert in drie lagen. Niet omdat frameworks elegant zijn, maar omdat ik in de praktijk zag dat mensen steeds dezelfde fout maken: ze werken aan de verkeerde laag, of ze slaan er een over. Dit stuk beschrijft die drie lagen: ophalen, lezen, kiezen.

Laag 1: ophalen

De eerste laag is bereikbaarheid. Kunnen AI-bots je site uberhaupt vinden en ophalen? Dit is waar Rob over schrijft, en het is grotendeels bekend terrein voor wie zoals ik al meer dan een decennium SEO doet. De principes zijn niet nieuw, de spelers wel.

Wat bij deze laag hoort: je robots.txt moet de juiste crawlers toelaten. GPTBot, ClaudeBot, OAI-SearchBot, PerplexityBot, Amazonbot. Ze hebben elk hun eigen user-agent string en ze respecteren, anders dan veel scraping-bots, je instructies. Ze checken robots.txt en sitemap.xml als eerste. In onze eigen server logs zagen we dat /robots.txt en /sitemap.xml tot de meest gecrawlde paths behoren. Ze willen het netjes doen.

Daarnaast is er llms.txt, een opkomende standaard die functioneert als een gestructureerd visitekaartje voor AI-systemen. Een tekstbestand in je root dat je belangrijkste content, diensten en contactinfo samenvat in een formaat dat machines sneller parsen dan proza. Het is geen vervanging van je sitemap, maar een aanvulling die specifiek gericht is op hoe LLMs informatie verwerken.

Caching hoort hier ook. Rob's punt is precies juist: als je caching-strategie alleen gericht is op menselijke browsers, mis je het grootste deel van je publiek. AI-crawlers maken herhaalde requests. Een solide cache-laag zorgt dat die requests snel en consistent beantwoord worden, zonder je server onnodig te belasten.

En dan zijn er de basics die mensen vergeten: server uptime, response headers, TLS-certificaten, redirect chains. Een 301 die naar een 302 wijst die naar de uiteindelijke pagina gaat, kost een crawler drie requests waar een nodig is. Dat klinkt triviaal, maar vermenigvuldig het met duizenden pagina's en je verspilt crawlbudget dat je niet terugkrijgt.

Voor de meeste sites is laag 1 het best gedocumenteerde stuk. Er zijn handleidingen voor robots.txt configuratie, er zijn implementatiegidsen voor llms.txt, er zijn checklists. Het probleem zit niet in het gebrek aan informatie. Het probleem is dat de meeste discussie hier stopt.

Bots kunnen nu binnen. Wat doen ze daar?

Laag 2: lezen

Dit is waar de meeste discussie tekortschiet. We weten dat AI-bots onze sites bezoeken. We kunnen het tellen in server logs. Maar wat ze doen als ze er zijn, hoe ze onze content verwerken, wat ze extraheren, wat ze negeren, dat blijft voor de meeste site-eigenaren een zwart gat.

Laten we preciezer zijn over wat "lezen" betekent voor een AI-bot. Er zijn twee fundamenteel verschillende typen.

Het eerste type zijn pre-training crawlers. GPTBot, ClaudeBot, Google-Extended. Deze bots crawlen het web om trainingsdata te verzamelen voor toekomstige modelversies. Wat ze vandaag lezen, wordt onderdeel van het model dat over maanden of een jaar uitkomt. Je hebt geen directe invloed op hoe die data wordt verwerkt, maar je hebt wel invloed op wat ze vinden. Gestructureerde, feitelijke, goed gemarkeerde content wordt schoner verwerkt dan een ongestructureerde muur van tekst.

Het tweede type zijn realtime retrieval bots. ChatGPT-User, OAI-SearchBot, Perplexity-User. Deze bots halen content op op het moment dat een gebruiker een vraag stelt. Als iemand in ChatGPT typt "wat is AI search visibility" en het model besluit actuele bronnen te raadplegen, stuurt het een ChatGPT-User request naar relevante pagina's. Wat het daar vindt, bepaalt mede wat de gebruiker als antwoord krijgt. Dit is real-time. Dit is meetbaar. Dit is waar laag 2 concreet wordt.

Op hiveminds.nl/lens/live publiceren we deze data voor onze eigen site: welke AI-bots, welke pagina's, hoe vaak. Geen samenvatting, geen interpretatie, gewoon de logs.

Rob's data is in volume groter dan wat wij op hiveminds.nl meten en daarmee een betere referentie voor de patronen die dit stuk beschrijft. Wat hij ziet, zien wij ook — alleen op een andere schaal.

Onze eigen meting op hiveminds.nl is recent begonnen, parallel aan de launch van Hiveminds Lens. Het volume is op dit moment beperkt — een paar tientallen AI-bot requests per dag — maar dat is precies de reden om nu te beginnen met meten. Over een maand publiceren we een vervolgartikel met de meting na indexering. Niet als bewijs, als nulmeting. We willen weten hoe snel de drie lagen op een nieuwe site daadwerkelijk opbouwen, en publiek bijhouden wat werkt en wat niet.

Wat daar opvalt is een patroon dat we consequent zien: de meest gecrawlde content op hiveminds.nl gaat over AI search zelf. Artikelen over llms.txt, over AI-crawlers, over structured data. De sitemap-files. De glossary-termen.

Dat is geen toeval. Het is een zelf-bewijzend patroon. We schrijven over AI search, en AI-bots crawlen het. We schrijven over hoe machines content verwerken, en machines verwerken die content het meest. Het bevestigt precies wat laag 2 probeert te meten: bots crawlen wat ze begrijpen.

Gestructureerde, expliciete content met duidelijke headings, definitie-zinnen, en semantische markup is voor een machine makkelijker te parsen dan creatieve copy die leunt op context en impliciete verwijzingen. Een zin als "Core Web Vitals meet drie metrics: LCP, INP en CLS" is voor een retrieval-systeem onmiddellijk bruikbaar. Een zin als "de snelheid van je site is heel belangrijk en daar moet je echt iets aan doen" bevat voor een machine geen extracteerbaar feit.

Dit heeft directe consequenties voor hoe je over je content nadenkt. Het gaat niet alleen om wat je schrijft, maar om hoe je het structureert. HTML-hierarchie die logisch genest is. Schema.org markup die machines een feiten-laag geeft boven je proza. Openingszinnen per sectie die zelfstandig werken als antwoord op een directe vraag. Vergelijkingstabellen die een retrieval-systeem kan extraheren zonder de rest van de pagina te hoeven begrijpen.

De kern van laag 2 is dit: als je niet kunt zien wat AI-bots lezen, kun je niet weten of je laag 1 werkt. En je kunt niet sturen op laag 3. Je optimaliseert blind.

Het verschil tussen "bots bezoeken mijn site" en "ik weet wat bots op mijn site lezen" is het verschil tussen een vermoeden en een strategie.

Laag 3: kiezen

Niet alle content die gelezen wordt, komt terug in antwoorden. Dat is het frustrerende aan AI search visibility: je kunt alles goed doen in laag 1 en 2, perfect bereikbaar zijn, helder gestructureerd, en alsnog niet geciteerd worden. Wat bepaalt wat AI engines kiezen om te citeren?

Dit is het lastigste, minst transparante deel van de stack. Er zijn geen server logs om in te kijken. Je kunt niet zien welke interne weging een model maakt wanneer het beslist welke bron het citeert. Maar er zijn patronen. En die patronen zijn steeds consistenter naarmate we meer meten.

Domein-autoriteit speelt een rol, zij het anders dan bij Google. Een site die veelvuldig wordt aangehaald in trainingsdata, die backlinks heeft van erkende bronnen, die consistent feitelijke content publiceert, wordt door retrieval-systemen als betrouwbaarder beoordeeld. Het is geen directe "authority score" zoals bij traditionele SEO, maar het mechanisme is verwant: betrouwbaarheid wordt afgeleid uit externe validatie.

Expertise-signalen wegen zwaar. Content die specifieke feiten bevat, concrete getallen noemt, bronnen citeert, nuances benoemt, wordt vaker geciteerd dan content die in algemeenheden blijft hangen. Onderzoek naar Generative Engine Optimization (Aggarwal et al., gepubliceerd op ACM KDD 2024) toonde aan dat technieken als het toevoegen van statistieken en bronvermeldingen de zichtbaarheid in AI-antwoorden met tot 40% kunnen verhogen. Dat is geen subtiel effect.

Freshness telt, vooral voor retrieval-bots. Een pagina met een recente publicatiedatum wordt bij gelijke relevantie geprefereerd boven een pagina zonder datum of met een datum van jaren geleden. Dit is logisch: het model probeert actuele informatie te geven, en de publicatiedatum is een van de weinige signalen die het daarvoor heeft.

Distinctiveness is misschien de meest onderschatte factor. Als tien sites dezelfde informatie bieden in dezelfde bewoordingen, heeft het model weinig reden om jou te citeren boven een ander. Content die een eigen perspectief biedt, die data presenteert die niemand anders heeft, die een framework introduceert dat elders niet bestaat, die content valt op in een retrieval-resultaat. Dat is ook de reden waarom generieke "wat is AI search visibility" content minder geciteerd wordt dan specifieke observaties uit eigen data. Het model heeft genoeg generieke definities. Het zoekt bronnen die iets toevoegen.

En dan is er multi-source corroboration. Als meerdere onafhankelijke bronnen dezelfde feitelijke claim maken, verhoogt dat het vertrouwen van het model in die claim. Wat betekent dat je feitelijke content wilt schrijven die aansluit bij wat experts in je vakgebied ook zeggen, maar dan met je eigen data, je eigen perspectief, je eigen toepassing.

De methode om laag 3 te meten is prompt testing. Stel de vragen die voor jouw business relevant zijn aan ChatGPT, Claude, Perplexity. Kijk wie wordt genoemd. Kijk wie niet wordt genoemd. Kijk welke formuleringen en welke bronnen het model kiest.

Concreet: als je een hypotheekadviseur bent in Utrecht, test dan "wie is de beste hypotheekadviseur in Utrecht" in drie AI-systemen. Noteer wie wordt genoemd, in welke volgorde, en met welke woorden. Doe hetzelfde voor "hypotheek voor zzp'er", "annuiteitenhypotheek vs lineair", en elke andere vraag die jouw klanten stellen. Dat is handmatig en arbeidsintensief, maar het is de directe manier om te meten wat werkt. Hiveminds Lens is gebouwd voor precies dit: meten welke AI engines welke bedrijven noemen op welke prompts, en welke signalen ontbreken bij de bedrijven die niet worden genoemd.

Laag 3 is afhankelijk van laag 1 en 2. Geen technische bereikbaarheid betekent geen lezen. Geen leesbaarheid betekent geen kiezen. Geen kiezen betekent onzichtbaarheid in AI-antwoorden, ongeacht hoe goed je content is.

Wat traditionele SEO is voor Google, is dit framework voor AI search. De vragen zijn anders. De spelers zijn anders. Maar de structuur is dezelfde: bereikbaarheid, leesbaarheid, selectie. In die volgorde.

Verder lezen

Rob Hoeijmakers' artikelen die de aanleiding vormden voor dit stuk:

Gerelateerde Hiveminds-content: