ChatGPT slaat je technische documentatie over omdat die niet leesbaar of niet extraheerbaar is. Assistenten halen een handvol bronnen op, vatten die samen en citeren wat het duidelijkst gestructureerd staat. Als jouw docs achter JavaScript laden, geen koppen hebben en changelogs als losse HTML-lappen publiceren, kom je niet in het antwoord. De oplossing: korte zelfstandige secties, schema.org-markup, een llms.txt-bestand en een machine-leesbaar changelog-formaat.
Dat klinkt technisch. Dat is het ook. Maar je hoeft geen developer te zijn om je dev-team te briefen.
Dat is precies het probleem dat we bij B2B-softwarebedrijven zien. De docs zijn in orde. Het antwoord komt van ergens anders.
Technische documentatie vindbaar maken voor AI-assistenten is een ander spel dan klassieke SEO. Een assistent scoort geen tien blauwe links. Hij kiest er drie of vier, leest ze en schrijft één antwoord. Kom je daar niet tussen, dan besta je voor die gebruiker niet.
Onze ervaring is dat technische kopers steeds vaker een AI-assistent als eerste research-stap gebruiken, nog voor ze een demo aanvragen. Ze typen een vraag over integratie, over een API-limiet, over een migratiepad. Het antwoord bepaalt welke leverancier ze serieus nemen.
Bij AI-zoekoptimalisatie voor B2B-software gaat het mis op drie punten. De docs laden client-side, dus de crawler ziet niets. De tekst staat in lange ongestructureerde blokken. En de changelog mist elke consistentie in datum en versie.
Wij zien dat documentatie in korte, zelfstandig leesbare secties met heldere koppen vaker letterlijk wordt geciteerd dan een lap tekst van tweeduizend woorden. De reden is simpel. Het model pakt het brokje dat het makkelijkst te extraheren is.
Grote taalmodellen werken vaak via retrieval-augmented generation. Het model haalt externe documenten op, gebruikt die als context en genereert daarmee een antwoord. Wil je docs structureren voor ChatGPT en Perplexity, dan moet je begrijpen wat er in die ophaalstap gebeurt.
De drie assistenten pakken het net anders aan.
De rode draad: elk van deze systemen kiest een klein aantal bronnen en vat die samen. Er is geen tweede pagina. Technische content geciteerd krijgen door AI betekent dus dat je in die eerste selectie moet zitten.
Wat helpt bij die selectie? Een pagina die de vraag direct beantwoordt in de eerste alinea. Een kop die letterlijk de vraag stelt die de gebruiker typt. En een structuur waarin elk stukje op zichzelf klopt, zonder de rest van de pagina.
LLM-vriendelijke documentatie schrijven draait om extraheerbaarheid. Kan het model één paragraaf uit je pagina lichten die op zichzelf een compleet antwoord vormt? Zo ja, dan word je geciteerd. Zo nee, dan pakt het model een concurrent die het wel voor elkaar heeft.
Begin elke pagina met het antwoord. Niet met een inleiding over wat je gaat behandelen. De vraag staat in de kop, het antwoord staat in de eerste twee zinnen daaronder. Alles daarna is uitwerking.
Hak je content in stukken. Eén onderwerp per sectie, één gedachte per kop. Een sectie van drie alinea's die je los kunt lezen werkt beter dan een hoofdstuk van tien.
Een paar principes die we consistent zien werken:
Structured data voor AI hoort hierbij, maar begint bij de tekst zelf. Als de onderliggende tekst een warboel is, redt geen enkele markup je. Eerst de inhoud opschonen. Dan pas de markup eroverheen.
Schema markup voor documentatie vertelt crawlers en AI-assistenten wat een pagina precies is. Schema.org biedt gestandaardiseerde types zoals TechArticle en SoftwareApplication die zoekmachines en AI-crawlers kunnen interpreteren. Voor een docs-pagina is dat de tolk tussen jouw HTML en het model.
Welk type gebruik je waar? Een paar richtlijnen die we in de praktijk aanhouden.
Zet de schema als JSON-LD in de head van de pagina. Dat is het formaat dat Google adviseert en dat het makkelijkst te onderhouden is. Je dev-team hoeft de HTML er niet voor te verbouwen.
Een waarschuwing. Schema die niet klopt met de zichtbare tekst is erger dan geen schema. Beschrijf in de markup wat er echt op de pagina staat. Verzin geen velden om beter voor de dag te komen. Assistenten en crawlers prikken daar doorheen en het schaadt je meer dan het oplevert.
Het llms.txt-voorstel is een openbaar gepubliceerde conventie waarmee een website een gestructureerd tekstbestand aanbiedt dat specifiek bedoeld is voor grote taalmodellen. Je zet het in de root van je domein, net als robots.txt. Het geeft assistenten een schone route naar je belangrijkste content.
Waarom dit werkt voor docs? Je documentatie zit vaak verspreid over honderden pagina's. Een llms.txt-bestand wijst het model naar de kern. Hier staat de API-referentie, hier de guides, hier de changelog.
Een basaal bestand ziet er zo uit. Bovenaan een korte omschrijving van je product in platte tekst. Daaronder een lijst met links naar je belangrijkste pagina's, elk met één zin uitleg. Kort houden. Het is een wegwijzer, geen kopie van je hele site.
Dit is nog een jong voorstel. Niet elke assistent leest het al. Maar het kost je dev-team een uur en het schaadt niks. Voor docs structureren richting ChatGPT en Perplexity is het een goedkope stap die je vandaag kunt zetten.
Changelog AI-citatie optimaliseren begint bij consistentie. Onze ervaring is dat een consistent, machine-leesbaar changelog-formaat het verschil maakt of een release überhaupt door AI wordt opgepikt. Datum, versie, categorie. Elke keer hetzelfde.
Wij zien dat veel Nederlandse B2B-softwarebedrijven hun changelogs als losse HTML-pagina's publiceren, zonder gestructureerde markup en zonder consistente datumnotatie. Het gevolg: een assistent kan niet vaststellen wanneer een feature verscheen of welke versie iets introduceerde.
Een changelog die AI wel oppikt, ziet er zo uit:
Release notes SEO en AI-citatie lopen hier gelijk op. Een gestructureerde changelog is voor beide leesbaar. Voeg per entry een echte datum toe in de tekst, niet alleen visueel. En zorg dat elke entry op zichzelf te begrijpen is, zonder de vorige tien te lezen.
Eén extra: publiceer je changelog op een vaste, crawlbare URL. Niet in een modal die pas laadt na een klik. Wat een crawler niet kan bereiken, kan een assistent niet citeren.
Technische documentatie vindbaar maken voor AI-assistenten wordt behapbaar als je het in stappen zet. Deze checklist kun je doorsturen naar je dev-team.
Loop deze lijst één keer per kwartaal langs. Modellen veranderen, je docs groeien. Wil je weten of assistenten je nu al noemen, dan kun je een gratis AI-zichtbaarheidsscan draaien op onze GEO-scanner.
De meeste problemen die we tegenkomen zijn geen exotische edge-cases. Het zijn dezelfde drie fouten, telkens opnieuw.
Fout één: alles laadt client-side. AI-crawlers voeren JavaScript vaak niet uit. Draait je docs-portaal volledig op een front-end framework zonder server-side rendering, dan ziet de crawler een lege pagina. Je mooiste content bestaat voor het model niet.
Fout twee: lange ongestructureerde tekst. Een pagina van tweeduizend woorden zonder koppen dwingt het model om te gokken welk stuk relevant is. LLM-vriendelijke documentatie schrijven betekent het model die keuze uit handen nemen. Korte secties, heldere koppen, één onderwerp per blok.
Fout drie: schema die niet klopt met de tekst. Markup die iets anders beweert dan de zichtbare pagina ondermijnt je geloofwaardigheid. Technische content geciteerd krijgen door AI vraagt om eerlijke structured data die één op één matcht met wat er staat.
Herken je hier je eigen docs in? Dan is de goede nieuws-kant: d