Ferskhetsstempel: Regler for publiserings- og oppdateringsdatoer

Et ferskhetsstempel forteller leserne når en side først ble offentliggjort, når informasjonen de stoler på sist ble endret, og — der det er nyttig — hva som ble sjekket. Det er et åpningselement fordi tid kan endre hvordan enhver påstand nedenfor skal tolkes.

Oppdatert 27. august 2026 · Publisert 14. mars 2025 · Priser og funksjonstilgjengelighet verifisert

Det gjengitte eksemplet gir tre forskjellige påstander. «Publisert» bevarer opprinnelse, «Oppdatert» registrerer en innholdsmessig endring, og omfangsfrasen sier hva gjennomgangen dekket. Datoen er et opprinnelsessignal, ikke en dekorasjon eller en snarvei for å få gammelt innhold til å se nytt ut.

Hvorfor dette elementet er viktig

Lesere bruker datoer for å vurdere risiko. En tre år gammel forklaring av et matematisk konsept kan være helt pålitelig, mens en tre måneder gammel sammenligning av programvarepriser allerede kan være feil. Et synlig stempel hjelper en leser med å avgjøre om de skal stole på siden, verifisere en ustabil påstand eller lete etter en nyere kilde. Å vise begge datoene beskytter også historikken: leseren kan se at en moden ressurs ble vedlikeholdt i stedet for å bli falskt presentert som nylig publisert.

Psykologien svikter når etiketten overdriver. «Oppdatert i dag» innebærer at noen endret informasjon en leser stoler på. Hvis den eneste handlingen var å endre datoen, rette tegnsetting eller flytte siden inn i en ny mal, skaper etiketten tillit uten å fortjene den. Å endre en oppdateringsdato uten å gjøre innholdsmessige endringer er et policybrudd, selv om et innholdsstyringssystem gjør redigeringen enkel.

Maskinuttrekkbarhet betyr at programvare kan identifisere publiseringstidspunkt, endringstidspunkt, gjennomgangsomfang og forholdet mellom dem uten å gjette ut fra prosa. Stabile felt kan mate side-maler, strømmer, revisjoner og strukturerte data. En nettsøker kan skille datePublished fra dateModified; en redaksjonell overvåker kan identifisere volatile sider hvis gjennomgangsvindu er utløpt. En vag setning som «nylig oppfrisket» gir verken et brukbart tidsstempel eller en etterprøvbar påstand.

Det typede elementet har forrang over en dato som er skrevet inn i vanlig prosa. Følg skrivereglene for elementer : komponenten må lese kanoniske datofelt og gjengi dem konsekvent. Forfattere må ikke manuelt skrive inn en ny dato som kan avvike fra metadataene.

Når du skal bruke det

Bruk et ferskhetsstempel når alder i vesentlig grad endrer om siden er trygg, nøyaktig eller nyttig. Vanlige triggere er priser, produktfunksjoner, tilgjengelighet, lover, standarder, statistikk, rangerte anbefalinger, kompatibilitetsinstruksjoner, kvalifikasjonsregler, tidsplaner og navngitte personer. Disse faktaene forfaller fordi verden endrer seg, selv når prosaen ikke gjør det.

Bruk det på en levende ressurs når utgiveren forplikter seg til å revurdere definerte påstander. En programvaresammenligning kan si «Prisplaner og funksjonsbegrensninger verifisert»; dokumentasjon kan si «Verifisert for versjon 6.8»; en regulatorisk forklaring kan navngi jurisdiksjonen og gjeldende regel. Omfanget forhindrer at en nylig sjekk av én tabell innebærer at hver setning, lenke og konklusjon fikk like mye gransking.

Eviggrønt innhold trenger kanskje ikke et synlig ferskhetsstempel. En stabil definisjon, historisk redegjørelse, avgrenset casestudie, versjonsmerknad eller forskningsrapport knyttet til et lukket datasett trenger ofte bare en ærlig publiseringsdato. Legg til korreksjonsnotater eller en separat endringslogg når tolkningen endres, men lag ikke et vedlikeholdsteater der en uforanderlig registrering får en ny dato hvert kvartal.

Nære bommerter inkluderer:

• Automatiske gjeldende datoer: å gjengi dagens dato ved hver forespørsel sier ingenting om gjennomgangsaktivitet og er alltid forbudt.
• Et år i tittelen: «Beste verktøy 2026» er en påstand om aktuell dekning, ikke bevis på at siden ble sjekket i 2026.
• Et byggetidsstempel: å bygge om nettstedet endrer filer, ikke redaksjonelt innhold.
• Et gjennomgangsmerke uten omfang eller eier: det skaper autoritet uten en etterprøvbar handling.
• En endret produktstrøm: automatiske prisoppdateringer kan oppdatere et spesifikt felt, men de rettferdiggjør ikke å merke den omkringliggende redaksjonelle analysen som oppdatert med mindre konklusjonen ble dobbeltsjekket.

Hvor du skal plassere det

Plasser stempelet i heltens metadatarad: under H1 og én-linjers beskrivelse, og før introduksjonen eller det første direkte-svar-elementet. Leseren bør få tidskonteksten før de møter påstander som kan forfalle. På en lang side kan stempelet også vises ved siden av en stabil tabell eller et bevisblokk når denne blokken har sin egen smalere verifikasjonsdato.

Hold forfatterskap og gjennomgangsidentitet i samme opprinnelsesregion når malen støtter det, men bevar en klar leserekkefølge: forfatter, publiserings-/oppdateringsdatoer, deretter gjennomgangsomfang. Stempelet kan stå ved siden av et estimat for lesetid fordi begge er nøytrale metadata. Det må ikke stå ved siden av et reklameringsmerke, nedtellingsklokke for rabatt, «trender»-etikett eller stjernevurdering; disse signalene kan få en redaksjonell dato til å se ut som haster eller godkjenning.

Ikke plasser stempelet inne i introduksjonen, etter den første ustabile påstanden, kun i bunnteksten eller inne i et bilde. Ikke gjenta motstridende datoer i helten, sidefeltet og tabellen. Hvis en seksjon har sin egen datovintage, merk den verdien «Data frem til juni 2026» eller «Priser sjekket 27. august 2026» i stedet for å endre oppdateringsdatoen på sidenivå.

Anatomi

1. Primæretikett: «Oppdatert» når en gyldig endring finnes; ellers «Publisert.» Det må være synlig tekst, ikke et ikon eller verktøytips.
2. Primærdato: En menneskelesbar kalenderdato avledet fra kanoniske metadata.
3. Opprinnelig publisering: Beholdes når primæretiketten er «Oppdatert» og opprinnelse har nytte av å vise begge.
4. Gjennomgangsomfang: Valgfri kort tekst som navngir faktaene, versjonen, jurisdiksjonen eller datasettet som faktisk ble sjekket.
5. Maskintidsstempel: En full ISO 8601-verdi i HTML-attributtet datetime, inkludert tidssone der tid er lagret.
6. Dokumentrelasjon: Elementet tilhører sidehelten; en smalere bevisdato tilhører beviset den kvalifiserer.

Farge, ikon, avstand og skilletegn tilhører gjengiveren. Den semantiske sekvensen må fortsatt leses riktig når CSS ikke er tilgjengelig.

Designeksempler

De støttede variantene gjenspeiler forskjellige redaksjonelle tilstander, ikke kosmetiske preferanser.

Kun publisert: Bruk for en ny side eller en stabil side som aldri har fått en innholdsmessig revisjon. Dette er standard.

Publisert og oppdatert: Bruk etter en innholdsmessig revisjon. Oppdatert kommer først fordi det er den beslutningsrelevante datoen; publisering forblir tilgjengelig som historikk.

Avgrenset verifikasjon: Legg til et kort omfang når kun definerte ustabile påstander ble dobbeltsjekket eller når siden er versjonsbundet. Omfanget må ikke antyde en bredere revisjon.

Gjennomgått uten endring: Bruk kun når en reell gjennomgang fant at siden fortsatt var nøyaktig. Registrer reviewedAt separat; ikke endre dateModified og ikke merk hendelsen som «Oppdatert.»

Smalt visningsområde: Tillat naturlig linjebryting mellom fullstendige elementer. Forkort aldri en dato eller skjul «Publisert» mens du lar et umerket tall stå igjen.

Parametere

Datofeltene er metadataattributter, ikke forfattet brødtekst. Dette forhindrer at en synlig etikett er uenig med strømmer eller skjema. Frontmatter-spesifikasjonen er fortsatt autoritativ for dokumentnivåverdier.

Elementet har ingen brødtekst og ingen første-overskrift-tilordning. En brødtekst ville la forfattere duplisere kanoniske metadata. Omfanget er bevisst et attributt fordi det er kort, stabilt og maskinlesbart.

Syntaks og kodeeksempler

Alle adaptere leser de samme publiserings-, endrings- og omfangsverdiene. De kan formatere datoer for lokale, men de må ikke endre betydningen.

Bærbar Markdown-direktiv

:::freshness-stamp{published="2025-03-14T09:00:00+01:00" updated="2026-08-27T10:00:00+02:00" scope="Pricing and feature availability verified"}
:::

Hugo shortcode-kontrakt

{{< freshness-stamp published="2025-03-14T09:00:00+01:00" updated="2026-08-27T10:00:00+02:00" scope="Pricing and feature availability verified" >}}

I Hugo bør den foretrukne produksjonsadapteren lese .Date og den godkjente updated-parameteren fra sidemetadata slik at forfattere ikke gjentar dem. De eksplisitte verdiene ovenfor dokumenterer den bærbare felttilordningen; de er ikke tillatelse til å hardkode en annen sannhetskilde.

WordPress-blokk

<!-- wp:amicited/freshness-stamp {"published":"2025-03-14T09:00:00+01:00","updated":"2026-08-27T10:00:00+02:00","scope":"Pricing and feature availability verified"} /-->

En WordPress-adapter bør som standard hente published og updated fra innleggsposten, eksponere omfang som et redaksjonelt felt, og forhindre at en kun-dato-oppdateringsarbeidsflyt stille presenterer en revisjon som ikke fant sted.

Eksempler

Oppdatert 27. august 2026 · Publisert 14. mars 2025
Priser, prisplangrenser og funksjonstilgjengelighet verifisert mot leverandørsider.

Dette er bra fordi etikettene bevarer begge hendelsene, omfanget navngir de ustabile faktaene, og påstanden kan etterprøves mot sidens redigerings- og kildehistorikk. En gjennomgangsperson vet hva «oppdatert» betyr her.

Nylig oppdatert i dag!
Opprinnelig publisert nylig.

Dette er dårlig fordi «i dag» flytter seg uten noen redaksjonell hendelse, «nylig» er reklamerende, «nylig» sletter historikk, og ingen av linjene eksponerer et maskinlesbart tidsstempel. Hvis siden bare ble omformatert, ville selv å erstatte disse frasene med eksakte datoer forbli villedende. Den korrekte handlingen er å beholde den opprinnelige publiseringsdatoen og utelate en oppdateringsdato.

Skjemamerking og tilgjengelighet

Stempelet kan mate datePublished og dateModified på en omsluttende Article, TechArticle, NewsArticle eller annen sannferdig sidetype. datePublished kommer fra den opprinnelige publiseringsposten. dateModified kommer kun fra den siste innholdsmessige endringen. En separat registrert gjennomgang som ikke endrer noe, må ikke overskrive dateModified; skjema bør ikke gjøre en gjennomgangshendelse til en falsk endring.

Ikke oppfinn en FreshnessStamp Schema.org-type. Gjennomgangsomfang forblir vanligvis synlig tekst og interne revisjonsmetadata. Hvis en side siterer ustabile fakta, hold bevisene deres i en kilder-blokk i stedet for å antyde at en ny dato beviser dem.

Gjengi hver dato med et semantisk <time datetime="…">-element. Den synlige formen følger sidens lokale; datetime-verdien bevarer et utvetydig maskintidsstempel. Etiketter må være tekst. Ikke stol på et klokkeikon, grønn farge, verktøytips eller relativt ordvalg som «to måneder siden.» Skilletegn merket som dekorative bør ignoreres av hjelpeteknologi, og linjebryting må bevare en logisk leserekkefølge.

Stempelet er statiske metadata, så det trenger ikke noe ARIA live-region, knapperolle, fokusmål eller kunngjøring. Hvis en endringslogg er lenket, bruk en beskrivende etikett som «Se hva som endret seg,» ikke «Mer.»

Skriveregler

Skriv etiketter som faktisk opprinnelse: «Publisert,» «Oppdatert» eller «Gjennomgått.» Bruk en absolutt lokalisert dato, ikke «i dag,» «nylig,» «ny» eller «fersk.» Hold omfanget til 3–12 ord og navngi det sjekkede objektet: «Prisplaner og grenser verifisert» er sterkere enn «Innhold gjennomgått.» Ikke legg til utropstegn, hastverk, SEO-påstander eller løfter om at siden er fullstendig nøyaktig.

En innholdsmessig endring tilbakestiller updated kun når den forbedrer informasjon en leser stoler på. Legitime triggere inkluderer å korrigere et vesentlig faktum, erstatte utdaterte priser eller spesifikasjoner, revidere instruksjoner etter en produktendring, legge til betydelig bevis, endre en anbefaling etter ny vurdering, utvide omfanget nok til å endre svaret, eller fullføre en dokumentert gjennomgang som resulterer i meningsfulle innholdsendringer.

Følgende tilbakestiller det ikke: retting av skrivefeil, tegnsetting, formatering, bildekomprimering, CSS- eller malendringer, analysesporing, lenkesporing, metadata-ene redigeringer, automatiske bygg, kategoriendringer, forfatterprofilformatering, eller bare å sjekke siden og finne at ingen endring var nødvendig. En erstatning av ødelagt lenke tilbakestiller datoen kun når destinasjonen endrer beviset eller veiledningen; å bytte til en tilsvarende fungerende URL gjør det ikke.

Sett aldri en påstand som «Google belønner friskt innhold,» en reklamerende melding, rabattutløp, lesetid, forfatterbiografi, kildeliste, endringslogg eller full gjennomgangsmetodikk inne i stempelet. Disse har forskjellige formål. Aldri etterdater en oppdatering, overskriv publiseringsdatoen, utled endringstid fra depotet, eller planlegg en fremtidig oppdateringsdato.

Innleggstyper som bruker det

postTypes frontmatter er kilden til denne tilordningen. Inkludering betyr at formatet har en gjentakende forfallsrisiko; det betyr ikke at hver forekomst må vise en oppdateringsdato.

Stabile ordliste-definisjoner, historiske opptegnelser, forskning med lukkede datasett og versjonsmerknader beholder vanligvis publiseringsdatoer uten å hevde kontinuerlig ferskhet. Deres bevisperiode eller utgivelsesversjon gjør mer tolkningsarbeid enn en rullerende «oppdatert»-etikett.

QA-sjekkliste

• Den opprinnelige publiseringsdatoen er bevart og går forut for eller er lik hver senere hendelse.
• updated tilsvarer en innholdsmessig endring synlig i innholdet eller dokumentert bevis.
• En gjennomgang uten innholdsendring bruker reviewedAt, ikke updated eller dateModified.
• Den synlige datoen, frontmatter-verdien, strømmeverdien og strukturert-datoverdien er enige.
• Omfanget navngir nøyaktig hva som ble sjekket og innebærer ikke en helside-revisjon når kun én blokk ble endret.
• Stempelet vises i helten før ustabile påstander, med smalere datoer ved siden av smalere bevis.
• Absolutte datoer og synlige teksteetiketter forblir forståelige uten farge, ikoner, CSS eller omkringliggende prosa.
• Hvert maskintidsstempel bruker gyldig ISO 8601-syntaks og riktig tidssone.
• Ingen byggetid, filendringstid, gjeldende-år-token eller automatisk flyttende dato mater elementet.
• Redigeringshistorikken kan forklare hvorfor datoen endret seg; en kun-dato-redigering strøk ikke gjennomgang.
• Publiserte, oppdaterte og gjennomgåtte hendelser forblir distinkte i synlig kopi og skjema.
• Sidens innleggstype og forfallsrisiko rettferdiggjør visning av elementet.

FAQ

Bør hver artikkel vise en sist-oppdatert-dato?

Nei. Vis en oppdateringsdato kun etter en innholdsmessig endring. En stabil eviggrønn side kan vise publiseringsdatoen alene, mens en side som forfaller bør vise datoen og omfanget av sin siste gyldige gjennomgang.

Rettferdiggjør retting av en skrivefeil endring av oppdateringsdatoen?

Nei. Typografiske, formaterings-, sporings-, mal- og metadata-ene redigeringer endrer ikke informasjonen en leser stoler på, og tilbakestiller derfor ikke oppdateringsdatoen.

Kan en side vise en gjennomgått-dato når ingen endringer var nødvendige?

Ja, hvis en kvalifisert person faktisk sjekket det definerte omfanget og etiketten sier «Gjennomgått,» ikke «Oppdatert.» Hold publiserings- og endringsdatoene uendret, og registrer gjennomgangen separat.

Bør publiseringsdatoen forsvinne etter en oppdatering?

Vanligvis nei. Behold den opprinnelige publiseringsdatoen i metadata og vis den ved siden av oppdateringsdatoen når opprinnelse er viktig. Oppdateringsdatoen må aldri omskrive sidens historie.

Forbedrer et ferskhetsstempel rangeringer av seg selv?

Nei. En datoetikett er ikke bevis på at siden er nøyaktig. Verdien kommer fra sannferdig vedlikehold, konsistent metadata og innhold som faktisk gjenspeiler den oppgitte gjennomgangen.