Your sitemap has one field Google reads, and lying loses it

A sitemap entry can carry four things: the URL, a last modification date, a change frequency, and a priority. Google's own documentation disposes of half of them in one sentence: "Google ignores <priority> and <changefreq> values" (Google Search Central, Build and submit a sitemap, consulted 1 August 2026).

That leaves lastmod, and the wording on it is conditional in a way that most sitemap plugins ignore: "Google uses the <lastmod> value if it's consistently and verifiably accurate", with the example given being a comparison against the actual last modification of the page.

Read that as an instruction rather than as a description, because it is one. You are being told that the field is checked against reality, and that failing the check costs you the field. Which means a sitemap full of confidently wrong dates is strictly worse than a sitemap with no dates: you have paid for the field and taught the crawler to discount it.

How the dates go wrong without anybody lying

Nobody writes false dates on purpose. Three mechanisms do it for you.

The template touch. A shared layout, a footer, a navigation change. If your sitemap derives dates from anything that includes template files, every URL on the site ages at once, every time you adjust a menu. A date that moves everywhere simultaneously distinguishes nothing, which is exactly the pattern that reads as unreliable.

The rebuild. Dates taken from file modification times survive an in-place deploy and do not survive a fresh clone or a container built from scratch, which stamps every file with today. The first deploy after moving hosts announces that the entire site changed this morning.

The hand-maintained list. Somebody writes the dates in a configuration file, intending to keep them current. They are right on the day they are written and wrong every day after, and nothing in any test suite can notice, because there is no artefact to compare them against.

That third one is the trap we walked into on this site and had to walk back out of, so here is the fix rather than the warning. Every date in our sitemap is derived from something that exists independently of the claim. For a static page, the modification timestamps of the files that render it, plus the data files it reads. For an article or a category, the updated_at column, which the application already maintains for its own reasons. No date is written by a human anywhere, which means no date can be stale without something else also being stale.

The data-file part is the detail worth stealing. Our comparison pages contain no facts of their own: the facts live in a configuration file with its own survey date. Correcting a figure in that file is a modification of those pages, even though no template changed. If your date source only watches templates, content corrections are invisible to it, which is the precise case where you most want the crawler to come back.

What a sitemap is and is not for

It is a discovery mechanism and a freshness hint. It is not an indexing request, and inclusion confers nothing.

Two consequences follow, and both are commonly got wrong on client sites.

A page that is only reachable from the sitemap is an orphan. Being listed does not compensate for having no internal links; if nothing on the site points at a page, the site is saying the page does not matter, and the sitemap does not outrank that.

And a page in the sitemap that answers a redirect, a 404, or a noindex is a contradiction. You are asking for a crawl of something you have simultaneously declared uninteresting. Individually harmless, at scale it is the thing that makes the whole file untrusted. The one to watch for is the URL that answers 200 while telling a human it is missing, because it looks perfectly healthy to any check that reads only the status: a soft 404 is an error that answers 200.

The three checks worth running

Take a sample of URLs straight from the file and ask what they actually return.

curl -s https://example.com/sitemap.xml \
  | grep -oP '(?<=<loc>)[^<]+' | shuf -n 20 \
  | while read -r u; do
      printf '%s %s\n' "$(curl -sS -o /dev/null -w '%{http_code}' -L "$u")" "$u"
    done

Anything that is not 200 is a URL you are recommending and would not want visited.

Then check the canonical agreement, which is the mismatch nobody looks for. The URL in the sitemap must be the same string as the canonical the page declares, character for character. A trailing slash on one side and not the other, or http in the file and https on the page, is a disagreement between two of your own signals. We hit exactly this on the homepage, where the sitemap said https://uptimeez.com/ and the canonical said https://uptimeez.com: the same URL by the letter of RFC 3986, and flagged by validators, which costs somebody ten minutes every time they read the report.

And check the size limits, which arrive sooner than people expect on any site with facets or tags: 50 MB uncompressed or 50,000 URLs per file, per the same Google documentation. Beyond that, split and use an index.

The part that belongs to whoever is watching the site

A sitemap is generated, which means it can be generated wrongly and keep returning 200 while doing so. The failure modes are all silent: an empty file after a plugin update, a file that grew to include every filter combination, a file whose URLs all point at a staging hostname because an environment variable was wrong on one deploy.

None of that produces an error. The file is there, the server serves it, and the status code is fine. What is worth checking, on a schedule and per client site, is that the file parses, that the URL count has not moved sharply since yesterday, and that a sample of entries still answers 200. Three assertions, all cheap, all of a kind with the general problem that a healthy status code says nothing about whether the response is the thing you meant to publish: what a 200 does not prove.