Opdateringslog: Vis hvad der ændrede sig og hvornår

En opdateringslog er en dateret registrering af substantielle sidesændringer: hvad der ændrede sig, hvorfor, og om svaret, anbefalingen eller evidensen flyttede sig.

Opdateringslog

27. august 2026 — Priser og anbefaling opdateret
Erstattede den udgåede Starter-plan med den nuværende Essentials-plan, opdaterede sammenligningstabellen og ændrede anbefalingen for teams der har brug for revisions-eksport. Kilder blev genkontrolleret mod leverandørens plandokumentation.

12. maj 2026 — Evidens opfrisket; konklusion uændret
Erstattede to forældede funktionsreferencer og verificerede de resterende plangrænser. Den anbefalede mulighed ændrede sig ikke.

Hver dato er knyttet til en inspicerbar hændelse. En bar “Opdateret 27. august 2026” er uforklaret; loggen afslører arbejdets omfang og konsekvens.

Hvorfor dette element er vigtigt

Læsere behandler ikke alle ændringer ens. At rette en forkert stavet overskrift er ikke det samme som at ændre en anbefaling, erstatte et datasæt eller rette en usikker instruktion. En enkelt opdateret dato slår disse hændelser sammen til samme signal. På sider der bruges til at bruge penge, følge en procedure, fortolke forskning eller forstå en politik, har læsere brug for at vide om det afsnit, de stoler på, er ændret.

En opdateringslog bevarer historikken uden at tvinge læsere til at sammenligne cachelagrede kopier. Den besvarer fire spørgsmål: Blev siden vedligeholdt? Påvirkede ændringen mig? Blev en fejl rettet åbent? Er konklusionen stadig underbygget? Klare svar skaber ansvarlighed og forhindrer falsk friskhed fra en dato fremrykket uden meningsfuldt arbejde.

Rapportér konsekvens, ikke aktivitet. “Opdaterede links” beskriver en handling. “Erstattede den tilbagetrukne kilde for 2024-markedstallet; værdien og konklusionen er uændret” fortæller læserne hvad der stadig er troværdigt. Hvis en konklusion flyttede sig, sig det klart.

Maskinel udtrækning betyder at software kan opdele hver hændelse i en dato, type, resume, detalje, berørt afsnit og evidensreference. Stabile felter lader revisioner finde rettelser, lader agenter forklare ændrede anbefalinger og lader migrationer bevare historikken. Inkonsekvent prosa tvinger software til at gætte hvor hændelser begynder og slutter.

Elementets typedefinerede formål har derfor forrang over en visuelt lignende tidslinje eller punktopstilling. Følg elementets skriveregler : når indholdet registrerer revisioner af den aktuelle side, kod det som en opdateringslog. Gengiveren kan bruge en liste, kort eller et udvidbart arkiv, men de kanoniske hændelsesfelter skal overleve enhver præsentation.

Hvornår skal det bruges

Brug en opdateringslog når læsere kan have brug for at sammenligne den aktuelle og en tidligere version af siden. Udløsere inkluderer en ændret anbefaling, korrigeret faktum, revideret metode, erstattet datasæt, ændret beregning, ny version, ændret berettigelse, opdateret prismodel, modificerede instruktioner eller arkiveret mulighed.

Elementet er mest værdifuldt når autoritet akkumuleres over tid. Forskning kan modtage en korrigeret nævner; dokumentation kan understøtte et nyt interface; en reguleringsforklaring kan skelne mellem en ændring og en redaktionel præcisering. Stille omskrivning ville ødelægge historik som en tilbagevendende læser har brug for.

Brug en gennemgangspost sparsomt når en afgrænset gennemgang ikke fandt nogen ændring. Mærk den “Gennemgået”, angiv hvad der blev kontrolleret, og sig at konklusionen er uændret. Dette passer til volatile statistikker, priser, produktkapaciteter eller regler; det er ikke tilladelse til at fremstille aktivitet.

Næsten-ramte tilfælde kræver en anden behandling:

• En offentliggørelses- eller ændringsdato: brug et friskhedsstempel for at afsløre kanoniske sidedatoer. Stemplet og loggen kan arbejde sammen, men den ene kan ikke erstatte den anden.
• Produktudgivelseshistorie eller projekt-tidslinje: disse beskriver ændringer i emnet. En opdateringslog registrerer redaktionelle ændringer af den aktuelle side.
• Versionskontrol-output: commit-beskeder indeholder implementeringsstøj, interne identifikatorer og sikkerhedsfølsomme detaljer. De er ikke læservendte redaktionelle registreringer.
• En kildeliste: en kildeblok beviser hvor påstande kom fra. Opdateringsloggen siger hvornår og hvorfor disse kilder eller påstande ændrede sig.
• Mindre vedligeholdelse: log ikke stavefejl, tegnsætning, formatering, billedkomprimering, analyse, sporingsparametre eller en skabelonmigration, medmindre ændringen ændrede betydning eller tilgængelighed.

En side uden substantiel revision har brug for en offentliggørelsesdato, ikke et tomt panel eller fiktiv historik.

Hvor skal den placeres

Placer hele loggen efter svaret, evidensen, konklusionerne og kilderne, men før relateret indhold, nyhedsbrevstilmelding eller det afsluttende call-to-action. Læsere har først brug for den aktuelle side, derefter dens historik. På forsknings-, statistik- og politiksider følger loggen typisk efter kilder eller metode.

Hvis den seneste ændring påvirker hvordan siden skal læses, tilføj “Se hvad der ændrede sig” ved hoveddatoen og spring til hele loggen. Dupliker ikke posten der. En korrektion der påvirker sikkerhed, penge, berettigelse eller konklusionen har også brug for en meddelelse ved siden af den korrigerede påstand.

Loggen kan dele et vedligeholdelsesområde med forfatterskab når begge forbliver adskilte. Den må ikke placeres ved siden af en købsknap, tidsbegrænset tilbud, nedtælling, bedømmelse, udtalelse eller reklamemærke; det gør historik til hastværk eller underforstået godkendelse. Sammensmelt den ikke med kildeblokken: grunden til at en kilde ændrede sig er redaktionel historik, ikke en citation.

Behold én kanonisk log. En sidebjælke må linke til den, ikke duplikere den. Efter fem poster vises de seneste tre til fem og resten afsløres via “Se tidligere opdateringer.” Behold hele historikken på siden eller i et stabilt styret arkiv.

Anatomi

1. Elementtitel: Bruger “Opdateringslog”, “Revisionshistorik” eller en snævrere godkendt etiket der forbliver tydelig uden for sidedesignet.
2. Hændelsesdato: Viser en absolut kalenderdato og eksponerer samme værdi som et ISO 8601 maskintidsstempel.
3. Hændelsestype: Skelner mellem opdateret, korrigeret, gennemgået, metode-ændret og arkiveret uden at stole på farver.
4. Resumé: Navngiver det ændrede objekt og resultat i én kort linje.
5. Detalje: Forklarer den gamle tilstand, nye tilstand og årsag, når disse fakta hjælper læseren med at fortolke siden.
6. Berørt afsnit: Linker eventuelt til den stabile overskrift eller figur der er ændret, ved hjælp af et fragment der ikke vil blive genbrugt.
7. Konsekvens: Angiver om svaret, konklusionen, anbefalingen, berettigelsen eller instruktionerne ændrede sig.
8. Evidensreference: Peger eventuelt på en kildeidentifikator der allerede er defineret i sidens kildeblok.
9. Arkivkontrol: Afslører tidligere poster uden at slette dem fra dokumentet eller tilgængelighedstræet.

Poster skal forblive forståelige uden styling. Ikoner, linjer og farver må aldrig bære type eller konsekvens alene.

Designeksempler

Varianter afspejler informationsmængde og redaktionel risiko.

Kompakt seneste-ændringsrække

Brug én kompakt række til en enkelt simpel revision. Inkluder dato, type, resume og konsekvens. Brug standardlisten når forklaringen overstiger to sætninger.

Standard revisionsliste

Brug en nyeste-først-liste til to til fem poster, med samme feltordre hele vejen igennem.

Korrektionsledet variant

Ved en væsentlig fejl, mærk “Korrektion”, vis den forkerte og korrigerede tilstand, angiv påvirkning, og link til det berørte afsnit. Fremhæv det uden alarmistisk sprog.

Metode- eller versionsændring

Når et datasæt, en formel, produktversion, jurisdiktion eller metode ændres, vis gamle og nye versioner. Angiv når tidligere resultater ikke længere er sammenlignelige.

Udvidbart arkiv

Efter fem poster, mærk arkivet med dets postantal og datointerval. Bevar overskrifter og listestruktur; gør ikke JavaScript til den eneste måde at nå registreringen på.

Smal visning

Stable dato, type, resume og detalje. Klip aldrig datoer eller skjul konsekvenstekst på mobil.

Parametre

Overordnede felter styrer samlingen; gentagne elementfelter beskriver hver hændelse.

Poster er gentagne elementer, ikke ét HTML-felt. Den overordnedes første overskrift kortlægges til title; hvert elements første overskrift kortlægges til summary, og dens resterende brødtekst kortlægges til detail. Datoer, typer, påvirkning, referencer og versioner forbliver attributter.

impact er påkrævet så læsere ikke skal gætte om svaret flyttede sig. Brug not-applicable kun når materialet ikke har nogen konklusion. En gennemgang uden redigeringer bruger type=reviewed og impact=unchanged.

Syntaks og kodeeksempler

Alle repræsentationer bevarer de samme felter. Kildeidentifikatorer henviser til den kanoniske kildeblok.

Bærbar Markdown-direktiv

:::update-log{order=newest-first visibleItems=3}
## Update log

::item{date="2026-08-27" type=updated impact=changed affectedSection="plans" evidenceRef="vendor-plans"}
### Pricing and recommendation updated

Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
::

:::

Hugo shortcode-kontrakt

{{< update-log title="Update log" order="newest-first" visibleItems="3" >}}
  {{< update-log-item date="2026-08-27" type="updated" impact="changed" affectedSection="plans" evidenceRef="vendor-plans" >}}
  ## Pricing and recommendation updated
  Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
  {{< /update-log-item >}}
{{< /update-log >}}

Dette er en adapterkontrakt, ikke en eksisterende shortcode. Hver parameter er navngivet.

WordPress-blokke

<!-- wp:amicited/update-log {"title":"Update log","order":"newest-first","visibleItems":3} -->
<!-- wp:amicited/update-log-item {"date":"2026-08-27","type":"updated","impact":"changed","affectedSection":"plans","evidenceRef":["vendor-plans"]} -->
<h3>Pricing and recommendation updated</h3>
<p>Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.</p>
<!-- /wp:amicited/update-log-item -->
<!-- /wp:amicited/update-log -->

WordPress bør eksponere strukturerede kontroller for dato, type, påvirkning, afsnit og evidens.

Eksempler

God opdateringspost

18. juli 2026 — Beregning korrigeret
Korrigerede konverteringsrate-nævneren fra alle sessioner til berettigede produktsessioner i tabellen “Kanalperformance”. Værdier for organisk søgning ændrede sig fra 3,1% til 2,4%; rangeringen af kanaler og artiklens konklusion ændrede sig ikke. De underliggende sessionstal blev ikke påvirket.

Dette virker fordi det navngiver fejlen, gamle og nye definitioner, berørt afsnit, numerisk konsekvens og konklusionsstatus. Læsere kan vurdere om tidligere arbejde skal gennemgås.

Dårlig opdateringspost

Sommer 2026 — Fuldstændig opfrisket!
Vi gennemgik denne side og foretog flere forbedringer, så du kan stole på at alt er opdateret.

Dette fejler fordi datoen er vag, “fuldstændig” overvurderer omfang, “flere forbedringer” skjuler fakta, og “stole på” kræver en ufortjent konklusion. Hvis arbejdet var kosmetisk, slet posten. Hvis substantielt, navngiv hver beslutningsrelevant ændring.

Skemamarkering og tilgængelighed

En opdateringslog har ingen selvstændig Schema.org-type. Den forbliver indhold inden for den omsluttende Article, TechArticle eller Report. Den seneste substantielle hændelse kan understøtte dateModified; en gennemgang uden ændring må ikke. Erstat aldrig datePublished.

Kod ikke poster som CreativeWork, Event, HowToStep eller ItemList; disse typer implicerer betydninger som loggen mangler. Brug forudsigelig HTML: et mærket afsnit, listeelementer, overskrifter, <time datetime="2026-08-27">27. august 2026</time> og stabile fragmenter.

Brug ét listeelement pr. hændelse; CSS kan tegne en tidslinje uden at ændre rækkefølge. Angiv at poster er nyeste først. Vis type i tekst, ikke kun farve eller ikoner, og brug beskrivende links.

Et arkiv har brug for en indbygget afsløring mærket med dets antal eller rækkevidde. Alle poster skal være tilgængelige via tastatur og skærmlæser. Brug ikke et ARIA live-region. Bevar overskriftsrækkefølge og lokaliserede datoer.

Placer en korrektionsmeddelelse ved den berørte påstand og registrer den i loggen. Den første beskytter øjeblikkelige læsere; den anden bevarer historikken.

Skriveregler

Indled med det ændrede objekt og et præcist verbum: “Berettigelsesregel præciseret”, “Datasæt erstattet” eller “Formel korrigeret”. Hold resuméer på 4–14 ord og detaljer på 25–90 ord. Brug én sætning til ændring og årsag, en anden til påvirkning. Brug lokaliserede absolutte datoer og nyeste-først-visning.

Forklar årsagen før resultatet. “Leverandøren udfasede Starter, så vi erstattede den med Essentials og revurderede anbefalingen” registrerer årsag; “Vi forbedrede vores sammenligning” registrerer mening. Brug neutral datid.

Hver væsentlig post bør besvare disse spørgsmål:

• Hvilket specifikt faktum, instruktion, metode, kilde, omfang eller konklusion ændrede sig?
• Hvorfor var ændringen nødvendig?
• Hvor på siden fandt den sted?
• Ændrede hovedsvaret, anbefalingen eller konklusionen sig?
• Skal læseren gentage en beslutning eller handling baseret på den tidligere version?

Opret én post pr. redaktionel hændelse, ikke pr. tastetryk. Gruppér relaterede ændringer fra én gennemgang; opdel ikke-relateret arbejde, forskellige påvirkninger eller forskellige datoer. Vis tre til fem og behold væsentlig historik.

Inkluder aldrig fortrolige noter, sikkerhedsdetaljer, sårbarheder, personlige data, skyld, rå commit-hashes, uforklarede tickets, marketing, hastværk eller en bibliografi. Lov aldrig “100% opdateret”, slet ikke rettelser, omskriv ikke poster i stilhed, eller omdatoér ikke kosmetisk arbejde.

Hvis en post har brug for korrektion, bevar dens dato og tilføj en korrektionshændelse. Privatliv, sikkerhed eller juridiske forpligtelser kan retfærdiggøre redigering; angiv at registreringen blev ændret og hvorfor på et passende niveau.

Posttyper der bruger det

postTypes frontmatter-arrayet er kilden til denne tabel. “Påkrævet” betyder at substantiel revisionshistorik er en del af formatets tillidskontrakt; “betinget” betyder at loggen vises når en kvalificerende ændring finder sted.

En ny side har ikke brug for en tom log. Efter en kvalificerende ændring, bevar elementet.

QA-tjekliste

• Hver synlig post repræsenterer en substantiel redaktionel hændelse, ikke en kosmetisk eller automatiseret ændring.
• Hændelsesdatoen er præcis, gyldig, ikke-fremtidig og matcher den godkendte redaktionelle registrering.
• Resuméet navngiver det ændrede objekt og holder sig inden for 4–14 ord.
• Detaljen angiver hvad der ændrede sig og hvorfor, før den beskriver fordel.
• Posten identificerer om svaret, konklusionen, anbefalingen, berettigelsen eller instruktionerne ændrede sig.
• En væsentlig korrektion vises også ved siden af den berørte påstand.
• Afsnitsfragmenter og evidensidentifikatorer opløses til stabile mål på samme kanoniske side.
• Loggen vises efter hovedindholdet og kilderne, men før salgsfremmende afsluttende moduler.
• Loggen er ikke visuelt sammensmeltet med et CTA, tilbud, bedømmelse, udtalelse eller kildeblok.
• Datoer bruger semantiske <time>-værdier; hændelsestyper og påvirkninger er ikke afhængige af farve eller ikoner.
• Arkivkontrollen er tastaturbetjenbar, tydeligt mærket og eksponerer sit fulde indhold til hjælpeteknologi.
• En gennemgangs-post ændrer ikke dateModified; en substantiel seneste hændelse stemmer overens med den kanoniske opdaterede dato.
• Fortrolige noter, personlige data, sikkerhedsdetaljer, rå implementeringshistorik og marketingsprog er fraværende.
• Sidens posttype og læserrisiko retfærdiggør elementet.

FAQ

Hører hver eneste indholdsredigering til i opdateringsloggen?

Nej. Registrer ændringer der ændrer fakta, instruktioner, evidens, omfang, fortolkning, anbefalinger eller en læsers beslutning. Udelad stavefejl, mellemrum, sporing, skabeloner og andre ikke-substantielle redigeringer.

Hvordan adskiller en opdateringslog sig fra en senest-opdateret-dato?

En senest-opdateret-dato siger at en substantiel ændring fandt sted. En opdateringslog angiver hvad der ændrede sig, hvorfor det ændrede sig, og om svaret eller konklusionen flyttede sig, så vedligeholdelsespåstanden kan inspiceres.

Skal den nyeste eller ældste opdatering vises først?

Vis den nyeste post først på en vedligeholdt side, fordi læsere normalt har brug for den aktuelle ændring. Bevar kronologisk rækkefølge i maskinoutput og sørg for et tydeligt mærket arkiv når den synlige liste er forkortet.

Kan en opdateringslog erstatte korrektionsmeddelelser?

Nej. En væsentlig fejl kræver en synlig korrektion ved den berørte påstand samt en permanent logpost. Loggen bevarer historikken; den må ikke skjule en korrektion nederst på siden.

Skal gennemgange uden ændringer vises i loggen?

Kun når gennemgangsstatus er vigtig for læsere, og posten er mærket “Gennemgået”, ikke “Opdateret.” Angiv hvilket omfang der blev kontrolleret, og at der ikke var behov for substantielle ændringer; ændr ikke dateModified.