Mät AI-citeringar per URL: ett granskbart protokoll

Varför ett protokoll med körningslogik är nödvändigt

Det är lockande att börja mäta AI-citeringar genom att helt enkelt ställa en fråga till ChatGPT eller Perplexity, se om din webbplats nämns, och notera resultatet i ett dokument. Problemet med den metoden är att den inte är reproducerbar, inte är jämförbar över tid, och blandar ihop fundamentalt olika saker: hur ofta en fråga ger ett svar överhuvudtaget, hur ofta din URL förekommer i de svaren, och hur många gånger du råkade ut för tekniska störningar under mätperioden.

När du läser om AI-citeringar i ett affärssammanhang är det lätt att anta att det finns ett enkelt enda tal att följa – ungefär som klickfrekvens i sökmotoranalys. Men AI-svar är icke-deterministiska, modeller uppdateras utan förvarning, och samma fråga kan ge olika svar beroende på vilket gränssnitt, vilket land eller vilket språk du väljer. Utan ett protokoll som fångar dessa betingelser mäter du i praktiken ingenting reproducerbart.

Det här är inte ett abstrakt metodproblem. Det är ett praktiskt problem som avgör om din data kan användas för beslut. Om du inte kan förklara exakt hur ett tal räknades fram kan du inte avgöra om en förändring nästa månad beror på att ditt innehåll blivit bättre, på att modellen ändrade sitt beteende, eller på att du råkade köra frågorna med ett annat gränssnittsinställning. Guiden Vad visar AI-siffrorna? ger en bra bakgrund till de olika mätlagren innan du sätter upp protokollet.

Det protokoll som beskrivs i den här artikeln bygger på en enkel princip: en körning är ett frågetillfälle. Från den principen följer alla andra strukturbeslut logiskt.

Grundbegrepp: körning, citationsrad och täckning

Innan du sätter upp kalkylbladet behöver du ha tre begrepp skarpt definierade, eftersom förvirring om dem är en möjlig orsak till att mätdata blir oanvändbar.

Körning

En körning är ett enda tillfälle då du ställer en specifik fråga till en AI-modell under definierade betingelser. Betingelserna inkluderar: modellnamn och version om känd, gränssnittsinställning (webbläsare, API, app), land och språk i gränssnittet, och eventuellt läge som standardsökning kontra djupanalys. En körning genererar exakt en rad i körningsloggen, oavsett hur många URL:er som citeras i svaret.

Citationsrad

En citationsrad är en post som kopplar en specifik normaliserad URL till en specifik körning. Om ett svar innehåller tre URL:er genererar körningen tre citationsrader, men fortfarande bara en körningsrad. Det här är den distinktion som de flesta mätupplägg missar. Om du räknar citationsrader som körningar och en fråga om din bransch råkar citera din webbplats tre gånger i ett enda svar, verkar du ha tre lyckade körningar men har i verkligheten bara en.

Täckning

Täckning är andelen giltiga körningar där minst en av dina mål-URL:er förekommer i minst en citationsrad. Formeln är enkel: antal lyckade körningar delat med antal giltiga körningar. Tekniska felkörningar ingår inte i nämnaren. Det är det enda jämförbara nyckeltalet över tid, förutsatt att frågeset och betingelser hålls konstanta.

Kalkylbladets struktur: två tabeller, inte en

Ett misstag att undvika när man börjar mäta är att försöka få plats med all information i ett enda flackt kalkylblad. Resultatet blir att en körning med tre citeringar tar upp tre rader i körningsloggen, och du förlorar möjligheten att skilja körningsstatistik från citationsstatistik. Lösningen är att använda två separata tabeller med ett gemensamt körnings-ID som nyckel.

Tabell 1: Körningsloggen

Körningsloggen har en rad per körning och innehåller följande kolumner: körnings-ID (ett unikt löpnummer), datum och klockslag, frågetext, frågekategori, modellnamn, gränssnittsläge, land, språk, och utfallsklass. Utfallsklassen kan vara ett av tre värden: lyckat (svar returnerades och kunde analyseras), tekniskt_fel (timeout, fel språk, modellkrasch, oväntat beteende), eller giltig_negativ (svar returnerades men ingen av dina mål-URL:er citerades).

Tabell 2: Citationsloggen

Citationsloggen har en rad per citerad URL per körning och innehåller: körnings-ID (referens till körningsloggen), råa URL:en exakt som den apparerade i svaret, normaliserad URL, din klassificering av om URL:en är en av dina mål-URL:er, och citatposition om du kan avgöra den (exempelvis löpnummer i källlistan). Det är i citationsloggen som du gör URL-normalisering, inte i körningsloggen.

Med den här strukturen kan du köra en pivottabell eller en enkel COUNTIF-formel för att räkna täckning, utan att riskera att en körning med många citeringar väger tyngre än en körning med en citering.

URL-normalisering: vad du ska ta bort och vad du ska behålla

URL-normalisering är ett steg som många hoppar över med motiveringen att det verkar tekniskt och oviktigt. I praktiken är det ett av de enklaste sätten att förstöra sin mätdata. Om din webbplats kan nås via både https://example.se/sida/ och https://example.se/sida och du inte normaliserar, registreras de som två olika URL:er i citationsloggen. Detsamma gäller om en gammal version av ett blogginlägg fortfarande citeras med en UTM-parameter från en kampanj du körde för sex månader sedan.

Vad du tar bort

Tracking-parametrar som börjar med utm_, fbclid, gclid, msclkid och liknande ska alltid tas bort eftersom de inte påverkar sidinnehållet. Ta också bort trailing slash-varianter genom att välja ett konsekvent format, exempelvis alltid med trailing slash, och konvertera alla URL:er till lowercase.

Vad du behåller

Strukturella parametrar som faktiskt styr vilket innehåll som visas ska behållas. Om din webbplats visar olika innehåll beroende på ?kategori= eller ?sida=, ska dessa parametrar finnas kvar i den normaliserade formen. En bra tumregel: öppna URL:en med och utan parametern och jämför innehållet. Om innehållet är identiskt, ta bort parametern.

Normalisering ska göras i citationsloggen, inte i körningsloggen, och du ska alltid spara råa URL:en i en separat kolumn så att du kan granska normaliseringslogiken i efterhand. Vill du förstå hur AI-botar faktiskt hanterar URL:er på servernivå är guiden om AI-botbesök och serverloggar ett bra komplement.

# Pseudokod för normalisering
def normalisera_url(raa_url):
    url = raa_url.lower().strip()
    url = ta_bort_tracking_parametrar(url)  # utm_*, fbclid etc.
    url = lagg_till_trailing_slash(url)     # konsekvent format
    url = konvertera_till_https(url)        # protokoll
    return url

Tekniska fel: klassificering och exkludering

Tekniska fel är körningar där betingelserna inte uppfylldes på det sätt du avsåg. De ska aldrig räknas som negativa utfall eftersom de inte säger något om huruvida din URL citeras eller inte. Att blanda ihop tekniska fel med giltiga negativa körningar är en möjlig orsak till att täckningssiffror varierar mer än de borde.

Vanliga feltyper och hur du kodar dem

Det finns fyra feltyper som återkommer i praktiken. Timeout är när modellen inte svarar inom en rimlig tid, vanligtvis definierat som mer än 30 sekunder för ett webbläsarbaserat gränssnitt. Felaktigt språk är när du ställde frågan på svenska men fick ett svar på engelska, vilket kan påverka vilka källor som citeras. Modellbyte är när gränssnittet utan förvarning bytte till en annan modellversion än den du avsåg att använda. Okänt är en uppsamlingskategori för fel du inte kan klassificera tydligare.

I körningsloggen loggar du feltypen i kolumnen för utfallsklass och exkluderar dessa rader när du beräknar täckning. Räkna dem däremot i en separat sammanfattningsrad så att du kan följa om felprocenten är stabil. En felprocent på mer än 15 procent av körningarna under en mätperiod är en signal om att protokollet behöver ses över, exempelvis för att ett gränssnitt blivit instabilare eller för att du kör för många frågor för snabbt.

Illustrativt räkneexempel: 40 planerade körningar

Det här är ett hypotetiskt exempel med transparenta antaganden för att illustrera protokollets aritmetik. Antag att du planerar 40 körningar under en vecka, fördelade på tio frågor och fyra körningar per fråga (två modeller, två tidpunkter per modell). Du mäter täckning för fem mål-URL:er på en hypotetisk B2B-webbplats inom redovisningstjänster.

När du summerar körningsloggen ser du följande utfall: 5 körningar klassificeras som tekniska fel (varav 3 är timeouts och 2 är felaktigt språk). Det ger 35 kvarstående körningar. Av dessa är 23 giltiga negativa, det vill säga körningar där ett svar returnerades men ingen av de fem mål-URL:erna citerades. 12 körningar är lyckade, det vill säga körningar där minst en mål-URL förekom i minst en citationsrad.

Täckningen beräknas då som 12 dividerat med 35, vilket ger 34,3 procent. De 5 tekniska felen ingår alltså inte i nämnaren. Om du av misstag hade inkluderat dem hade täckningen blivit 12 dividerat med 40, det vill säga 30 procent. Det är en skillnad på fyra procentenheter, och om du inte är konsekvent med exkluderingslogiken kan den skillnaden se ut som en förändring när du jämför med en annan mätperiod där du råkade ha noll tekniska fel.

I citationsloggen för de 12 lyckade körningarna kan du se att totalt 19 citationsrader loggades, fördelade på fyra av de fem mål-URL:erna. Den femte URL:en citerades aldrig under perioden. Det är information om vilken URL som är osynlig i AI-svaren, men det förändrar inte täckningskalkylen eftersom täckning mäts per körning, inte per URL.

RANGELs arbetsmetod och illustrativa typfall

I RANGELs arbete med AI-SEO används protokollet ovan som underlag för att avgöra vilka åtgärder som är meningsfulla att testa. Det är inte ett rapporteringsverktyg i sig utan ett beslutsstöd: data från protokollet leder till en av tre typiska situationer, var och en med en annan lämplig åtgärd.

Typfall 1: låg täckning, stabila betingelser

I det här illustrativa typfallet visar protokollet en täckning på under 20 procent över två på varandra följande mätperioder med stabila betingelser och låg felprocent. Ingen modelluppdatering har noterats. En möjlig hypotes är att innehållet inte matchar de frågor som ställs, men låg täckning ensamt räcker inte för att fastslå orsaken. Nästa steg är att granska om det finns ett strukturellt gap mellan frågorna i frågesettet och det innehåll som faktiskt finns på de mål-URL:er som aldrig citeras. AI-frågepanel kan vara ett bra stöd för att strukturera om frågorna och kontrollera om du mäter rätt saker. Guiden om AI-citeringsgap beskriver hur du går från ett observerat gap till en konkret åtgärd.

Typfall 2: hög variation mellan körningar

I det här illustrativa typfallet varierar täckningstalet kraftigt mellan körningar som körs med identiska betingelser, exempelvis 60 procent vid ena körningsomgången och 25 procent vid den andra. Det är ett tecken på att frågeformuleringar med hög variabilitet används, eller att modellen i sig är i ett instabilt tillstånd kring de ämnen du mäter. Rätt åtgärd är att öka antalet körningar per fråga och period för att stabilisera medelvärdet, inte att dra slutsatser baserade på ett litet sample. Notera att liten förändring i ett litet dataset aldrig är robust nog för ett beslut om innehållsändring.

Typfall 3: teknisk felprocent ökar

Om den tekniska felprocenten stiger från under 5 procent till över 15 procent mellan perioder utan att du ändrat din mätmetod, är det ett tecken på ett externt problem: gränssnittsstabilitet, hastighetsbegränsning eller modellbyte. Rätt åtgärd är att pausa mätningen och diagnostisera felet innan du drar slutsatser om täckningsförändringar. Att fortsätta mäta med hög felprocent och sen exkludera felen retroaktivt ger inte reliabel data, eftersom du inte kan veta om felen var jämnt fördelade över frågetyperna eller koncentrerade till specifika frågor.

Mät AI-citeringar per URL: ett granskbart protokoll
https://rangel.se/guider/ai-citeringar-per-url/

LÄSARUPPGIFT
Skapa de två tabellerna – körningslogg och citationslogg – och kör tio frågor med samma inställningar.

Räkna citeringar med rätt nämnare
[ ] Definiera en giltig körning
Underlag att dokumentera: Ange hur tekniska fel och utebliven citering skiljs åt.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Normalisera citerade URL:er
Underlag att dokumentera: Dokumentera URL-regler och räkna samma URL en gång per svar.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Redovisa period och urval
Underlag att dokumentera: Visa giltiga svar, citerade svar och fel utan att blanda med trafik.
Mitt underlag:
Ansvarig / nästa steg:

Markeringarna är dina egna arbetsnoteringar, inte en granskning av RANGEL eller ett kvalitets-/rankingbetyg.

Beslutstabellen: när ska du återköra, revidera eller agera?

Den här tabellen beskriver vilka evidensförhållanden som bör styra ditt nästa steg. Den är ett redaktionellt ramverk baserat på metodologisk logik, inte ett löfte om specifika utfall.

Frågesettet: vad som ska in och varför det är protokollets kärnbeslut

Protokollet är bara så bra som frågesettet det baseras på. Det är ett av de beslut som är svårast att få rätt men enklast att ignorera. Om frågorna inte speglar de faktiska ämnen där du vill bli citerad, mäter du ingenting meningsfullt, oavsett hur välstrukturerat ditt kalkylblad är.

Ett frågeset bör innehålla tre typer av frågor. Den första typen är definitionsfrågor om ditt ämnesområde: frågor som en potentiell kund kan ställa när de befinner sig tidigt i en köpresa och försöker förstå ett problem. Den andra typen är jämförelsefrågor som ber AI:n välja mellan alternativ, exempelvis vilka leverantörer eller metoder som passar en specifik situation. Den tredje typen är procedurella frågor som ber om steg-för-steg-vägledning inom ditt expertområde.

Använd AI-frågepanelen för neutrala startfrågor och välj sedan frågor som representerar kundernas olika beslut. Ett första arbetsurval kan vara 15 frågor, men antalet garanterar ingen statistisk säkerhet. Spara upprepade körningar, vilka frågor som ingår och vilka fel som inträffar. Pröva ett regelbaserat förslag på innehållsformat först när ni har kontrollerat vilket svar läsaren behöver.

Det är också viktigt att dokumentera exakt frågatext i protokollet, inte en parafras. Om du ändrar frågaformuleringar mellan mätperioder är perioderna inte jämförbara, och du kan inte avgöra om en förändring i täckning beror på innehåll eller på att du formulerade frågan annorlunda.

Det finns ytterligare metodologiska perspektiv att ta del av för den som vill jämföra olika infallsvinklar på AI sökmätning: Aleyda Solis checklista för AI sökoptimering och iPullRanks genomgång av AI sökmått erbjuder var sin infallsvinkel som kompletterar det operativa protokoll som beskrivs här.

Mätlager: citeringar och trafik är separata signaler

Det är frestande att behandla AI-citeringar och AI-trafik som två mått på samma fenomen. Det är de inte. En AI-modell kan citera din URL utan att en enda användare klickar sig vidare. Omvänt kan trafik från AI-gränssnitt nå din webbplats via vägar som inte alls är synliga i ett citationsprotokoll, exempelvis via sammanfattningar där din webbplats nämns men utan en klickbar länk.

Citeringar och AI-trafik är separata mätlager – detta är en observationell iakttagelse, inte ett kausalt test. Det betyder att du behöver mäta båda lagren, med separata protokoll och separata nyckeltal, och vara försiktig med att dra orsakssamband mellan dem. En ökning i AI-citeringar under en period där AI-trafiken inte rör sig är inte nödvändigtvis ett tecken på att mätningen är fel, det kan vara ett tecken på att användarbeteendet kring de specifika frågor du mäter inte leder till klick.

För att förstå AI-trafiklagret på ett sätt som är komplementärt till citationsprotokollet behöver du titta på serverloggar och referrer-data, vilket beskrivs i detalj i guiden om AI-botbesök och serverloggar. De två datakällorna svarar på olika frågor och bör inte aggregeras till ett enda tal.

Verktyget AI-mätning kan hjälpa dig att strukturera uppladdade CSV-observationer från de olika mätlagren utan att blanda ihop dem – verktyget hämtar inte data automatiskt eller övervakar AI-svar på egen hand. Om du planerar att presentera AI-synlighetsdata för en ledningsgrupp eller kund är det också värt att förbereda ett SEO-affärscase som transparent räknar på dina egna antaganden och tydligt förklarar vad mätningen faktiskt visar och vad den inte kan visa.

Konkret checklista: sätt upp protokollet steg för steg

Den här checklistan är avsedd att användas direkt. Varje steg är avgränsat och producerar en konkret artefakt som nästa steg kan bygga på.

1. Definiera mål-URL:er. Lista de URL:er du vill mäta citering för. Börja med fem till tio URL:er som representerar ditt kärninnehåll. Spara listan i en separat flik i kalkylbladet märkt Mål-URL-register.
2. Skapa normaliseringsregel. Skriv upp din normaliseringslogik explicit: vilket format du väljer för trailing slash, vilka parametrar du tar bort, hur du hanterar protokoll. Spara regeln i kalkylbladets dokumentationsflik.
3. Bygg körningslogg-tabellen. Skapa kolumnerna körnings-ID, datum, tid, frågetext, frågekategori, modell, gränssnitt, land, språk, utfallsklass. Lägg till en valideringsregel för utfallsklasskolumnen: tillåt bara lyckat, tekniskt_fel och giltig_negativ.
4. Bygg citationslogg-tabellen. Skapa kolumnerna körnings-ID, rå URL, normaliserad URL, är_mål-URL (ja/nej), position i källlista. Koppla körnings-ID som referens till körningsloggen.
5. Sätt upp frågesettet. Välj ett avgränsat urval av definitionsfrågor, jämförelsefrågor och procedurfrågor som motsvarar era kundbeslut. Dokumentera vad urvalet inte täcker; ett visst antal frågor garanterar inte representativitet. Dokumentera den exakta frågaformuleringen, inte en parafras.
6. Gör en pilotkörning. Kör en delmängd av frågesettet, exempelvis fem frågor, och fyll i protokollet manuellt för att verifiera att strukturen fungerar och att normaliseringslogiken är korrekt.
7. Kör fullständigt frågeset. Kör alla frågor under identiska betingelser. Dokumentera eventuella avvikelser från planerade betingelser i en noteringskolumn.
8. Beräkna täckning. Räkna lyckade körningar i körningsloggen och dividera med giltiga körningar (totalt minus tekniska fel). Spara täckningstalet med datum och betingelsebeskrivning i en sammanfattningsflik.
9. Diagnostisera innan du agerar. Granska tabellen i beslutsmatrisen ovan och avgör vilken situation du befinner dig i. Agera inte på täckningsförändringar förrän du har kontrollerat att betingelserna var stabila och att variansen inte beror på ett litet sample.
10. Dokumentera nästa körningsdatum. Bestäm ett fast intervall för nästa körning. Jämförbara mätperioder kräver att betingelserna är identiska, vilket i praktiken innebär att samma person kör protokollet med samma inställningar.

Vad protokollet inte löser och vad du gör då

Ett välbyggt mätprotokoll ger dig reproducerbara täckningssiffror, men det löser inte frågan om vad du ska göra med informationen. Det är ett separerat beslutsproblem, och det är viktigt att hålla isär de två stegen för att inte fastna i en mätloop där du samlar data utan att agera, eller agerar för tidigt utan tillräcklig evidens.

Protokollet säger ingenting om varför en specifik URL inte citeras. Den frågan kräver en innehållsanalys: jämför dina mål-URL:ers innehållsstruktur med de URL:er som faktiskt citeras av modellen på liknande frågor. Är dina sidor tillräckligt specifika? Svarar de tydligt på den typ av frågor du mäter? Innehåller de faktapåståenden i en form som en AI-modell kan extrahera direkt? Det är innehållsarbete, och det börjar med ett innehållsbriefverktyget snarare än med mer mätning.

Protokollet säger inte heller något om länkprofil, domänauktoritet eller teknisk indexering i förhållande till AI-modeller. Det är separata faktorer som påverkar om en modell känner till din webbplats överhuvudtaget, men de är utanför vad ett citationsprotokoll kan mäta direkt. Om du misstänker att en URL aldrig citeras för att den är okänd för modellen, snarare än för att dess innehåll inte är relevant, är orsaken okänd utan vidare diagnostik och kan inte avgöras enbart från citationsloggen. Om ni därefter planerar köpta placeringar kan kalkylen för placeringskostnad visa ett prisintervall för valt antal. Den bedömer inte en sidas relevans eller synlighet.

Det är också viktigt att understryka att protokollet mäter ett tillstånd vid en given tidpunkt med ett givet frågeset mot en given modell. Det mäter inte AI-synlighet som ett generellt fenomen, och det ger inga garantier om framtida tillstånd. Modeller uppdateras, gränssnitt förändras, och en URL som citeras konsekvent i dag kan vara osynlig nästa kvartal av skäl som har ingenting med ditt innehåll att göra. Det är en grundläggande osäkerhet i AI-mätning som protokollet hjälper dig att hantera, men inte eliminera.