Ferskhet i Google-søk (QDF): hva oppdatering egentlig betyr

#Hva ferskhet i Google-søk (QDF) betyr

I vitneforklaringen i konkurransesaken US v. Google ga Pandu Nayak tre eksempler, sitert i en analyse fra Hobo fra 5. oktober 2026. En sportsfan vil ha sider fra i morges. En laptopkjøper vil ha tester fra riktig modellår, ikke fra i dag. Den som planlegger en kalkunmiddag kan være bedre tjent med en oppskrift på ti år.

Det tredje tilfellet hopper WordPress-eiere over. Ferskhet er ikke en bonus alle sider henter. For mange søk er den eldre, etablerte siden det riktige svaret, og å “oppdatere” den kan bare skade. Før du rører et innlegg, spør om søket i det hele tatt venter noe nytt.

#Hvorfor gamle sider får flere klikk i Google

Årsaken er mekanisk. Google rangerer delvis på det brukere har klikket på før, og Nayak beskrev bieffekten (sitatet er oversatt fra vitneforklaringen):

Utfordringen med ferskhet og klikk er at klikk hoper seg opp over tid, noe som betyr at eldre sider, potensielt utdaterte sider, ofte har flere klikk enn ferske sider

Pandu Nayak, Google, Hobo Web, egen oversettelse

En ny side starter uten klikk, en gammel har år med dem. For søk der ferskhet teller, må Google kompensere. For alle andre gjør de samlede klikkene det de ble bygd for.

For en eier følger to ting. Et ferskhetssystem skal løfte sider som virkelig er nye, så det er bygd for å stå imot billige signaler. Og en fersk side uten klikk starter med et handikap som en ny dato ikke fjerner.

#Hva Google sier om å endre datoer

Hobo siterer en tweet fra John Mueller 5. februar 2022, siden slettet:

Når du skriver noe nytt, eller endrer noe eksisterende vesentlig, så endre datoen. Å endre datoen uten å gjøre noe annet er bare støy og ubrukelig.

John Mueller, Google, Hobo Web, egen oversettelse

Tweeten er borte, så dette er referert tale og ikke dokumentasjon. Samme artikkel siterer et spørsmål fra Googles retningslinjer for nyttig innhold:

Endrer du datoen på sider for å få dem til å virke ferske når innholdet ikke er vesentlig endret?

Google, veiledning om nyttig innhold, Hobo Web, egen oversettelse

Les første setning i Muellers råd en gang til. Den sier ikke at datoen aldri skal endres. Den sier at den skal endres når noe nytt er skrevet eller noe vesentlig endret. En dato er en påstand, og regelen er at påstanden må stemme.

#Content Warehouse-lekkasjen og datofelt for ferskhet

Hobo går lenger og legger vitneforklaringene over feltnavn fra den lekkede dokumentasjonen til Content Warehouse API: egne datoer for byline, for URL-mønster og et tidsstempel for siste vesentlige oppdatering. Bildet er ryddig, og det er forfatterens slutning. Ingen hos Google har bekreftet at feltene driver ferskhetsrangeringen slik det fremstilles. Vitneforklaringene og de offentlige retningslinjene støtter prinsippet, og historien på feltnivå er en tolkning av en lekkasje.

Det praktiske rådet overlever uten den. En side der datoen flyttet seg mens teksten knapt rørte seg, ser ut for ethvert system som sammenligner versjoner som en side med et løfte den ikke holdt. Enten det er et navngitt felt eller en generell sammenligning, trenger ikke taktikken en lekkasje for å være et dårlig spill.

#Samme lastmod-dato for alle URL-er i sitemapen

24. august 2026 målte vi fem av våre sitemaper i produksjon. I hver hadde alle oppføringer nøyaktig én lastmod-verdi, byggedatoen. Sitemap-integrasjonen regnet ut dagens dato én gang og stemplet alle URL-er med den. Google planlegger nye besøk etter lastmod bare så lenge verdien kan etterprøves som sann. En side der hver URL erklærer en endring ved hver build, lærer roboten å ignorere feltet. De siste crawl-datoene på enkeltsider i utvalget lå mellom tre uker og tre måneder tilbake.

Det er mønsteret dato uten endring, bygd av oss, i full bredde, uten et menneske involvert. Rettelsen henter datoen fra updatedDate, ellers fra pubDate, og fra 29. september får en URL uten kjent innholdsdato ingen lastmod i det hele tatt, fordi en manglende dato er bedre enn en falsk.

Målt i dag har den engelske blogg-sitemapen 329 URL-er med 100 ulike lastmod-datoer. Det er formen til en side som endrer seg til ulike tider. Det er ikke et rent resultat. 130 av URL-ene deler én dag, 22. september, og vi har ikke undersøkt om disse redigeringene la til innhold. Hvis ikke, har vi bygd problemet opp igjen i mindre skala, én redaktør om gangen.

#Sjekk når Google sist leste sitemapen

Et eget punkt for deg som har rettet datoene: en riktig lastmod hjelper ikke før Google har hentet sitemapen på nytt. I Search Console viser sitemap-rapporten siste lesedato og antall URL-er Google så ved den siste lesingen. Når tallet avviker fra antall <loc> i den live filen, er sitemapen utdatert i Googles øyne. Vi har sett sitemaper som ble stående uleste i flere dager mens andre ble lest daglig.

Rekkefølgen vi bruker når en side ikke vises: først siste lesedato og URL-tall i Search Console, deretter robots-meta, canonical og innholdet.

#Hvor lang tid Google bruker på å crawle siden på nytt

På et arrangement i Search Central Live viste Gary Illyes interne tider, som Barry Schwartz omtalte hos Search Engine Roundtable. Oppfriskning av en kjent URL tar typisk omtrent 30 dager, i verste fall uker eller aldri. Behandling av sitemap tar omtrent 24 timer, opptil 14 dager eller aldri. Illyes la til et forbehold:

husk at dette var en øvelse for å se om publikum kjenner seg igjen i tallene vi hentet ut internt og la inn i de lysbildene.

Gary Illyes, Google, Search Engine Roundtable, egen oversettelse

Dette er størrelsesordener, ikke garantier. De endrer likevel hvordan en oppdatering bør vurderes. Redigerer du et innlegg mandag og ser på resultatet onsdag, har du ikke målt noe. Og hvis typisk oppfriskning tar en måned, er en ærlig lastmod den eneste måten å si til Google at denne siden er verdt et tidligere besøk.

#Hva som er en oppdatering i WordPress

WordPress lagrer post_modified ved hver lagring. En skrivefeil, en masseendring av kategorier og en plugin som lagrer innlegg på nytt flytter verdien, og mange SEO-plugins sender den videre til lastmod og til den synlige linjen “sist oppdatert”. Plattformens standard er altså å publisere påstander ingen har kontrollert.

En oppdatering som fortjener ny dato er:

• et tall, en pris eller en versjon som har endret seg, sammen med setningen rundt
• et avsnitt lagt til fordi temaet vokste
• en anbefaling snudd etter nye bevis
• en frist som har passert, med omskrevet tid i teksten

Ikke en oppdatering er:

• ny lagring for å utløse en plugin
• omsortering av avsnitt eller bytte av bilde
• masseredigering av metadata i mange innlegg
• å lese siden på nytt og ikke finne noe å endre

For det siste tilfellet bruker vi et eget felt, lastVerified, atskilt fra updatedDate: en kontroll er et faktum verdt å notere, men ikke en endring av innholdet.

#Når bør du endre oppdateringsdatoen

1. Åpne forrige versjon ved siden av den nåværende. Er forskjellen bare mellomrom, markup eller rekkefølge, stopp.
2. Spør om søket venter noe nytt. Hvis ikke, er en uendret dato ærlig og trygg.
3. Er endringen reell, skriv hva som endret seg, nær toppen eller bunnen, så et menneske ser grunnen og ikke bare datoen.
4. La lastmod følge innholdsdatoen og ingenting annet. Sjekk selve sitemapen, ikke plugin-innstillingene, og tell de ulike verdiene.

Ferskhet fortjenes med en endring en leser eller en robot kan se. En dato kan bare registrere den, og en dato som ikke registrerer noe er det billigste signalet en side kan sende, og det første Google lærer seg å ignorere.

QDF er nytteløst uten en publiseringsvane GEO og LLMO kan stole på: oppdater fakta, behold URL, vis dato.