Update Log: Show What Changed and When

An update log is a dated record of substantive page changes: what changed, why, and whether the answer, recommendation, or evidence moved.

Update log

27 August 2026 — Pricing and recommendation updated
Replaced the discontinued Starter plan with the current Essentials plan, updated the comparison table, and changed the recommendation for teams that need audit exports. Sources were rechecked against the vendor’s plan documentation.

12 May 2026 — Evidence refreshed; conclusion unchanged
Replaced two superseded feature references and verified the remaining plan limits. The recommended option did not change.

Each date is tied to an inspectable event. A bare “Updated 27 August 2026” is unexplained; the log exposes the work’s scope and consequence.

Why this element matters

Readers do not treat every change equally. Correcting a misspelled heading is not equivalent to reversing a recommendation, replacing a dataset, or fixing an unsafe instruction. A single updated date collapses those events into the same signal. On pages used to spend money, follow a procedure, interpret research, or understand a policy, readers need to know whether the relied-on section changed.

An update log preserves history without forcing readers to compare cached copies. It answers four questions: Was the page maintained? Did the change affect me? Was an error corrected openly? Is the conclusion still supported? Clear answers create accountability and prevent false freshness from a date advanced without meaningful work.

Report consequence, not activity. “Updated links” describes an action. “Replaced the withdrawn source for the 2024 market total; the value and conclusion are unchanged” tells readers what remains trustworthy. If a conclusion moved, say so plainly.

Machine extractability means software can separate each event into a date, type, summary, detail, affected section, and evidence reference. Stable fields let audits find corrections, let agents explain changed recommendations, and let migrations preserve history. Inconsistent prose forces software to guess where events begin and end.

The element’s typed purpose therefore takes precedence over a visually similar timeline or bullet list. Follow the element writing rules : when the content records revisions to the current page, encode it as an update log. The renderer may use a list, cards, or an expandable archive, but the canonical event fields must survive every presentation.

When to use it

Use an update log when readers may need to compare the current and earlier page. Triggers include a changed recommendation, corrected fact, revised method, replaced dataset, altered calculation, new version, changed eligibility, updated price model, modified instructions, or archived option.

The element is most valuable when authority accumulates over time. Research may receive a corrected denominator; documentation may support a new interface; a regulatory explainer may distinguish an amendment from editorial clarification. Silent rewriting would destroy history a returning reader needs.

Use a review entry sparingly when a scoped review found no change. Label it “Reviewed,” name what was checked, and say the conclusion is unchanged. This suits volatile statistics, prices, product capabilities, or rules; it is not permission to manufacture activity.

Near-miss cases need a different treatment:

• A publication or modification date: use a freshness stamp to expose canonical page dates. The stamp and log may work together, but one cannot substitute for the other.
• Product release history or project timeline: these describe changes in the subject. An update log records editorial changes to the current page.
• Version control output: commit messages include implementation noise, internal identifiers, and security-sensitive details. They are not reader-facing editorial records.
• A source list: a sources block proves where claims came from. The update log says when and why those sources or claims changed.
• Minor maintenance: do not log spelling, punctuation, formatting, image compression, analytics, tracking parameters, or a template migration unless the change altered meaning or accessibility.

A page with no substantive revision needs a publication date, not an empty panel or fictional history.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

Place the full log after the answer, evidence, conclusions, and sources, but before related content, newsletter capture, or the closing call to action. Readers first need the current page, then its history. On research, statistics, and policy pages, the log commonly follows sources or methodology.

If the latest change affects how the page should be read, add “See what changed” beside the hero date and jump to the full log. Do not duplicate the entry there. A correction affecting safety, money, eligibility, or the conclusion also needs a notice beside the corrected claim.

The log may share a maintenance region with authorship when both remain distinct. It may not sit beside a purchase button, limited-time offer, countdown, rating, testimonial, or promotional badge; that turns history into urgency or implied endorsement. Do not merge it into the sources block: the reason a source changed is editorial history, not a citation.

Keep one canonical log. A sidebar may link to it, not duplicate it. After five entries, show the latest three to five and expose the rest through “View earlier updates.” Keep the complete history on the page or a stable governed archive.

Anatomy

1. Element title: Uses “Update log,” “Revision history,” or a narrower approved label that remains clear outside the page design.
2. Event date: Shows an absolute calendar date and exposes the same value as an ISO 8601 machine timestamp.
3. Event type: Distinguishes updated, corrected, reviewed, method-changed, and archived without relying on color.
4. Summary: Names the changed object and result in one concise line.
5. Detail: Explains the old state, new state, and reason when those facts help the reader interpret the page.
6. Affected section: Optionally links to the stable heading or figure changed, using a fragment that will not be repurposed.
7. Consequence: States whether the answer, conclusion, recommendation, eligibility, or instructions changed.
8. Evidence reference: Optionally points to a source identifier already defined in the page’s sources block.
9. Archive control: Reveals earlier entries without deleting them from the document or accessibility tree.

Entries must remain understandable without styling. Icons, lines, and colors never carry type or consequence alone.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

Variants reflect information density and editorial risk.

Compact latest-change row

Use one compact row for a single simple revision. Include date, type, summary, and consequence. Use the standard list when the explanation exceeds two sentences.

Standard revision list

Use a newest-first list for two to five entries, with the same field order throughout.

Correction-led variant

For a material error, label “Correction,” show the incorrect and corrected states, state impact, and link to the affected section. Emphasize it without alarmist language.

Method or version change

When a dataset, formula, product version, jurisdiction, or method changes, show old and new versions. State when earlier results are no longer comparable.

Expandable archive

After five entries, label the archive with its entry count and date range. Preserve headings and list structure; do not make JavaScript the only way to reach the record.

Narrow viewport

Stack date, type, summary, and detail. Never clip dates or hide consequence text on mobile.

Parameters

Parent fields control the collection; repeated item fields describe each event.

Entries are repeated items, not one HTML field. The parent’s first heading maps to title; each item’s first heading maps to summary, and its remaining body maps to detail. Dates, types, impact, references, and versions remain attributes.

impact is required so readers do not infer whether the answer moved. Use not-applicable only when the material has no conclusion. A review with no edits uses type=reviewed and impact=unchanged.

Syntax and code examples

All representations preserve the same fields. Source identifiers refer to the canonical sources block.

Portable Markdown directive

:::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 contract

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

This is an adapter contract, not an existing shortcode. Every parameter is named.

WordPress blocks

<!-- 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 should expose structured controls for date, type, impact, section, and evidence.

Examples

Good update entry

18 July 2026 — Calculation corrected
Corrected the conversion-rate denominator from all sessions to eligible product sessions in the “Channel performance” table. Values for organic search changed from 3.1% to 2.4%; the ranking of channels and the article’s conclusion did not change. The underlying session counts were not affected.

This works because it names the error, old and new definitions, affected section, numerical consequence, and conclusion status. Readers can judge whether earlier work needs review.

Bad update entry

Summer 2026 — Fully refreshed!
We reviewed this page and made several improvements so you can trust that everything is current.

This fails because the date is vague, “fully” overclaims scope, “several improvements” hides facts, and “trust” demands an unearned conclusion. If the work was cosmetic, delete the entry. If substantive, name every decision-relevant change.

Schema markup and accessibility

An update log has no standalone Schema.org type. It remains content within the enclosing Article, TechArticle, or Report. The newest substantive event may support dateModified; a review with no change must not. Never replace datePublished.

Do not encode entries as CreativeWork, Event, HowToStep, or ItemList; those types imply meanings the log lacks. Use predictable HTML: a labelled section, list items, headings, <time datetime="2026-08-27">27 August 2026</time>, and stable fragments.

Use one list item per event; CSS may draw a timeline without changing order. State that entries are newest first. Show type in text, not only color or icons, and use descriptive links.

An archive needs a native disclosure labelled with its count or range. All entries must be keyboard and screen-reader reachable. Do not use an ARIA live region. Preserve heading order and localized dates.

Place a correction notice at the affected claim and record it in the log. The first protects immediate readers; the second preserves history.

Writing rules

Lead with the changed object and a precise verb: “Eligibility rule clarified,” “Dataset replaced,” or “Formula corrected.” Keep summaries to 4–14 words and details to 25–90 words. Use one sentence for change and reason, another for impact. Use localized absolute dates and newest-first display.

Explain the reason before the result. “The vendor retired Starter, so we replaced it with Essentials and reevaluated the recommendation” records cause; “We improved our comparison” records opinion. Use neutral past tense.

Every material entry should answer these questions:

• What specific fact, instruction, method, source, scope, or conclusion changed?
• Why was the change needed?
• Where on the page did it occur?
• Did the main answer, recommendation, or conclusion change?
• Does the reader need to redo a decision or action based on the earlier version?

Create one entry per editorial event, not per keystroke. Group related changes from one review; split unrelated work, different impacts, or different dates. Show three to five and retain material history.

Never include confidential notes, security details, vulnerabilities, personal data, blame, raw commit hashes, unexplained tickets, marketing, urgency, or a bibliography. Never promise “100% current,” erase corrections, silently rewrite entries, or redate cosmetic work.

If an entry needs correction, preserve its date and add a correction event. Privacy, security, or legal duties may justify redaction; state that the record was amended and why at an appropriate level.

Post types that use it

The postTypes frontmatter array is the source of this table. “Required” means that substantive revision history is part of the format’s trust contract; “conditional” means the log appears once a qualifying change occurs.

A new page needs no empty log. After a qualifying change, preserve the element.

QA checklist

• Every visible entry represents a substantive editorial event, not a cosmetic or automated change.
• The event date is exact, valid, non-future, and matches the approved editorial record.
• The summary names the changed object and stays within 4–14 words.
• The detail states what changed and why before describing benefit.
• The entry identifies whether the answer, conclusion, recommendation, eligibility, or instructions changed.
• A material correction also appears beside the affected claim.
• Section fragments and evidence identifiers resolve to stable targets on the same canonical page.
• The log appears after the main content and sources but before promotional closing modules.
• The log is not visually merged with a CTA, offer, rating, testimonial, or sources block.
• Dates use semantic <time> values; event types and impacts do not rely on color or icons.
• The archive control is keyboard-operable, clearly labelled, and exposes its complete content to assistive technology.
• A review-only entry does not change dateModified; a substantive latest event agrees with the canonical updated date.
• Confidential notes, personal data, security details, raw implementation history, and marketing language are absent.
• The page’s post type and reader risk justify the element.

FAQ

Does every content edit belong in the update log?

No. Record changes that alter facts, instructions, evidence, scope, interpretation, recommendations, or a reader’s decision. Omit spelling, spacing, tracking, template, and other non-substantive edits.

How is an update log different from a last-updated date?

A last-updated date says that a substantive change occurred. An update log states what changed, why it changed, and whether the answer or conclusion moved, so the maintenance claim can be inspected.

Should the newest or oldest update appear first?

Show the newest entry first for a maintained page because readers usually need the current change. Preserve chronological order in machine output and provide a clearly labelled archive when the visible list is shortened.

Can an update log replace correction notices?

No. A material error needs a conspicuous correction at the affected claim as well as a permanent log entry. The log preserves history; it must not hide a correction at the bottom of the page.

Should reviews with no changes appear in the log?

Only when review status matters to readers and the entry is labelled “Reviewed,” not “Updated.” State the scope checked and that no substantive change was required; do not change dateModified.