Show a date on the page where readers can see it, and put the same date in machine-readable form: datePublished and dateModified in JSON-LD, or a date meta tag. Update the "modified" date only when you make a real change. That is what the freshness check looks for.
What the freshness check means
The AEO checker looks for a date signal on the page and reports one of four results. If AEO is new to you, SEO, AEO and GEO: what is the difference explains where it fits.
- Pass: a readable, recent date was found. Keep it accurate.
- Warning, old date: a date was found, but it is old. Review the page, update it if it is outdated, then change the date.
- Warning, date can't be read: something looks like a date, but the format isn't machine-readable. Use a standard format.
- Fail, no date signal: no date found. Add a visible date and a machine-readable one.
When a page has no date signal, the report labels the Freshness signals result "Missing" and scores it 0 out of 20. That is the "Fail, no date signal" case above.
The checker also counts a Last-Modified header as a date signal, alongside the meta tags and JSON-LD fields this post covers.
An old date is not automatically bad. A guide that is still correct can stay as it is. The warning is a prompt to check it, not an order to refresh.
Why dates are worth adding
- Readers judge whether a page is still current by looking for a date.
- Search engines and other tools can read dates from the page and from structured data, and a clear, consistent date makes that easier.
- Content with a clear date is easier to judge when you write answers AI tools can quote, because a reader or a tool can tell how current the answer is.
- It forces a useful habit of reviewing old pages.
This does not mean newer is always better, and a fresh date will not rescue a thin page. Nobody can promise that a date changes rankings or whether an AI tool cites you.
How to add it
1. Show it on the page
Put a date near the title, such as "Published September 20, 2026. Updated October 2, 2026." Use the <time> element so tools can read it:
<p>
Published <time datetime="2026-09-20">September 20, 2026</time>.
Updated <time datetime="2026-10-02">October 2, 2026</time>.
</p>
2. Add it to structured data
The dates belong in your Article structured data. If you haven't added any yet, what to add first is the place to start. Here is an Article with the fields most pages need:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to add a publish and updated date to your pages",
"image": "https://example.com/images/freshness-dates-cover.png",
"author": {
"@type": "Person",
"name": "Alex Morgan"
},
"datePublished": "2026-09-20",
"dateModified": "2026-10-02"
}
The headline, image and author are example values. Use your own, and keep datePublished and dateModified in the same format as shown. If you also add FAQ markup, the FAQPage schema guide has copy-paste JSON-LD you can combine with this.
You can also set the dates as meta tags, which is a lighter option if you can't edit JSON-LD:
<meta property="article:published_time" content="2026-09-20">
<meta property="article:modified_time" content="2026-10-02">
3. Use a standard format
The ISO format YYYY-MM-DD is the safest. Avoid formats like "20/09/26", where day and month can be confused. If you include a time, add the time zone offset as well, for example 2026-10-02T09:30:00+05:00, so the moment is unambiguous.
4. Make all the dates agree
The visible date, the <time> value, the meta tags and the JSON-LD should say the same thing. A mismatch makes it harder for any tool to trust the page.
Rules for the updated date
- Change
dateModifiedonly when the content really changed: corrected facts, new sections, updated steps. - Don't bump the date for a typo fix or a layout change.
- Don't change the published date. It records when the page first went live.
- If you update a page, check that the information is right, not just that the date is new. Fake freshness is easy to spot and doesn't help readers.
For Next.js and other frameworks
Store publishedAt and updatedAt as fields on each post (for example in your database), and render both the visible text and the JSON-LD from the same values. That keeps them consistent without extra work. Here is a Next.js App Router page that does it:
// app/blog/[slug]/page.js
import { getPost } from '@/lib/posts'; // your own data source
function formatDate(iso) {
return new Date(iso).toLocaleDateString('en-US', {
year: 'numeric',
month: 'long',
day: 'numeric',
timeZone: 'UTC',
});
}
export default async function PostPage({ params }) {
const { slug } = await params;
const post = await getPost(slug);
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'Article',
headline: post.title,
image: post.coverImageUrl,
author: { '@type': 'Person', name: post.authorName },
datePublished: post.publishedAt,
dateModified: post.updatedAt,
};
return (
<article>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify(jsonLd).replace(/</g, '\\u003c'),
}}
/>
<h1>{post.title}</h1>
<p>
Published <time dateTime={post.publishedAt}>{formatDate(post.publishedAt)}</time>
{post.updatedAt !== post.publishedAt && (
<>
. Updated <time dateTime={post.updatedAt}>{formatDate(post.updatedAt)}</time>
</>
)}
.
</p>
{/* post body */}
</article>
);
}
Two details matter here. The visible date and the JSON-LD both read from post.publishedAt and post.updatedAt, so they can't drift apart. And timeZone: 'UTC' stops a date like 2026-10-02 from showing as October 1 for readers west of UTC, because a date-only value is read as midnight UTC.
Keep your sitemap in step
If your sitemap lists a <lastmod> for each page, it should match the page's dateModified. Both describe the same event: the last time the page really changed. In a Next.js sitemap, feed lastModified from post.updatedAt, not from the build date. How to create and submit an XML sitemap shows the code.
How to check
View the source. Search the page source for datePublished, dateModified and <time.
Use the console. Open DevTools, go to the Console, and run this to list every <time> value on the page:
[...document.querySelectorAll('time')].map((t) => t.getAttribute('datetime'))
And this to print the dates from the page's JSON-LD:
document.querySelectorAll('script[type="application/ld+json"]').forEach((s) => {
try {
const data = JSON.parse(s.textContent);
console.log(data.datePublished, data.dateModified);
} catch (e) {
console.log('This JSON-LD block is not valid JSON');
}
});
If a block prints undefined undefined, the dates may be nested inside a @graph array, so look inside it. If one block is not valid JSON, fix that first, because a broken block is ignored.
Run the checker. Run the AEO checker on the page to see what date it picks up and which of the four results you get.
Common mistakes
- Showing a date visually but not in structured data, or the other way around.
- Setting every page's modified date to the site's build date.
- Using a date format a machine can't parse.
- Updating the date without updating the content.
- Hiding the date entirely to make old content look current.
- Letting the sitemap
lastmodsay one thing and the pagedateModifiedanother.
Quick reference
- Visible date:
<time datetime="YYYY-MM-DD">near the title. - Structured data:
datePublishedanddateModifiedin Article JSON-LD. - Alternative:
article:published_timeandarticle:modified_timemeta tags. - Format: ISO
YYYY-MM-DD, with a time zone offset if you add a time. - Change
dateModified: only after a real content change. - Change
datePublished: never. - Keep in sync: visible text,
<time>, JSON-LD, meta tags and sitemaplastmod. - Check: view source, the console snippets above, or the AEO checker.
Where to go next
Dates are one item on a longer list. Once they're in place, work through the full audit checklist to see what else a new site needs.
Comments
No comments yet ā be the first.