Every treatment center blog eventually faces the same question: an article from two years ago still gets traffic, someone on the team wants it to look current, and the fastest way to make it look current is to change the date. That instinct is understandable. It is also the one change Google’s documentation names directly as a warning sign. This post explains how Google actually decides what date to show next to a page, which signals it reads, and what a real update looks like on a WordPress site.
What a byline date is, and where Google gets it
The date that sometimes appears beside a result in Google Search is called a byline date. Google describes it as its estimate of when the page was published or updated, and it shows it only when it considers the date useful to the searcher. The key word is estimate. Google’s byline date documentation says its systems do not depend on a single date factor, because every factor can be wrong; they look at several and pick a best guess.
In practice, the signals a site controls fall into three places:
- The visible date on the page: a labeled line such as “Published” or “Last updated” that a reader can see.
- Structured data: the
datePublishedanddateModifiedproperties on an Article, BlogPosting or similar Schema.org CreativeWork type. - The XML sitemap: the
<lastmod>value for the URL, which tells Google when the page last changed in a meaningful way.
When those three agree with each other and with what is actually on the page, Google has an easy job. When they disagree, Google has to choose, and it may not choose the date you wanted.
The rules Google actually publishes
Google’s guidance on byline dates is short and specific. A date is required in markup; a time is optional but recommended, with the correct timezone, including daylight saving time. The visible date and the structured date should match. Dates must describe when the page was published or updated, not the date of an event the page talks about, and they must never be in the future. If Google keeps picking the wrong date even after you follow those rules, the documentation suggests removing some of the other dates on the page.
The Article structured data documentation adds two details worth knowing. First, both datePublished and dateModified are recommended rather than required, and the Rich Results Test will not warn you if they are missing. A clean test result therefore tells you nothing about whether your dates are present or correct. Second, both values use ISO 8601 format, and if you leave out the timezone, Google defaults to the timezone used by Googlebot. A post published late in the evening Pacific time without a timezone offset can be read as the following day.
What counts as an update, in Google’s own words
Google’s Build and Submit a Sitemap documentation names three kinds of change that generally count as significant for a sitemap’s <lastmod> value: changes to the main content, the structured data, or the links on the page. It says a change to the copyright date does not count, and that Google uses <lastmod> only when it is consistently and verifiably accurate, which Google checks by comparing it with the page itself. The same page states that Google ignores the <priority> and <changefreq> values entirely.
Why changing the date alone backfires
Google’s guide to creating helpful, reliable, people-first content includes a list of self-assessment questions about search-engine-first content. One of them asks whether you are changing the date of pages to make them seem fresh when the content has not substantially changed. The next asks whether you are adding or removing large amounts of content because you believe it makes the whole site seem “fresh,” and Google answers its own question in parentheses: it won’t. We checked that wording on October 8, 2026; Google’s page showed a last-updated date of October 5, 2026.
Here is the mechanism, laid out the way we explain it to clients:
- Mismatched signals: a new visible date on unchanged content gives Google a date it can compare against its own stored copy and find false.
- Lost trust in lastmod: if the sitemap date moves with the visible date, Google learns that this site’s
<lastmod>values are not verifiably accurate, and can stop relying on them for pages that really did change. - Reader trust: a behavioral health article that says “Updated last week” but still describes an insurance rule or admissions process that changed two years ago is worse than one that honestly shows its original date.
- Competing dates on the page: a published date, a modified date, a “clinically reviewed” date and dated comments give Google four candidates. The documentation’s own advice is to reduce them.
What we see on WordPress treatment center sites
The date problems we find in audits are rarely deliberate. They usually come from how WordPress and its plugins record changes. WordPress updates a post’s modified timestamp whenever the post is saved, whether the edit was a rewritten section or a single fixed typo. The SEO plugins we commonly work with then use that same timestamp for the sitemap <lastmod> and the dateModified in the Article markup. So a bulk edit, such as reassigning a category across dozens of posts, can make every one of those unchanged articles report the same new modified date on the same day.
The second pattern is theme-specific. Some themes print the modified date under a “Posted on” label, which tells readers and Google that a two-year-old article was published yesterday. The third is common on healthcare sites: a “Clinically reviewed by” line with its own date that differs from both the published and updated dates. A clinical review line is valuable for readers and for showing expertise, but it is a third date in the article header, and Google’s documentation tells you plainly that extra dates can make its estimate harder.
None of these is a penalty trigger on its own. Each one makes the date signals less consistent, and consistency is the thing Google’s documentation keeps asking for.
A five-minute check you can run today
Pick your three most-visited blog posts and run this check on each one:
- Open the post and note the visible date and its label. Is it the published date, the updated date, or both, and is each one labeled?
- Right-click, choose View Page Source, and search (Ctrl+F or Cmd+F) for
dateModified. Compare it with the visible “Last updated” date. Confirm the value includes a timezone offset, such as-07:00. - Open your sitemap (usually
/sitemap_index.xmlor/sitemap.xml), find the post URL, and read its<lastmod>. - Ask one honest question: did the main content, structured data or links on this page actually change on that date?
If the three dates disagree, or if they agree on a date when nothing meaningful changed, you have found the problem. If the post shows more than two dates in its header, decide which ones a reader needs and remove the rest from the visible template.
How to refresh an older article the right way
A legitimate update is one a returning reader would notice. On treatment center sites that usually means replacing outdated insurance or admissions information, correcting clinical statements against current guidance, adding a section that answers a question families now ask, updating links that point to moved or retired pages, or rewriting the introduction so the page reflects how the program operates today. Once you have made a change like that, show a labeled “Last updated” date alongside the original “Published” date, keep datePublished fixed, and let dateModified and <lastmod> reflect the new date.
For practices publishing regularly, the fix is usually procedural rather than technical: agree on what counts as a substantial edit, make sure bulk edits do not touch post content, and choose a theme template that labels dates correctly. Our SEO services include this kind of template and sitemap audit, and the same consistency is part of how we approach answer engine optimization, since Google’s AI features draw on the same indexed pages. If the date problem traces back to the theme itself, it is usually best handled during a website rebuild or template revision rather than patched post by post.
The short version
Google estimates a page’s date from several signals and shows it only when it helps the searcher. Keep the visible date, the structured data and the sitemap in agreement, include a timezone, and only move the modified date when the main content, structured data or links have actually changed. Google’s documentation lists changing dates to make content seem fresh as a sign of search-engine-first content. On a behavioral health site, where readers rely on information being current, an honest date is part of the content’s credibility.
