Ändringslogg: Visa vad som ändrades och när

En ändringslogg är en daterad registrering av sakliga sidändringar: vad som ändrades, varför och om svaret, rekommendationen eller beviset flyttades.

Ändringslogg

27 augusti 2026 — Pris och rekommendation uppdaterad
Ersatte den utgångna Starter-planen med den aktuella Essentials-planen, uppdaterade jämförelsetabellen och ändrade rekommendationen för team som behöver exportfunktioner för granskning. Källor kontrollerades på nytt mot leverantörens plandokumentation.

12 maj 2026 — Bevis uppdaterade; slutsats oförändrad
Ersatte två ersatta funktionsreferenser och verifierade återstående planbegränsningar. Det rekommenderade alternativet ändrades inte.

Varje datum är kopplat till en granskningsbar händelse. Ett bart “Uppdaterad 27 augusti 2026” är oförklarat; loggen exponerar arbetets omfattning och konsekvens.

Varför detta element är viktigt

Läsare behandlar inte alla ändringar lika. Att rätta en felstavad rubrik är inte samma sak som att ändra en rekommendation, ersätta en datamängd eller fixa en osäker instruktion. Ett enda uppdateringsdatum slår samman dessa händelser till samma signal. På sidor som används för att spendera pengar, följa en procedur, tolka forskning eller förstå en policy, behöver läsare veta om det avsnitt de förlitar sig på har ändrats.

En ändringslogg bevarar historik utan att tvinga läsare att jämföra cachade kopior. Den besvarar fyra frågor: Underhålls sidan? Påverkade ändringen mig? Rättades ett fel öppet? Stöds slutsatsen fortfarande? Tydliga svar skapar ansvarstagande och förhindrar falsk färskhet från ett datum som flyttats fram utan meningsfullt arbete.

Rapportera konsekvens, inte aktivitet. “Uppdaterade länkar” beskriver en handling. “Ersatte den indragna källan för 2024 års marknadssumma; värdet och slutsatsen är oförändrade” berättar för läsarna vad som fortfarande är pålitligt. Om en slutsats flyttades, säg det rakt ut.

Maskinell extraherbarhet innebär att programvara kan separera varje händelse i ett datum, typ, sammanfattning, detalj, påverkat avsnitt och bevisreferens. Stabila fält låter revisioner hitta rättelser, låter agenter förklara ändrade rekommendationer och låter migreringar bevara historik. Inkonsekvent prosa tvingar programvara att gissa var händelser börjar och slutar.

Elementets typade syfte har därför företräde framför en visuellt liknande tidslinje eller punktlista. Följ skrivreglerna för element : när innehållet registrerar revisioner på den aktuella sidan, koda det som en ändringslogg. Renderaren kan använda en lista, kort eller ett utbyggbart arkiv, men de kanoniska händelsefälten måste överleva varje presentation.

När ska det användas

Använd en ändringslogg när läsare kan behöva jämföra den aktuella och tidigare sidan. Utlösare inkluderar en ändrad rekommendation, korrigerat faktum, reviderad metod, ersatt datamängd, ändrad beräkning, ny version, ändrad behörighet, uppdaterad prismodell, modifierade instruktioner eller arkiverat alternativ.

Elementet är mest värdefullt när auktoritet ackumuleras över tid. Forskning kan få en korrigerad nämnare; dokumentation kan stödja ett nytt gränssnitt; en regulatorisk förklaring kan skilja ett tillägg från redaktionellt förtydligande. Tyst omskrivning skulle förstöra historik som en återvändande läsare behöver.

Använd en granskningspost sparsamt när en avgränsad granskning inte fann någon ändring. Märk den “Granskad”, ange vad som kontrollerades och säg att slutsatsen är oförändrad. Detta passar för volatil statistik, priser, produktkapaciteter eller regler; det är inte tillstånd att fabricera aktivitet.

Nära-miss-fall behöver en annan behandling:

• Ett publicerings- eller ändringsdatum: använd en färskhetsstämpel för att exponera kanoniska siddatum. Stämpeln och loggen kan fungera tillsammans, men den ena kan inte ersätta den andra.
• Produktversionshistorik eller projekttidslinje: dessa beskriver ändringar i ämnet. En ändringslogg registrerar redaktionella ändringar på den aktuella sidan.
• Versionshanteringsutdata: commit-meddelanden innehåller implementationsbrus, interna identifierare och säkerhetskänsliga detaljer. De är inte läsarriktade redaktionella register.
• En källista: ett källblock bevisar var påståenden kom ifrån. Ändringsloggen anger när och varför dessa källor eller påståenden ändrades.
• Mindre underhåll: logga inte stavning, interpunktion, formatering, bildkomprimering, analys, spårningsparametrar eller en mallmigrering om inte ändringen påverkade innebörd eller tillgänglighet.

En sida utan saklig revision behöver ett publiceringsdatum, inte en tom panel eller fiktiv historik.

Var ska den placeras

Placera hela loggen efter svaret, bevisen, slutsatserna och källorna, men före relaterat innehåll, nyhetsbrevsfångst eller den avslutande uppmaningen. Läsare behöver först den aktuella sidan, sedan dess historik. På forsknings-, statistik- och policysidor följer loggen vanligtvis efter källor eller metodik.

Om den senaste ändringen påverkar hur sidan bör läsas, lägg till “Se vad som ändrades” bredvid datumet och hoppa till hela loggen. Duplicera inte posten där. En rättelse som påverkar säkerhet, pengar, behörighet eller slutsatsen behöver också ett meddelande bredvid det korrigerade påståendet.

Loggen kan dela ett underhållsområde med författarskap när båda förblir åtskilda. Den får inte placeras bredvid en köpknapp, tidsbegränsat erbjudande, nedräkning, betyg, vittnesmål eller reklammärke; det skulle förvandla historik till brådskande eller underförstått stöd. Slå inte samman den med källblocket: anledningen till att en källa ändrades är redaktionell historik, inte en citation.

Ha en kanonisk logg. En sidofält kan länka till den, inte duplicera den. Efter fem poster, visa de senaste tre till fem och exponera resten genom “Visa tidigare uppdateringar.” Behåll hela historiken på sidan eller ett stabilt förvaltat arkiv.

Anatomi

1. Elementtitel: Använder “Ändringslogg”, “Revisionshistorik” eller en snävare godkänd etikett som förblir tydlig utanför sidans design.
2. Händelsedatum: Visar ett absolut kalenderdatum och exponerar samma värde som en ISO 8601-maskintidsstämpel.
3. Händelsetyp: Skiljer mellan updated, corrected, reviewed, method-changed och archived utan att förlita sig på färg.
4. Sammanfattning: Namnger det ändrade objektet och resultatet i en kort rad.
5. Detalj: Förklarar det gamla tillståndet, det nya tillståndet och anledningen när dessa fakta hjälper läsaren att tolka sidan.
6. Påverkat avsnitt: Länkar eventuellt till den stabila rubriken eller figuren som ändrats, med ett fragment som inte kommer att återanvändas.
7. Konsekvens: Anger om svaret, slutsatsen, rekommendationen, behörigheten eller instruktionerna ändrades.
8. Bevisreferens: Pekar eventuellt på en källidentifierare som redan definierats i sidans källblock.
9. Arkivkontroll: Visar tidigare poster utan att ta bort dem från dokumentet eller tillgänglighetsträdet.

Poster måste förbli begripliga utan formatering. Ikoner, linjer och färger får aldrig bära typ eller konsekvens ensamma.

Designexempel

Varianter speglar informationsdensitet och redaktionell risk.

Kompakt rad för senaste ändring

Använd en kompakt rad för en enda enkel revision. Inkludera datum, typ, sammanfattning och konsekvens. Använd standardlistan när förklaringen överstiger två meningar.

Standard revisionslista

Använd en lista med nyast först för två till fem poster, med samma fältordning genomgående.

Rättelsestyrd variant

För ett väsentligt fel, märk “Rättelse”, visa det felaktiga och korrigerade tillståndet, ange påverkan och länka till det påverkade avsnittet. Betona det utan alarmistiskt språk.

Metod- eller versionsändring

När en datamängd, formel, produktversion, jurisdiktion eller metod ändras, visa gamla och nya versioner. Ange när tidigare resultat inte längre är jämförbara.

Utbyggbart arkiv

Efter fem poster, märk arkivet med dess postantal och datumintervall. Behåll rubriker och liststruktur; gör inte JavaScript till enda sättet att nå registret.

Smal visningsyta

Stapla datum, typ, sammanfattning och detalj. Klipp aldrig datum eller dölj konsekvenstext på mobil.

Parametrar

Moderfält styr samlingen; upprepade objektfält beskriver varje händelse.

Poster är upprepade objekt, inte ett HTML-fält. Moderns första rubrik mappas till title; varje objekts första rubrik mappas till summary, och dess återstående brödtext mappas till detail. Datum, typer, påverkan, referenser och versioner förblir attribut.

impact krävs så att läsare inte behöver gissa om svaret flyttades. Använd not-applicable endast när materialet saknar slutsats. En granskning utan redigeringar använder type=reviewed och impact=unchanged.

Syntax och kodexempel

Alla representationer bevarar samma fält. Källidentifierare hänvisar till det kanoniska källblocket.

Portabel 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 >}}

Detta är ett adapterkontrakt, inte en befintlig shortcode. Varje parameter är namngiven.

WordPress-block

<!-- 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 exponera strukturerade kontroller för datum, typ, påverkan, avsnitt och bevis.

Exempel

Bra uppdateringspost

18 juli 2026 — Beräkning korrigerad
Korrigerade konverteringsfrekvensens nämnare från alla sessioner till berättigade produktsessioner i tabellen “Kanalprestanda”. Värden för organisk sökning ändrades från 3,1 % till 2,4 %; rangordningen av kanaler och artikelns slutsats ändrades inte. De underliggande sessionsräkningarna påverkades inte.

Detta fungerar eftersom det anger felet, gamla och nya definitioner, påverkat avsnitt, numerisk konsekvens och slutsatsstatus. Läsare kan bedöma om tidigare arbete behöver granskas.

Dålig uppdateringspost

Sommaren 2026 — Helt uppfräschad!
Vi granskade denna sida och gjorde flera förbättringar så att du kan lita på att allt är aktuellt.

Detta misslyckas eftersom datumet är vagt, “helt” överdriver omfattningen, “flera förbättringar” döljer fakta och “lita på” kräver en oförtjänt slutsats. Om arbetet var kosmetiskt, ta bort posten. Om det var sakligt, namnge varje beslutsrelevant ändring.

Schema-märkning och tillgänglighet

En ändringslogg har ingen fristående Schema.org-typ. Den förblir innehåll inom den omslutande Article, TechArticle eller Report. Den nyaste sakliga händelsen kan stödja dateModified; en granskning utan ändring får inte göra det. Ersätt aldrig datePublished.

Koda inte poster som CreativeWork, Event, HowToStep eller ItemList; dessa typer innebär betydelser som loggen saknar. Använd förutsägbar HTML: en märkt sektion, listobjekt, rubriker, <time datetime="2026-08-27">27 augusti 2026</time> och stabila fragment.

Använd ett listobjekt per händelse; CSS kan rita en tidslinje utan att ändra ordning. Ange att poster är nyast först. Visa typ i text, inte bara färg eller ikoner, och använd beskrivande länkar.

Ett arkiv behöver en inbyggd utvikning märkt med dess antal eller intervall. Alla poster måste vara nåbara via tangentbord och skärmläsare. Använd inte ett ARIA live-område. Bevara rubrikordning och lokaliserade datum.

Placera en rättelseanmärkning vid det påverkade påståendet och registrera den i loggen. Det första skyddar omedelbara läsare; det andra bevarar historik.

Skrivregler

Börja med det ändrade objektet och ett precist verb: “Behörighetsregel förtydligad”, “Datamängd ersatt” eller “Formel korrigerad”. Håll sammanfattningar på 4–14 ord och detaljer på 25–90 ord. Använd en mening för ändring och anledning, en annan för påverkan. Använd lokaliserade absoluta datum och nyast-först-visning.

Förklara anledningen före resultatet. “Leverantören lade ner Starter, så vi ersatte det med Essentials och omvärderade rekommendationen” registrerar orsak; “Vi förbättrade vår jämförelse” registrerar åsikt. Använd neutral dåtid.

Varje väsentlig post bör besvara dessa frågor:

• Vilket specifikt faktum, instruktion, metod, källa, omfattning eller slutsats ändrades?
• Varför behövdes ändringen?
• Var på sidan inträffade den?
• Ändrades huvudsvaret, rekommendationen eller slutsatsen?
• Måste läsaren göra om ett beslut eller en åtgärd baserat på den tidigare versionen?

Skapa en post per redaktionell händelse, inte per tangenttryckning. Gruppera relaterade ändringar från en granskning; separera orelaterat arbete, olika påverkan eller olika datum. Visa tre till fem och behåll väsentlig historik.

Inkludera aldrig konfidentiella anteckningar, säkerhetsdetaljer, sårbarheter, personuppgifter, skuldbeläggning, råa commit-hashar, oförklarade ärenden, marknadsföring, brådskande budskap eller en bibliografi. Lova aldrig “100 % aktuellt”, radera inte rättelser, skriv inte om poster i tysthet och omdatera inte kosmetiskt arbete.

Om en post behöver korrigeras, bevara dess datum och lägg till en rättelsehändelse. Integritet, säkerhet eller juridiska skyldigheter kan motivera redigering; ange att posten ändrades och varför på en lämplig nivå.

Inläggstyper som använder det

Arrayen postTypes i frontmatter är källan till denna tabell. “Krävs” innebär att väsentlig revisionshistorik är en del av formatets förtroendekontrakt; “villkorlig” innebär att loggen visas när en kvalificerande ändring inträffar.

En ny sida behöver ingen tom logg. Efter en kvalificerande ändring, bevara elementet.

QA-checklista

• Varje synlig post representerar en saklig redaktionell händelse, inte en kosmetisk eller automatiserad ändring.
• Händelsedatumet är exakt, giltigt, icke-framtida och matchar den godkända redaktionella posten.
• Sammanfattningen namnger det ändrade objektet och håller sig inom 4–14 ord.
• Detaljen anger vad som ändrades och varför innan den beskriver fördel.
• Posten identifierar om svaret, slutsatsen, rekommendationen, behörigheten eller instruktionerna ändrades.
• En väsentlig rättelse visas även bredvid det påverkade påståendet.
• Avsnittsfragment och bevisidentifierare löser till stabila mål på samma kanoniska sida.
• Loggen visas efter huvudinnehållet och källorna men före marknadsföringsmoduler i slutet.
• Loggen är inte visuellt sammanslagen med en CTA, erbjudande, betyg, vittnesmål eller källblock.
• Datum använder semantiska <time>-värden; händelsetyper och påverkan förlitar sig inte på färg eller ikoner.
• Arkivkontrollen är tangentbordsanvändbar, tydligt märkt och exponerar sitt fulla innehåll för hjälpmedelsteknik.
• En granskningspost ändrar inte dateModified; en sista väsentlig händelse överensstämmer med det kanoniska uppdateringsdatumet.
• Konfidentiella anteckningar, personuppgifter, säkerhetsdetaljer, rå implementationshistorik och marknadsföringsspråk saknas.
• Sidans inläggstyp och läsarrisk motiverar elementet.

FAQ

Hör varje innehållsredigering hemma i ändringsloggen?

Nej. Registrera ändringar som påverkar fakta, instruktioner, bevis, omfattning, tolkning, rekommendationer eller en läsares beslut. Utelämna stavning, mellanrum, spårning, mallar och andra icke-sakliga redigeringar.

Hur skiljer sig en ändringslogg från ett senast uppdaterat-datum?

Ett senast uppdaterat-datum säger att en saklig förändring har inträffat. En ändringslogg anger vad som ändrades, varför det ändrades och om svaret eller slutsatsen flyttades, så att underhållspåståendet kan granskas.

Ska den nyaste eller äldsta uppdateringen visas först?

Visa den nyaste posten först på en underhållen sida eftersom läsare oftast behöver den aktuella ändringen. Behåll kronologisk ordning i maskinell utdata och tillhandahåll ett tydligt märkt arkiv när den synliga listan förkortas.

Kan en ändringslogg ersätta rättelsemeddelanden?

Nej. Ett väsentligt fel behöver en påtaglig rättelse vid det påverkade påståendet samt en permanent loggpost. Loggen bevarar historik; den får inte dölja en rättelse längst ned på sidan.

Ska granskningar utan ändringar visas i loggen?

Endast när granskningsstatus är viktig för läsare och posten är märkt “Granskad”, inte “Uppdaterad”. Ange vilken omfattning som kontrollerades och att ingen saklig ändring krävdes; ändra inte dateModified.