Så anpassar vi kodamera.se för AI

Vi skrev tidigare om hur du optimerar för AI-sökmotorer. Den artikeln handlade om vad man bör göra. Den här handlar om vad vi själva har gjort, på den här webbplatsen, och varför.

Varför maskinläsbarhet blivit en egen fråga

En traditionell sökmotor listar länkar och låter användaren välja. En svarsmotor läser, sammanfattar och citerar — ofta utan att besökaren klickar sig vidare. Skillnaden får en praktisk följd: det räcker inte att innehållet finns och går att hitta. Det måste också gå att tolka av en maskin som ska återge det korrekt för någon annan.

I praktiken handlar det mindre om knep och mer om hygienfaktorer. En sida med tydlig struktur, korrekt uppmärkning och ärliga signaler är lättare att citera rätt — och den som saknar det riskerar att antingen citeras fel eller hoppas över helt.

llms.txt: en karta över sajten

llms.txt är en enkel textfil i roten av webbplatsen som beskriver vad sajten innehåller. Konventionen kommer från llmstxt.org och är avsiktligt anspråkslös: en rubrik, en kort sammanfattning, och sedan länkar grupperade i avsnitt med en rad text per länk.

Vår ligger på kodamera.se/llms.txt och genereras direkt ur Sanity, samma innehåll som driver resten av sajten. Det betyder att den aldrig hamnar ur synk — publicerar vi en ny tjänst finns den i filen nästa gång den hämtas.

Tre val som visade sig spela roll:

Tjänsterna först. Filens uppgift är att svara på ”vad gör det här företaget?” i en enda hämtning. Då kan inte svaret vara ett arkiv med tvåhundra artiklar överst. Våra fyra affärsområden ligger först, sedan de enskilda tjänsterna grupperade på samma sätt som på tjänstesidan, och först därefter kundcase och artiklar.

Korta noteringar. Konventionen säger ”a short note” — inte en metabeskrivning. Vi kapar varje rad till första meningen eller 160 tecken. Skillnaden är inte kosmetisk: fullängdsbeskrivningar gjorde filen hälften så stor utan att tillföra något en modell behöver för att orientera sig.

Samma urval som sitemapen. En sida vi bett sökmotorer att inte indexera ska inte heller ligga i llms.txt. Filen respekterar samma noindex-flagga som sitemapen, så de två kan inte säga emot varandra.

Däremot ligger även artiklar vi valt bort från arkivsidan med i filen. Att inte lyfta fram något är inte samma sak som att dölja det, och en modell som ska besvara en smal fråga är precis den läsare en stödartikel skrevs för.

Samma sida, två format

En webbsida är byggd för ögon. Navigation, knappar, spårning och layout är nödvändiga för en besökare och brus för en modell som ska läsa texten.

Varje sida på kodamera.se svarar därför i två format. Den som ber om HTML får sidan som vanligt. Den som skickar Accept: text/markdown får samma innehåll som ren text — rubriker, brödtext och länkar, inget annat.

curl -H 'Accept: text/markdown' https://www.kodamera.se/tjanster/drupal

Konventionen kommer från acceptmarkdown.com och kräver tre saker: rätt innehållstyp på svaret, en icke-tom kropp, och Vary: Accept så att mellanliggande cachar vet att adressen har två skepnader. Den sista är lättast att glömma och ställer till mest — utan den kan en cache lämna HTML till den som bad om text.

Texten hämtas ur samma Sanity-innehåll som HTML-sidan, inte ur en kopia. Vi övervägde en separat uppsättning markdown-filer och övergav tanken ganska snabbt — den sortens parallella struktur hinner bli inaktuell innan någon kommer ihåg att den finns.

En varning till den som ska bygga samma sak: ramverkets egen trafik får inte förhandlas. Moderna React-ramverk hämtar delar av sidor i ett eget format när besökaren klickar runt. De förfrågningarna ser ut som vanliga sidhämtningar men är det inte, och svarar man dem med markdown slutar klientnavigeringen fungera — i produktion, där det är svårast att upptäcka.

En beskrivning av ytorna

llms.txt beskriver innehållet. En agent som ska använda sajten behöver också veta vilka adresser som finns och vad de svarar med, och det är vad kodamera.se/openapi.json gör: en maskinläsbar beskrivning av markdown-förhandlingen, llms.txt, sitemapsen och RSS-flödet.

Den beskriver det som finns, inte ett API vi önskar att vi hade. Vi säljer inte data: det finns ingen endpoint att anropa, inga nycklar och ingen inloggning. Specen säger det rakt ut, så att en agent slutar leta i stället för att gissa.

För den som hellre läser svenska än JSON ligger samma sak sammanfattad på kodamera.se/developers.

Vilka AI-crawlers vi släpper in

Det här är det beslut som kräver mest eftertanke, och det finns inget självklart rätt svar. Vi delar upp dem i två grupper, för de gör olika saker.

Svarsmotorer — OAI-SearchBot, ChatGPT-User, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended. De hämtar innehåll för att besvara en fråga, anger källa och skickar tillbaka trafik. Att blockera dem kostar synlighet och ger ingenting.

Träningscrawlers — GPTBot, ClaudeBot, anthropic-ai, CCBot, Bytespider, meta-externalagent. De bygger träningsdata och skickar inget tillbaka. Att släppa in dem är en verklig avvägning: räckvidd och närvaro i framtida modeller, mot innehåll som används utan attribution.

Vi tillåter båda grupperna i dag. Vi säljer tjänster kring att synas i AI-sök, och att blockera de motorer som besvarar de frågorna vore svårt att försvara. Men vi listar dem var för sig och namngivna i robots.txt, av ett skäl: den som läser filen om två år ska se att det var ett val, och kunna ändra en enskild crawler utan att nysta upp ett wildcard.

Strukturerad data som genereras, inte klistras in

Strukturerad data är det som låter en maskin veta att ”Kodamera” är en organisation och inte ett ord, att en artikel har en författare och ett datum, och var en sida ligger i hierarkin. Vi genererar all uppmärkning ur innehållet i Sanity i stället för att skriva den för hand:

• Organization på hela sajten, med adress
• Service på varje tjänstesida
• Article på artiklar, med riktig författare och datum
• BreadcrumbList på undersidor — samma data som den synliga brödsmulan, så att markup och sida inte kan säga olika
• FAQPage där det finns frågor och svar
• WebSite och ItemList på översiktssidor

En entitet, inte flera. Organisationsnoden har ett eget id som övrig uppmärkning pekar på, i stället för att upprepa företagsnamnet på flera ställen. Två noder som båda påstår sig vara företaget tvingar läsaren att välja mellan dem, och den väljer inte nödvändigtvis den mest kompletta. Det gäller både en sökmotor och en modell.

Poängen med att generera är att uppmärkningen inte kan bli gammal. Byter en artikel författare följer strukturerad data med. Handskriven markup gör inte det, och då blir den med tiden ett påstående om sidan som inte längre stämmer.

Sitemap som säger sanning

En sitemap är bara en lista, men lastmod är ett påstående: ”den här sidan ändrades då”. Om fältet rör sig när innehållet inte gjort det slutar en sökmotor lita på det — inte per sida, utan för hela sajten.

Vår sitemap är ett index över fyra kategorier: sidor, tjänster, kundcase och artiklar. Uppdelningen gör det möjligt att se i Search Console vilken typ av innehåll som inte indexeras, i stället för att få en enda siffra.

Datumet speglar när innehållet faktiskt ändrades. En omskriven metabeskrivning flyttar inte det, för det är inte en innehålländring. Där vi inte vet med säkerhet utelämnar vi fältet hellre än gissar.

changefreq och priority är borta. Google har i åratal sagt att det ignorerar båda, och ”veckovis, prioritet 0,5” på tvåhundra artiklar säger ingenting.

Ett fel som går att läsa

Det mesta som skrivs om AEO handlar om sidor som finns. Minst lika viktigt är vad som händer när en adress inte gör det.

Statuskoden måste vara sann. Det låter självklart och är lättare att gå fel på än man tror. Med partiell rendering kan ett sidskal hinna skickas iväg med kod 200 innan servern konstaterat att sidan inte finns, och då står det OK överst på ett tomt resultat. Adresser med punkt i — /nagot.json — är särskilt utsatta, eftersom de ofta undantas från just den kontroll som hade fångat felet. Testa saken: hämta en adress du vet inte finns och titta på statuskoden, inte på sidan.

Felet ska komma i samma format som frågan. Den som bett om markdown får en 404 i markdown, med en mening om vad som hänt och länkar vidare till llms.txt och sitemapen. Anrop under /api svarar med JSON: en felkod, ett meddelande och en rad om vad man kan göra i stället. En agent kan inte tolka en HTML-felsida, och ska inte behöva.

En 404 är också en sida, och värd samma omsorg som resten. Det bryr sig ingen maskin om — men människan som hamnade fel gör det.

Det som inte syns men ändå räknas

Semantisk HTML, rubriker i ordning, länktexter som går att förstå utan omgivande text. Sidorna fungerar utan JavaScript. Tillgänglighet testas automatiskt vid varje kodändring.

Ingen av de sakerna är AEO-specifik. Det är samma grundarbete som gör en sida användbar för en skärmläsare eller en långsam uppkoppling.

Vi mätte oss själva

Allt ovan är sådant vi försöker få rätt. Men det är lätt att tro att den egna sajten är i bättre skick än den är, så vi körde en utomstående mätning på oss själva: is-agentic.com testar hur väl en webbplats fungerar för agenter — statuskoder, maskinläsbara format, strukturerad data, felsvar.

Första körningen gav 65 av 100, och vi hittade saker vi inte visste om. Adresser som svarade ”OK” på sidor som inte fanns. Felmeddelanden i HTML där ett program förväntar sig JSON. Ingen maskinläsbar beskrivning alls av vad sajten erbjuder. Sådant märker man inte när man surfar runt på sin egen sajt — allt ser ju ut att fungera.

Efter en dags arbete, ungefär det som står i den här artikeln, låg vi på 96 vid mätningen i september 2026. De poäng som saknas hänger på saker en byrå inte har: ett publikt API, ett CLI-verktyg, självbetjänade API-nycklar. Vi hade kunnat bygga ett API ingen frågat efter för att fylla i rutorna. Det kändes fel.

Kör den gärna på er egen sajt: is-agentic.com. Det tar en minut, ni får en lista att beta av, och den är konkret på ett sätt som de flesta SEO-verktyg inte är. Behöver ni hjälp att beta av listan vet ni var vi finns.

Vad det här inte löser

Teknik gör innehåll möjligt att hitta och tolka. Den gör det inte värt att citera.

En svarsmotor väljer källa efter vad som faktiskt besvarar frågan. Perfekt strukturerad data på en tunn text hjälper ingen. Vi arbetar med den tekniska halvan — uppmärkning, struktur, indexering — och den andra halvan är innehåll som säger något.

Det är värt att vara tydlig med gränsen, för den går rakt genom det som brukar säljas som AEO.

Läs vidare

• Räcker vanlig SEO för att synas i ChatGPT? — vad som överlappar med teknisk SEO och vad som inte gör det.
• Hur väljer AI-sökmotorer vilka källor de citerar? — vad som rimligen avgör, och vilka siffror man inte ska lita på.
• Hur vet du om ditt företag nämns när kunder frågar ChatGPT? — en mätmetod som tar en eftermiddag och inget verktyg.
• AI i CMS: vad det faktiskt gör — tre saker som kallas samma, och vad man bör fråga först.