De fleste udviklere tror, at API-dokumentation er til mennesker. Det er den ikke længere.
Når ingeniører spørger ChatGPT, hvordan man godkender mod et API, bygger en webhook eller håndterer begrænsning af antal kald, konkurrerer din dokumentation direkte mod 50 andre kilder i AI-systemets vurdering. AI-motorer vurderer teknisk dokumentation som primære kilder. En veludformet API-reference kan blive citeret hundredvis af gange om måneden. En dårligt optimeret bliver helt ignoreret.
Problemet er, at teknisk dokumentation ikke er lavet til AI. Den er lavet til mennesker, der søger på Google, klikker på links og læser trin for trin. AI-systemer læser anderledes. De trækker ud, deler op, tilskriver og citerer. Din dokumentations opbygning, dine kodeeksempler og din versionering har alle betydning for, om et AI-system kan finde, forstå og citere dit indhold. Dette kapitel gennemgår, hvordan optimering af teknisk dokumentation ser ud, og hvilke konkrete ændringer der gør din dokumentation fra usynlig til uundværlig.
Hvad er optimering af teknisk dokumentation til AI?
Optimering af teknisk dokumentation til AI er den praksis at opbygge API-referencer, implementeringsguides, fejldokumentation og kodeeksempler, så AI-crawlere kan læse, trække ud, tilskrive og citere dem korrekt. I modsætning til klassisk SEO, som optimerer til at følge links og matche søgeord, fokuserer optimering af dokumentation til AI på semantisk klarhed, let udtræk og tæthed af fakta.
Et AI-system, der indekserer din dokumentation, gør tre ting. Det crawler dine sider for at læse dem (crawlbarhed). Det gemmer dele af dit indhold som selvstændige bidder, der kan hentes frem, når de er relevante (opdeling i bidder). Og det afgør, om det vil citere din bid som kilde, når det genererer et svar (værd at citere). De fleste dokumentationer fejler på ét eller flere af de trin.
Hvorfor AI-citater betyder noget for teknisk indhold
Teknisk dokumentation er en af de indholdstyper, AI-systemer stoler mest på. Når en udvikler spørger ChatGPT, hvordan man bruger dit API, vægter systemet teknisk dokumentation tungere end blogindlæg eller fora, fordi API'er kræver præcision. Et forkert endpoint, en manglende parameter eller en forkert godkendelsesmetode får integrationen til at bryde sammen.
AI-systemer belønner den opfattelse. Din API-referencedokumentation har større chance for at blive citeret end dit blogindhold, fordi den er mere konkret, nemmere at kontrollere og mere komplet. Problemet er, at udviklere ikke finder dig gennem AI-søgning på samme måde, som de finder blogindhold. De finder dig gennem direkte søgninger på dit API, gennem mund-til-mund og gennem tidlig brug. Når de først har fundet din dokumentation, afgør din optimering, om andre udviklere finder din løsning gennem AI.
Sådan læser og trækker AI-systemer ud af teknisk dokumentation
AI-crawlere behandler din dokumentation som en struktureret database, ikke som en fortælling. Sådan går det, når et AI-system indekserer din dokumentation.
Først anmoder crawleren om din side (eller din dokumentationsplatform leverer den gennem et API). Hvis din dokumentation er bygget med JavaScript-frameworks uden rendering på serveren, får crawleren tom HTML. Det er en af de mest almindelige fejl. Hvis din dokumentation er bygget med et moderne JavaScript-framework, så tjek, at din hosting eller dokumentationsplatform renderer siderne på serveren, ellers bliver dit indhold usynligt for de fleste AI-crawlere.
Dernæst deler systemet din side op i bidder. Det gemmer ikke din API-reference på 4.000 ord som én blok. Det deler den op i afsnit, normalt på mellem 100 og 300 ord hver. Overskrifternes hierarki betyder enormt meget her. Hvis du springer overskriftsniveauer over (fra H1 direkte til H3), bliver systemet forvirret over, hvad der hører hvor. Hvis dine overskrifter er vage ("Overblik" i stedet for "Godkendelsesmetoder"), kan systemet ikke se, hvad hvert afsnit dækker, uden at læse hvert ord.
Så giver systemet hver bid metadata. Det læser din overskrift, afsnittets tekst, kodeeksempler og strukturerede data (schema-markup) for at forstå, hvad bidden handler om. Derefter gemmer det bidden i en vektordatabase, hvor lignende begreber samler sig. Når en udvikler stiller et spørgsmål, finder systemet de klynger, der ligger tæt på spørgsmålets vektor, og henter de mest relevante bidder.
Til sidst afgør systemet, om det vil citere din bid. Det afhænger af tæthed af fakta, klarhed, konkrete detaljer og af, om oplysningen findes andre steder. En generel forklaring på, hvordan man sætter headers, bliver citeret sjældnere end et konkret eksempel, der viser, hvilke headers dit API kræver.
Optimer din dokumentations opbygning, så AI kan trække ud
Dit overskriftshierarki er dit stærkeste optimeringsværktøj. Brug ensartede, konkrete H2- og H3-overskrifter, der fortæller systemet præcis, hvad hvert afsnit dækker.
Brug konkrete, fuldstændige overskrifter
FORKERT overskrift: "Godkendelse"
RIGTIG overskrift: "Sådan godkender du API-kald"
Den rigtige version fortæller systemet, at afsnittet indeholder handlingsorienterede oplysninger om godkendelse. Den forkerte version er tvetydig. Den kan dække, hvorfor godkendelse findes, hvordan godkendelse virker, eller hvad man gør, hvis godkendelsen fejler. Vær konkret.
Lad overskrifterne følge indholdets hierarki
Hvis dit API har flere godkendelsesmetoder (API-nøgle, OAuth, JWT), så brug H3-underoverskrifter til hver af dem, ikke punkttegn eller fed tekst. Punkttegn er fine til lister over ting. De er ikke fine til navngivne afsnit, der har brug for deres egen struktur.
God struktur
- H2: Sådan godkender du API-kald
- H3: Godkend med API-nøgle
- H3: Godkend med OAuth 2.0
- H3: Godkend med JWT
Strukturen fortæller systemet, at godkendelse er hovedemnet, og at der findes tre forskellige metoder under det. Systemet kan trække OAuth-afsnittet ud for sig og citere det, når en udvikler spørger specifikt om OAuth.
Skriv tydelige indledninger til trin
Hvis du beskriver en rækkefølge af trin, så indled dem tydeligt. Antag ikke, at systemet forstår, at dine punkttegn er trin.
FORKERT: "For at godkende skal du sætte din API-nøgle i headeren i kaldet. Brug headernavnet Authorization. Skriv værdien som Bearer YOUR_API_KEY."
RIGTIG: "For at godkende dit API-kald skal du følge de her tre trin. Først finder du din API-nøgle i indstillingerne for din WEMASY-konto. Dernæst tilføjer du Authorization-headeren til dit kald. Til sidst skriver du værdien som Bearer YOUR_API_KEY."
Den rigtige version bruger tydeligt sprog, der fortæller systemet, at det er trin i rækkefølge og ikke beslægtede fakta.
Gør dine kodeeksempler klar til udtræk
Kodeeksempler er den indholdstype i teknisk dokumentation, der bliver citeret mest. AI-systemer elsker at citere kode, fordi den er entydig. Men ikke alle kodeeksempler er lige gode. Måden, du præsenterer kode på, afgør, om systemet kan trække den ud og citere den korrekt.
Sæt kode sammen med en tekst foran, der forklarer, hvad koden gør
Sæt ikke kodeblokke for sig selv. Hvert kodeeksempel bør have en sætning foran, der forklarer, hvad det viser.
FORKERT struktur
[Kodeblok]
[Afsnit med forklaring]
RIGTIG struktur
[Sætning med forklaring]
[Kodeblok]
[Yderligere sammenhæng eller fejlhåndtering]
Forklaringen foran fortæller systemet, hvad det kan forvente af koden. Den giver også en sammenhæng, systemet kan citere, før koden selv vises.
Hold eksemplerne fokuseret på én opgave
Vis ikke et kodeeksempel på 50 linjer, der viser fem forskellige ting. Del det op i flere eksempler, der hver viser én bestemt adfærd. Et AI-system, der trækker et kodeeksempel ud, skal være sikkert på, at eksemplet faktisk er komplet og ikke afhænger af en opsætning, der vises et andet sted.
Tag fejlhåndtering med i kodeeksemplerne
Rigtige udviklere spørger altid om fejl. Hvis dit kodeeksempel mangler fejlhåndtering, vil udviklere spørge AI-systemet, hvad der sker, når koden fejler. Hvis din dokumentation ikke svarer på det, citerer AI-systemet en andens dokumentation, der gør. Tag try-catch-blokke, fejlsvar eller tydelige noter med om, hvilke fejl handlingen kan give.
Opbyg API-referencens endpoints, så AI kan forstå dem
Din reference til API-endpoints er din vigtigste dokumentation for AI-citater. Gør hvert endpoint forståeligt for sig selv, uden at læserne skal hoppe mellem sider.
Start hvert endpoint med, hvad det gør
Start ikke en endpoint-reference med "Users-endpointet returnerer brugerdata." Start med en hel sætning, der forklarer handlingen.
FORKERT: "/users-endpointet giver adgang til brugerposter."
RIGTIG: "Hent en liste over alle brugere i dit workspace."
Den rigtige version er en handling. Den fortæller systemet præcis, hvad endpointet gør, uden at systemet selv skal gætte det ud fra stien.
Tag hele kaldets opbygning med i hvert endpoint-afsnit
Henvis ikke til et fælles afsnit om "Godkendelse" og antag, at systemet samler oplysningerne. Beskriv, hvordan man godkender, hvilke headers man skal bruge, og hvordan hele kaldet ser ud i hvert endpoints dokumentation. Så kan hvert endpoint trækkes ud for sig.
Vis både svar ved succes og ved fejl
Dokumentér, hvordan et vellykket svar ser ud. Dokumentér derefter, hvordan fejlsvar ser ud. Tag mindst ét eksempel på hver almindelig fejl med (401 Unauthorized, 404 Not Found, 429 Rate Limited). Når et AI-system har både vellykkede svar og fejlsvar, kan det give udviklerne en mere komplet vejledning.
Håndtér versionering, så du er synlig for AI
Mange API'er har flere versioner. V1, V2 og nogle gange ældre versioner, der stadig kører i produktion. Versionering skaber et særligt problem for AI-systemer. Hvilken version skal citeres, når nogen spørger om dit API?
De fleste AI-systemer citerer den nyeste version, de kan finde. Hvis din nuværende version er v3, men din dokumentationsplatform gør v1 og v2 lige så nemme at finde, kan systemet citere den gamle version og efterlade udviklerne med forældede instruktioner.
Brug en URL-struktur, der viser, hvilken version der har forrang
Hvis det er muligt, så læg den nuværende dokumentation på en ren URL (/docs/api) og læg ældre versioner på URL'er med version (/docs/api/v1, /docs/api/v2). Det signalerer til AI-systemer, at URL'en uden version er den nuværende, anbefalede version.
Tilføj versionsnoter til gammel dokumentation
Hvis du vedligeholder dokumentation til ældre versioner (fordi udviklere stadig bruger dem), så sæt en tydelig versionsnote øverst. Antag ikke, at systemet læser din URL og forstår, hvilken version det ser på.
GOD note: "Du ser dokumentationen til API v1. Den version er udfaset og bliver fjernet den 1. januar 2027. Vi anbefaler, at du opgraderer til API v3. Se opgraderingsguiden."
Gør udfasningen tydelig. Skriv datoen for lukning med. Link til den nuværende version og til en guide til at skifte. Så får systemet alt, det skal bruge for at sætte den udfasede dokumentation i den rette sammenhæng.
Lav integrationsguides og vejledninger, der er lette at trække ud
Integrationsguides er noget andet end API-referencer. De er fortællende, opgavefokuserede og henvender sig til udviklere, der implementerer bestemte arbejdsgange. AI-systemer citerer dem på en anden måde.
Start med slutresultatet, ikke med forklaringen
En integrationsguide om at bygge en webhook-modtager bør åbne med, hvordan en fungerende webhook-modtager ser ud. Vis derefter trinene til at bygge den. Vis så, hvordan man tester den.
Rækkefølgen betyder noget, fordi AI-systemer trækker afsnit ud hver for sig. Hvis en udvikler spørger "hvordan lytter jeg efter webhook-hændelser", kan systemet hente dit afsnit om webhook-lyttere. Det afsnit bør være komplet nok til at stå alene.
Brug nummererede trin med tydelige beslutningspunkter
Betinget logik bør være tydelig. Skriv ikke "hvis du har brug for at filtrere hændelser, så tilføj den her kode". Stil i stedet et direkte spørgsmål som overskrift.
RIGTIG struktur
Trin 1: Opret et webhook-endpoint
Trin 2: Registrér dit endpoints URL
Trin 3: Håndtér indkommende webhooks
Trin 4: Skal du filtrere hændelser? (Ja / Nej)
- Hvis ja: Tilføj filtrering af hændelser
- Hvis nej: Spring til test
Trin 5: Test din webhook
Strukturen gør det tydeligt for AI-systemet, hvor der er betinget logik, og hvilke valg der findes.
Marker din dokumentation med strukturerede data
Schema-markup fortæller AI-systemer, hvilken slags indhold de læser. Implementeringsguide? API-reference? Vejledning? Strukturerede data gør formålet tydeligt.
Brug Article-schema til guides og integrationsdokumentation
Al dokumentation, der er mere end en referenceside, bør bruge Article-schema. Tag forfatter, udgivelsesdato og dato for sidste ændring med. Det hjælper systemet med at forstå autoritet og friskhed.
Brug HowTo-schema til guides trin for trin
Hvis din dokumentation har nummererede trin, så brug HowTo-schema. Tag hvert trin med et navn og en beskrivelse med. Det hjælper systemet med at trække de enkelte trin ud og citere det relevante.
Brug FAQPage-schema til almindelige spørgsmål
Hvis din dokumentation har et FAQ-afsnit, så marker det. Antag ikke, at systemet selv genkender det som FAQ.
Sådan understøtter WEMASY teknisk dokumentation
WEMASYs hjemmesidebygger har værktøjer, der gør det lettere at opbygge teknisk dokumentation. Du kan sætte tydelige overskriftshierarkier op, indsætte kodeblokke med den rette formatering og samle dokumentation over flere sider i en sammenhængende opbygning. WEMASY håndterer også rendering på serveren automatisk, så din dokumentation kan crawles fuldt ud af AI-systemer. Se, hvad der er med i hver plan.
Ofte stillede spørgsmål
Skal min tekniske dokumentation ligge på et separat domæne?
Nej. Din dokumentation kan ligge på docs.dinvirksomhed.dk, dinvirksomhed.dk/docs eller endda dinvirksomhed.dk/api. Det vigtige er, at dokumentationen er offentlig, kan crawles og opdateres jævnligt. AI-systemer citerer dokumentation, uanset hvor den ligger. Men hvis dokumentationen ligger på et separat domæne, kan du følge AI-trafik for sig, adskilt fra trafikken på din hovedhjemmeside. Med WEMASYs hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Hvor ofte bør jeg opdatere min API-dokumentation?
Opdater din dokumentation, hver gang du udgiver ændringer i API'et. Tilføj en ændringslog, som AI-crawlere kan se, og som viser, hvad der er ændret, og hvornår. AI-systemer vægter ny dokumentation tungere end forældet dokumentation. Hvis du udgav API v3 for seks måneder siden, men din v2-dokumentation står højere i søgeresultaterne, er det et problem med friskhed. Hold din nuværende version opdateret.
Hvad er forskellen på dokumentation til mennesker og dokumentation til AI?
Dokumentation til mennesker kan være fortællende og forudsætte sammenhæng. Dokumentation til AI skal være tydelig og stå på egne ben. En menneskelig læser husker, at du nævnte godkendelse tidligere i guiden. Et AI-system, der trækker ét afsnit ud, gør ikke. Skriv, som om hvert afsnit bliver læst for sig. Tag al den sammenhæng med, der skal til for at forstå afsnittet uden at hoppe andre steder hen.
Er kodeeksempler eller tekstforklaringer vigtigst for AI-citater?
Kodeeksempler bliver citeret oftest, fordi de er konkrete og entydige. Men kode uden forklaring bliver citeret sjældnere end kode med en tydelig indledende sætning. Den dokumentation, der bliver citeret mest, sætter klare forklaringer sammen med kodeeksempler, der virker.
Skal jeg lade AI-crawlere indeksere min dokumentation?
Ja, medmindre du har en særlig grund til ikke at gøre det. Hvis din dokumentation er en konkurrencefordel, og du ikke vil have den citeret, kan du blokere AI-crawlere gennem robots.txt. Men de fleste API'er har gavn af at blive citeret af AI-systemer, fordi det giver relevant trafik fra udviklere. Blokerer du crawlere, bruger udviklere konkurrerende API'er, der er mere synlige i AI-søgning.
Hvilke tekniske GEO-værktøjer kan hjælpe mig med at følge, om min dokumentation bliver citeret?
Brug værktøjer til at følge AI-synlighed, så du kan se, hvilke af dine dokumentationssider ChatGPT, Perplexity, Claude og andre AI-systemer citerer. Test din dokumentation manuelt ved at spørge ChatGPT og Claude om dit API's funktioner. Hvis din dokumentation optræder i svarene, virker optimeringen. Hvis konkurrenter optræder i stedet, har du optimeringsarbejde at gøre.