You just updated a page, and now you want Google and the AI answer engines to see that it changed. The good news is that the visible and structured pieces are small and you can do all of them in an afternoon. This guide walks through seven steps for putting content freshness signals on a page that has already been revised: the dates readers see, the notes that explain the change, the schema values, and the sitemap entry. By the end you'll have one page where all of it agrees and a short checklist you can reuse.
One thing to say up front. These date signals help Google interpret when a page was published and when it changed. They don't prove the information on the page is current, they don't guarantee a date shows up in search results, and they don't give a page special treatment in AI answers. Google says its AI Overviews and AI Mode follow the same SEO basics as regular search, with no extra markup required. So the goal here is simple: report an update that really happened, clearly and consistently.
This guide is about communicating the update. Deciding which stats and sources to change is a separate job, and we cover it in how to update stats, sources, and dates. Whether freshness affects citations at all is covered in our look at freshness and AI search citations. Here we assume the edit is done.
What you need: one page that has been meaningfully revised, access to its CMS history, and a way to see the page's source and your sitemap.
1. Record the original and actual update dates
Before you touch the page, write down what really happened. Get the original publication date, the date of the editorial update, the time zone your CMS uses, and one plain sentence describing what changed. Pull these from the CMS revision history, not from today's date. It also helps to name one person who approves the reader-facing update label, so it doesn't get changed by whoever is in the CMS that week.
You're done with this step when a teammate can read your notes and tell you what changed and when, and the update date isn't earlier than the first publication date or in the future.
This is where date signals SEO efforts most often go wrong, because a few different dates look alike and aren't. A scheduled publishing date, an event date mentioned in the article, a copyright year, and the time someone last hit save are all different things from the date a page was updated. Google says page dates should describe when the page was published or updated, not the dates of events the page talks about. The other trap is replacing the old publication date with today's. That hides the page's history, and the next steps depend on keeping it.
2. Label the published and last-updated dates where readers can see them
Put the dates near the headline or byline, where a visitor sees them without hunting. Use plain labels so the two dates mean different things: "Published" for the first date and "Last updated" for the revision. Google allows a publication date, an updated date, or both, and showing both is the clearest choice when the original date matters. A readable date is enough. Here's an illustrative example (these are made-up dates, not from a real article):
Published April 9, 2026 · Last updated July 16, 2026
If you're editing a template, you can wrap each date in a <time> element with a machine-readable datetime attribute, while the visible text stays readable. For example, <time datetime="2026-07-16">July 16, 2026</time> can sit right after the "Last updated" label. Just make sure the values come from the real editorial record you wrote down in step 1.
You're done when someone looking at the live page can tell right away which date is the original and which one reflects the update, and the calendar days shown agree with the structured values you'll add in step 4.
Common ways this goes wrong are keeping dates only in the metadata where no reader can see them, showing one unlabeled date that could mean anything, and putting a date where it might be read as the date of an event in the article. Google recommends a prominent, user-visible date with a sensible label. It doesn't promise that either date will become the byline date in search results, so treat the visible label as good practice for readers first.
3. Add an update note when it helps explain the change
For a substantial revision, add a short "What changed" or "Update note" line near the date or at the end of the article. Say what was actually done, at a level a reader could check. You don't need to retell how you did the fact-checking. An illustrative note looks like this:
Updated July 16, 2026: Clarified the implementation steps and added a validation checklist.
If a page has been through several meaningful revisions, a short list with the newest first works well, with a date and a plain sentence for each. And if a correction changes how a reader should interpret something, say so directly rather than quietly relabeling it as a general refresh.
You're done when the note says what changed, its date matches the visible "Last updated" date, and a teammate can compare it to the revised page and see that it's true.
It's worth being honest about what these content update markers are. A changelog or update note is a good editorial habit that builds trust with readers, but Google doesn't document it as a requirement, and it isn't a special tag for AI search. So don't describe it to your team as an algorithm rule. It's also better to save the prominent "Last updated" treatment for changes big enough to explain. That's our editorial suggestion, not a Google threshold. Google's own test for significance appears in its sitemap guidance, which we get to in step 5.
Common mistake: Changing the visible label, the schema date, and the sitemap date all at once doesn't turn unchanged information into an update. These fields are there to report an update you've already made, so if nothing meaningful changed, leave the dates alone.
4. Match datePublished and dateModified in the article's structured data
Start by looking at what the page already has. Many blogs already output Article or BlogPosting markup through the theme, a plugin, or the CMS, and adding a second block just to carry dates can leave you with two conflicting versions. If you want a deeper walk through the markup itself, our guide to Article schema for blog posts covers the full node. Getting the updated date schema right comes down to two date properties, set to the verified timestamps from step 1, inside the node that's already there.
Schema.org defines datePublished as the date of first publication and dateModified as when the work was most recently modified. That's the whole difference, and it's why the original date stays original. Here's an illustrative fragment to merge into an existing article node. It isn't complete JSON-LD on its own:
{
"datePublished": "2026-04-09T10:00:00Z",
"dateModified": "2026-07-16T14:30:00Z"
}
Keep the rest of the existing node as it is, including its context, type, and other properties. Google's Article guidance asks for ISO 8601 dates and recommends including time zone information. The date is what matters for byline purposes and the time is optional, but adding the time and the right zone makes the value more precise. The example uses UTC, and a correctly calculated local offset works too.
Here's a detail that catches people. If your visible date doesn't show a time, that's fine, but its calendar day has to match the structured timestamp in the relevant local time zone. A timestamp of 11:30 p.m. on July 15 in one zone can land on July 16 in UTC, and then the page says one thing while the markup says another. Daylight saving time can shift the offset too, so check the offset that applies on that particular date.
You're done when the page has the intended date values, the original date is still the original, the modified value matches the real revision, and neither timestamp contradicts what a visitor sees. If your CMS or SEO plugin already outputs these properties, verify what it produces instead of adding a second implementation on top.
Watch for swapped fields, the update day used as datePublished, an offset that's wrong for that date, and the assumption that schema alone makes a page eligible for AI search. Google's Article documentation has no universally required properties, structured data doesn't guarantee a search feature, and Google's generative AI features need no special schema. If you're building markup without a developer, this walkthrough on adding schema markup without a developer shows how to do it in common platforms.
A note on DeepSmith: Content Studio's writing pipeline includes schema markup and metadata on the articles it produces. For a page that already exists and has been revised, though, you'll want to look at the published CMS output yourself and confirm how the dates are represented. DeepSmith doesn't edit dateModified on an existing page or write your update note for you.
5. Make the sitemap lastmod accurate
Find the page's entry in your live XML sitemap and compare its <lastmod> value with the real last significant change and with the dates you've set in the visible label and the schema. An entry might look like <lastmod>2026-07-16T14:30:00Z</lastmod>, which is just an example. Also check that the entry points to the fully qualified canonical address of the page, since Google recommends absolute URLs.
This is where Google gives its clearest definition of "significant." It counts changes to the main content, the structured data, or the links as generally significant, and it doesn't count a copyright-year change. Google says it uses <lastmod> when the values are consistently and verifiably accurate. If your sitemap generator bumps every entry on every save, or stamps every page with today's date each time the sitemap rebuilds, the value stops telling Google anything, and it's worth changing how that value gets produced. The best source is a record of significant changes, not a routine CMS save or a sitewide footer edit. For more on what sitemaps do and don't do for crawlers, see our piece on whether XML sitemaps help AI crawlers.
You're done when the entry points to the intended page, the <lastmod> reflects the relevant significant change, and you can explain any gap between it and the editorial "Last updated" date. For example, if you later changed the page's links or structured data, the sitemap's last significant change could be later than the date in your update note about the main text. Consistency here means the histories are truthful and compatible. It doesn't mean every timestamp has to match to the second.
What goes wrong is setting every entry to the current date at build time, bumping <lastmod> for a copyright-year change, or assuming that submitting a sitemap forces a recrawl. Google treats a submitted sitemap as a hint. Each sitemap file is limited to 50,000 URLs or 50 MB uncompressed, whichever you hit first, but that's an infrastructure limit and not advice about how often to update.
A note on DeepSmith: Content Map checks the sitemaps of connected sites for new pages as part of mapping your topics. That's different from generating your publishing stack's XML sitemap or confirming its <lastmod> values, so check the sitemap in the system that actually produces it.
6. Check the page, schema, and sitemap as one record
Now look at all of it together, on the live page. This is the check that keeps your date signals SEO work honest. Open the public page the way a visitor would and write down the visible labels and dates. Then inspect the real structured-data output, since the CMS editor field isn't the same as what ships in the page source. Compare both against your editorial record and against the sitemap entry for the canonical URL.
A few tools help here. Google's Rich Results Test checks how Google reads your supported structured data, and it's where you fix critical errors. The Schema Markup Validator checks general schema.org syntax and vocabulary, which is useful, but it doesn't replace the Google-specific test. Search Console's URL Inspection shows Google's view of a representative page and confirms it isn't blocked by robots.txt, a noindex tag, or a login. If it fits your setup, you can also submit the sitemap in the Sitemaps report and look at any processing errors. If you want more on this kind of check, our guide to validating schema markup goes step by step.
You're done when a reviewer can point to four things that agree with each other: the visible date labels, the date properties in the article markup, the matching sitemap entry, and the dated update note if you used one. The page also needs to be crawlable, and the structured-data test should show no unresolved critical errors.
Mistakes at this step are testing a staging copy in place of the published page, assuming a passing syntax check proves the article was actually updated, and expecting search results to change right away. A validator can find implementation problems, but it can't tell whether the date and note describe a real update, so that part stays a human call. Google also says crawling, indexing, byline display, and sitemap use aren't guaranteed, and its Article guidance notes that discovery and crawling can take several days. If you're waiting on a recrawl, this guide to getting crawlers to recrawl updated content has practical options.
Pro tip: If Google shows a byline date that doesn't match your page even though your signals are correct, look for other dates competing on the page. Google's guidance suggests keeping competing dates to a minimum. That doesn't mean removing dates a reader needs, like an event date, but it's worth making sure each one is clearly labeled for what it is.
If you use WordPress
WordPress gives you two separate values to work with. The get_the_date() function returns a post's publish date, and get_the_modified_date() returns its last-modified date. Both accept a PHP date-format argument, and both can take a specific post ID or post object. Use those two underlying values to build your visible labels, and format them separately for readers and for machine-readable timestamps. The WordPress documentation includes an example of get_the_date('c') inside a <time> element, which gives you an ISO 8601 value. You still need to check the rendered day, the time zone, and the actual post record.
Yoast says Yoast SEO outputs schema.org datePublished and dateModified data, which Google may use when deciding on a search-result date. Installing a plugin doesn't mean your visible labels, your update note, and your sitemap dates are all correct, so look at a representative live page after you publish. For Webflow, Strapi, Sanity, Contentful, and other systems, the steps differ, so the output checks above are the reliable part, and you can apply them on any platform.
7. Add a date check to your publishing handoff
The last step is making this repeatable. Give the editor or publishing owner a short acceptance checklist to run on every revised page:
- Keep the page's true original publication date.
- Approve the meaningful-update date and any update note.
- Check the rendered labels on the live page.
- Check the existing schema output.
- Check the sitemap entry.
- Confirm the page is crawlable and fix any mismatch.
Recheck after a deployment if a template, an SEO plugin, or a sitemap generator could overwrite the dates. When the page gets another meaningful update later, run the checklist again against the new revision. Don't just bump a year in the headline.
Whatever content update markers you settle on, keep them the same from page to page. You're done when the person publishing can answer "What changed, when, and where do the visible page and the machine-readable signals say so?" by looking at the live page. The mistake to avoid is treating the checklist as a promise about how the page will appear in search or that an AI engine will endorse it. Google draws no such guarantee, and neither should your team's process notes.
If you're planning how often to revisit pages in the first place, how often to refresh content covers cadence. The 30-minute content refresh checklist is a handy companion for the edit itself. If you're curious whether any of this changes what AI engines cite, how recency and freshness affect citations looks at that question. For more, see our freshness and citations explainer goes further into it.
What to do next
Pick one page you've already revised and take it through all seven steps, start to finish. Once you've seen your content freshness signals (the visible label, the schema, the sitemap entry, and the update note) agree on a live page, add the checklist from step 7 to your publishing workflow so it happens the same way every time.
If you'd like help producing articles with schema markup and metadata built in, and organizing that work in one place, you can start a DeepSmith free trial. You'll still be the one checking that the dates on a published page are accurate, but you can spend less time on the production work around it.
