Adding Transparent Update Dates That Mean Something
Readers use dates to decide whether advice still applies to them: last year's tax threshold, an old price or a discontinued product can all be wrong now. Many sites show no date at all, only the original date on a page that has since been rewritten, or an "updated" date that changes every time anyone clicks Save.
The E-E-A-T Checker flags pages without visible update dates. This guide covers what should count as an update, how to show published and updated dates clearly, how to stop your CMS inventing changes, and how to keep markup and sitemaps telling the same story.
Why dates are a trust signal
A date answers a reader's first question about advice: is this still true? On topics that change, such as tax, law, prices, software and health guidance, an old page can be accurate on the day it was written and wrong today. A clear date lets the reader judge that for themselves. A missing date forces them to guess, and a misleading one tricks them.
Dates also matter to search engines and AI assistants, which may show a date in the result or prefer recent sources for time-sensitive questions. That creates a temptation to refresh dates without refreshing content. It does not work in any useful sense: the page is no more accurate, readers who notice the gap between the date and the content lose trust, and Google's guidance on byline dates specifically asks publishers not to artificially freshen a page without adding significant information.
The four date problems the checker finds
| What you see | Usual cause | Fix |
|---|---|---|
| No date on the page at all | The theme hides dates, often by design on "evergreen" templates | Turn date display on for articles and guides |
| Only the original published date on a page that has been rewritten | The template prints the publish date and ignores revisions | Add a labelled updated date that reflects real revisions |
| An updated date that changes constantly | The template prints the CMS's last-saved time | Drive the updated date from an editor-controlled field |
| Visible date disagrees with markup or sitemap | Each is generated from a different source | Feed all three from the same value |
Service pages, contact pages and legal pages do not usually need a visible date in the same way. Articles, guides, reviews, comparisons, price lists and anything giving advice do. Policies such as privacy notices should show an effective date, because readers need to know which version applies.
The fix, step by step
Step 1
Write down what counts as a real update
Agree a short rule for your site and share it with everyone who edits content. A real update changes what the reader learns or does: new or corrected facts, revised figures, changed advice, a rewritten or added section, or a fresh check confirming everything is still accurate. Typo fixes, formatting, new images, internal links and template changes do not count. Writing the rule down stops dates drifting because different people interpret updated differently.
Step 2
Show both dates under the headline
Print
the original published date beside the byline, and add the updated date only when there has been a real
update since publication. Label each clearly, for example Published 4 March 2026 and
Updated 19 July 2026, and write the month in words so British and American readers cannot
misread it. Wrap each in a <time> element with a machine-readable datetime
value. Do not hide the original date when showing the new one.
Step 3
Stop trivial saves changing the updated date
Most CMSs record a last-modified time whenever a page is saved, including when a plugin, bulk edit or import touches it. Do not print that value as the updated date. Instead add a separate field, such as Last substantive update, that an editor sets deliberately when a real update is made, and have the template, markup and sitemap read from it. Fall back to the published date when the field is empty.
Step 4
Keep markup and sitemap in step with the page
Check that datePublished and dateModified in the Article
markup equal the visible dates, and that each page's lastmod in the XML sitemap uses the
same updated value rather than the last-saved time. Google has said it uses lastmod only
when it is consistently accurate, so a sitemap that changes every page's date daily teaches search engines
to ignore it. Fix the source rather than patching each output separately.
Step 5
Say what changed on significant revisions
For pages where accuracy matters, add a short note near the updated date or at the end of the page listing what changed, with the date of each change, such as 19 July 2026: updated the VAT registration threshold and added a section on flat rate schemes. Keep the newest entry first and trim very old entries if the list grows long. For corrections, say that something was corrected. Readers returning to the page can then see at a glance whether anything affects them.
Step 6
Schedule reviews for pages whose facts expire
List pages that contain facts with a shelf life, such as rates, thresholds, prices, product models, rules and deadlines, and give each a review date based on when those facts are likely to change, for example the start of each tax year. When the review happens, check every time-sensitive fact against its source. If anything changed, update it and the date; if nothing did, you may record the review, but only change the date if your rule counts a full check.
Step 7
Check what Google shows as the date
Search for a few updated pages and look at the date shown in the result, if any. Google chooses a date from several signals, including visible dates and structured data, so conflicting dates can lead it to show the wrong one. If the result shows an unexpected date, look for other dates prominent on the page, such as a date in a related-posts widget or a comment, and make the byline dates the clearest ones.
Example markup for the byline dates
The visible dates and the structured data should come from the same values. A byline for a fictional accountancy firm's guide:
<p class="byline">
By <a href="/team/sam-whitlow/">Sam Whitlow</a>, Chartered Accountant ·
Published <time datetime="2026-03-04">4 March 2026</time> ·
Updated <time datetime="2026-07-19">19 July 2026</time>
</p>
<details class="changes">
<summary>What changed</summary>
<ul>
<li>19 July 2026: updated thresholds for the 2026/27 tax year.</li>
<li>2 April 2026: corrected the payment deadline example.</li>
</ul>
</details>The matching datePublished and dateModified values then go in the Article
markup with a time and a UK offset. The exact format, and the British Summer Time trap that catches many
sites, are explained in AI schema date
errors.
Platform specifics
WordPress
WordPress stores post_date and post_modified. The modified value changes
on every save, including bulk edits and plugin updates, so a theme that prints it with the_modified_date()
will show constant, meaningless changes. Many SEO plugins also use post_modified for dateModified
and the sitemap. A more reliable approach is a custom field set by editors, printed only when it is present:
<?php
$updated = get_post_meta( get_the_ID(), 'last_substantive_update', true );
if ( $updated && strtotime( $updated ) > get_post_time( 'U' ) ) : ?>
Updated <time datetime="<?php echo esc_attr( $updated ); ?>">
<?php echo esc_html( date_i18n( 'j F Y', strtotime( $updated ) ) ); ?>
</time>
<?php endif; ?>If your SEO plugin cannot read the same field for its markup and sitemap, check whether it provides a filter for the modified date, or ask your developer to hook one up, so all three stay aligned.
Shopify
Blog articles expose article.published_at and article.updated_at in Liquid.
The second changes whenever the article is saved, so the same problem applies. Create a date metafield
for articles, for example custom.last_updated, and print it in the article template, formatted
with the date filter, only when it has a value.
Hosted builders
Squarespace, Wix and similar platforms show a publish date on blog posts but often have no separate updated date. Add a short "Updated" line manually at the top of the post when you make a real revision, and keep the change note in the post body.
Static sites and frameworks
Store date and updated in front matter and set updated by hand.
Avoid deriving the updated date automatically from file timestamps or the last commit, because a formatting
change or a site-wide rename will then update every page at once.
Edge cases
Republishing an old post
If you substantially rewrite an old article, keep the original URL and published date and add an updated date. Changing the published date to today suggests the piece is new, which is misleading and loses the page's history.
Evergreen content that has not changed
A page that is still accurate does not need a newer date. Showing the original date honestly, perhaps with a note that it was last checked on a given date if you have really checked it, is better than a false update.
Merged pages
When two posts are combined, use the earlier published date, add an updated date for the merge and mention the merge in the change note.
Scheduled and backdated posts
Never show or mark up a date in the future. Backdating a post to fill gaps in an archive gives it a history it does not have; publish it with its real date instead.
Keeping dates honest over time
- One source of truth for the updated date, used by the page, the markup and the sitemap.
- Editors set the date, not the system, and only when the written rule is met.
- Check after theme or plugin changes, which often switch dates off or change which date is printed.
- Keep review dates in the content calendar for pages with time-sensitive facts.
- Re-run the E-E-A-T Checker on a sample of articles after any template change.
1. Should I show the published date, the updated date or both?
Show both when a page has been meaningfully revised since publication, each clearly labelled. The published date tells readers how long the piece has existed, and the updated date tells them how current it is. If the page has not been revised, show only the published date. Hiding the original date and showing only a recent updated date can give the impression that an old page is new, which is exactly what readers and Google's guidance warn against.
2. Will changing the date make my page rank better?
Not in any lasting way, and it is not worth the risk to reader trust. Search engines use many signals to judge how current and useful a page is, and a new date on unchanged content adds nothing to them. Google's byline date guidance asks publishers not to artificially freshen pages without adding significant information. If a page needs to be more current, update what it says, check its facts and sources, and then change the date to reflect that real work.
3. Why does my WordPress post show a new updated date when I have not edited it?
Because WordPress records the last time the post was saved, not the last time the content meaningfully changed. Bulk edits, plugin updates, imports and even some SEO plugin actions can save the post and update that value. If your theme prints the modified date directly, every one of those saves appears to readers as an update. The fix is to print a date that an editor sets deliberately, and use the same value for structured data and the sitemap.
4. Does every page on my site need a visible date?
No. Dates matter most on content where time affects whether it is still right: articles, guides, reviews, comparisons, prices and any advice. Home, service and contact pages usually do not need one. Legal pages such as privacy notices and terms should show an effective or last updated date, because readers need to know which version applies. The E-E-A-T Checker's date findings are most relevant to editorial pages, so start there.
5. How should I date a page I have checked but not changed?
If you have genuinely reviewed every time-sensitive fact against its source and confirmed it is still correct, it is reasonable to show a line such as last reviewed, with the date, separate from the updated date. That tells readers the content has been checked recently without claiming it was rewritten. Do not use a review line as a way to refresh dates without doing the review. If you did not check the facts, leave the dates as they are.
6. What date format should UK sites show to readers?
Write the date with the month in words, such as 19 July 2026, which is clear to readers everywhere and avoids the confusion between day-first and month-first numeric dates. Behind the scenes, use the ISO 8601 format in the datetime attribute of the time element and in structured data, such as 2026-07-19, with a time and UK offset in the markup. Use the same format consistently across the site, so readers learn where to look for it.
7. Should I keep a change log on every article?
Not necessarily on every article. A short list of what changed is most useful on pages that readers rely on for decisions or return to over time, such as tax guides, legal explainers, pricing pages and product comparisons. For simple blog posts, a clear updated date may be enough. Where you do keep a change log, record corrections honestly, date each entry, and keep it short enough that a reader can see the most recent change without scrolling through years of history.
The E-E-A-T Checker scans your page for bylines, bio depth, Person markup, citations, update dates, trust pages and reviewer disclosures, and links each finding to the guide that fixes it.
Open E-E-A-T Fixes →