Waarom je AI-assistent verouderde antwoorden geeft

Geeft de AI-assistent op je website een verouderd antwoord, dan is de eerste gedachte vaak dat het model niet deugt. Meestal ligt het ergens anders. Zo'n assistent antwoordt uit jouw eigen content. Het systeem leest je website in, zoekt bij een vraag de documenten erbij die erover gaan, en laat het model daar een antwoord uit schrijven. Klopt er iets niet aan wat het ophaalt, dan klopt het antwoord ook niet.

Een moderne assistent redt zich daar overigens beter in dan je zou denken. Krijgt hij drie documenten waarvan er één achterhaald is, dan is de kans reëel dat hij dat doorheeft en het goede antwoord geeft. Gratis is dat niet. Het model moet dan eerst uitzoeken welke bron nog geldt, en dat kost tijd die de bezoeker als wachten ervaart. Rommelige content maakt je assistent dus niet alleen minder betrouwbaar, maar ook trager.

Ik werk aan de kant van vragen.ai waar die content binnenkomt. Dit stuk gaat over wat daar misgaat, en waarom dat vaker een crawlprobleem is dan een AI-probleem. De meeste voorbeelden hieronder hebben we zelf al eens moeten repareren.

Drie crawlers, één probleem

Er lezen op dit moment waarschijnlijk drie soorten crawlers je website. Googlebot, om je te indexeren. De crawlers van AI-bedrijven, die het web afstruinen. En, als je een AI-assistent op je eigen site hebt, de crawler die je daar zelf voor hebt ingehuurd.

Die drie doen technisch hetzelfde. Ze halen een URL op, krijgen HTML terug en proberen daar tekst en structuur uit te halen. Een pagina die de een niet kan lezen, kan de ander ook niet lezen. Een sitemap die voor Google rammelt, rammelt voor ons net zo hard.

Het verschil zit in hoe snel je het merkt:

• Googlebot

  Maanden

  Een pagina die niet wordt gelezen, zakt langzaam weg in de posities. Tegen de tijd dat je het in Search Console ziet, staat het er al een tijdje.

• AI-crawlers van derden

  Nooit

  Je krijgt geen melding en geen rapport. Of ChatGPT je pagina heeft gelezen, is voor jou niet te controleren.

• Je eigen assistent

  Morgen

  Een bezoeker stelt een vraag en krijgt het antwoord van vorig jaar. Dat staat in je inbox, met de vraag erbij.

Die laatste kolom is de reden dat ik dit interessant vind. Een AI-assistent op je eigen content is de snelste kwaliteitscontrole op je website die er bestaat. Hij vertelt je binnen een dag welke pagina onvindbaar is, welke informatie dubbel staat en welke vraag je nergens beantwoordt. Voor precies dezelfde problemen geeft Google je een halfjaar later een lichte daling in je posities, zonder uitleg.

Het werk dat je doet om je assistent goede antwoorden te laten geven, verbetert dus grotendeels ook je vindbaarheid. Dat komt doordat het over dezelfde HTML gaat.

Je sitemap is vaker stuk dan je denkt

Een sitemap is een lijst van URL's die op je site zouden moeten staan. Vrijwel elk CMS genereert er automatisch een, en juist daarom kijkt niemand er ooit in. Dit zijn de problemen die wij in de praktijk het vaakst tegenkomen, allemaal in sitemaps die het volgens het CMS prima deden.

De sitemap staat op http:// terwijl de site op https:// draait. Dit is met afstand de vervelendste, omdat hij zo onschuldig oogt. Elke URL in de lijst leidt dan tot een omleiding: de crawler vraagt de http-versie op, krijgt een omleiding naar https en moet opnieuw. Het inlezen wordt twee keer zo traag en je server krijgt het dubbele aantal verzoeken. Bij een grote site is dat het verschil tussen een uur en een halve dag.

Entries zonder <loc>, of met witruimte eromheen. Een regelovergang of een paar spaties binnen het element, en de URL die eruit komt bestaat niet. Een strenge parser slaat hem over, een soepele parser vraagt een onzin-URL op.

Een lastmod in een eigen datumformaat. Die datum bepaalt wanneer een pagina opnieuw wordt opgehaald. Is hij onleesbaar, dan verliest de crawler zijn belangrijkste aanwijzing dat er iets is veranderd.

URL's van een ander domein. Vaak een restant van een migratie of een koppeling met een externe tool. De crawler krijgt dan pagina's aangeboden die niet bij je site horen.

<!-- Drie fouten in vier regels -->
<url><loc>http://www.voorbeeld.nl/contact</loc></url>
<url><loc> https://www.voorbeeld.nl/over-ons </loc></url>
<url><lastmod>11-08-2026</lastmod></url>

En dan het punt dat vaak ontbreekt: een sitemap is een aanwijzing, geen waarheid. Hij vertelt wat er volgens je CMS zou moeten zijn. Wat er werkelijk staat, blijkt pas bij het ophalen. Een goede crawler gebruikt de sitemap als startpunt en controleert daarna zelf, want anders neemt hij de fouten van je CMS over.

Wil je weten hoe onze crawler hiermee omgaat en hoe snel wijzigingen doorwerken, dan staat dat in de documentatie over de crawler.

Structured data richt je assistent in

Als je ooit schema.org-markup hebt toegevoegd om in Google een mooier zoekresultaat te krijgen, heb je zonder het te weten ook het inlezen door AI-systemen makkelijker gemaakt. Dat JSON-LD-blok in je HTML is namelijk de enige plek op een webpagina waar expliciet staat wat iets is. De rest is opmaak waar je uit moet afleiden.

Bij ons haalt het systeem de titel, de auteur en de samenvatting van een document rechtstreeks uit die structured data, als die er is. Sinds begin augustus gaat het een stap verder: bij het aanmaken van een nieuwe bron kijkt een agent naar je pagina's en stelt zelf voor waar metadata vandaan moet komen. Staat er nette JSON-LD op je site, dan wijst hij die aan en is het klaar.

Staat die er niet, dan zoekt hij terug welk stukje HTML de publicatiedatum bevat en stelt een CSS-selector voor. Dat werkt, maar het is fragieler: een themawijziging verschuift zo'n selector, en dan lopen je datums stil zonder dat iemand het merkt. Structured data verschuift niet.

Aan onze kant gaat het trouwens ook weleens mis. In juli stonden er documenttitels in de kennisbank met “ erin, op de plek waar een aanhalingsteken hoorde.

De oorzaak zat in onze eigen opschoning van de HTML. Die zet leestekens en accenten om in een veilige code, en “ is zo'n code. Prima voor gewone tekst, maar hij deed het ook binnen het JSON-LD-blok, en daar hoort die omzetting niet thuis. De titel kwam dus keurig uit de structured data en raakte onderweg beschadigd.

Zulke fouten ziet niemand, totdat een bezoeker een antwoord krijgt met een rare titel eronder. Het model had er niets mee te maken.

De crawler moet er wel bij kunnen

Voor het inlezen begint, moet de crawler binnenkomen. Daar zitten twee lagen, en de meeste organisaties kennen alleen de bovenste.

De eerste is robots.txt. Onderzoeksbureau Writgo scande op 1 augustus 2026 de vijfhonderd best bezochte .nl-domeinen: 21,7 procent blokkeert daar minstens één AI-crawler, met GPTBot als meest geweerde op 16,8 procent. Dat is een legitieme keuze; niet iedereen wil dat zijn content in een taalmodel belandt. Wel is het goed om te weten dat zo'n regel breder kan uitpakken dan bedoeld, zeker als hij is opgesteld met een algemene lijst bot-namen erin.

De tweede laag is de laag waar dat onderzoek expliciet niets over zegt, en waar wij in de praktijk het vaakst tegenaan lopen: je firewall. Cloudflare, een WAF, bot fight mode, rate limiting. Die systemen kijken niet naar je robots.txt en beslissen zelf. Een crawler die netjes een User Agent meestuurt en zich aan de regels houdt, ziet er voor zo'n filter uit als precies het verkeer dat het moet tegenhouden.

Je herkent het aan 403-fouten in je serverlogs. Bij ons zie je het aan de melding "systeem tijdelijk gepauzeerd": loopt het inlezen in korte tijd tegen te veel fouten aan, dan stoppen we automatisch. Dat is met opzet. We blijven liever niet doorbeuken op een site die de verzoeken op dat moment niet aankan. Het stappenplan om dat op te lossen, inclusief de instellingen voor Cloudflare, staat in dezelfde documentatiepagina.

Alleen jouw kennis, in vier formaten

Eén ding sneeuwt in dit verhaal makkelijk onder. vragen.ai gebruikt uitsluitend de bronnen die jij aanlevert. Er wordt niets bijgehaald van elders op het internet, en het model vult niets aan uit wat het ooit heeft gelezen. Staat het antwoord niet in jouw content, dan komt er geen antwoord. Daarom gaat dit hele stuk over inlezen: het is de enige plek waar kennis binnenkomt.

Content komt op drie manieren binnen. Via de crawler, die je website uitleest en wijzigingen bijhoudt. Via een directe koppeling met je CMS, met de API of een van de plugins. Of via een feed, zowel RSS als Atom. Aan documenten verwerken we HTML, PDF en Word, zowel het huidige DOCX als het oudere DOC.

Dat PDF's daar tussen staan is handig, en tegelijk een waarschuwing waard. Een webpagina heeft structuur die een machine kan lezen: koppen zijn koppen, een tabel is een tabel. In een PDF is dat vaak weg. Wat overblijft is tekst op posities, waar de structuur uit afgeleid moet worden. Onderzoekers van OHRBench, een benchmark met ruim achtduizend documentafbeeldingen die op ICCV 2025 werd gepresenteerd, keken wat dat doet met de antwoordkwaliteit van RAG-systemen. Hun conclusie over de beschikbare technieken om documenten uit te lezen is niet mals: geen enkele is goed genoeg om er een betrouwbare kennisbank op te bouwen. Fouten bij het uitlezen werken door in het antwoord, en de rest van de keten repareert dat niet.

De praktische les: staat belangrijke informatie alleen in een PDF, dan is een gewone webpagina bijna altijd de betere bron. Dat geldt trouwens ook voor je vindbaarheid.

Waar techniek ophoudt en redactie begint

Tot hier ging het over dingen die je kunt repareren. Nu het deel dat geen technische oplossing heeft.

Stel: de richtlijn uit 2019 staat nog online, en de herziene versie uit 2024 staat er ook. Allebei gaan ze over de vraag die iemand stelt. Allebei komen ze van jouw eigen website, dus allebei zijn ze even betrouwbaar. Welke van de twee nu geldt, is een inhoudelijk oordeel. Dat kan jouw organisatie vellen en een systeem niet.

Dit is een bekend en hardnekkig probleem. Een onderzoeksgroep bij Google publiceerde in juni 2025 CONFLICTS, een benchmark voor precies dit soort tegenstrijdigheden tussen bronnen. De uitkomst: taalmodellen lossen zulke conflicten vaak niet goed op. Wat wel helpt, is het model expliciet over het conflict laten nadenken. Een beter model kiezen en hopen dat het overgaat, helpt niet.

Je hebt hier twee knoppen voor, en allebei kosten ze iets. Je kunt de oude versie uitzetten, zodat hij niet meer meedoet. Dat kost geen seconde extra, maar je moet vooraf weten welke pagina achterhaald is. Bij een handvol richtlijnen lukt dat, bij duizenden documenten niet. Of je laat de agent oordelen: die weegt mee hoe oud een document is en zoekt zo nodig naar een recentere versie. Dat schaalt wel, maar het kost een denkstap, en de bezoeker wacht net iets langer op zijn antwoord.

Verder is het handig om te weten dat weghalen anders werkt dan mensen verwachten. Verwijderen haalt een document nu weg, maar de crawler pikt het bij een volgende ronde weer op als het nog op je site staat. Uitzetten onthoudt dat je het bewust niet wilt. Voor een archief dat online moet blijven maar niet in antwoorden hoort, is uitzetten dus de juiste knop. En verdwijnt een pagina echt van je site, reken dan op een dag vertraging; blijft het onderwerp daarna terugkomen, dan linken andere pagina's er nog naar. Meer daarover staat in content in je kennisbank beheren.

Dat opruimwerk is precies het werk dat je site ook beter vindbaar maakt. Dubbele pagina's, verouderde versies en content die nergens meer vandaan te bereiken is: daar heeft een zoekmachine net zo veel last van.

Wat je vandaag kunt nakijken

Zes dingen die geen project zijn en die zowel je assistent als je vindbaarheid helpen.

• Open je sitemap en kijk of de URL's op https staan, of de lastmod-datums kloppen en of er geen vreemde domeinen tussen staan.
• Zoek in je serverlogs naar 403-fouten van crawlers. Dat is je firewall die iets tegenhoudt.
• Controleer wat er in je robots.txt staat en of die regels nog zijn wat je bedoelde.
• Kijk of je belangrijkste pagina's structured data hebben, en of daar een fatsoenlijke titel en datum in staan.
• Zoek de onderwerpen waarvan twee versies online staan en bepaal welke de geldende is.
• Kijk of informatie die er echt toe doet alleen in een PDF staat.

Krijg je nu al verouderde antwoorden uit een AI-assistent, dan is dat lijstje meteen je diagnose. En zit je nog te twijfelen of zoiets iets voor je organisatie is: je kunt onze eigen widget op onze eigen content proberen, inclusief de bronnen onder elk antwoord. Wat je hierboven leest, is precies het werk dat daar onder zit.