Waarom je geen aparte AI-pagina’s moet bouwen

En wat wél werkt voor AEO en GEO

De opkomst van ChatGPT, Google AI Overviews en andere AI-zoekervaringen heeft een nieuwe, soms ietwat paniekerige optimalisatietrend in gang gezet.

Websites maken vereenvoudigde Markdown-versies van hun bestaande pagina’s. Anderen publiceren speciale tekstpagina’s voor taalmodellen, zetten een llms.txt-bestand online of proberen hun volledige website in een tweede, uitgeklede vorm aan AI-systemen aan te bieden.

De gedachte daarachter klinkt logisch.

Als AI-systemen informatie moeten ophalen, verwerken en samenvatten, waarom zouden we die informatie dan niet in een zo eenvoudig mogelijk formaat aanbieden?

Toch is dat de verkeerde afslag.

Niet omdat Markdown een slecht bestandsformaat is. Ook niet omdat iedere machineleesbare voorziening nutteloos is. Het probleem ontstaat wanneer je naast je gewone website een tweede contentversie bouwt die uitsluitend voor AI-systemen bedoeld is.

Daarmee creëer je een parallelle website voor machines, terwijl je bestaande website juist de centrale en betrouwbare bron zou moeten zijn.

De waarschuwing van John Mueller: bouw geen tweede website voor bots

Google Search Advocate John Mueller waarschuwde tegen het spiegelen van gewone HTML-pagina’s in aparte Markdown-versies voor AI-agenten. Search Engine Journal deed verslag van de waarschuwing van John Mueller en Martin Splitt tegen parallelle Markdownversies voor AI.

De aanleiding was veelzeggend. Sommige websites investeren tijd in speciale pagina’s voor taalmodellen, terwijl de gewone website nog steeds problemen heeft met toegankelijkheid, semantische HTML of bruikbaarheid voor bezoekers die bijvoorbeeld een schermlezer gebruiken.

Daarmee worden de prioriteiten volledig omgedraaid.

Een goed gebouwde website hoort niet eerst voor mensen te functioneren en daarna via een technische omweg geschikt te worden gemaakt voor machines. Goede webcontent zou van nature bruikbaar moeten zijn voor:

• menselijke bezoekers;
• zoekmachines;
• schermlezers;
• browsers;
• crawlers;
• en AI-agenten die de website mogen bezoeken.

De kern van Muellers waarschuwing is daarom niet dat Markdown verboden of schadelijk is.

De werkelijke waarschuwing gaat over het creëren van parallelle contentversies en de technische schuld die daaruit voortkomt.

Markdown is niet het probleem

Markdown is een prima formaat voor documentatie, repositories, interne kennisbanken en contentworkflows.

Ook een llms.txt-bestand is op zichzelf niet gevaarlijk. Het kan functioneren als een compacte inhoudsopgave of wegwijzer voor systemen die ervoor kiezen dit bestand te gebruiken.

Maar een llms.txt-bestand is iets anders dan het dupliceren van iedere webpagina in een tweede formaat.

De problemen ontstaan wanneer:

• dezelfde informatie op meerdere plaatsen wordt beheerd;
• de machineversie handmatig moet worden bijgewerkt;
• prijzen, voorwaarden of specificaties uiteen kunnen gaan lopen;
• de alternatieve versie niet door gewone bezoekers wordt gecontroleerd;
• een organisatie ervan uitgaat dat het bestand automatisch tot AI-citations leidt;
• de tweede versie wordt gebruikt om zwakke HTML of een slechte informatiearchitectuur te maskeren.

Voor zichtbaarheid in AI-search is geen tweede website nodig.

De gewone website moet de bron blijven. Technische voorzieningen kunnen die bron ondersteunen, maar mogen haar nooit vervangen.

Waarom aparte AI-pagina’s technische schuld veroorzaken

Je creëert dubbel onderhoud

Zodra dezelfde informatie op twee plaatsen staat, moet iedere wijziging ook twee keer worden doorgevoerd.

Verandert een productprijs, openingstijd, dienstomschrijving, medische richtlijn of garantievoorwaarde? Dan moet niet alleen de gewone webpagina worden aangepast, maar ook de speciale AI-versie.

In theorie kun je daarvoor synchronisatie bouwen.

In de praktijk ontstaat vroeg of laat een verschil.

De zichtbare website noemt een nieuwe prijs, terwijl de Markdown-kopie nog het oude bedrag bevat. Een dienst is aangepast, maar de machineversie beschrijft nog het vorige aanbod. Of de gewone pagina vermeldt gewijzigde voorwaarden, terwijl een vergeten tekstbestand achterblijft.

Het resultaat is precies wat je bij SEO, AEO en GEO wilt voorkomen: meerdere versies van dezelfde organisatie die verschillende feiten communiceren.

Dat is slecht voor bezoekers, zoekmachines én AI-systemen die juist proberen vast te stellen welke informatie actueel en betrouwbaar is.

Fouten blijven langer onzichtbaar

Een gewone webpagina wordt bekeken door klanten, medewerkers en websitebeheerders. Een defect valt daardoor meestal op.

Een pagina die alleen voor machines is bedoeld, kan maandenlang verouderd, incompleet of technisch onbereikbaar zijn zonder dat iemand het merkt.

Denk aan:

• een export die niet meer wordt bijgewerkt;
• een verkeerde statuscode;
• ontbrekende velden;
• verouderde interne links;
• verkeerd verwerkte speciale tekens;
• dubbele of tegenstrijdige teksten;
• een bestand dat per ongeluk wordt geblokkeerd;
• informatie die achterloopt op de zichtbare website.

Je bouwt dus niet alleen een extra publicatiekanaal. Je creëert ook een extra test-, beheer- en controleproces.

Je splitst je bron van waarheid

Voor belangrijke bedrijfsinformatie wil je één centrale bron hebben.

Eén plek waar prijzen, diensten, voorwaarden, auteursinformatie, producten en andere feiten worden beheerd. Vanuit die centrale bron kunnen verschillende systemen dezelfde gegevens gebruiken.

Zodra een aparte AI-pagina zelfstandig wordt onderhouden, ontstaat er een tweede bron van waarheid.

En twee bronnen van waarheid leveren vroeg of laat twee versies van de waarheid op.

Je behandelt het symptoom in plaats van het probleem

Wanneer een AI-systeem je website moeilijk kan verwerken, is de eerste vraag niet:

Hoe maak ik een aparte tekstversie voor de bot?

De eerste vraag is:

Waarom is de gewone website niet duidelijk genoeg?

Misschien staat belangrijke informatie alleen in JavaScript. Misschien bestaat de pagina vooral uit visuele componenten zonder logische HTML-structuur. Misschien zijn productspecificaties verstopt in afbeeldingen, tabbladen of downloads.

Of misschien bestaat de tekst voornamelijk uit algemene marketingclaims, zonder concrete feiten die een zoekmachine of AI-systeem kan gebruiken.

Een aparte Markdownpagina maskeert zulke problemen. Ze lost de onderliggende informatiearchitectuur niet op.

Eén sterke pagina voor mens én machine

Dat begint bij gewone HTML.

HTML is niet alleen bedoeld voor menselijke bezoekers. Het is de fundamentele informatielaag waarmee browsers, zoekmachines, accessibility-tools en crawlers de structuur van een pagina interpreteren.

Dat is waarom technische SEO de basis blijft voor AI-search.

Een goede pagina bevat daarom:

• één duidelijke hoofdonderwerptitel;
• logisch opgebouwde H2- en H3-koppen;
• echte HTML-links met betekenisvolle ankerteksten;
• concrete informatie in de zichtbare hoofdcontent;
• tabellen wanneer gegevens daadwerkelijk tabulair zijn;
• lijsten voor stappen, voorwaarden of kenmerken;
• heldere definities en antwoordblokken;
• belangrijke informatie die zonder onnodige interactie beschikbaar is;
• voldoende context om losse passages correct te kunnen begrijpen.

Voor AEO en GEO is niet alleen de volledige pagina belangrijk.

Lees ook wat GEO betekent voor je bestaande SEO-strategie.

Ook afzonderlijke alinea’s, tabellen, definities en secties moeten zelfstandig betekenisvol zijn. Retrievalsystemen werken immers vaak met passages of fragmenten, niet noodzakelijk met een volledige pagina van begin tot eind.

Een duidelijke sectie over retourvoorwaarden, productspecificaties of technische oorzaken is daarom bruikbaarder dan een lange tekst waarin verschillende onderwerpen door elkaar lopen.

Ondersteunende machineleesbare lagen zijn geen aparte AI-pagina’s

Dat je geen aparte AI-pagina’s moet bouwen, betekent niet dat iedere machineleesbare voorziening overbodig is.

Er is een belangrijk verschil tussen:

1. een tweede contentversie die uitsluitend voor AI-systemen wordt onderhouden;
2. een ondersteunende technische laag die dezelfde zichtbare bron verduidelijkt of ontsluit.

Structured data is een goed voorbeeld van die tweede categorie.

Met Schema.org-markup in JSON-LD kun je zoekmachines expliciete aanwijzingen geven over wat onderdelen van een pagina voorstellen en hoe entiteiten met elkaar samenhangen.

Je maakt daarmee geen nieuwe pagina. Je voegt geen tweede URL toe en je dupliceert de zichtbare tekst niet. Je verrijkt de bestaande bron met aanvullende betekenis.

Praktijkvoorbeeld: een webshop met een onduidelijke identiteit

Stel dat een volledig fictieve Nederlandse online speciaalzaak de naam Vespera Koffie draagt.

Uit de bedrijfsnaam alleen wordt niet direct duidelijk dat de onderneming gespecialiseerd is in ambachtelijk gebrande specialty coffee, espressomachines, barista-tools, koffietrainingen en koffie-abonnementen.

In dit fictieve voorbeeld wordt daarnaast de alternatieve merknaam Vespera Coffee Roasters gebruikt.

Een developer kan de bestaande organisatie-entiteit dan bijvoorbeeld als volgt aanvullen:

$data['description'] = 'Vespera Koffie is een Nederlandse online speciaalzaak voor ambachtelijk gebrande specialty coffee, espressomachines, barista-tools, koffietrainingen en koffie-abonnementen.';

/*
- Volledig fictief voorbeeld van Yubb, uitsluitend ter illustratie.
 */
$data['alternateName'] = 'Vespera Coffee Roasters';

$data['knowsAbout'] = array(
    'Specialty coffee',
    'Ambachtelijk koffiebranden',
    'Espressomachines',
    'Barista-trainingen',
    'Slow coffee'
);

$data['areaServed'] = array(
    array(
        '@type' => 'Country',
        'name'  => 'Nederland',
        '@id'   => 'https://www.wikidata.org/wiki/Q55'
    ),
    array(
        '@type' => 'Country',
        'name'  => 'België',
        '@id'   => 'https://www.wikidata.org/wiki/Q31'
    )
);

return $data;

Deze aanvulling doet vier dingen.

De description verduidelijkt de identiteit

De beschrijving legt compact vast:

• wat voor onderneming Vespera Koffie is;
• waar het bedrijf gevestigd is;
• waarin de webshop gespecialiseerd is;
• welke productgroepen centraal staan.

Dat vermindert mogelijke ambiguïteit rond een merknaam die zonder extra context nog weinig zegt over de specialisatie.

De beschrijving moet uiteraard overeenkomen met wat ook zichtbaar op de website wordt gecommuniceerd.

alternateName verbindt een werkelijk gebruikte alternatieve naam

Een alternatieve naam kan nuttig zijn wanneer een onderneming daadwerkelijk onder meerdere herkenbare namen voorkomt.

In dit volledig fictieve voorbeeld wordt Vespera Coffee Roasters als alternatieve merknaam gebruikt. Wanneer een naam daadwerkelijk op verpakkingen en socialemediaprofielen voorkomt, kan alternateName helpen om beide benamingen met dezelfde organisatie te verbinden.

Het veld is niet bedoeld om simpelweg een zoekwoord aan de bedrijfsnaam toe te voegen.

Wanneer een webshop nergens een alternatieve naam gebruikt, hoort die ook niet in de structured data thuis.

knowsAbout beschrijft de inhoudelijke specialisatie

Met knowsAbout wordt de organisatie gekoppeld aan een beperkt aantal relevante onderwerpen.

De lijst moet compact en inhoudelijk blijven. Het is geen plaats voor tientallen Nederlandse en Engelse zoekwoordvarianten.

Dus niet:

• specialty coffee;
• specialty koffie;
• koffiebonen;
• coffee beans;
• espressomachines;
• espresso machines;
• barista-tools;
• barista tools;
• koffie-abonnementen.

Maar een kleine groep duidelijke expertise- of specialisatiegebieden die werkelijk bij de onderneming passen.

areaServed maakt het werkgebied expliciet

Wanneer de webshop daadwerkelijk aan Nederland en België verkoopt, kan dat geografische bereik eveneens worden beschreven.

Dit vervangt geen zichtbare informatie over verzendkosten, levertijden of retourvoorwaarden. Het maakt alleen explicieter in welke landen de organisatie actief is.

Waarom dit géén aparte AI-pagina is

Dit voorbeeld creëert:

• geen tweede URL;
• geen kopie van de zichtbare content;
• geen alternatief publicatiekanaal;
• geen afzonderlijk te beheren AI-document;
• geen tweede versie van de organisatie.

De markup beschrijft de bestaande organisatie binnen de bestaande webpagina en de bestaande schema-graph.

Dat is een fundamenteel ander principe dan een volledige Markdownkopie van de website bouwen.

De website blijft de bron.

Structured data helpt machines om onderdelen van die bron ondubbelzinniger te classificeren en relaties tussen entiteiten te begrijpen.

Daarbij helpen topical authority en entiteitsrelaties om samenhang zichtbaar te maken.

Wat structured data wel en niet doet

De rol van JSON-LD moet daarbij wel correct worden uitgelegd.

Structured data kan:

• een organisatie explicieter beschrijven;
• een auteur aan een artikel koppelen;
• producten, aanbiedingen en beschikbaarheid structureren;
• relaties tussen pagina’s, personen en organisaties verduidelijken;
• mogelijke ambiguïteit rond entiteiten verminderen;
• bestaande zichtbare informatie machineleesbaar classificeren.

Maar structured data:

• is geen directe lijn naar een taalmodel;
• bewijst niet dat een bewering waar is;
• garandeert geen opname in een AI-antwoord;
• garandeert geen citation;
• vervangt geen goede zichtbare content;
• repareert geen slechte informatiearchitectuur;
• maakt een onbetrouwbare website niet automatisch betrouwbaar.

JSON-LD is een verduidelijkingslaag.

De beste structured data beschrijft goede content. Ze probeert zwakke of ontbrekende content niet te compenseren.

HTML voor mensen én machines

De uitspraak “HTML voor mensen, structured data voor machines” klinkt aantrekkelijk, maar klopt niet helemaal.

HTML is ook voor machines.

Zoekmachines, browsers, schermlezers en AI-agenten kunnen onder meer gebruikmaken van:

• de DOM-structuur;
• headings;
• links;
• paragrafen;
• lijsten;
• tabellen;
• labels;
• formulieren;
• toegankelijkheidsinformatie;
• zichtbare context.

Structured data vult die HTML aan, maar staat er niet los van.

De juiste volgorde is daarom:

1. zorg dat de zichtbare HTML inhoudelijk en technisch goed is;
2. maak de structuur logisch en toegankelijk;
3. voeg waar relevant accurate structured data toe;
4. zorg dat beide lagen elkaar niet tegenspreken.

Niet andersom.

Van keywords naar betekenis, zonder keywords af te schrijven

Binnen AEO en GEO wordt vaak gezegd dat zoekwoorden niet meer belangrijk zijn omdat AI-systemen alleen nog met concepten werken.

Ook dat is te kort door de bocht.

Moderne zoek- en AI-systemen kijken inderdaad verder dan exacte zoekwoordovereenkomsten. Ze proberen de intentie achter een vraag te begrijpen, herkennen synoniemen en analyseren relaties tussen onderwerpen en entiteiten.

Maar exacte termen blijven belangrijk.

Productnamen, modelnummers, locaties, vaktermen, persoonsnamen en specifieke diensten moeten nog steeds duidelijk in je content voorkomen.

Semantisch begrip vervangt taal niet. Het gebruikt taal om betekenis af te leiden.

De verschuiving is daarom niet van zoekwoorden naar géén zoekwoorden.

De verschuiving is van het optimaliseren voor losse termen naar het helder behandelen van de volledige informatiebehoefte achter die termen.

Wat AI-systemen wél nodig hebben

Een AI-systeem heeft geen uitgeklede kopie van je website nodig.

Het heeft een bron nodig die duidelijk genoeg is om betrouwbaar te kunnen gebruiken.

Dat betekent in de praktijk:

Concrete informatie

Vervang algemene claims door controleerbare feiten, voorwaarden, kenmerken en voorbeelden.

“Wij leveren de beste service” zegt weinig.

“Bestellingen vóór 15.00 uur worden op werkdagen dezelfde dag verzonden” bevat concrete informatie die kan worden gecontroleerd en gebruikt.

Heldere context

Maak duidelijk op welk product, jaar, land, doelgroep of scenario een uitspraak betrekking heeft.

Een prijs zonder valuta, een openingstijd zonder datum of een technisch advies zonder toepassingsgebied kan gemakkelijk verkeerd worden geïnterpreteerd.

Consistente entiteiten

Gebruik consistente namen voor je organisatie, auteurs, producten, diensten en locaties.

Wanneer dezelfde onderneming op de homepage, contactpagina, socialemediaprofielen en in structured data telkens anders wordt genoemd, ontstaat onnodige ambiguïteit.

Bewijs en herkomst

Onderbouw belangrijke claims met bronnen, eigen onderzoek, praktijkervaring, testresultaten of deskundige uitleg.

Juist nu het web wordt overspoeld met generieke AI-teksten, worden aantoonbare ervaring en verifieerbare informatie waardevoller.

Ook de AI-paradox voor onafhankelijke publishers laat zien waarom oorspronkelijke informatie belangrijk blijft.

Technische toegankelijkheid

• Zorg dat belangrijke informatie aanwezig is in crawlbare, indexeerbare en logisch opgebouwde HTML.
• Verstop essentiële productinformatie niet uitsluitend in afbeeldingen, downloads of interactieve componenten.
• Actueel beheer
• Voorkom dat prijzen, openingstijden, voorwaarden of beschikbaarheid verspreid staan over meerdere verouderde documenten.
• Eén goed beheerde bron is betrouwbaarder dan vijf half bijgewerkte varianten.

Wanneer feeds en API’s wel behulpzaam zijn

Ook productfeeds, voorraadkoppelingen, vacaturefeeds en API’s kunnen een website ondersteunen.

Dat zijn echter geen aparte AI-pagina’s.

Het verschil zit in het doel en de architectuur.

Een verantwoordelijke ondersteunende laag:

• heeft een concrete technische of operationele toepassing;
• wordt automatisch uit dezelfde centrale databron gegenereerd;
• hoeft niet handmatig naast de website te worden bijgehouden;
• blijft inhoudelijk gelijk aan de zichtbare bron;
• wordt gemonitord en gevalideerd;
• vervangt de gewone webpagina niet.

Een productfeed die automatisch wordt gevuld vanuit dezelfde database als de webshop is dus geen tweede website. Het is een gestructureerde gegevensuitwisseling rondom dezelfde bron.

Honderden zelfstandig onderhouden Markdownkopieën van bestaande pagina’s vormen wél een parallelle contentlaag.

De techniek zelf is niet het probleem.

De vraag is of je één bron ondersteunt of een tweede bron creëert.

Een praktische controle voor je eigen website

Voordat je een aparte AI-laag laat bouwen, controleer eerst de bestaande website:

1. Staat de belangrijkste informatie in de HTML die de server of gerenderde pagina beschikbaar maakt?
2. Is de pagina logisch opgebouwd met duidelijke headings en secties?
3. Zijn prijzen, voorwaarden, specificaties en datums zichtbaar en actueel?
4. Kunnen belangrijke passages zelfstandig worden begrepen?
5. Zijn auteurs, organisaties, producten en andere entiteiten consistent beschreven?
6. Komt structured data overeen met de zichtbare informatie?
7. Is er één duidelijke bron van waarheid voor belangrijke bedrijfsdata?
8. Kunnen zoekmachines en gewenste AI-crawlers de pagina bereiken?
9. Is de website bruikbaar met een schermlezer en zonder complexe interacties?
10. Kun je aantonen waar belangrijke claims vandaan komen?
11. Worden ondersteunende feeds en endpoints automatisch uit dezelfde databron opgebouwd?
12. Bestaan er geen vergeten alternatieve versies met afwijkende informatie?

Wanneer deze basis niet klopt, is een Markdownversie geen oplossing.

Dan digitaliseer je dezelfde onduidelijkheid alleen in een tweede formaat.

Conclusie: bouw niet voor een veronderstelde bot

De waarschuwing van Google is goed nieuws voor nuchtere marketeers, publishers en website-eigenaren.

We hoeven geen tweede website voor AI-bots te bouwen. We hoeven het web ook niet opnieuw uit te vinden met losse tekstkopieën waarvan niemand zeker weet welke systemen ze daadwerkelijk gebruiken.

De toekomstbestendige aanpak begint bij één betrouwbare informatiebron:

• toegankelijke en semantische HTML;
• nuttige content voor mensen;
• een heldere informatiearchitectuur;
• concrete en controleerbare informatie;
• consistente entiteiten en relaties;
• en structured data die de zichtbare inhoud correct verduidelijkt.

JSON-LD kan machines helpen begrijpen wat iets voorstelt, maar het is geen ultiem AEO-wapen en geen garantie op een citation.

Een llms.txt-bestand kan als aanvullende of experimentele wegwijzer worden ingezet, maar het vervangt de technische en inhoudelijke kwaliteit van je website niet.

Bouw daarom geen aparte pagina’s voor een veronderstelde AI-bot.

Bouw één website die mensen goed bedient en die zoekmachines, schermlezers en AI-systemen zonder kunstgrepen kunnen crawlen, interpreteren en gebruiken.

Voeg alleen ondersteunende machineleesbare lagen toe wanneer daar een concrete toepassing voor bestaat en wanneer ze voortkomen uit dezelfde centrale bron.

De website blijft de bron. De techniek eromheen ondersteunt die bron.

Dat is geen nieuwe GEO-truc.

Dat is toekomstbestendige SEO.

Lees meer artikelen in de kennisbank.

Bronnen en verdere verdieping

• John Mueller en Martin Splitt over parallelle Markdownversies voor AI — Search Engine Journal
• Introduction to the Technical Debt Concept — Agile Alliance