Sådan tjekker du dine Core Web Vitals i AmICited

Hurtige, stabile sider betyder også noget for AI-synlighed — svarmotorer foretrækker kilder, der indlæses hurtigt. Før du dykker ned i AmICiteds audit, er det nyttigt at forstå, hvad Core Web Vitals faktisk måler, og hvorfor et problem med sidehastighed stille og roligt kan blive et problem for AI-citationer.

Hvad er Core Web Vitals?

Core Web Vitals er et sæt standardiserede målinger, som Google har udviklet for at kvantificere reel page experience i praksis: hvor hurtigt en sides hovedindhold vises, hvor hurtigt den reagerer på input, og hvor visuelt stabil den forbliver, mens den indlæses. De blev designet til at erstatte vage forestillinger om, at “siden føles langsom”, med tal, du kan spore, benchmarke og holde udviklingsteams ansvarlige for. Google indarbejdede dem i sine rankingsignaler for søgning for flere år siden, og den samme underliggende data — indsamlet fra rigtige Chrome-brugere via Chrome UX Report (CrUX) — påvirker i stigende grad, hvilke kilder svarmotorer er villige til at hente, rendere og citere.

De tre kernemålinger er Largest Contentful Paint (LCP), Interaction to Next Paint (INP) og Cumulative Layout Shift (CLS), hver parret med en bestået/ikke-bestået-tærskel, som Google offentliggør og opdaterer løbende. To understøttende målinger, First Contentful Paint (FCP) og Time to First Byte (TTFB), fuldender billedet af sidehastighed ved at isolere, hvor hurtigt serveren svarer, og hvor hurtigt overhovedet noget vises på skærmen, selv før hovedindholdet er klar. Fordi CrUX er bygget på anonymiseret feltdata — faktiske besøg fra faktiske Chrome-brugere — afspejler tallene reelle forhold (enhedstype, netværkskvalitet, geografi) frem for en enkelt laboratorietest kørt på en hurtig kontorforbindelse.

Hvorfor betyder det noget specifikt for generativ engine-optimering ? AI-crawlere og de retrieval-systemer, der ligger bag AI Overviews, ChatGPT-søgning og Perplexity, skal hente og fortolke din side, før de kan citere den. En side, der timer ud, indlæses langsomt, eller hvor indholdet flytter sig rundt under indlæsning, er dyrere at crawle i stor skala og mindre pålidelig at udtrække rent indhold fra. Særligt langsom TTFB kan få en crawler til at opgive et hentningsforsøg, før dit hovedindhold overhovedet når frem. Intet af dette er den afgørende faktor for, om du bliver citeret — indholdsrelevans, autoritet og struktur betyder langt mere — men en kronisk langsom eller ustabil startside er en friktion, som svarmotorer ikke har nogen grund til at acceptere, når en hurtigere konkurrent tilbyder den samme information.

Dette er også et område, hvor teknisk SEO og answer engine-optimering overlapper næsten fuldstændigt: de samme tekniske rettelser, der forbedrer dine Google-placeringer — billedstørrelse, serversvartid, layoutstabilitet — er dem, der holder dine sider tilgængelige og citerbare for AI-systemer. Dette overlap er præcis grunden til, at AmICited viser Core Web Vitals som en del af en bredere AI-synligheds -audit frem for som et selvstændigt SEO-værktøj: det er én blandt flere faktorer for, om AI-motorer finder dit site troværdigt og nemt at arbejde med.

Sådan finder du den

Åbn Audit → Web Vitals fra venstre navigation. Siden forklarer det selv: “Core Web Vitals for dit domænes startside… sidehastighed er en Google-rankingfaktor, og AI-svarmotorer foretrækker hurtigt indlæsende sider.” AmICited henter automatisk denne data for dit sporede domæne og for hver konkurrent, du overvåger, så du ikke behøver at køre et separat værktøj eller indsætte URL’er manuelt — det er det samme konkurrentsæt, du allerede bruger til at spore share of voice og citationsrank andre steder på platformen.

Fordi CrUX kræver en vis minimumsmængde reel Chrome-trafik, før den offentliggør stabile tal for en URL, vil lavtrafik-domæner — herunder mange B2B- og nichesites — nogle gange vise tomme værdier i en periode. Det er forventet adfærd, ikke en fejl: det betyder, at Google endnu ikke har akkumuleret nok feltdata til at rapportere med sikkerhed, og det udfyldes, når trafik (eller tid) samles op.

Hvad målingerne betyder

Konkurrentsammenligningstabellen viser hvert domæne med:

• Score — en samlet oversigt over bestået/ikke-bestået for Core Web Vitals, der giver dig et hurtigt overblik over, om et domæne klarer Googles tærskelværdier på tværs af alle målinger.
• LCP (Largest Contentful Paint) — hvor hurtigt hovedindholdet indlæses, typisk det største billede eller tekstblok i viewportet. Dette er den måling, der er mest direkte knyttet til en besøgendes — eller en crawlers — opfattelse af, om “siden er klar endnu”.
• INP (Interaction to Next Paint) — hvor responsiv siden føles, når en bruger faktisk interagerer med den (klikker, trykker, skriver). Den erstattede den ældre First Input Delay-måling, fordi den fanger responsivitet gennem hele sidebesøget, ikke kun den første interaktion.
• CLS (Cumulative Layout Shift) — hvor visuelt stabil siden er, mens den indlæses. Høj CLS betyder, at elementer hopper rundt, efterhånden som billeder, annoncer eller skrifttyper indlæses, hvilket er forstyrrende for besøgende og kan gøre indhold sværere for automatiserede systemer at fortolke konsistent.
• FCP (First Contentful Paint) — hvor hurtigt noget først vises på skærmen, selv før hovedindholdet er klar. Det er et tidligt signal om, at siden overhovedet indlæses, i stedet for at forblive en blank skærm.
• TTFB (Time to First Byte) — serverens svarhastighed: tiden mellem forespørgslen på siden og modtagelsen af den første byte tilbage. Dette er næsten udelukkende en backend-/infrastrukturmåling, og det er ofte den nemmeste at rette med ændringer i hosting, caching eller CDN.

Dit eget domæne er markeret Dig, med dine sporede konkurrenters startsider nedenunder, så hver måling straks bliver benchmarket i stedet for at blive vurderet isoleret.

Sådan bruger du den

1. Benchmark mod rivaler. Hvis konkurrenters sider er hurtigere, er det endnu en fordel, de har i både søgning og AI-svar — og et hul, der er billigt at lukke sammenlignet med indholds- eller autoritetsarbejde.
2. Ret de røde. En fejlende LCP eller CLS peger på konkret ingeniørarbejde: for store hero-billeder, manglende width/height-attributter, render-blokerende scripts eller uoptimerede webfonte er de sædvanlige syndere.
3. Prioritér TTFB, hvis den er langsom. Fordi den ligger opstrøms for alle andre målinger, trækker en langsom TTFB også LCP ned, og det er ofte den hurtigste måling at forbedre — typisk gennem caching, en CDN eller en hosting-opgradering frem for en omskrivning af indholdet.
4. Tjek igen efter ændringer. Efterhånden som feltdata opdateres, kan du vende tilbage for at bekræfte, at forbedringerne har slået igennem. CrUX-data er et rullende 28-dages vindue, så ændringer tager tid om at vise sig — forvent ikke, at tallene flytter sig dagen efter et deploy.
5. Betragt TTFB som et tidligt advarselssignal. En server, der regelmæssigt bruger over et sekund på at returnere den første byte, er en stærk kandidat til crawl- og renderingsproblemer, der rækker langt ud over denne ene audit — det er værd at læse om, hvorfor crawler-ingeniører i stigende grad betragter hurtig TTFB som en tærskel for pålidelig succes med AI-crawlere snarere end en kærkommen bonus.

Ingen af disse fire målinger fungerer isoleret fra resten af dit tekniske fundament. En startside, der scorer godt på Core Web Vitals, men blokerer AI-crawlere i robots.txt, eller serverer en stort set tom side til klienter uden JavaScript, bliver stadig ikke citeret — hastighed hjælper kun, når en crawler faktisk får lov til at komme ind og kan fortolke det, der er der. Derfor er det værd at behandle denne audit som ét kontrolpunkt i en bredere rutine frem for en engangsindsats: kør den sammen med dine andre AmICited-audits med jævne mellemrum, ligesom du periodisk ville genbesøge en bredere teknisk tjekliste, der dækker crawlability, structured data og udtrækkelighed af indhold.

Web Vitals vinder ikke citationer alene, men langsomme, ustabile sider kan holde dig tilbage — denne audit fortæller dig, hvor du står i forhold til de sites, AI-motorer vælger imellem. Hvis du vil have den dybere research bag anbefalingen, kan du læse om hvorvidt sidehastighed faktisk påvirker AI-søgesynlighed , og kombinere dette tjek med en bredere AI-tilgængeligheds-audit af dit site for at dække crawlability-siden af ligningen. Herfra er det naturlige næste skridt at indarbejde Web Vitals i din faste overvågningsrutine sammen med AmICiteds AI rank tracker og citationssporing, så en performance-regression bliver opdaget på samme tid, som du ville bemærke et fald i omtaler — i stedet for at blive opdaget separat, uger senere, når det allerede har kostet dig synlighed.