Every post on your WordPress site carries two timestamps, not one. There’s the day you hit Publish, and there’s the last time you touched a single character of it. Most people only ever think about the first. Google pays attention to the second, and so does the sitemap your site quietly hands to search engines every day.
That second timestamp is the “last modified” date, and it drives more than you’d guess: what shows up under your headline in search results, how quickly Google comes back to recrawl a page you just improved, and whether a two-year-old guide reads as maintained or abandoned. It’s also the field people most love to fake, which is where the trouble starts.
This guide covers where WordPress keeps that date, how it leaks out to Google through your sitemap and your structured data, and the surprisingly easy ways to wreck it — including the bulk operation that once reset the modified date on a client’s entire archive to the same afternoon.
The Two Dates WordPress Keeps for Every Post
Open your database and look at the wp_posts table, and you’ll find four datetime columns sitting on every single post, page, and custom post type entry. They come in two pairs. post_date and post_date_gmt record when the post was published — one in your site’s local time, one in UTC. post_modified and post_modified_gmt record the last time the post was saved, again in local and UTC form.
The publish date is set once and generally stays put. The modified date is different: WordPress rewrites it every time the post is updated, whether you rewrote three paragraphs or fixed a single typo. Change the title, swap a featured image, tweak a category — the moment you click Update, post_modified jumps to now.
This is why the two dates drift apart over the life of a post. A guide published in 2024 and quietly maintained ever since might show a publish date of eighteen months ago and a modified date of last week. That gap is the whole point. It’s WordPress keeping an honest record of when the content actually last changed.
Google’s crawlers use freshness as a signal, and for queries where recency matters — anything that changes year to year — a genuinely updated page can outrank an older one that hasn’t moved. But the operative word is genuinely. The modified date only helps you when it reflects real work. Faking it does nothing, and can quietly cost you trust.
How the Modified Date Leaks Out to Google
Here’s the part most site owners miss: you don’t have to do anything special to send your modified dates to search engines. WordPress already does it for you, through two separate channels that run whether you know about them or not.
Your sitemap broadcasts it every day
Since version 5.5, released in August 2020, WordPress core has generated an XML sitemap automatically at /wp-sitemap.xml — no plugin required. That first version didn’t carry modification dates, but WordPress 6.5, released in early 2024, added a <lastmod> element to each URL in the core sitemap, populated straight from post_modified_gmt. So on any current install, the exact timestamp of your last edit is published in a machine-readable file to any crawler that asks for it.
If you run Yoast, Rank Math, or another SEO plugin, it typically replaces the core sitemap with its own — and those plugin sitemaps have carried lastmod for years, derived from the same underlying field. Either way, the modified date is out there. Google’s own sitemap documentation says it uses the lastmod value only when it’s consistently and verifiably accurate — but when it is, a lastmod newer than Google’s last crawl is a nudge to come back and take another look.
Your theme prints it on the page
The second channel is your theme. WordPress ships template tags built specifically for this: get_the_modified_date() returns the modified date as a string, the_modified_date() echoes it, and get_the_modified_time() gives you the time component. Plenty of themes use these to print an “Updated on” line beneath the byline, which is exactly the kind of visible freshness cue that reassures a reader who lands on an older post.
If your theme doesn’t surface it and you want it to, the tag is a one-liner in your child theme’s template. Just don’t drop it into the parent theme directly — an update will erase your edit, which is a whole separate headache we’ve written about before.
The Structured-Data Piece Google Actually Reads
Beyond the sitemap, there’s a more precise way to tell Google when a page changed: the dateModified property inside your Article or BlogPosting structured data. Google’s own documentation for article structured data lists both datePublished and dateModified, and recommends supplying dates in ISO 8601 format so there’s no ambiguity about time zones.
The two dates in your JSON-LD should mirror the two columns in your database. datePublished maps to post_date_gmt, dateModified maps to post_modified_gmt. When they line up, you’re giving search engines a consistent story across three places at once: the sitemap, the visible page, and the structured data. When they contradict each other — a sitemap saying one thing and the schema saying another — you’ve handed Google a reason to trust none of them.
Most SEO plugins that emit Article schema handle dateModified for you automatically, pulling it from the same core field. If you’re generating structured data with a dedicated tool — our own amplifi.schema does this — the dates come from WordPress, so they stay accurate without you managing them by hand.
Sitemap — the <lastmod> element, from post_modified_gmt.
Theme — an “Updated on” line via get_the_modified_date().
Structured data — the dateModified property in your Article JSON-LD.
Search results — Google may show a date it picks from these signals plus the page itself.
Checking and Reading Modified Dates from the Command Line
If you want to see the real state of your modified dates without clicking through hundreds of posts, WP-CLI is the fastest path. It reads the raw fields straight from the database, so there’s no theme or plugin interpretation in the way.
To list your posts sorted by when they were last touched, oldest first, so the stalest content floats to the top:
wp post list --post_type=post --orderby=modified --order=ASC \
--fields=ID,post_title,post_modified --format=tableThat single command is a content-audit tool in disguise. The posts at the top of the list are the ones that haven’t been updated in the longest time — the natural candidates for a refresh, a merge, or a redirect if they’ve stopped earning their keep. To inspect one post’s dates in detail, wp post get <ID> --field=post_modified pulls exactly the field you want.
You can also compare a post’s publish and modified dates side by side to spot which of your “evergreen” pieces have genuinely been maintained and which have just been sitting there since launch. A post where the two dates are identical has never once been edited after publication.
The Ways People Wreck Their Own Modified Dates
Now the cautionary half. The modified date is easy to corrupt, usually by accident, and once it’s wrong across a lot of posts it’s tedious to put right. A few patterns come up again and again.
The bulk operation that stamps everything “today”
This is the big one. Any operation that re-saves posts in bulk — a find-and-replace across post content, a mass category reassignment, a migration script that touches every row — can rewrite post_modified on every post it processes, setting them all to the same moment. We watched this happen on a client site during a domain migration: a bulk URL rewrite ran through the whole archive, and the next morning every one of four hundred posts showed a modified date of 2:14 the previous afternoon. To Google’s sitemap, the entire site had apparently been rewritten in a single afternoon, which is exactly the kind of implausible signal you don’t want to send.
The safe tools avoid this. WordPress’s own wp search-replace command, the documented way to rewrite URLs during a migration, is careful about what it changes and won’t gratuitously bump timestamps on rows whose content it didn’t alter. The danger is in blunt-instrument scripts and plugins that loop through wp_update_post() on everything. Before you run any bulk job against your posts, take a database backup — and afterward, spot-check a few modified dates to confirm they weren’t all reset.
Faking freshness to game the search snippet
The temptation is obvious: if fresher pages can rank better, why not just touch every old post to reset its date? Because it doesn’t work the way people hope. Google doesn’t simply trust the date you print — its own documentation explains that it estimates a page’s date from several signals in the actual content, not just the number in your markup. If the visible date disagrees with what Google infers from the content and the page’s history, it may ignore your stated date and show its own estimate, or none at all. A date bump with no real edit behind it tends to buy you nothing.
Update dates should follow real edits, not lead them. If you genuinely revise a post — new data, corrected facts, expanded sections — the fresh modified date is earned and useful. If you’re only touching it to reset the clock, you’re adding noise, and you’ve lost the one thing the modified date is good for: telling the truth about maintenance.
Losing dates entirely in a bad import
Migrations and imports are the other classic failure. Move a site through a tool that doesn’t preserve the original timestamps, and every imported post can land with its publish and modified dates set to the import moment. Suddenly a decade of content all looks like it was written last Tuesday. If you’re migrating, confirm your export includes the original dates and your import writes them back — and check a handful of old posts on the new site before you point DNS at it.
Treat the modified date as a factual record, not a marketing dial. Let it move when you do real work, back up before any bulk job that could reset it, and check a few dates afterward. A site whose modified dates are accurate is a site whose freshness signals Google can actually trust.
A Sensible Refresh Workflow
Once your dates are honest, they become a genuinely useful audit tool. Here’s a workflow that turns the modified date into a maintenance schedule rather than a liability.
Start by pulling that WP-CLI list sorted oldest-modified-first. The posts at the top are your review queue. For each one, decide honestly: is it still accurate, still getting traffic, still worth ranking for? A page that’s outdated but valuable gets a real refresh — updated facts, current screenshots, a fresh read-through — and earns its new modified date legitimately. A page that’s outdated and dead gets consolidated into a stronger post with a redirect, or retired.
Work through the queue on whatever cadence your site can sustain, a few posts a week. Over a quarter you’ll have touched the whole tail of your archive with real edits, your sitemap’s lastmod values will reflect actual improvements, and Google will have a steady, believable stream of freshness signals to act on — because every one of them is true.
Frequently Asked Questions
A modified date is only worth as much as the truth behind it. Keep yours honest, and it becomes a maintenance map for your whole archive instead of a number you’re tempted to fudge.
Built by amplifi.studio — see also our WordPress XML sitemap guide.