Hvor hurtig skal din hjemmeside være til AI-crawlere?

Du har optimeret dit indhold. Din hjemmeside har ekspertise, autoritet og signaler om tillid. Men når en AI-crawler kommer til din side og møder en tidsgrænse, fordi din server bruger 6 sekunder på at svare, eller fordi LCP ikke er færdig med at vise siden efter 5 sekunder, går crawleren videre. Dit indhold bliver aldrig indekseret. Dine henvisninger kommer aldrig.

Hastighed dræber synlighed. Ikke langsomt. Øjeblikkeligt og helt.

AI-crawlere arbejder under vilkår, som almindelige søgemaskiner ikke har. De har strenge tidsgrænser, begrænsede regneressourcer og ringe tålmodighed. En side, der står perfekt hos Google, kan være helt usynlig for ChatGPT, Perplexity eller Claude, fordi den ikke indlæses inden for crawlerens frist. Dette kapitel handler om, hvordan Core Web Vitals virker for AI, hvilke tal der betyder mest, og hvad du skal ændre.

Hvad Core Web Vitals måler, og hvorfor de findes

Core Web Vitals er tre tal, som Google har lavet for at måle, hvordan brugerne rigtigt oplever en side. De fanger det øjeblik, hvor browseren begynder at vise indhold, det øjeblik, hvor brugerne kan bruge siden, og hvor stabilt layoutet er under indlæsning. Google bruger dem som faktorer for placering. Men for AI-crawlere er de faktorer for at overleve.

De tre tal er:

Largest Contentful Paint (LCP): Hvor lang tid der går, før det største visuelle element er indlæst. Målet er under 2,5 sekunder. Det er det, brugerne ser først. Hvis dit hovedbillede, din overskrift eller dit vigtigste afsnit tager 4 sekunder om at dukke op, skal både mennesker og crawlere vente.

Interaction to Next Paint (INP): Hvor lang tid det tager, før browseren svarer, efter en bruger har klikket på noget. Målet er under 200 millisekunder. Det tal viser, om din JavaScript er oppustet, eller om din side fryser, når crawlere efterligner, at nogen bruger siden.

Cumulative Layout Shift (CLS): Hvor meget siden hopper rundt under indlæsning. Målet er under 0,1. Når elementer flytter sig uventet, trækker crawlere rodet eller ufuldstændigt indhold ud. Dine omhyggeligt skrevne afsnit bliver forvrængede, når crawleren læser dem.

I almindelig søgning er det fingerpeg. For AI-crawlere er det hårde grænser.

Hvorfor AI-crawlere har andre krav til hastighed end Google

Googles crawler fordeler arbejdet. Den gennemgår millioner af webadresser på tusindvis af servere. Den har råd til at vente 10 sekunder på, at en side indlæses, fordi ventetiden er spredt ud over en enorm infrastruktur.

AI-crawlere arbejder ud fra hver enkelt søgning. Når en bruger stiller ChatGPT et spørgsmål, har Perplexity 3 til 5 sekunder til at finde, hente og læse dit indhold, før svaret skal begynde at blive lavet. Hvert sekund tæller. Hvert millisekund bliver regnet med i crawlerens budget.

Undersøgelser af, hvordan AI-crawlere opfører sig, viser, at hjemmesider med First Contentful Paint under 0,4 sekunder i gennemsnit får 6,7 henvisninger, mens hjemmesider, der indlæses på over 1,13 sekunder, i gennemsnit får 2,1 henvisninger. Det er ikke en tilfældighed. Det er årsag og virkning. Langsomme sider bliver sprunget over.

ChatGPTs crawler til at hente har en dokumenteret grænse for tid. Sider, der ikke svarer inden for den frist, bliver markeret som utilgængelige og nedprioriteret ved senere forsøg på at gennemgå dem. Perplexitys bot gør det samme. En hjemmeside, der bruger 6 sekunder på at svare, får ikke en ny chance.

Time to First Byte (TTFB): det tal, AI-crawlere går mest op i

TTFB måler tiden mellem, at en forespørgsel bliver sendt, og at den første byte kommer tilbage fra serveren. Det er det reneste mål for, hvor hurtigt serveren svarer.

For AI-crawlere afgør TTFB, om de overhovedet forsøger at vise siden. Hvis din server bruger 700 millisekunder på at svare, har crawleren allerede spildt 700 millisekunder af sit vindue på 3 til 5 sekunder. Crawleren opgiver helt at vise siden og nøjes med at læse HTML. Det betyder, at indhold, der bliver lavet af JavaScript, bliver usynligt.

Tallene er tydelige. En TTFB under 200 millisekunder regnes for exceptionel. 200 til 500 millisekunder er acceptabelt, men ikke ideelt. Over 600 millisekunder har du et problem med serverens infrastruktur.

De fleste artikler om hastighed behandler TTFB som mindre vigtig end de visuelle tal. For AI-crawlere er det den, der holder porten. Hvis TTFB fejler, betyder alt andet ikke noget.

Almindelige årsager til langsom TTFB er langsomme forespørgsler til databasen bag hver indlæsning af en side, overbelastet hosting med for mange hjemmesider pr. server, dårlig geografisk routing af forespørgsler og manglende caching i et content delivery network (CDN). Det er ikke problemer med design. Det er problemer med infrastruktur.

Largest Contentful Paint (LCP): at vente på det store element

LCP måler tiden, til det største visuelle element er helt indlæst. Det er som regel et hovedbillede, et baggrundsbillede eller en stor blok tekst. På sider med meget indhold er det hovedområdet med indhold.

En LCP under 2,5 sekunder er grænsen for "god". AI-crawlere henviser til sider i det interval 2,8 gange oftere end til sider med langsommere LCP. Forskellen er ikke lille.

Crawleren venter ikke på, at hvert eneste element er indlæst. Men den venter på, at hovedindholdet dukker op. Hvis dit hovedbillede er på 4 megabyte, og du ikke har optimeret det til nettet, sidder crawleren og venter, mens billedet hentes. Når billedet er færdigt, er du allerede over crawlerens tidsgrænse.

Almindelige årsager til langsom LCP er billeder, der er for store og ikke komprimeret, videoer indlejret uden optimering, der blokerer for visningen, skrifttyper på nettet, der ikke er skåret ned og ikke indlæses hurtigt, og scripts fra tredjepart, der bliver vist øverst på siden. Hver af dem lægger sekunder til LCP.

Løsningen er ikke at vente længere. Løsningen er at få LCP til at ske hurtigere. Det betyder optimering af billeder, at indlæse indhold længere nede på siden først senere (lazy loading), at indlæse scripts asynkront og eventuelt at skifte tunge indlejringer fra tredjepart ud med statisk HTML.

Interaction to Next Paint (INP): hvor godt JavaScript kører

INP måler, hvor hurtigt siden reagerer. Når en bruger (eller en crawler, der efterligner en bruger) bruger siden, hvor lang tid går der, før noget ændrer sig på skærmen? Målet er under 200 millisekunder.

For AI-crawlere viser INP, om din JavaScript er optimeret eller oppustet. En dårlig INP viser, at din side har for meget kode, der kører i hovedtråden, eller at koden ikke er delt rigtigt op og udskudt.

Crawlere, der efterligner brug, gør det for at trække dynamisk indhold ud. Hvis din side indlæser statisk HTML, men afhænger af JavaScript for at vise formularer, indhold med betingelser eller interaktive elementer, skal crawleren køre den JavaScript. Hvis JavaScript er langsom, får crawleren en dårlig INP og markerer din side som ineffektiv.

Det skjulte problem ved at vise sider på klientsiden er, at de fleste AI-crawlere slet ikke kører JavaScript. Undersøgelser viser, at statisk HTML med schema markup opnår 94 % succes med at blive læst, mens indhold, der bliver vist af JavaScript, ligger på 23 %. Det betyder, at hvis dit indhold er skjult bag JavaScript, ser AI-crawlere det måske aldrig.

Hvis din hjemmeside viser sider på klientsiden, bliver problemet med INP til et problem med synlighed. Crawleren kan ikke vente på, at JavaScript bliver kørt, så den springer indhold over, der afhænger af JavaScript.

Cumulative Layout Shift (CLS): stabilitet, mens oplysninger bliver trukket ud

CLS måler visuel ustabilitet. Når elementer på siden flytter sig under indlæsning, stiger Cumulative Layout Shift. Målet er under 0,1.

For crawlere handler CLS ikke om, hvordan brugerne oplever det. Den handler om, hvor præcist siden bliver læst. Når DOM flytter sig, mens crawleren trækker indhold ud, kan den tage de forkerte elementer. En overskrift kan flytte sig ind på en anden overskrifts plads. En sidebjælke kan skubbe hovedindholdet ud af position. Crawleren trækker den tekst ud, der står på en position, ikke den tekst, der logisk hører til der.

Almindelige årsager til høj CLS er pladser til annoncer, der indlæses sent og skubber indhold nedad, billeder uden angivne mål, der bliver indlæst og flytter layoutet, skrifttyper på nettet, der skifter og ændrer afstanden, og karruseller, der selv kører og flytter indhold. Hver af dem får layoutet til at bevæge sig.

Løsningen er at reservere plads til alt, der skal indlæses. Angiv målene på billeder i HTML. Sæt font-display til swap, så skrifttyper ikke blokerer for visningen. Indlæs annoncer og dynamisk indhold i reserverede beholdere, der ikke får layoutet til at flytte sig.

Sådan optimerer du til hastighed for AI-crawlere

Optimering af hastighed til AI-crawlere er anderledes end optimering af hastighed til mennesker. Brugerne går op i, hvornår de ser siden, og hvornår de kan bruge den. Crawlere går op i, hvornår serveren svarer, og om alt indhold bliver færdigt vist.

Start med TTFB. Hvis din server bruger mere end 500 millisekunder på at svare, betyder alt andet ikke noget. Gennemgå dine forespørgsler til databasen, skift til en hurtigere udbyder af hosting, indfør caching i selve programmet, eller brug et CDN. Det betaler sig med det samme i, hvor meget crawlerne kan dække, at du investerer i TTFB.

Optimér billeder. Hvert billede på din side bør være komprimeret, have de mål, det bliver vist i, og leveres i moderne formater som WebP med PNG som reserve. Brug et værktøj til at optimere billeder. Til hovedbilleder kan du bruge et CDN med automatisk optimering.

Udskyd JavaScript, der ikke er kritisk. Indlæs kun JavaScript, der er absolut nødvendigt for, at crawleren kan se indholdet. Scripts, der følger statistik, indlæser annoncer eller driver interaktive funktioner, bør udskydes eller indlæses asynkront. Så er hovedtråden fri, og kørslen er hurtig.

Vis kritisk indhold på serveren. Hvis din hjemmeside bruger et framework til JavaScript på klientsiden, så vis den kritiske del på serveren, og gør den interaktiv på klienten. Så er det sikkert, at crawlere ser indholdet med det samme. Statisk generering af hjemmesider (SSG) er endnu bedre: byg dine sider til HTML, når du udgiver.

Undgå store indlejringer fra tredjepart. Hvis du indlejrer afspillere fra YouTube, afspillere til musik eller store eksterne widgets, blokerer de for visningen. Erstat dem med pladsholdere, der først indlæses, når man klikker, eller læg de vigtigste oplysninger ind som statisk HTML.

Reservér plads til dynamisk indhold. Angiv tydelige mål for billeder, annoncer og dynamiske afsnit. Det forhindrer, at layoutet flytter sig, og sikrer, at crawleren trækker det rigtige indhold ud.

Brug et CDN. Et content delivery network sender forespørgsler til den server, der er tættest på, og det mindsker ventetiden og TTFB. De fleste CDN'er tilbyder også automatisk optimering og komprimering af billeder.

Hvad WEMASY har med til hastighed og crawlere

WEMASY's hjemmesidebygger har hosting med automatisk caching i et CDN, optimering af billeder ved upload og visning af alt indhold på serveren. Sider bygget med WEMASY lever som standard op til standarderne for Core Web Vitals.

Når du udgiver en hjemmeside med WEMASY, er din TTFB optimeret gennem vores CDN, dine billeder bliver automatisk gjort mindre og komprimeret, og din HTML bliver leveret som statiske sider og ikke lavet, når nogen beder om dem. Det betyder, at AI-crawlere ser dit indhold med det samme uden at vente på at siden bliver vist eller behandlet.

Se, hvad der er med i WEMASY's planer.

Ofte stillede spørgsmål