Sitemap hygiene before year-end: a worked example.

Why the sitemap file belongs in a year-end audit

A sitemap is a plain list of the addresses you say matter. Over twelve months that list drifts. Pages are removed, a shop moves from http to https, a redesign changes the habit of ending addresses with a slash, an export script stamps every row with the same date. The file keeps saying whatever it said the last time something generated it.

Search documentation describes a sitemap as a hint: submitting one does not guarantee that it will be downloaded or that its addresses will be crawled. That is a useful frame for the year-end audit. The aim is not to chase an outcome. The aim is a file that is accurate, consistent and within the published limits, so that it says what you mean.

Put it on the calendar for the first week of January, next to the other year-end audit tasks. An hour is enough for a small site: export the file as it is served today, run it through the sitemap XML checker, fix the cause of each finding, and write down the counts.

The limits, as plain numbers

The protocol sets a few hard numbers. Keep them in front of you while you read the file:

• 50,000 URLs in one sitemap file.
• 50 MB, which is 52,428,800 bytes, for one file before compression. A compressed file is allowed, but the limit applies to the uncompressed size.
• Fewer than 2,048 characters in each address.
• 50,000 sitemaps at most in one sitemap index.
• UTF-8 text, nothing else.

A file over either limit should be split into several files, which you then list in a sitemap index. Splitting by section of the site (guides, products, pages) also makes the year-end audit easier, because each file has one owner and one purpose.

Full addresses, one host, one scheme

Search documentation asks for fully-qualified, absolute URLs and says it will attempt to fetch them exactly as listed. A relative location such as /pricing/ has no host, so the reader of the file has nothing to join it to. The protocol adds that every address in a file should come from a single host and use the same protocol as the sitemap.

Two mistakes account for most findings here. The first is the www and non-www forms of a host appearing side by side, usually because two data sources were merged. The second is http addresses surviving a move to https. Pick your canonical host and your preferred scheme once, enter them in the checker, and treat every address that disagrees as a finding.

Fix these at the source: the site address setting or the script that writes the file. Editing the output by hand fixes this year’s file and nothing else.

Escaping, encoding and the invisible first character

Five characters must be written as entities inside an XML sitemap: ampersand (&), single quote ('), double quote ("), greater-than (>) and less-than (<). A bare ampersand in a query string is the classic break: the XML stops being well-formed, and a strict reader may stop at that line. The opposite slip is escaping twice, which turns one ampersand into & and changes the address.

Wrapping an address in CDATA is also valid XML and avoids the escaping question, so a reader of the file must accept both forms. The checker does, and it reads each value once.

Last, the encoding. The file must be UTF-8. A byte order mark in front of the XML declaration is invisible in most editors but can upset strict readers, so save as UTF-8 without a mark. Non-ASCII characters in an address should be percent-encoded.

Slashes, letter case, fragments and query strings

A site usually has one habit about trailing slashes, and a sitemap that mixes both is a sign that two sources were merged. /pricing and /pricing/ may be served as one page or two. Choose one form for page addresses, leave file names such as /guide.pdf alone, and make every entry match.

Host names are not case-sensitive but paths usually are, so /About/ and /about/ could be one page listed twice or two different pages. Open both on your own site before deciding. Check that you do not list one page under two spellings.

A #fragment points inside a page; it is not a separate address and does not belong in the file. Query strings need a judgement call: a filter, a sort order and a tracking tag are all the same page in different clothes. List the clean version and remove the variants you do not want to stand for the page.

lastmod: honest dates or none

The protocol asks for W3C date format. A date alone is fine (2026-12-31); when a time is given it needs a time zone, as Z or an offset such as +01:00. 10/09/2026 is ambiguous and 2026-09-28 10:00:00 has a space where a T belongs, so both are invalid.

Search documentation says a date is used only when it is consistently and verifiably accurate, and that it should reflect the last significant update to the page: changing a copyright year does not count. The protocol makes the same point from the other side: the date is for when the page changed, not for when the sitemap was generated. The same documentation says priority and changefreq values are ignored, so there is no year-end audit work to do on them.

A date in the future cannot be a change date, whatever the time zone. The checker compares each value as an instant, so 2026-10-17T14:00:00+02:00 is read as noon in UTC, and a bare date is only called late when it is later than today everywhere on Earth. If you cannot keep a date true, leave it out.

A worked example with twelve URLs

Here is a small file for www.example.com, preferred scheme https. Each entry is shown as written, with what the checker says and what the corrected list contains.

1. https://www.example.com/ lastmod 2026-09-28

   Finding none

   Kept as written.

2. https://www.example.com/pricing/ lastmod 2026-09-12

   Finding none

   Kept as written.

3. https://www.example.com/pricing lastmod 2026-09-12

   Finding Trailing slash differs: the same page as entry 2 without its slash.

   Corrected: left out, entry 2 already covers it

4. http://www.example.com/about/ lastmod 2026-08-02

   Finding Scheme differs from your preferred https.

   Corrected: https://www.example.com/about/

5. https://example.com/contact/ lastmod 2026-07-21

   Finding Other host: the non-www form of www.example.com.

   Corrected: https://www.example.com/contact/

6. /blog/year-end-checklist/ lastmod 2026-09-30

   Finding Relative location: no scheme or host.

   Corrected: https://www.example.com/blog/year-end-checklist/

7. https://www.example.com/blog/sitemap-hygiene/ lastmod 2026-09-24T09:15:00+01:00

   Finding none

   Kept as written.

8. https://www.example.com/Blog/Sitemap-Hygiene/ lastmod 2026-09-24

   Finding Differs only by letter case from entry 7.

   Corrected: left out until you confirm it is the same page

9. https://www.example.com/shop/?sort=price#reviews no lastmod

   Finding A #fragment, a query string and no lastmod.

   Corrected: https://www.example.com/shop/?sort=price

10. https://www.example.com/guides/faq/ lastmod 10/09/2026

    Finding Invalid lastmod: the day and month order is ambiguous.

    Corrected: address kept; rewrite it as YYYY-MM-DD

11. https://www.example.com/guides/returns/ lastmod 2062-09-30

    Finding lastmod in the future: a typo for 2026.

    Corrected: address kept; correct the date

12. https://www.example.com/ lastmod 2026-09-28

    Finding Duplicate of entry 1.

    Corrected: left out

The checker reports 12 entries, 11 unique and 1 duplicate. It raises ten things to fix and one to look at (the query string in entry 9). The corrected list keeps 9 addresses: 4 of them corrected, 3 left out. The two date problems are in the CSV rather than the list, because only the person who owns the page knows the true date. Open the checker and press “Fill in the 12-URL example” to run exactly this file.

A year-end audit routine in seven steps

1. Export the live file. Take the copy your site serves today, not the one in your editor.
2. Paste it and set the host and scheme. Use the form you want visitors to see.
3. Read the fixes in order. File-level findings first, then addresses, then dates.
4. Fix the source. Change the setting or script that writes the file. Use the corrected list only as a stopgap.
5. Check again until nothing is left to fix.
6. Compare the unique count with your page inventory. A large gap either way is worth an hour.
7. Write down the date and the counts so next year starts from a baseline.

The same pages deserve a second look in other places. The self-check scores whether each page is built to be quoted, and the llms.txt generator turns your key addresses into a short summary file. Both start from the list you have just cleaned.

A clean report means the file is consistent, within the limits and says what you intend. Treat it as housekeeping for the file itself, and carry on with the content work that matters.