Freshness Stamp: Published and Updated Date Rules

A freshness stamp tells readers when a page first became public, when its relied-on information last changed, and—where useful—what was checked. It is an opening element because time can change how every claim below it should be interpreted.

Updated 27 August 2026 · Published 14 March 2025 · Pricing and feature availability verified

That rendered specimen makes three different claims. “Published” preserves origin, “Updated” records a substantive change, and the scope phrase says what the review covered. The date is a provenance signal, not a decoration or a shortcut for making old content look new.

Why this element matters

Readers use dates to estimate risk. A three-year-old explanation of a mathematical concept may be perfectly reliable, while a three-month-old comparison of software prices may already be wrong. A visible stamp helps a reader decide whether to trust the page, verify a volatile claim, or look for a newer source. Showing both dates also protects history: the reader can see that a mature resource was maintained rather than falsely presented as newly published.

The psychology fails when the label overclaims. “Updated today” implies that someone changed information a reader relies on. If the only action was changing the date, fixing punctuation, or moving the page into a new template, the label manufactures confidence without earning it. Touching an updated date without substantively touching content is a policy violation, even if a content management system makes the edit easy.

Machine extractability means software can identify the publication time, modification time, review scope, and relationship between them without guessing from prose. Stable fields can feed page templates, feeds, audits, and structured data. A crawler can distinguish datePublished from dateModified; an editorial monitor can identify volatile pages whose review window has expired. A vague line such as “recently refreshed” provides neither a usable timestamp nor a testable claim.

The typed element has precedence over a date typed into ordinary prose. Follow the element writing rules : the component must read canonical date fields and render them consistently. Authors must not hand-type a second date that can drift away from metadata.

When to use it

Use a freshness stamp when age materially changes whether the page is safe, accurate, or useful. Common triggers are prices, product features, availability, laws, standards, statistics, ranked recommendations, compatibility instructions, eligibility rules, schedules, and named personnel. These facts decay because the world changes even when the prose does not.

Use it on a living resource when the publisher commits to revisiting defined claims. A software comparison might say “Plans and feature limits verified”; documentation might say “Verified for version 6.8”; a regulatory explainer might name the jurisdiction and effective rule. The scope prevents a recent check of one table from implying that every sentence, link, and conclusion received equal scrutiny.

Evergreen content may not need a visible freshness stamp. A stable definition, historical account, fixed case study, release note, or research report tied to a closed dataset often needs only an honest publication date. Add correction notes or a separate update log when interpretation changes, but do not create a maintenance theatre in which an immutable record receives a new date every quarter.

Near misses include:

• Automatic current dates: rendering today’s date on every request says nothing about review activity and is always prohibited.
• A year in the title: “Best tools 2026” is a claim about current coverage, not proof that the page was checked in 2026.
• A build timestamp: rebuilding the site changes files, not editorial substance.
• A review badge with no scope or owner: it creates authority without an auditable act.
• A changed product feed: automated price updates may update a specific field, but they do not justify marking the surrounding editorial analysis as updated unless the conclusion was rechecked.

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 stamp in the hero metadata row: below the H1 and one-line description, and before the introduction or first direct-answer element. The reader should receive the time context before encountering claims that may decay. On a long page, the stamp may also appear beside a volatile table or evidence block when that block has its own narrower verification date.

Keep authorship and review identity in the same provenance region when the template supports them, but preserve a clear reading order: author, publication/update dates, then review scope. The stamp may sit beside a reading-time estimate because both are neutral metadata. It must not sit beside a promotional badge, discount countdown, “trending” label, or star rating; those signals can make an editorial date look like urgency or endorsement.

Do not place the stamp inside the introduction, after the first volatile claim, only in the footer, or inside an image. Do not repeat conflicting dates in the hero, sidebar, and table. If a section has its own data vintage, label that value “Data through June 2026” or “Prices checked 27 August 2026” rather than changing the page-level updated date.

Anatomy

1. Primary label: “Updated” when a valid modification exists; otherwise “Published.” It must be visible text, not an icon or tooltip.
2. Primary date: A human-readable calendar date derived from canonical metadata.
3. Original publication: Retained when the primary label is “Updated” and provenance benefits from showing both.
4. Review scope: Optional short text naming the facts, version, jurisdiction, or dataset actually checked.
5. Machine timestamp: A complete ISO 8601 value in the HTML datetime attribute, including timezone where time is stored.
6. Document relationship: The element belongs to the page hero; a narrower evidence date belongs beside the evidence it qualifies.

Color, icon, spacing, and separators belong to the renderer. The semantic sequence must still read correctly when CSS is unavailable.

Stay Updated on AI Visibility Trends

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

Email address

Subscribe

Design examples

The supported variants reflect different editorial states, not cosmetic preferences.

Published only: Use for a new page or a stable page that has never received a substantive revision. This is the default.

Published and updated: Use after a substantive revision. Updated leads because it is the decision-relevant date; publication remains available as history.

Scoped verification: Add a short scope when only defined volatile claims were rechecked or when the page is version-bound. The scope must not imply a broader audit.

Reviewed without change: Use only when a real review found the page still accurate. Record reviewedAt separately; do not change dateModified and do not label the event “Updated.”

Narrow viewport: Allow natural wrapping between complete items. Never truncate a date or hide “Published” while leaving an unlabeled number.

Parameters

The date fields are metadata attributes, not authored body copy. This prevents a visible label from disagreeing with feeds or schema. The frontmatter specification remains authoritative for document-level values.

The element has no body and no first-heading mapping. A body would let authors duplicate canonical metadata. The scope is deliberately an attribute because it is short, stable, and machine-readable.

Syntax and code examples

All adapters read the same publication, modification, and scope values. They may format dates for the locale, but they must not change their meaning.

Portable Markdown directive

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

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

In Hugo, the preferred production adapter should read .Date and the approved updated parameter from page metadata so authors do not repeat them. The explicit values above document the portable field mapping; they are not permission to hard-code a second source of truth.

WordPress block

<!-- 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"} /-->

A WordPress adapter should default published and updated from the post record, expose scope as an editorial field, and prevent a date-only update workflow from silently presenting a revision that did not occur.

Examples

Updated 27 August 2026 · Published 14 March 2025
Pricing, plan limits, and feature availability verified against vendor pages.

This is good because the labels preserve both events, the scope names the volatile facts, and the claim can be audited against the page’s edit and source history. A reviewer knows what “updated” means here.

Freshly updated today!
Originally published recently.

This is bad because “today” moves with no editorial event, “freshly” is promotional, “recently” erases history, and neither line exposes a machine-readable timestamp. If the page was only reformatted, even replacing those phrases with exact dates would remain deceptive. The correct action is to retain the original publication date and omit an updated date.

Schema markup and accessibility

The stamp can feed datePublished and dateModified on an enclosing Article, TechArticle, NewsArticle, or other truthful page type. datePublished comes from the original publication record. dateModified comes only from the latest substantive content change. A separately recorded review that changes nothing must not overwrite dateModified; schema should not turn a review event into a false modification.

Do not invent a FreshnessStamp Schema.org type. Review scope usually remains visible text and internal audit metadata. If a page cites volatile facts, keep their evidence in a sources block rather than implying that a recent date proves them.

Render each date with a semantic <time datetime="…"> element. The visible form follows the page locale; the datetime value preserves an unambiguous machine timestamp. Labels must be text. Do not rely on a clock icon, green color, tooltip, or relative wording such as “two months ago.” Separators marked decorative should be ignored by assistive technology, and wrapping must preserve a logical reading order.

The stamp is static metadata, so it needs no ARIA live region, button role, focus target, or announcement. If an update log is linked, use a descriptive label such as “See what changed,” not “More.”

Writing rules

Write labels as factual provenance: “Published,” “Updated,” or “Reviewed.” Use an absolute localized date, not “today,” “recently,” “new,” or “fresh.” Keep scope to 3–12 words and name the checked object: “Plan prices and limits verified” is stronger than “Content reviewed.” Do not add exclamation marks, urgency, SEO claims, or promises that the page is fully accurate.

A substantive change resets updated only when it improves information a reader relies on. Legitimate triggers include correcting a material fact, replacing stale prices or specifications, revising instructions after a product change, adding significant evidence, changing a recommendation after reevaluation, expanding scope enough to change the answer, or completing a documented review that results in meaningful content changes.

The following do not reset it: typo fixes, punctuation, formatting, image compression, CSS or template changes, analytics tags, link tracking, metadata-only edits, automated builds, category changes, author-profile formatting, or merely checking the page and finding no change necessary. A broken-link replacement resets the date only when the destination changes the evidence or guidance; swapping an equivalent working URL does not.

Never put a claim such as “Google rewards fresh content,” a promotional message, discount expiry, reading time, author biography, source list, change log, or full review methodology inside the stamp. Those have different purposes. Never backdate an update, overwrite the publication date, derive modification time from the repository, or schedule a future updated date.

Post types that use it

The postTypes frontmatter is the source of this mapping. Inclusion means the format has a recurring decay risk; it does not mean every instance must display an updated date.

Stable glossary definitions, historical records, closed-dataset research, and release notes usually retain publication dates without claiming continual freshness. Their evidence period or release version does more interpretive work than a rolling “updated” label.

QA checklist

• The original publication date is preserved and predates or equals every later event.
• updated corresponds to a substantive change visible in the content or documented evidence.
• A review with no content change uses reviewedAt, not updated or dateModified.
• The visible date, frontmatter value, feed value, and structured-data value agree.
• The scope names exactly what was checked and does not imply a whole-page audit when only one block changed.
• The stamp appears in the hero before volatile claims, with narrower dates beside narrower evidence.
• Absolute dates and visible text labels remain understandable without color, icons, CSS, or surrounding prose.
• Each machine timestamp uses valid ISO 8601 syntax and the correct timezone.
• No build time, file modification time, current-year token, or automatically moving date feeds the element.
• The edit history can explain why the date changed; a date-only edit fails review.
• Published, updated, and reviewed events remain distinct in visible copy and schema.
• The page’s post type and decay risk justify displaying the element.

FAQ

Should every article show a last-updated date?

No. Show an updated date only after a substantive change. A stable evergreen page can show its publication date alone, while a decaying page should expose the date and scope of its latest valid review.

Does fixing a typo justify changing the updated date?

No. Typographic, formatting, tracking, template, and metadata-only edits do not change the information a reader relies on, so they do not reset the updated date.

Can a page show a reviewed date when no changes were needed?

Yes, if a qualified person genuinely checked the defined scope and the label says “Reviewed,” not “Updated.” Keep the publication and modified dates unchanged, and record the review separately.

Should the publication date disappear after an update?

Usually no. Keep the original publication date in metadata and show it beside the updated date when provenance matters. The updated date must never rewrite the page’s history.

Does a freshness stamp improve rankings by itself?

No. A date label is not evidence that the page is accurate. Its value comes from truthful maintenance, consistent metadata, and content that actually reflects the stated review.