Google satte tal på indeksering. Det hurtigste tal er det mindst vigtige

Hvad Google viste frem i Barcelona

På tredjedagen af Search Central Live Deep Dive Europe i Barcelona, 2. oktober 2026, gik Gary Illyes på scenen med tre tabeller: crawling, indeksering og servering. Hver række havde to kolonner — typisk og langsomste. Det er første gang Google lægger tal på hele kæden i ét oplæg, og værdierne er siden refereret enslydende af John Campbell fra ROAST, Search Engine Roundtable og Search Engine Journal.

Et udpluk af de typiske tider: opdagelse af en ny URL ~20 timer, genbesøg af en kendt URL ~30 dage, sitemap-behandling ~24 timer, rendering sekunder at udføre men timer i kø, indeksering ende til ende ~1,5 time, titel- og snippetopdatering 1-2 dage, kanonisk ændring 1-3 uger, sideflytning 1-3 måneder, fjernelse af manuel handling 1-2 uger og genopretning efter en core update 3-6 måneder.

1,5 time er ikke tiden fra udgivelse til indeks

Det tal, der bliver citeret ud af sammenhæng, er indeksering ende til ende på ~1,5 time. Det lyder som et løfte om, at en ny side står i Google inden frokost. Det gør den ikke, for de halvanden time begynder først, når siden er hentet.

Før det led skal Google finde URL'en — typisk ~20 timer — og derefter skal den gennem renderingskøen, hvor selve renderingen tager sekunder, men køen tager timer. Illyes sagde det selv på scenen: processerne hænger sammen, en side kan ikke indekseres, før den er crawlet, og forsinkelserne lægger sig oven i hinanden. Lægger man de typiske tal sammen, er en ny side typisk omkring et døgn om at komme fra udgivelse til indeks, ikke halvanden time.

Det har en praktisk konsekvens. Hvis du tjekker en nyudgivet side efter to timer og ikke finder den, er der ingenting galt. Du har målt det forkerte sted i kæden.

De 30 dage er det tal, der koster penge

Den mest overraskende række i crawling-tabellen er ikke opdagelsen. Det er genbesøget: en URL, Google allerede kender, bliver typisk hentet igen efter ~30 dage. En ny URL findes på ~20 timer. Forholdet er omkring seksogtredive til én i den nye URL's favør.

Det vender et stykke standardrådgivning på hovedet. «Opdater dine gamle sider i stedet for at skrive nye» er fornuftigt nok som indholdsstrategi, men rådet kommer aldrig med den latenstid, der hører til. En rettelse i en eksisterende artikel kan ligge en måned, før Google overhovedet har set den — og først derefter begynder indekseringen og de 1-2 dage til en ny titel eller et nyt snippet.

Et forbehold, tabellen ikke giver: de ~30 dage er et gennemsnit på tværs af hele nettet. Forsiden på et nyhedssite bliver hentet igen i løbet af minutter. Tallet beskriver den lange hale af sider, der ikke giver Google nogen grund til at komme forbi, og det er netop dér, de fleste opdateringer af gammelt indhold foregår. Det gør ikke tallet forkert. Det gør det relevant præcis for den slags arbejde, man plejer at forvente hurtig effekt af.

«Aldrig» står fem gange i den langsomste kolonne

Fem rækker har «aldrig» som det langsomste udfald, og tre af dem er mærket med kvalitet: sitemap-behandling, indeksering ende til ende og opdatering af strukturerede data. Det er ikke en tidsangivelse. Det er en afvisning.

Formuleringen siger noget, Google sjældent skriver så direkte: for de her processer er det værste tilfælde ikke, at det går langsomt, men at det ikke sker. Et korrekt sitemap, et rent robots.txt og fejlfri schema-markup køber dig ikke et crawl, hvis Google ikke mener, siden er besværet værd. Den vurdering er den samme, der blev flyttet ind i dokumentationen med bedømmernes vokabular om hovedindhold og originalitet — og den ligger før alle de tekniske tal i tabellen.

Tallene står ikke i Googles dokumentation

Her er det forbehold, der betyder mest, hvis du skal bruge tallene over for en kunde. Tabellerne er ikke udgivet af Google. De findes ikke i et blogindlæg, ikke på en hjælpeside, ikke i slides på Search Centrals eventside. De nåede ud, fordi en deltager skrev dem ned og lagde referatet op.

Der følger ingen metode med, ingen stikprøvestørrelse, ingen måleperiode. Og kolonnen for hurtigste tilfælde mangler helt, så spredningen kan kun ses i den ene retning.

Det ses tydeligst på genopretning. Googles egen dokumentation om core updates siger, at nogle ændringer kan slå igennem på få dage, men at det kan tage «flere måneder», før systemerne har bekræftet forbedringen — og at man ellers kan være nødt til at vente på den næste core update. Slidet oversætter det til 3-6 måneder typisk og 6 måneder til et år i værste fald. Det er første gang der står et tal, og tallet kan ikke linkes til. Samme mønster som med rulningsvinduet på september-spamopdateringen, hvor det annoncerede skøn og den faktiske varighed på statusdashboardet er to forskellige ting.

Brug tallene som pejlemærker. Ikke som leveringstider, og slet ikke i en aftale.

Sådan ville jeg bruge dem

Tabellerne ændrer ikke, hvad man skal gøre teknisk. De ændrer, hvor man måler, og hvornår man konkluderer.

• Mål opdagelse og indeksering hver for sig. «Hvornår så Google siden første gang» og «hvornår kom den i indekset» er to forskellige problemer med to forskellige løsninger. Serverlogs svarer på det første, Search Console på det andet.
• Dom over en opdatering falder efter en måned, ikke efter en uge. Et genbesøg på ~30 dage betyder, at en uges manglende effekt ikke er data.
• Skal en ændring ud hurtigt, så vælg den korteste kæde. En ny URL, der er med i sitemappet og linket fra en side, Google besøger ofte, går gennem opdagelsesledet på timer i stedet for at vente på et genbesøg.
• Tjek «aldrig»-rækkerne, før du fejlsøger teknik. En side, der ikke er crawlet efter flere uger, har sjældent et robots-problem.
• Før din egen log. Udgivelsestidspunkt, første crawl, første visning i indekset, pr. site. Googles tal er et gennemsnit af hele nettet. Dit eget er det eneste, der beskriver dit site — og det er også det eneste, du kan vise en kunde uden at henvise til et referat af et oplæg.