Three Dates, One Page: When the Byline, dateModified and Meta Tags Disagree

Pick a blog post, open its source and count the dates. On one made-up but painfully familiar cooking blog, the byline says “Updated 12 March 2026”. Further up, the JSON-LD says dateModified is 27 February. Right next to it, an article:modified_time meta tag insists on 9 March. Three dates, one page, and none of them agrees with the others. It’s a calendar with commitment issues.

Nobody typed three different dates on purpose. A theme wrote one, an SEO plugin wrote another, and the CMS quietly moved the third when someone fixed a typo. Most advice stops at “make sure your dates match”, which is true and about as useful as “make sure your website works”. Dates rarely disagree on one page only. They disagree on every page built from the same template, and that’s where the fix is.

In short
A page can state its date in the visible byline, in JSON-LD datePublished and dateModified, in article:published_time and article:modified_time meta tags, in <time> elements and in the sitemap. Google asks for the visible and structured dates to match, and it weighs several signals because any of them can be wrong. When they disagree, the cause is usually a template, a plugin or a CMS setting, so trace one conflict back to the code that writes it and fix it there once. Dates aren’t a ranking lever and markup won’t buy you AI citations. This is about telling readers and search engines the same, true date.

Where a page says when it was published

A typical article page can carry its date in five places, and each one has a different audience:

• The visible byline. “Published 3 November 2025” or “Updated 12 March 2026”. This is the one readers see and the one that matters most to them.
• JSON-LD or Microdata. datePublished and dateModified on the Article or BlogPosting. Schema.org defines dateModified as the date the work was most recently modified. Search engines read it.
• Open Graph article tags. The Open Graph protocol defines article:published_time as the first publication and article:modified_time as the last change. Social platforms and plenty of other tools read them.
• The `<time>` element. The HTML standard treats its datetime attribute as the machine-readable version of what the element shows, so the attribute and the visible text should name the same day.
• The sitemap. lastmod says when the page last changed in a way that matters. It lives in another file and is often filled from another field.

Google’s byline date documentation is direct about the first two: “Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values.” It’s just as direct about why it doesn’t trust any single one: “Google doesn’t depend on a single date factor because all factors can be prone to issues.” Danny Sullivan said the same thing more casually in 2023, as reported by Search Engine Journal: “there are good reasons why we like multiple date signals present.”

Google’s documentation doesn’t name the Open Graph tags. Some plugin guides say Google reads them; we couldn’t find Google saying so. Keep them in line for the platforms that do read them.

Why the dates drift apart

The CMS has two fields and the template picks the wrong one

Most CMSs store a publication date and a last modified date. WordPress keeps both, in local time and in GMT: post_date, post_date_gmt, post_modified and post_modified_gmt, as its developer reference lists them. A theme that prints the modified date after “Published”, or the other way round, is wrong on every post. Consistently wrong, which is almost an achievement.

Someone types the “Updated” date by hand

Some themes and page builders give editors a text field for the update date. It works until the first edit where nobody remembers the text field. The structured date moves, the typed one doesn’t, and the byline ages quietly while the markup claims the page is fresh.

Two plugins, two opinions

An SEO plugin outputs JSON-LD, the theme outputs its own BlogPosting, and a recipe plugin adds a third block. Each reads whichever date field its developer preferred, so one page can carry two dateModified values that disagree before anyone has looked at the byline.

“Modified” often means “saved”

When WordPress updates a post, it sets post_modified to the current time, whatever changed. You can see it in the source of wp_insert_post(). Rank Math says it plainly: “WordPress by itself cannot distinguish whether a change is significant”, which is why it offers a Lock Modified Date option. Fix a comma, swap a photo, add a tag: congratulations, the article has been officially updated.

Google’s idea of a change that counts is narrower. Its sitemap guidance says “an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.” John Mueller is relaxed about automatic dates: if your CMS changes them by default and you can’t control it, he has said, that’s fine. The trouble starts when the automatic date and a hand-typed byline part ways. Moving the date forward on purpose is a different story, and our piece on content decay explains why it rarely helps.

The scheduled post that was updated before it existed

Finish a post on Friday, schedule it for Wednesday, and some setups record Friday as the modified time and Wednesday as the publication time. The page now claims it was updated five days before it existed, which is more time travel than most editorial calendars allow. A Yoast SEO issue opened in October 2023 described exactly this for dateModified and article:modified_time on scheduled posts. It was closed in January 2025 with a change titled “Only show a modified time tag if it’s later than the created time”.

Time zones and dates without an offset

A post that goes live at 23:30 on 14 March in New York is already 15 March in London. Write the time with an offset (2026-03-14T23:30:00-04:00) or in UTC (2026-03-15T03:30:00Z) and everyone can work out the same moment. Leave the offset out and you’ve set a puzzle. RFC 3339, the internet’s timestamp standard, says interpreting an unqualified local time “will fail in approximately 23/24 of the globe”. Google’s Article structured data documentation recommends giving a time zone, “otherwise, we will default to the timezone used by Googlebot”, and Google says that’s Pacific Time when it crawls from the US.

The software gets this wrong too. WordPress’s documentation for get_post_datetime() warns that the local and GMT values “might get out of sync in database, typically because of timezone setting changes”. In 2019 Yoast shipped a patch release because a bug in Yoast SEO 12.5 and WordPress 5.3 output a slightly offset publishing time. If it happens to the people who write the plugin, it can happen to your theme.

Cached and static pages

A full-page cache or a CDN serves HTML made at some earlier moment, a static site serves its last build, and the sitemap is often generated separately. We found no good study of how often this causes date conflicts, so treat caching as a suspect to rule out, not the usual culprit: when dates look impossible, check the cache headers before you rewrite a template.

How to trace a conflict back to its source

Don’t start by fixing the page. Start by finding out which code writes each date, because that’s what you’ll end up fixing.

1. Read the source, not the rendered page. View the page source or fetch it with curl, then search for datePublished, dateModified, published_time, modified_time and <time. Note every value and where it sits. Developer tools show the page after JavaScript has run, which may not be what a crawler received.
2. Name the writer of each value. Plugins often sign their output with an HTML comment, a class name or an @id pattern. The byline usually comes from a theme template such as single.php or a template part.
3. Match each value to a stored field. Is it the publication date, the modified date, a custom field, or the moment the page was generated?
4. Compare three pages built from the same template. If all three show the same pattern, it’s the template. If only one does, it’s that post’s data.
5. Check the whole site. A crawler with custom extraction, such as Screaming Frog’s, can pull every date field from every page into one table, from the raw or the rendered HTML. An audit can also do the comparing for you; more on ours below.

Fix it once, in the template

Once you know which field feeds each output, most of the work is plumbing.

• Decide what each date means. Published is the first publication and stays put. Updated is the last change a reader would care about. Write it down; the next developer will ask.
• Feed every output from the same field. The byline, the <time> element, JSON-LD and the article:* tags should read one stored value and only format it differently. If two plugins both write Article markup, switch one off instead of trying to keep them in step. Yoast documents a wpseo_schema_article filter for changing its Article output; use filters like that rather than adding another block.
• Don’t let a save do an editor’s job. If small fixes keep moving the modified date, lock it for minor edits (Rank Math’s option above) or keep a deliberate “last updated” field that editors change on purpose, and use it everywhere. Never let a template print the current time as dateModified.
• Always include the time zone. Use ISO 8601 with an offset, such as 2026-03-14T23:30:00-04:00, or UTC with a Z. Google asks for “the correct timezone, taking into account daylight saving time as appropriate”, so if your CMS lets you choose a city instead of a fixed offset, choose the city.
• Sort out scheduled posts. A modified date should never be earlier than the publication date. Update the plugin, or set both on publication.
• Retire legacy tags. og:updated_time isn’t part of the Open Graph protocol, and Yoast’s own Open Graph specification lists it as a legacy tag it removed in version 14.0 (April 2020). If your theme still prints it, that’s one more date to keep in sync for no benefit.
• Purge the cache after the fix, or you’ll see the old dates and start fixing the template again.

Here’s the difference in the page head, before and after:

<!-- Before: three writers, three dates -->
<p class="byline">Updated 12 March 2026</p>
<meta property="article:modified_time"
      content="2026-03-09T16:40:00+00:00">
<script type="application/ld+json">
{"@type": "BlogPosting", "dateModified": "2026-02-27"}
</script>

<!-- After: one stored value, three formats -->
<p class="byline">Updated
  <time datetime="2026-03-12T09:05:00+00:00">12 March 2026</time></p>
<meta property="article:modified_time"
      content="2026-03-12T09:05:00+00:00">
<script type="application/ld+json">
{"@type": "BlogPosting", "dateModified": "2026-03-12T09:05:00+00:00"}
</script>

When to leave it alone
Not every difference is a problem. A byline that shows only the publication date while dateModified is later is fine: they describe different things. A one-day gap is often the same moment in two time zones. A sitemap lastmod or an HTTP Last-Modified header newer than the page’s own dates is normal too; the HTTP standard describes Last-Modified as the latest change to any part of the response, so a template or sidebar change counts too. And an evergreen page doesn’t need a new date at all. As John Mueller put it: “Keep your dates, make it great.”

We checked our own blog first

Before writing this, we looked at deepspider.ai. Our blog template takes the visible date and its <time> element from the post’s publication date. JSON-LD dateModified comes from an update field we set by hand, or the publication date when it’s empty. Until this article went live, the sitemap took lastmod from somewhere else again: Sanity’s _updatedAt, a system timestamp that moves on every save.

On 18 October we gave our post on pages with few internal links a second category. Not a word of the article changed, but the page ended up with three dates:

Was that wrong? Not quite. The new category added a link to the page, and Google counts link changes as significant. DeepSpider wouldn’t have reported it either, since it doesn’t compare lastmod with a page’s own dates. But it showed how three honest fields end up telling three stories: the same timestamp would have moved for a typo fix. So we changed it. The sitemap now takes lastmod from the same field as dateModified, and the build checks that the two match on every post. The price is a rule we now have to keep: when an article really changes, someone sets the update date. A date a person decides on beats one a save button decides on.

What DeepSpider.ai checks, and what it doesn’t

Two checks look at dates.

Page dates that disagree compares the dates a page states about itself. It reads labelled visible dates (“Published”, “Updated” and their equivalents in Estonian, German, French, Spanish, Finnish and Japanese) from the article header or byline, the main JSON-LD or Microdata entity, article:published_time, article:modified_time and og:updated_time, and each <time datetime> against its own text. It reports dates for the same role that are 2 days or more apart, an update dated before the publication in a different source, dates more than a day in the future, and a site where dateModified equals the time of the request on most pages. That last one usually means a template printing “now”; Bing says it may ignore sitemap dates that are always the current date, and a dateModified that always says today is no more useful. The check is Informational and stays outside Website Health Score: Google documents no ranking effect, and a wrong date is something to fix, not a score to lose.

Schema date inconsistencies is narrower. It reports a valid dateModified that is earlier than datePublished on the same JSON-LD entity. It’s a Warning and counts towards the score. Invalid property values, a separate check, flags datePublished and dateModified values that aren’t valid ISO dates at all.

In the check details, the suggested fix follows the kind of conflict found on your pages, so a scheduled post gets scheduled-post advice and a time zone gap gets none at all.

What they don’t do:

• They read the source HTML, so dates added by JavaScript aren’t seen.
• Home pages, listing pages and pages with several visible dates for one role aren’t judged on their visible dates.
• Unlabelled dates, years in URLs, copyright years, the HTTP Last-Modified header and sitemap lastmod aren’t compared with the page’s dates. Invalid or suspicious lastmod checks the lastmod values themselves for malformed and future dates.
• No check can tell you which date is true. They tell you where the page disagrees with itself; deciding which date is right is still your call.

Frequently asked questions

Do consistent dates improve rankings?

Nothing we found says so. Google’s documentation is about which date it shows, not about ranking, and John Mueller has said Google wouldn’t rank a page differently just because its date changed. In a 2022 SearchPilot test, adding dateModified to store pages was inconclusive for organic traffic and wasn’t enough on its own to get dates shown in results. Fix dates so people see the right one.

Will structured data dates help my pages appear in AI answers?

Don’t count on it. Google’s guide to generative AI features says “Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add”, while still recommending it for rich result eligibility. Ahrefs tracked 1,885 pages that added JSON-LD against 4,000 control pages and found “no major uplift in citations on any platform”. Accurate dates are worth having, just not as an AI trick.

Should I show both the published and the updated date?

If the page has changed meaningfully since it was published, showing both helps readers. Google’s guidance covers datePublished, dateModified or both. Label each one clearly and make each match its structured counterpart.

Can I just remove the dates?

You can, but search engines still have to decide how old the page is. Mueller has pointed out that Google still keeps time when a page has no date. For news and advice that ages, readers want a date. For a contact page, nobody minds.

The short version

A page that disagrees with itself about its own date is almost never a one-page problem. Find every place the date is written, name the code that writes each one, and make them all read the same stored field, with a time zone. Change the modified date when the content really changes, retire the tags nobody reads, and leave honest differences alone. Your dates won’t rank you higher, but your pages will stop being out of date in three different ways at once, and your readers will know how old the advice is.

Sources