Guide · Sitemap
A sitemap that tells the truth
Almost every site has a sitemap.xml. Far fewer have an accurate sitemap. The difference comes down to a single field, far more than to the format, which remains trivial: the last-modification date. It's the one filled in fastest, checked least, and the one that decides the order in which a search engine comes back to you.
Five things a sitemap declares
Every line in a sitemap is a claim about your site, and a search engine treats it as such. The five points below can be verified from the evidence, from the file as served.
01
A sitemap declares, the search engine decides
The sitemap.xml file lists the URLs you want indexed, and for each one the date it last changed. A search engine uses it to discover what it's still missing and to decide where to come back first. It remains in charge of its own path: it reads you.
See it: Request /sitemap.xml and read it. Every entry must be a real page, served with a 200, at the exact URL the site publishes — same protocol, same domain, same trailing slash.
Holding it: A sitemap generated by the publication process itself. A hand-written list drifts from the second release onwards.
02
The date is the field most often wrong
This was our own incident, on 27 August 2026: six pages out of seven announced "modified on 17 August" in our sitemap, while IndexNow was telling search engines those pages had just changed. The two signals contradicted each other. The cause came down to one line — the dates were written by hand. A hand-written date always ends up lying.
See it: Take three pages at random from your sitemap and compare their lastmod with the actual last modification of their text. If all three carry the same date, or today's date, you're reading a publication timestamp where the search engine expects a modification date.
Holding it: A script compares the visible text of the page about to be published with that of the page currently online, and only dates today what has genuinely changed. The other pages keep their date. That's the fix we put in place, and it's the one that holds.
03
What a search engine does with a date that lies
A date serves to prioritise crawls. If a whole site re-dates itself at every release, all its pages look alike: the signal flattens out, and the search engine reverts to the rhythm it had chosen on its own. The order of visits then remains its own; an accurate date is the only lever a sitemap gives you over it.
See it: Publish a correction on a single page, then read the sitemap again. Only one line should have moved.
Holding it: A date that only moves when the content changes. On 7 September 2026, an audit of our site showed that the sitemap re-dated every page at each publication; four distinct causes were fixed, and the script then left the sitemap untouched, each page keeping its date.
04
What a sitemap contains
A URL earns its place in the sitemap when three conditions hold together: the path is open to crawling in robots.txt, the page declares itself indexable, and its canonical URL points to itself. The three go together: listing a URL that the rest of the site excludes amounts to giving two contradictory instructions within the same site.
See it: For each URL in the sitemap: is the path allowed by robots.txt? Does the page declare itself indexable? Does its canonical point to its own URL?
Holding it: Keep in the sitemap only the pages you stand behind as indexable. A sitemap is exactly that: the list of pages you want indexed.
05
Language versions are part of the sitemap
A translated page is a page in its own right: it must be submitted like any other, and its membership of the group must be readable from the sitemap. The seorecords.com sitemap carries, for each page, the complete hreflang cluster in xhtml:link.
See it: Open a sitemap entry corresponding to a translated page. It must list every language in the group, and that list must be the same from one entry to the next.
Holding it: Generate the cluster in the same place as the sitemap, from the same source. Two lists maintained separately will diverge.
Checking your sitemap in four steps
These four steps can be done with the naked eye, with the file in front of you. All they require is reading it instead of assuming it's right.
- 01Request the file and check that it comes back as 200 and as XML: an error page in disguise gives itself away by its content.
- 02Count its URLs and compare that number with the number of pages you want indexed. A clear gap shows up immediately.
- 03Pick three URLs at random and follow them: response code, canonical, indexing directive.
- 04Publish a single correction, then read the sitemap again: only one date should have changed.
An observation drawn from our two rounds: the sitemap is the last place anyone looks for a mistake, because it's generated and therefore assumed to be mechanical. It only truly becomes mechanical the day you read it again. In our case, it took two successive reviews for the date to tell the truth, line by line — and today it's a check that runs at every publication.
Read your sitemap the way a crawler reads it
The Checker reads your address and reports the status of your signals, free of charge, in about ten seconds. Your site remains entirely yours: the reading is done from the outside. The Audit SEO Records goes further: it reads your entire sitemap, page by page, and delivers a dated report.