Google Page Experience Update — UX som rankingfaktor

Da Google i maj 2020 annoncerede Page Experience Update, var reaktionen i SEO-branchen blandet. Mange hilste det velkommen — endelig en officiel anerkendelse af, at hurtige og velfungerende sider fortjener en plads i toppen. Andre var mere skeptiske: var dette et reelt rankingsignal eller endnu et PR-tiltag fra Mountain View?

Jeg har fulgt Googles arbej med brugeroplevelse siden de første mobile-venlige tests i 2012, og Page Experience Update er i mine øjne det mest håndgribelige forsøg Google nogensinde har lavet på at kvantificere UX. Det lykkedes delvist — men implementeringen viste os også, hvad Google stadig kæmper med.

Hvad er Google Page Experience Update?

Definition og baggrund

Google Page Experience Update er en algoritmeændring, der introducerede en gruppe brugeroplevelsessignaler som officielle rankingfaktorer. Opdateringen samlede eksisterende signaler — mobilvenlig visning, HTTPS, fraværet af påtrængende interstitials og safe browsing — og lagde Core Web Vitals oven på dem som det nye centerpoint.

Kernen i opdateringen er den simple præmis, at sider der indlæser hurtigt, er stabile under indlæsning og reagerer promptt på brugerinteraktion, fortjener en rankeringsmæssig fordel. Google refererede til det som en samlet “Page Experience Score” — ikke et enkelt tal, men et sæt signaler der tilsammen beskriver oplevelsen af at besøge en side.

Google Opdateringer har historisk handlet om indhold og links. Page Experience var anderledes: det handlede om teknisk kvalitet set fra brugerens perspektiv.

Juni 2021: Core Web Vitals bliver officielle

Google annoncerede opdateringen i maj 2020, men udrulningen begyndte først i juni 2021 — med en gradvis implementering frem til august 2021. Den lange forvarsel var usædvanlig for Google og gav udviklere og bureauer tid til at forberede sig.

De tre Core Web Vitals ved lanceringen var:

• LCP (Largest Contentful Paint): Mål for, hvor hurtigt det største synlige element indlæser. God score: under 2,5 sekunder.
• FID (First Input Delay): Mål for, hvor hurtigt siden reagerer på første brugerinteraktion. God score: under 100 ms.
• CLS (Cumulative Layout Shift): Mål for visuell stabilitet — hvor meget siden “hopper” under indlæsning. God score: under 0,1.

I marts 2024 erstattede Google FID med INP (Interaction to Next Paint), som måler responsivitet på tværs af hele sessionen, ikke kun første interaktion.

Hvad ændrede Page Experience Update?

Core Web Vitals: LCP, FID/INP, CLS

Jeg husker tydeligt de første måneder efter udrulningen. Mange sider med middelmådige CWV-scores mistede ikke det store — og det er faktisk i overensstemmelse med, hvad Google sagde fra starten. Page Experience er et tiebreaker-signal: når to sider har tilsvarende relevant indhold, vinder den med bedre brugeroplevelse.

Det, der overraskede mange, var CLS. Sider med reklamer, der loadede forskudt, eller billeder uden definerede dimensioner, fik pludselig en konkret straf der var målbar i Search Console. Jeg har set e-commerce-sider med store produktbilleder tabe signifikant placering, alene fordi billederne ikke havde height og width-attributter sat i HTML.

LCP er det mest komplekse at løse i praksis. Det handler sjældent om én ting — det er en kombination af serverresponstid, render-blocking ressourcer, billedoptimering og cachingstrategi. Vi oplevede hos klienter, at en god hosting-løsning alene kunne rykke LCP fra “needs improvement” til “good” for langt de fleste sider.

Hvilke sider blev påvirket

Sider med meget dynamisk indhold — nyhedsmedier, store webshops, tunge WordPress-installationer — mærkede opdateringen mest. Statiske sider og simple blogs klarede sig generelt godt.

Google bruger Core Web Vitals-data fra Chrome User Experience Report (CrUX), som er baseret på rigtige brugerdata fra Chrome-brugere. Det betyder, at laboratoriedata fra PageSpeed Insights ikke altid matcher, hvad Google faktisk ser. En side kan se fin ud i et lab-test men have dårlige feltdata, fordi rigtige brugere på langsomme forbindelser eller ældre enheder oplever noget andet.

Google Page Experience Update i dag — CWV stadig vigtige

I 2026 er Core Web Vitals stadig en del af Googles rankingsystem, men diskussionen om, hvor meget vægt de bærer, fortsætter. Google har gentagne gange bekræftet, at indholdskvalitet vejer tungest — men de har aldrig sagt, at CWV er ligegyldige.

Jeg ser det sådan: sider med virkelig god indholdsrelevans og autoritet kan sagtens rangere højt med middelmådige CWV-scores. Men i konkurrenceprægede nicher, hvor top-10 er tæt på indholdet, kan god performance være det, der afgør om du er nr. 3 eller nr. 7. Det er ikke uvæsentligt.

Google Opdateringer fra 2024 og 2025 har ikke direkte ændret CWV-systemet, men de løbende Google Core Updates minder os om, at Googles algoritme er under konstant udvikling.

Hvad betyder PEU for din SEO?

Konkrete handlinger: mål og optimer CWV

Begyn altid med at forstå dine faktiske feltdata. Google Search Console har en dedikeret Core Web Vitals-rapport, der viser, hvilke URL-grupper der har problemer. Supplement med PageSpeed Insights og se på “Field Data” fremfor “Lab Data”.

De mest effektive tekniske tiltag jeg har set:

• LCP: Sørg for at hero-billedet har fetchpriority="high" og at serveren svarer hurtigt (TTFB under 600 ms er et godt mål). Overvej et CDN.
• INP: Reducer JavaScript-eksekvering på main thread. Tunge analytics-scripts og chat-widgets er hyppige syndere.
• CLS: Sæt altid eksplicitte dimensioner på billeder og videoer. Reservér plads til annoncer og embeds.

Typiske fejl

Den største fejl jeg ser er, at virksomheder optimerer til PageSpeed Insights’ lab-score og glemmer feltdata. Et perfekt lab-resultat med 100/100 hjælper dig ikke, hvis rigtige brugere på mobilnetværk oplever noget andet.

En anden klassisk fejl er at overse tredjepartsskripter. Tag-managers, chat-widgets, anmeldelsesværktøjer og sociale deleknapper kan alene bidrage med 500-800 ms ekstra INP-forsinkelse. Jeg anbefaler altid at loade tredjepartsskripter asynkront og helst efter first user interaction.

Fra Mobilegeddon til Page Experience — UX som SEO-discipline

Page Experience Update er ikke opstået i et vakuum. Google Mobilegeddon i 2015 var første gang Google officielt bestraffede sider, der ikke fungerede på mobil. Det var begyndelsen på en lang proces, hvor UX gradvist er blevet en SEO-disciplin.

Linjen fra Mobilegeddon til Page Experience handler om det samme: Google vil levere gode brugeroplevelser, fordi det fastholde brugerne i Googles økosystem. En frustrerend oplevelse på en ranket side er Googles problem, ikke kun udgiverens. Derfor er det rationelt at belønne sider, der fungerer godt.

Jeg forventer, at denne tendens fortsætter. Hvad vi ser som “teknisk SEO” i dag, vil gradvist fusionere med frontend-performance og UX-design på en måde, der gør det svært at adskille de tre discipliner.

Ofte stillede spørgsmål om Google Page Experience Update

Hvornår blev Page Experience Update lanceret? Opdateringen begyndte at rulle ud i juni 2021 og var fuldt implementeret i august 2021. Google annoncerede den allerede i maj 2020 for at give udviklere tid til at tilpasse sig.

Hvad er Core Web Vitals, og hvilke metrics bruger Google i dag? Core Web Vitals er tre performance-metrics: LCP (Largest Contentful Paint), INP (Interaction to Next Paint, som erstattede FID i marts 2024) og CLS (Cumulative Layout Shift). Google bruger feltdata fra rigtige Chrome-brugere via CrUX-databasen til at evaluere siderne.

Kan dårlige Core Web Vitals-scores koste mig placeringer? Ja, men det afhænger meget af din konkurrencesituation. Page Experience er et tiebreaker-signal — relevant og autoritativt indhold vejer stadig tungest. I tætte vertikaler kan dårlige CWV-scores dog være den faktor, der koster dig de afgørende pladser i toppen af SERP.

Hvad er den hurtigste måde at forbedre min CWV-score? Start med at fixe CLS ved at sætte dimensioner på billeder og reservere plads til annoncer. Det er teknisk enkelt og har typisk en stor effekt. Herefter: optimer LCP ved at prioritere hero-billedet og forbedre serverresponstiden. INP kræver typisk et dybere JavaScript-audit.