Agentisk webbläsning i PageSpeed Insights: så läser du betyget

PageSpeed Insights har fått en femte kategori. Under prestanda, tillgänglighet, bästa praxis och SEO står numera Agentisk webbläsning, och den mäter något annat än de fyra andra: hur väl en AI-agent kan läsa din sida, lita på att den står still och faktiskt klicka på rätt sak.

Betyget är gratis, det kräver ingen installation, och det tar under en minut att hämta. Det är också lätt att missförstå, eftersom det inte är ett tal mellan 0 och 100 utan ett bråktal, och eftersom nämnaren i det bråktalet ändrar sig beroende på vad din sajt har byggt.

Den här artikeln går igenom var betyget finns, vad kontrollerna faktiskt tittar på, varför siffran inte går att jämföra mellan två sajter, och vad som är värt att göra åt saken. Jag visar också vad som hände med betyget på den här sajten när jag byggde om den, eftersom jag mätte före och efter.

Det här är en fristående del i min guideserie om AI-SEO: så syns din hemsida i ChatGPT och Google.

Vad är agentisk webbläsning?

En AI-agent är ett program som utför uppgifter på webben åt en användare. I stället för att en människa öppnar en sida, letar rätt på ett formulär och fyller i det, kan agenten göra det själv. Den läser sidan, planerar, klickar och skriver.

Agenter läser inte sidor på samma sätt som du. De arbetar i huvudsak med tre representationer: skärmbilder, rå HTML-kod, och tillgänglighetsträdet. Tillgänglighetsträdet är den förenklade version av sidan som webbläsaren bygger upp och som skärmläsare har använt i många år. För en agent fungerar det som en ren karta över vad som går att klicka på, utan visuellt brus.

Google kallar kategorin Agentic Browsing i den engelska rapporten. Den kom med Lighthouse 13.3 i maj 2026 och är märkt som under utveckling, vilket är Googles eget sätt att säga att man ännu inte vet exakt vad som borde mätas.

Var hittar jag betyget?

När kategorin var ny fanns den bara i kommandoradsverktyget, alltså krävdes Node och en installation. Så är det inte längre. PageSpeed Insights kör numera en Lighthouse-version som har kategorin med, kontrollerat på den här sajten den 28 augusti 2026.

1. Gå till pagespeed.web.dev.
2. Klistra in adressen till en sida på din sajt. Inte bara domänen: testa den sida du bryr dig om, exempelvis en artikel eller kontaktsidan.
3. Klicka på Analysera och vänta ungefär en halv minut.
4. Rapporten öppnas på fliken Mobilt. Högst upp ligger de färgade ringarna för prestanda, tillgänglighet, bästa metoder och SEO. Agentisk webbläsning ligger sist i den raden och visar ett bråktal i stället för en ring.
5. Klicka på bråktalet, eller rulla ned till kategorins egen rubrik, för att se vilka kontroller som ingick och vilka som passerade.

Du behöver inget konto och du behöver inte äga sajten. Testet går att köra på vilken publik adress som helst, inklusive dina konkurrenters.

Varför är det ett bråktal och inte 0 till 100?

Det här är den viktigaste punkten i hela artikeln, och den som gör att siffran ofta läses fel.

Google skriver rakt ut att kategorin inte har ett viktat medelvärde från 0 till 100, till skillnad från de andra fyra. Skälet som anges är att standarderna för den agentiska webben fortfarande växer fram, och att syftet just nu är att samla in data och ge användbara signaler, inte att sätta ett slutbetyg.

I stället visas ett bråktal: hur många av de kontroller som var tillämpliga på just din sida som gick igenom.

Och där ligger fällan. Nämnaren är inte konstant. En kontroll som inte går att tillämpa på din sida räknas inte alls, varken i täljaren eller i nämnaren. En helt vanlig sajt som inte har gjort någonting för AI-agenter kan därför få 2 av 2, alltså grönt hela vägen, medan en sajt som har byggt mer får 4 av 4. Båda ser perfekta ut. De har inte mätts på samma sak.

• Jämför inte ditt bråktal med någon annans. 3 av 3 är inte sämre än 4 av 4, och 2 av 2 säger inte att sajten är färdig.
• Jämför med dig själv över tid, och skriv upp både täljaren och nämnaren. Går nämnaren upp har du tagit något nytt i bruk. Går täljaren ned har något gått sönder.
• Ett grönt bråktal är inget kvitto på att en agent klarar din sajt. Det säger att de kontroller Lighthouse kunde köra passerade.

Vilka kontroller ingår?

Kategorin består av sex kontroller, grupperade i fyra områden. Tre av dem gäller WebMCP, som är frivilligt och som de flesta sajter inte har.

1. Tillgänglighetsträdet är välformat

Ingen ny kontroll, utan ett urval ur de tillgänglighetstester Lighthouse redan kör. Google plockar ut de test som är avgörande för maskiner: att varje klickbart element har ett programmatiskt namn, att roller och förälder-barn-relationer är giltiga, och att innehåll inte är dolt för tillgänglighetsträdet samtidigt som det går att interagera med.

Det här är den kontroll som betyder mest i praktiken, eftersom den påverkar både agenter och besökare som använder skärmläsare. En knapp utan text, en ikon utan etikett eller ett formulärfält utan label är osynligt för båda.

2. Layoutstabilitet, alltså CLS

Samma CLS-mått som redan finns under prestanda, visat i ett nytt sammanhang. Googles motivering: agenter arbetar ofta med skärmbilder och koordinater, alltså kan ett element som hoppar mellan att agenten hittar det och att agenten klickar leda till att klicket hamnar fel. En agent hinner dessutom oftare än en människa fram innan sidan har lagt sig till rätta.

3. llms.txt

Kontrollen heter i den svenska rapporten llms.txt följer rekommendationerna och tittar efter en llms.txt i domänens rot.

Läs det här noga, eftersom det ofta återges fel: enligt Googles dokumentation markeras kontrollen som Ej tillämplig om filen saknas och servern svarar 404, eftersom filen är frivillig i dagsläget. Sidan flaggas däremot om servern ger ett serverfel när filen ska hämtas.

Med andra ord: du blir inte underkänd för att du saknar llms.txt. Men om du har en fil och servern krånglar när den ska levereras, då märks det. Har du en fil som går att hämta granskas den mot rekommendationerna, vilket är vad kontrollens namn syftar på. Mer om filen i min artikel om llms.txt.

4, 5 och 6. WebMCP

WebMCP är ett API som låter en sajt exponera konkreta kommandon för agenter, exempelvis ”sök artiklar” eller ”boka bord”, i stället för att agenten ska gissa sig fram genom att klicka. Tre kontroller hör hit:

• Registrerade WebMCP-verktyg. Informativ. Lighthouse listar alla verktyg som registrerats på sidan, oavsett om de kommer från HTML-attribut eller från JavaScript. Har du inga verktyg blir listan tom.
• Formulär som saknar deklarativ WebMCP. Informativ. Lighthouse letar efter <form>-element som saknar både toolname och tooldescription. Kontrollen ger i dagsläget ingen varning.
• WebMCP-schemats giltighet. Här kan det bli fel: har du skrivit attributen men inte enligt det förväntade schemat, säger kontrollen ifrån.

Det deklarativa sättet är två attribut på ett formulär:

<form toolname="newsletter_signup"
      tooldescription="Prenumererar på nyhetsbrevet">
  <input name="email" type="email"
         toolparamdescription="Läsarens e-postadress">
  <button type="submit">Prenumerera</button>
</form>

Det finns också ett programmatiskt sätt, document.modelContext.registerTool, som kräver JavaScript.

Viktig begränsning som avgör om du ska bry dig: WebMCP fungerar i dag bara i Chrome, det bygger på ett förslag som inte är en färdig standard, och för att verktygen ska finnas för vanliga besökare krävs ett så kallat origin trial-token som du registrerar per domän och som har ett utgångsdatum. Google skriver själva att WebMCP-kontrollerna kräver Chrome 150 eller senare och en registrering i försöket.

Det här är alltså inte en punkt på en checklista för en vanlig företagssajt. Det är ett experiment.

Vad hände på den här sajten

Jag mäter erkensten.se löpande och skriver upp siffrorna. Kategorin agentisk webbläsning har rört sig två gånger under augusti 2026, och båda gångerna av en känd orsak.

23 augusti: 3 av 3. Jag hade tagit bort de layoutskift som fanns på sidan, och CLS gick till 0 i tre körningar i rad. Vid det tillfället var tre kontroller tillämpliga: tillgänglighetsträdet, layoutstabiliteten och llms.txt, som funnits på sajten sedan den 19 augusti.

26 augusti: 4 av 4. Ingen av de tre gamla kontrollerna hade ändrats. Skillnaden var att sajten nu registrerar WebMCP-verktyg, alltså tändes en fjärde kontroll som tidigare varit ej tillämplig.

Det är precis den mekanik jag beskrev längre upp: täljaren gick upp därför att nämnaren gick upp. Sajten blev inte plötsligt 33 procent bättre för agenter. Den fick ett nytt test att bli mätt på, och klarade det.

28 augusti: fortfarande 4 av 4. De fyra godkända kontrollerna heter i den svenska rapporten Tillgänglighetsträdet är korrekt formaterat, WebMCP-scheman är giltiga, Cumulative Layout Shift med värdet 0 och llms.txt följer rekommendationerna. En kontroll står som ej tillämplig.

Är det här ett sidospår?

Det är en rimlig fråga, och svaret är nej. Google pekar själva på agentspåret i sin huvudguide om AI-sök. I avsnittet om agentiska upplevelser hänvisar de till en guide om agentvänliga sajter, och de nämner Universal Commerce Protocol som ett framväxande protokoll för att söktjänsternas agenter ska kunna göra mer.

Och det är inte bara Google. OpenAI skriver i sin vägledning för utgivare att deras agent i webbläsaren ChatGPT Atlas läser ARIA-märkning, alltså samma etiketter och roller som skärmläsare använder, och hänvisar till de etablerade riktlinjerna för hur de ska skrivas. Två olika företag, samma besked: det som gör sajten begriplig för en skärmläsare gör den begriplig för en agent.

Det är därför den första kontrollen i kategorin väger tyngst. Den mäter arbete som redan var värt att göra.

Vad ska jag som sajtägare faktiskt göra?

I den här ordningen, och de två första är arbete du har nytta av oavsett vad som händer med agenter.

1. Se till att varje klickbar sak har en text som beskriver den.
Detta är kontroll ett, och det är den enda som verkligen mäter kvalitet. Konkret på en WordPress-sajt: ge varje bild en alt-text, se till att ikonlänkar i menyn och sidfoten har en läsbar etikett och inte bara en symbol, och kontrollera att sökrutan har ett label. Kör tillgänglighetskategorin i samma PageSpeed-rapport och åtgärda det som listas där. Det höjer båda kategorierna.

2. Se till att sidan inte hoppar när den laddar.
Det är CLS. Vanligaste orsakerna på en vanlig sajt: bilder utan angiven bredd och höjd, en cookiebanner eller en annons som skjuts in ovanför innehållet, och typsnitt som laddas sent och byter storlek på texten. PageSpeed pekar ut vilka element som flyttade sig.

3. Lägg gärna in en llms.txt, men vänta dig ingen effekt på betyget.
Saknas filen blir kontrollen ej tillämplig, alltså varken plus eller minus. Filen kan ha andra värden, men den höjer inte det här bråktalet från att sakna fil till att ha fil på det sätt många beskriver.

4. Strunta i WebMCP tills vidare, om du inte experimenterar.
En webbläsare, ett förslag som inte är standard, och ett token som går ut. Är du nyfiken går det att prova, men det hör inte hemma på en lista över saker en företagssajt behöver.

Vad betyget inte är

• Det är inte en rankingfaktor. Kategorin finns i Lighthouse, alltså i ett testverktyg. Det finns i dag inget som säger att Google Sök använder den för att rangordna sidor.
• Det är inte samma sak som att synas i AI-svar. Att en agent kan använda din sajt när den väl är där, och att en AI-tjänst väljer att citera dig i ett svar, är två olika frågor. Hur du testar det senare går jag igenom i artikeln om att testa din AI-synlighet.
• Det är inte färdigt. Google märker själva kategorin som under utveckling. Kontrollerna kan tillkomma, försvinna eller byta innebörd, och då ändras ditt bråktal utan att du har rört sajten.

Kort sammanfattning

Agentisk webbläsning är en ny kategori i PageSpeed Insights som mäter hur väl AI-agenter kan läsa och använda din sida. Den visar ett bråktal, inte en poäng mellan 0 och 100, och nämnaren varierar med vad din sajt har byggt, alltså går siffran inte att jämföra mellan sajter. Sex kontroller ingår, varav tre gäller det frivilliga WebMCP. Det som faktiskt är värt att göra åt saken är samma arbete som gör sajten användbar för människor med skärmläsare: tydliga etiketter på allt klickbart, och en layout som står still.

Hur vet jag att det här stämmer?

Alla påståenden ovan går att kontrollera i källorna nedan, och mätvärdena kommer från den här sajten. Jag publicerar dem oavsett utfall.

Källor

1. Google: Agentic Browsing, poängsättning
2. Google: llms.txt-kontrollen
3. Google: Optimizing for generative AI features on Google Search, avsnittet om agentiska upplevelser
4. web.dev: Agent-friendly website best practices
5. OpenAI: Publishers and Developers FAQ
6. Marcus Österberg, Webperf: Den agentiska webben kan testas med Lighthouse 13.3
7. Egna mätningar på erkensten.se, 23, 26 och 28 augusti 2026