Ik zie het steeds vaker bij Nederlandse bedrijven: een pagina doet alles “volgens het boekje” voor SEO, staat netjes in Google en haalt verkeer binnen, maar komt niet terug in AI antwoorden, samenvattingen of citaten. Dat voelt oneerlijk, want de content is vaak prima. Het probleem zit meestal ergens anders. AI systemen hergebruiken geen complete pagina’s, ze hergebruiken stukjes betekenis. En die betekenis moet het wel overleven wanneer de pagina wordt opgehaald, uitgelezen, opgeknipt en omgezet naar embeddings.
AI leest geen pagina’s, maar haalt fragmenten op
Zoekmachines beoordelen een URL als document. Ze kunnen veel compenseren als je structuur niet perfect is, met linkcontext, historiek en allerlei signalen over tevredenheid.
AI systemen werken anders. Ze starten vaak bij de ruwe HTML, halen daar tekst uit, knippen die op in stukken en zetten die stukken om naar embeddings, een soort compacte betekenisweergave waarmee gezocht wordt in een vectorruimte. Vervolgens selecteert het systeem niet “de beste pagina”, maar het meest bruikbare fragment.
Daar ontstaat een zichtbaarheidsgat. Je kunt winnen op ranking, terwijl de embedding versie van je inhoud te vaag, te rommelig of simpelweg onvolledig is. Dan ben je wel vindbaar, maar niet herbruikbaar.
Het zichtbaarheidsgat: ranking versus retrieval
Ranking gaat over gekozen worden in een lijst met resultaten. Retrieval gaat over teruggevonden worden als bruikbaar stukje betekenis. Dat is een andere laag, met andere spelregels.
Je hoeft SEO niet overboord te gooien. Alleen, als AI tussen de gebruiker en de zoekresultaten komt te zitten, bepaalt retrieval steeds vaker of jouw uitleg, definities of stappenplan überhaupt in beeld komen. Zie het als een tweede etalage: de ene in Google, de andere in AI.
Als die tweede etalage leeg blijft, komt dat zelden doordat je geen verstand van je vak hebt. Het komt doordat de structuur niet meewerkt.
Structurele misser 1: de inhoud bereikt AI niet
De meest pijnlijke fout is ook de simpelste. Veel AI crawlers lezen alleen de HTML die de server meteen teruggeeft. Ze draaien geen JavaScript, wachten niet op hydration en renderen geen client side content.
Daardoor kan je kerntekst voor een bezoeker zichtbaar zijn en door Google nog net goed verwerkt worden, terwijl AI praktisch een lege pagina ziet. Vanuit retrieval gezien bestaat die inhoud dan niet, want wat niet wordt ingelezen, wordt ook niet ge embed.
Wil je dit testen, kijk dan niet naar je browser. Kijk naar de initiële HTML response. Met een simpele curl request zie je wat een crawler bij het ophalen krijgt. Gebruik je daarbij een AI user agent, zoals GPTBot, dan valt het verschil vaak direct op. Pagina’s die “vol” lijken, blijken bij fetch time vooral uit scripts en containers te bestaan.
Op grotere schaal kun je dit ook controleren met Screaming Frog, door JavaScript rendering uit te zetten. Wat dan niet verschijnt, is voor veel AI systemen een blinde vlek.
Waarom veel code ook pijn doet als de tekst er wel staat
Soms staat de tekst technisch gezien in de initiële HTML, maar is de pagina zo vol met markup, scripts en frameworkruis dat extractie lastiger wordt. AI crawlers lezen niet zoals een browser. Ze scannen snel, knippen agressief en kunnen stukken overslaan of afkappen.
Hoe meer rommel rondom je kerntekst, hoe moeilijker het wordt om betekenis netjes te isoleren. Dat levert zwakkere embeddings op, waardoor je fragmenten minder vaak geselecteerd worden. Zware code is dus niet alleen een performance kwestie. Het maakt de betekenis minder helder voor systemen die op fragmentniveau zoeken.
Wat je wél helpt: vooraf gerenderde HTML of schonere eerste response
Als dit soort rendering problemen speelt, zijn er grofweg twee praktische routes.
De eerste is pre rendering. Je genereert een volledige HTML versie van de pagina vooraf, zodat de kerninhoud direct in de eerste response staat. Geen JavaScript nodig om de tekst zichtbaar te maken.
In de praktijk werkt dit vaak het best aan de edge laag, omdat elke request daar eerst langskomt. AI crawlers krijgen dan direct een leesbare versie, terwijl mensen nog steeds de interactieve ervaring kunnen krijgen die je voor conversie nodig hebt.
De tweede route is: zorg dat je belangrijkste tekst al in de initiële HTML staat en maak die zo schoon mogelijk. Minder scaffolding, minder diepe nesting, minder ruis rondom je boodschap. Als de extractie eenvoudiger wordt, wordt de embedding doorgaans ook duidelijker.
Deze ingrepen vervangen SEO niet, maar ze herstellen de basisvoorwaarde voor AI zichtbaarheid: er moet iets zijn dat je kunt uitlezen, knippen en begrijpen.
Structurele misser 2: geschreven voor keywords, niet voor entiteiten
Veel content is nog gebouwd op het idee dat keywords gelijk staan aan relevantie. Dat kan werken voor rankings, maar retrieval draait minder om losse woorden en meer om entiteiten en relaties. Wie of wat is het. Voor wie geldt het. In welke context. Waar zit het verschil met alternatieven.
Als je teksten vooral bestaan uit brede claims en algemene formuleringen, dan voelt het voor een lezer misschien nog logisch, maar de embedding wordt vaag. Het systeem ziet dan minder houvast om jouw fragment te kiezen en te citeren.
Mijn praktische vuistregel: laat belangrijke zinnen niet leunen op impliciete kennis. Zet namen, definities, doelgroep en situatie gewoon expliciet in de tekst. Je helpt daarmee niet alleen AI, maar ook je klant die snel wil begrijpen of dit over hem gaat.
Structurele misser 3: de structuur draagt geen betekenis zodra context wegvalt
AI knipt pagina’s op. Wat een mens begrijpt door de opbouw van het hele verhaal, wordt in retrieval vaak los beoordeeld. Dan moet elk onderdeel op eigen benen kunnen staan.
Daarom zijn duidelijke koppen belangrijk. Niet “Slimme tips” of een grappige kop die alleen werkt als je het hele stuk leest, maar koppen die meteen zeggen wat er staat, liefst met entiteiten erin. Een goede kop geeft context nog voordat de alinea wordt meegenomen.
Daarnaast helpt het als secties één doel hebben. Zodra je in één blok meerdere onderwerpen, doelgroepen of intenties mengt, vervaagt de grens van betekenis. Het resultaat is dat het fragment minder scherp wordt en dus minder vaak wordt teruggevonden.
Structurele misser 4: conflicterende signalen maken je betekenis troebel
Zelfs als je inhoud zichtbaar, duidelijk en goed gestructureerd is, kun je jezelf alsnog in de voet schieten met tegenstrijdige signalen. Dit geeft embedding ruis, omdat een AI systeem meerdere varianten van hetzelfde verhaal tegenkomt.
Dat gebeurt bijvoorbeeld bij conflicterende canonicals, waarbij meerdere URL’s bijna dezelfde inhoud tonen, maar niet één duidelijke “bron” aanwijzen. Google kan dat vaak op indexniveau oplossen. Veel retrieval systemen doen dat niet, waardoor je betekenis verspreid raakt.
Ook inconsistente metadata helpt niet. Als titels en descriptions per variant net anders zijn, wordt het minder duidelijk waar de pagina over gaat.
En hergebruikte tekstblokken, licht aangepast op meerdere pagina’s, kunnen je boodschap verdunnen. In plaats van één sterke representatie krijg je meerdere middelmatige fragmenten die met elkaar concurreren.
Conclusie: volledige zichtbaarheid vraagt om ranking én retrieval
SEO blijft belangrijk, maar het is niet meer het hele verhaal. Ranking bepaalt of je pagina in resultaten kan verschijnen. Retrieval bepaalt of je inhoud kan worden uitgelezen, begrepen en hergebruikt in AI antwoorden.
Als je merkt dat je wel verkeer krijgt maar nauwelijks terugkomt in AI samenvattingen of citaten, kijk dan niet meteen naar “betere content” of “meer autoriteit”. Begin bij de structuur. Staat je kerntekst in de initiële HTML. Is de HTML schoon genoeg om goed te extracten. Zijn je secties helder afgebakend. Benoem je entiteiten en context expliciet. En stuur je overal consistente signalen.
Wanneer betekenis overeind blijft nadat een pagina in stukken is geknipt, volgt retrieval meestal vanzelf. En dan heb je de rust van twee kanten: je scoort in zoekresultaten, én je verhaal kan door AI systemen netjes worden meegenomen.