Agentisk browsing i PageSpeed: Sådan får du grøn – trin for trin

Kører du din hjemmeside igennem Google PageSpeed Insights i dag, dukker der en ny, femte kategori op ved siden af Performance, Accessibility, Best Practices og SEO: Agentisk browsing. Den viser, hvor godt din side er bygget til AI-agenter, og mange sider står med gult eller rødt uden helt at vide hvorfor.

I denne guide gennemgår vi, hvad kategorien måler, og hvordan du trin for trin får den grøn. Vi tager udgangspunkt i WordPress, fordi det er det, de fleste af vores kunder kører på, men principperne gælder for alle hjemmesider.

Hvad er Agentisk browsing i PageSpeed Insights?

Google tilføjede kategorien til Lighthouse, som er motoren bag PageSpeed Insights, med version 13.3 i maj 2026, og kort efter dukkede den op i PageSpeed Insights. Kategorien måler, hvor let det er for en AI-agent at læse og bruge din side. En AI-agent er software, der besøger hjemmesider på vegne af et menneske for at finde information, sammenligne tilbud eller udføre en handling, fx at booke en tid.

Vi har tidligere skrevet om, hvad agentisk browsing betyder for din virksomhed. Her går vi helt ned i det tekniske og ser på, hvordan du får en grøn markering.

Derfor får du ikke en score fra 0 til 100

Modsat de andre kategorier giver Agentisk browsing ikke en vægtet score. I stedet ser du en brøk, fx 2/2 eller 2/3, der viser, hvor mange af tjekkene din side består. Google skriver selv, at standarderne for det agentiske web stadig er under udvikling, og at målet indtil videre er at give brugbare signaler frem for en endelig rangering.

»Grøn« betyder derfor i praksis, at alle de tjek, der gælder for din side, er bestået. Står der 2/3, er der ét tjek, der fejler, og det er det, du skal finde og rette.

De tjek, der afgør, om du får grøn

Kategorien bygger på deterministiske tjek. Det betyder, at den samme side giver det samme resultat hver gang, så længe siden ikke ændrer sig. I PageSpeed Insights er det tre tjek, der tæller med i brøken, plus et fjerde, eksperimentelt tjek.

1. Tilgængelighedstræet (accessibility tree)

AI-agenter læser sjældent din side, som et menneske ser den. De læser i stedet tilgængelighedstræet: den forenklede struktur af overskrifter, knapper, links og formularfelter, som browseren bygger til bl.a. skærmlæsere. Lighthouse udvælger en række af sine eksisterende tilgængelighedstjek, som er særligt vigtige for maskiner:

• Navne og labels: Alle interaktive elementer, fx knapper, links og felter, skal have et navn, som en maskine kan læse.
• Gyldig struktur: Roller og relationer mellem elementer skal være korrekte, fx at et listepunkt ligger i en liste.
• Synlighed: Indhold, man kan klikke på eller udfylde, må ikke være skjult for tilgængelighedstræet.

En knap med et forstørrelsesglas-ikon er let at forstå for et menneske. For en agent er det bare en knap uden navn.

2. Layoutstabilitet (CLS)

Det andet tjek er Cumulative Layout Shift, som du måske kender fra Core Web Vitals. Mange agenter tager skærmbilleder og beslutter ud fra dem, hvor de skal klikke. Hvis indholdet flytter sig, mens siden indlæses, kan agenten ramme det forkerte sted. Sigt efter en CLS under 0,1, som er Googles grænse for »god«.

3. llms.txt

Det tredje tjek kigger efter en llms.txt-fil i roden af dit domæne. Filen er en kort oversigt i Markdown over, hvad din hjemmeside handler om, og hvor de vigtigste sider ligger. Læs mere i vores indlæg om, hvorfor llms.txt er blevet vigtigt.

Her er en vigtig detalje: Har du ingen fil, og svarer serveren med en almindelig 404, bliver tjekket markeret som ikke relevant. Det trækker ikke ned, det tæller bare ikke med. Derfor ser mange sider 2/2 i stedet for 3/3. Til gengæld fejler tjekket, hvis serveren svarer med en fejl, når Lighthouse forsøger at hente filen. Og findes filen, bliver den også vurderet på, om den mangler en H1-overskrift, er for kort eller ikke indeholder links.

4. WebMCP – det eksperimentelle tjek

WebMCP er en foreslået standard, hvor hjemmesiden selv fortæller AI-agenter, hvilke handlinger de kan udføre, fx at udfylde en kontaktformular eller booke en tid. Tjekket kræver Chrome 150 og tilmelding til et såkaldt origin trial, og det tæller ikke med i brøken i PageSpeed Insights i dag. Du behøver altså ikke gøre noget ved det for at få grøn, men det er værd at holde øje med.

Vil du have os til at gennemgå jeres hjemmeside for tekniske fejl, der påvirker både AI-agenter, tilgængelighed og SEO? Vi hjælper virksomheder med teknisk søgemaskineoptimering af WordPress-sider.

Sådan får du grøn i Agentisk browsing – trin for trin

Trin 1: Kør testen og find det røde tjek

Gå ind på pagespeed.web.dev, indtast adressen på den side, du vil teste, og start analysen. Scroll ned til kategorien Agentisk browsing, og fold de enkelte tjek ud. Test både mobil og computer, og test ikke kun forsiden. En kontaktformular eller et produktfilter på en underside kan sagtens fejle, selvom forsiden er fin.

Er du udvikler, kan du også køre Lighthouse lokalt med kommandolinjeværktøjet. Det er praktisk, hvis du vil teste en side under udvikling, før den går live:

npm install -g lighthouse@latest
lighthouse https://dinside.dk --view

Har du ikke forstand på kode, er det nok at notere, hvilket tjek der fejler, og hvilke elementer rapporten peger på. Lighthouse viser typisk præcis, hvilken knap, hvilket link eller hvilket felt der er problemet. Læs også vores guide til test af hastigheden på din hjemmeside.

Trin 2: Ryd op i tilgængelighedstræet

Det er oftest her, WordPress-sider fejler. Gennemgå de elementer, Lighthouse peger på, og ret dem en efter en. Det er typisk disse syndere, vi finder:

• Ikonknapper uden tekst: Burgermenuen på mobil, søgeikonet, luk-knappen i en popup og pilene i en slider skal have et navn. Brug en visuelt skjult tekst eller en aria-label.
• Links uden tekst: Sociale ikoner i footeren og logoet i headeren er klassikere. Et logo-link skal have en alt-tekst på billedet, fx virksomhedens navn.
• Formularfelter uden label: Placeholder-tekst er ikke nok. Hvert felt skal have et label, også selvom det er visuelt skjult.
• Billeder uden alt-tekst: Billeder med indhold skal have en beskrivende alt-tekst. Rent dekorative billeder skal have en tom alt-tekst, så de springes over.
• Forkert brug af ARIA: aria-hidden på noget, man kan klikke på, eller roller, der ikke passer til elementet. Tommelfingerreglen er, at almindelig semantisk HTML næsten altid er bedre end ARIA.
• Iframes uden titel: Indlejrede kort, videoer og bookingsystemer skal have en title-attribut.

Her er et eksempel på en søgeknap før og efter:

<!-- Før: knappen har intet navn -->
<button class="search-toggle"><svg>...</svg></button>

<!-- Efter: knappen har et navn, som agenter og skærmlæsere kan læse -->
<button class="search-toggle" aria-label="Søg på siden"><svg aria-hidden="true">...</svg></button>

I Kadence og de fleste andre temaer kan mange af rettelserne laves direkte i editoren: alt-tekster i mediebiblioteket, labels i formularblokken og tekst på knapper. Kommer fejlen fra et plugin, fx en slider, en chatwidget eller et cookiebanner, skal du enten finde indstillingen i pluginnet, kontakte udvikleren eller overveje et alternativ.

Godt at vide: Arbejdet betaler sig dobbelt. De samme rettelser forbedrer også din Accessibility-score og hjælper dig på vej mod kravene i tilgængelighedsloven.

Trin 3: Få layoutet til at stå stille

Fejler layoutstabiliteten, er det næsten altid et af disse elementer, der skubber indholdet rundt:

• Billeder og videoer uden faste dimensioner: Angiv width og height, så browseren kan reservere pladsen, før billedet er hentet. WordPress gør det automatisk for billeder indsat via editoren, men ikke altid for billeder i temaets header eller i page builders.
• Cookiebannere og topbannere, der skubber siden ned: Lad banneret ligge oven på indholdet, fx i bunden af skærmen, i stedet for at indsætte det øverst på siden.
• Webfonte, der skifter sent: Når standardfonten udskiftes med jeres egen font, kan teksten ændre størrelse og skubbe alt nedenunder. Hent fontene lokalt, og preload de vigtigste.
• Indhold, der indlæses med JavaScript: Anmeldelseswidgets, Instagram-feeds og annoncer skal have en reserveret højde, fx med min-height i CSS.
• Sticky headers, der ændrer højde: En header, der krymper, når man scroller, eller som først bliver fastgjort efter indlæsning, kan give skift.

Kig også i Performance-sektionen i samme rapport. Under diagnosticeringen kan du se, hvilke elementer der har flyttet sig mest. Start med det største. Et simpelt eksempel på at reservere plads til en widget:

/* Reservér plads til en widget, der indlæses sent */
.anmeldelser-widget {
  min-height: 320px;
}

Trin 4: Opret en gyldig llms.txt

Har du allerede en llms.txt, og fejler tjekket, skyldes det typisk, at filen mangler en H1, er for kort eller ikke har links. Har du ingen fil, er den ikke et krav for at få grøn. Men den er den nemmeste måde at gå fra 2/2 til 3/3 på, og samtidig giver du AI-systemer en klar oversigt over jeres virksomhed.

Filen skal ligge i roden af dit domæne, fx dinside.dk/llms.txt, og være skrevet i Markdown. Her er et enkelt eksempel:

# Malerfirma Hansen ApS

> Malerfirma i Aarhus. Vi udfører indvendig og udvendig maling for private og erhverv i Østjylland.

## Ydelser
- [Indvendig maling](https://dinside.dk/indvendig-maling/): Maling af lejligheder, huse og kontorer
- [Udvendig maling](https://dinside.dk/udvendig-maling/): Facader, vinduer og træværk

## Om os
- [Om Malerfirma Hansen](https://dinside.dk/om-os/): Historie, medarbejdere og certificeringer
- [Kontakt](https://dinside.dk/kontakt/): Telefon, e-mail og adresse

I WordPress kan du lave filen på to måder. Den nemmeste er et plugin: Nyere versioner af Rank Math har et indbygget llms.txt-modul, og der findes flere selvstændige plugins, der genererer filen automatisk ud fra dine sider. Alternativt kan du uploade en statisk llms.txt til rodmappen via FTP eller filhåndteringen hos din hosting.

Tjek bagefter i browseren, at filen kan åbnes, og at den vises som almindelig tekst. Vær også opmærksom på, at en firewall, et sikkerhedsplugin eller en bot-beskyttelse hos fx Cloudflare kan finde på at svare med en fejl til automatiske besøg. Så fejler tjekket, selvom filen findes.

Trin 5: Test igen og hold øje

Kør PageSpeed-testen igen, når rettelserne er live. Husk at tømme cachen i dit cacheplugin og eventuelt på dit CDN, ellers tester du den gamle version. Resultatet kan svinge en smule mellem tests, især hvis layoutskiftene afhænger af, hvor hurtigt eksterne scripts indlæses, så test gerne et par gange.

Gør det derefter til en fast del af vedligeholdelsen. Et nyt plugin, en ny slider eller et nyt cookiebanner kan hurtigt sende dig tilbage til gul.

Hvad en grøn score ikke betyder

Agentisk browsing er ikke en rankingfaktor i Google, og Google markerer selv kategorien som eksperimentel. En grøn markering betyder, at AI-agenter har gode forudsætninger for at læse og bruge din side. Den garanterer ikke, at ChatGPT, Gemini eller andre AI-tjenester nævner jeres virksomhed.

Det er alligevel værd at tage alvorligt, fordi rettelserne forbedrer brugeroplevelsen, tilgængeligheden og det tekniske fundament for SEO på samme tid. Læs mere om teknisk SEO.

Efterord

“Vi ser Agentisk browsing som en af de nemmeste kategorier at få grøn i PageSpeed, fordi den i bund og grund belønner god, gammeldags webudvikling: tydelige knapper, sider der står stille, og en klar beskrivelse af, hvem man er. Det er præcis det, der hjælper både mennesker og maskiner.”

Ofte stillede spørgsmål

Du er velkommen til at læse mere i nogle af vores andre blogindlæg