XML Sitemaps: The Fields That Matter and the Two Google Ignores

Sitemaps are the most over-explained and under-understood file in technical SEO. People tune <priority> values like they are adjusting a graphic equalizer, and Google has been throwing that number away the entire time. Meanwhile the one field that genuinely helps gets filled with today's date on every URL, every night, which turns it into noise. Let me sort out which parts do work.

What a sitemap is for

A sitemap answers exactly one question: which URLs exist on this site? It is a discovery aid. It helps crawlers find pages that are buried deep, poorly linked, or brand new. That is genuinely useful.

What it does not do is make a page rank, or force a page to be indexed. Listing a URL is a suggestion. Google decides on the merits, and plenty of submitted URLs never get indexed at all. If a page is not indexed, a sitemap entry is not the missing ingredient.

The five fields, honestly rated

Sitemap fields and whether Google uses them

Field	Required?	Does Google use it?
<loc>	Yes	Yes. This is the whole point.
<lastmod>	No	Yes, if it is consistently accurate. Google has said it ignores the value from sites that lie.
<changefreq>	No	No. Ignored.
<priority>	No	No. Ignored.
<xhtml:link>	No	Yes, for declaring language and region alternates.

Google's own documentation and its search advocates have been consistent for years: changefreq and priority are ignored. They are not penalties, they are just inert. Setting every page to 1.0 does nothing, and neither does carefully grading them.

lastmod is the interesting one, because it is the only field where you can actively make things worse. If your build stamps every URL with the current timestamp on every deploy, you are telling Google that all 40,000 pages changed at 3 a.m. Google notices that pattern and stops trusting the field. Set it to when the content actually changed, or leave it out. A missing lastmod is better than a fictional one.

A sitemap that validates

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-07-28</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/cache-headers</loc>
    <lastmod>2026-08-01T09:30:00+00:00</lastmod>
  </url>
</urlset>

Rules that trip up hand-written files:

• The xmlns declaration is mandatory. Without it the file is not a sitemap, it is XML-shaped text.
• URLs must be absolute, including the scheme.
• & in a query string must be escaped as &. This is the single most common validation error.
• lastmod uses W3C Datetime format. A plain YYYY-MM-DD is valid, and so is a full timestamp with an offset.

The limits, and what to do when you hit them

One sitemap file holds at most 50,000 URLs and must be no larger than 50 MB uncompressed. Gzip is allowed and the 50 MB ceiling applies to the uncompressed size.

Past that, you use a sitemap index, which is a sitemap of sitemaps. An index can itself point at up to 50,000 sitemaps:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-08-01</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-08-03</lastmod>
  </sitemap>
</sitemapindex>

Splitting by content type rather than by arbitrary chunks pays off immediately, because Search Console reports coverage per sitemap. If sitemap-blog.xml shows 12 indexed out of 400 submitted, you have learned something specific. One giant file tells you nothing.

Only list URLs you would defend

This is where most sitemaps go wrong. Every URL in a sitemap is a claim: this is a real, canonical, indexable page. Contradict that claim and you are sending mixed signals about your own site.

Do NOT list:
  - URLs that redirect (3xx)
  - URLs that 404 or 410
  - URLs with a canonical tag pointing somewhere else
  - URLs you have marked noindex
  - URLs blocked in robots.txt

That last combination is a real self-own: a URL that is in your sitemap and blocked by robots.txt is you asking a crawler to look at something you have simultaneously told it not to fetch. Search Console flags it, and rightly so.

Getting it discovered

Two ways, and you should do both. Reference it in robots.txt, which every major crawler reads:

Sitemap: https://example.com/sitemap.xml

And submit it in Google Search Console and Bing Webmaster Tools, which is also how you get the coverage reporting.

One niche detail: a sitemap can normally only list URLs on the same host it is served from. Cross-site submission is possible, but only if you have verified ownership of both hosts in Search Console. For nearly everyone, "keep it on the same domain" is the rule.

Build it, don't type it

For a site with a database behind it, generate the sitemap from the same query that decides what is publicly visible. Then the sitemap cannot drift out of sync with the site, because there is one source of truth. For a static site or a one-off list of URLs, our sitemap.xml generator takes a list of URLs and gives you a valid file, escaping and all. Pair it with the robots.txt generator so the Sitemap: line points at the right place.

The short version

Include <loc>. Include an honest <lastmod> or none at all. Skip <changefreq> and <priority> entirely, because nobody is reading them. Split large sites by content type so the reporting is useful. And list only canonical, indexable, 200-returning URLs, because a sitemap full of redirects and dead pages is worse than no sitemap at all.