Does fixing a typo change a post's last-modified date?

Two dates, and what moves each

Every post stores a publish date (post_date) and a modified date (post_modified). When a post is first published they are equal. After that, each save through the editor, Quick Edit, bulk edit, the REST API or a plugin that updates the post writes the current time into the modified field. Core makes no attempt to judge how big the change was.

The second-to-last row matters. Fields stored as post meta can be saved without touching the post itself, in which case the modified date does not move; saved through a full post update, it does.

Where the modified date shows up

• The XML sitemap. WordPress's core sitemap writes each post's modified time as <lastmod>. So does Hydrogen SEO's, in UTC, and for a category or tag it uses the date of the newest post in that term, as described in XML sitemaps.
• Structured data. Article schema normally carries datePublished from the publish date and dateModified from the modified date.
• Your theme. Many themes print "Updated on" beside or instead of the publish date. In block themes the Date block has an option to show the modified date.
• Open Graph. Plugins that print article:modified_time take it from the same field.

Feeds and archive order use the publish date, so a typo fix does not move a post to the top of the blog.

Does a newer date help rankings?

Not on its own. Google's sitemap documentation says it uses lastmod when the value is consistently and verifiably accurate, as a hint for scheduling recrawls. A changed date can bring the crawler back sooner; what it finds on the page decides everything after that. And for the date Google may display in results, its guidance is direct: do not artificially freshen a page without adding significant new information.

The practical risk runs the other way. If your modified dates change constantly for trivial reasons, the signal stops meaning anything:

• a bulk category change stamps hundreds of posts as "modified today";
• a find-and-replace across the database does the same;
• a visible "Updated: this week" on an article whose content is from 2021 misleads readers.

By the same documentation, a lastmod that is not reliably accurate is simply not used. That is the worst realistic outcome: you lose the hint, you are not penalised.

Keeping the date honest

For ordinary typo fixes, do nothing. One small edit now and then is noise that no search engine will hold against you.

For large mechanical changes, protect the date:

• Bulk edits. Know before you start that every post touched gets a new modified time. If your theme shows that date to readers, consider showing the publish date, or both, as your theme allows.
• Database-level edits. A search-and-replace run with WP-CLI (wp search-replace) writes to the database directly and does not update modified dates, which is usually what you want for a domain or URL change.
• Developers can keep the old value during a scripted update by passing the existing post_modified and post_modified_gmt through the wp_insert_post_data filter.

And for real updates, make the date deserved. When you revise an article's facts, examples or recommendations, the new modified date is accurate and useful: it invites a recrawl and tells readers the page is current. Our guide to refreshing old posts covers what counts as a meaningful update and whether to change the publish date as well.

To see what a search engine is told, open your sitemap, find the post, and compare its lastmod with the date printed on the page and the dateModified in its JSON-LD. The three should agree. The XML sitemap validator checks date formats.