The Date Can Be True.

The Signal Can Still Be Ignored.

Google and Bing both read a sitemap’s modification dates as a freshness signal, and both condition its use on accuracy. Google’s own words: if the dates stop matching reality, “eventually we’re not going to believe you anymore.” Bing: suspicious dates may be disregarded. Neither says how widely that disbelief spreads. The consequence is narrower than a switch, and still serious: a real update can lose the one signal that might have brought the crawler back sooner.

By William Douglas Baker

Founding Editor

You changed the page. A corrected credential. A revised position on a point of law. Updated clinical guidance. The kind of change you would want a machine to know about before it answers a question about you. The page updated. The sitemap said so. But the date was a signal, not an instruction. If the site’s dates had failed to match reality often enough, the crawler was free to set the signal aside and find the change on its own schedule.

The signal is one field in an XML sitemap: lastmod, the timestamp that tells a crawler when a page last meaningfully changed. Google says what it does with it: “a signal for scheduling crawls to URLs that we previously discovered.” And what it requires: the value is used “if it’s consistently and verifiably … accurate,” and if the dates stop matching reality, “eventually we’re not going to believe you anymore.” In June 2024, when a practitioner asked whether Google keeps something like a reputation score for how far to trust a site’s dates, Gary Illyes of Google Search Relations gave a one-line answer, as reported by Search Engine Journal: “It’s binary: we either trust it or we don’t.”

Not a curve. A decision: use the signal, or set it aside. What Google has not said is the level at which that decision lives. A URL. A pattern of URLs. A sitemap. A host. Its own guidance runs the other way from any single switch: use lastmod “for all the pages in your sitemap, or just the ones you’re confident about,” and where a date cannot be known, leave it out. This July, a practitioner told Illyes a bug had stamped “a set of unintentionally incorrect dates” across his site and asked whether it would be better off with no dates at all. Illyes’s reply the next morning, on his own record: “probably better off without the lastmods.” Bing’s own documentation, from February 2023, is discretionary and ends in the same place: where dates are “consistently set to the current date, we will suspect the validity of those dates and may disregard them.” Both establish the consequence. Neither establishes a switch that spans the sitemap.

What flips the switch is rarely deception. It is a content management system that stamps today’s date on every URL every time the site rebuilds, a default so ordinary that when Bing measured it, 18 percent of the sitemaps carrying a modification date had it set wrong. The most prevalent fault, Bing found, was dates that were all identical; after consulting webmasters, Bing traced most of them to the day the sitemap was generated rather than the day the content changed. John Mueller of Google, asked about a competitor whose sitemap showed today’s date on everything, named it, as reported by Search Engine Roundtable: “it’s just lazy.” Lazy, and expensive. Once the dates stop being believed, the page that actually changed loses one signal that could have brought the crawler back sooner.

The wrong moment

This would be a search-hygiene footnote if the answer layer ran on a different clock. It does not. Bing states it in one sentence: “For AI powered search engines like Bing, freshness signals directly influence how quickly updates are reflected in search results and AI generated answers.” Google’s AI features draw on the ordinary Search index: a supporting page must be “indexed and eligible to be shown in Google Search,” with “no additional technical requirements.” That makes crawl freshness relevant upstream. It does not establish that an ignored date delays any particular AI Overview or AI Mode answer, and Google has not written the sentence that would. Bing supports the direct connection. Google supports an architectural one.

The record has a name for what follows. Contextual Ambiguity — the third clinical characteristic of Digital Derangement Syndrome™: the system lacks clarity about when and why an entity should be surfaced. Usually the failure is the why: the wrong room, the wrong buyer. This one is a failure of the when. Right entity. Right page. Possibly cited before. And one machine-readable freshness signal has gone unreliable, raising the odds that the indexed version lags the published one. In this record’s terms, Contextual Ambiguity expressed through time: not uncertainty about who the entity is, but about whether the machine has come back to see what changed. Edition No. 038 filed a record that stopped listening while the machines kept citing it. This is the inverse: a record that kept updating, and lost the ability to prove it.

Most of the sites this describes did nothing wrong on purpose. A plugin shipped a default. A deployment touched every file. A generator recorded when it ran instead of when the content changed. The result is a signal that looks precise and means almost nothing.

The machine does not owe your dates belief. Accuracy earns their use.