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.

#Hvor query deserves freshness kommer fra

Navnet er eldre enn både lekkasjen og rettssaken. 3. juni 2007 beskrev Saul Hansell det i The New York Times, i et portrett av Amit Singhal, som avisen kalte mesteren bak Googles rangeringsalgoritme. Ifølge artikkelen hadde Google til da foretrukket sider som var gamle nok til å ha samlet lenker, og Singhal begynte å tvile på balansen da et søk etter Google Finance ikke fant Googles egen nye tjeneste for aksjekurser.

Svaret fra teamet hans, slik Hansell gjengir det, var en matematisk modell som prøver å avgjøre når brukerne vil ha ny informasjon og når de ikke vil. Den het QDF, for query deserves freshness. Den vurderte om et tema var varmt ut fra to signaler: nyhetssider og blogger som skriver aktivt om det, og Googles egen strøm av søk, som Singhal mente var den beste måleren. Eksempelet hans var et strømbrudd i New York, der de første artiklene kommer etter 15 minutter og søkene etter to sekunder.

To detaljer fra 2007 betyr fortsatt noe. Singhal forklarte kollegene at det å bare endre formlene for å vise flere nye sider som oftest ga dårligere resultater, så ferskhet var aldri ment som en generell forkjærlighet for nye sider. Og utløseren var etterspørselen rundt et tema, ikke alderen på én side. Et WordPress-innlegg gjør ikke søket sitt varmt ved å endre sin egen dato.

#Hvilke søk Googles ferskhetssystemer gjelder

I dag dokumenterer Google ideen i guiden til rangeringssystemene, i flertall: ulike “query deserves freshness”-systemer laget for å vise ferskere innhold for søk der det er forventet. Guiden gir to eksempler. Den som søker etter en film som nettopp har hatt premiere, vil sannsynligvis ha ferske anmeldelser og ikke artikler fra da innspillingen begynte. Et søk etter “jordskjelv” gir vanligvis stoff om beredskap, men etter et nylig jordskjelv kan nyheter og ferskere innhold dukke opp.

Begge eksemplene beskriver en endring i hva den som søker trenger, utløst av en hendelse utenfor siden. Ingen av dem beskriver en side som ble bedre av å få en ny dato. Det stemmer med kalkunoppskriften i Nayaks vitneforklaring: et system laget for å oppdage etterspørsel etter noe nytt har ingenting å belønne når etterspørselen ikke finnes. For et WordPress-nettsted er det nyttige spørsmålet hvilke av søkene dine som noen gang oppfører seg som “jordskjelv”. For de fleste tjenestesider og veiledninger er svaret ingen, og på de sidene er datoen en logg, ikke en spak.

#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.

Spørsmålet er ikke bare gjengitt av andre. Det står fortsatt i Googles egen guide om å lage nyttig, pålitelig innhold som setter folk først, sist oppdatert 5. oktober 2026, fulgt av et nytt spørsmål rettet mot den samme refleksen på nivå med hele nettstedet:

Legger du til mye nytt innhold eller fjerner mye eldre innhold hovedsakelig fordi du tror det vil hjelpe rangeringen totalt sett ved at nettstedet på en eller annen måte virker “ferskt”? (Nei, det gjør det ikke.)

Google Search Central, Lage nyttig innhold, egen oversettelse

Svaret i parentes er Googles, ikke vårt. Det dekker massepublisering og masseopprydding gjort for å se ferskt ut, som er versjonen av å flytte datoen for et helt nettsted.

#Må tidløst innhold oppdateres

Hobo lister opp flere slettede tweets fra Mueller, og én av dem er nyttig for alle som har veiledninger som ikke trenger å endres. Ifølge Hobo lød den slik:

Hvis innholdet er tidløst, trenger du per definisjon ikke å endre det. Du trenger ikke gjøre noe spesielt. Behold datoene, gjør det fremragende.

John Mueller, Google, Hobo Web, egen oversettelse

Som den forrige tweeten er den bare gjengitt og kan ikke bekreftes. Den stemmer likevel med det Nayak sa om kalkunoppskriften. En stabil veiledning beholder den opprinnelige datoen og har ingen grunn til å miste den. Trangen til å “friske den opp” hvert kvartal kommer av den feilaktige ideen om at Google belønner bevegelse. Google belønner riktig svar på søket, og for mange søk er det svaret allerede skrevet.

#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.

#Hva Google regner som en vesentlig endring for lastmod

Googles dokumentasjon om nettstedskart setter listen i to setninger. Google bruker lastmod-verdien hvis den er konsekvent og etterprøvbart riktig, for eksempel sammenlignet med siste endring av siden, og verdien skal vise dato og klokkeslett for den siste vesentlige oppdateringen. Eksemplene som gis: en endring i hovedinnholdet, de strukturerte dataene eller lenkene på siden regnes som regel som vesentlig, en oppdatering av opphavsrettsdatoen gjør det ikke. Den samme siden sier at Google ignorerer priority og changefreq, så heller ikke de to feltene bærer noe ferskhetssignal.

Definisjonen er snevrere enn det WordPress lagrer som en endring, og videre enn mange redaktører tror. En ny intern lenke eller en rettet dateModified i schemaet teller. Et årstall i bunnteksten som temaet skrur fram, en ny lagring eller en utvidelse som skriver om innlegg ved aktivering, teller ikke. “Etterprøvbart” er ordet som gjør jobben: Google kan sammenligne den oppgitte datoen med det den hentet sist, og stempelet vårt med byggedatoen strøk på den sammenligningen for alle URL-er samtidig.

#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.

#Hvordan Google velger datoen som vises i søkeresultatene

Datoen under et søkeresultat er en annen sak enn lastmod. Googles guide om datoer sier at Google ikke lener seg på én enkelt datofaktor, fordi alle faktorer kan ha feil, og ser på flere for å anslå når en side ble publisert eller vesentlig oppdatert. Det er heller ingen garanti for at noen dato blir vist.

Guiden ber om en dato som er synlig for brukeren, godt plassert og merket med tekst som “Publisert” eller “Sist oppdatert”. I strukturerte data anbefaler den en undertype av CreativeWork, som Article eller BlogPosting, med datePublished og/eller dateModified. Den synlige datoen og den strukturerte verdien skal stemme overens, en oppgitt tidssone skal være riktig, og datoen skal beskrive publiseringen eller oppdateringen av siden, ikke en dato fram i tid eller datoen for en hendelse siden handler om. Hvis Google fortsatt velger feil dato, foreslår guiden å fjerne noen av de andre datoene på siden.

For WordPress betyr det at tre steder bærer den samme påstanden: den synlige linjen “sist oppdatert”, dateModified i schemaet fra SEO-utvidelsen og lastmod i nettstedskartet. Hvis ett av dem flytter seg ved hver lagring og de andre ikke gjør det, motsier siden seg selv. Hvis alle tre flytter seg ved hver lagring, er siden konsistent og fortsatt feil. Løsningen er den samme som vi brukte på nettstedskartet: én innholdsdato, som bare endres av en redaktør som har endret innholdet, og alle utdata leser den datoen.

#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.