How to create a sitemap: the four fields, and the two Google ignores

To create a sitemap you need one file listing the absolute URLs you want in search results, hosted at your site root, in UTF-8. Two of the four fields people fill in are ignored by Google outright. The file does not get anything indexed; it tells a crawler what exists and, if you are honest with one field, when it last changed.

Before you start

You need a list of the pages you want ranked, which is not the same as a list of your pages. Filtered listings, tag archives, paginated duplicates and thank-you pages should be left out, not because a sitemap punishes them but because the file is a statement of intent that other signals get compared against.

If your content system already generates a sitemap, do not build a second one. Read the one you have first — most of this chapter is then a review rather than a build.

Why two of the four fields are dead weight

The XML sitemap format allows four elements per URL. Google's sitemap documentation, read on 2026-08-24, disposes of half of them in one line: "Google ignores <priority> and <changefreq> values."

The conditional on the second row is the interesting one, and it is a condition, not a preference: Google "uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate". The documentation then defines what counts, which is the part that gets ignored most often — "an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not".

So a template that stamps today's date on every URL every night is not sending a strong freshness signal. It is sending a field that can be checked against the page and found wrong, on every URL, every night. We measured how common that is: 13 of 24 sites say nothing with their lastmod.

A sitemap is a claim about your site that a crawler can verify. Every field you fill in dishonestly is a claim that fails the check.

How to create a sitemap in five steps

The whole job is about twenty minutes by hand for a small site, and it is worth doing by hand once even if a plugin will take it over afterwards. Doing it manually is what tells you which of your URLs you were not expecting to see.

1. List the URLs you want in search results, as fully-qualified absolute addresses. Google's guidance is explicit that relative paths do not work: "Google will attempt to crawl your URLs exactly as listed."
2. Write one <url> block per address, with <loc> and, if you can produce it truthfully, <lastmod>. Escape any ampersands and other entities, as in every XML file.
3. Save it as UTF-8 and put it at the site root. Location matters: "unless you submit your sitemap through Search Console, a sitemap affects only descendants of the parent directory".
4. Declare it in robots.txt with a Sitemap: line, and submit it in Search Console. The two routes are independent and both are cheap.
5. Split at the limits. A single sitemap is capped at "50MB (uncompressed) or 50,000 URLs" — past either, break it up and submit a sitemap index instead.

Step 4 has a second benefit that only shows up on larger sites: submitting several sitemaps separately lets you read coverage per group in Search Console, which is how you find out that one section of the site is being indexed and another is not.

The deliverable: two files and one count

A minimal sitemap. This is the whole format — there is no header block to get right beyond these two lines:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/foo.html</loc>
    <lastmod>2026-08-24</lastmod>
  </url>
</urlset>

A sitemap index, for when you cross a limit or want per-section reporting:

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

And the count, which is the check worth running after every deploy — it tells you how many URLs you are actually claiming and whether the file is anywhere near a limit:

curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*' | sed 's/<loc>//' | tee /tmp/sitemap-urls.txt | wc -l

# Bytes, against the 50MB ceiling
curl -s https://example.com/sitemap.xml | wc -c

# Anything listed that does not return 200
while read -r u; do
  printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$u")" "$u"
done < /tmp/sitemap-urls.txt | grep -v '^200'

What goes wrong, and how to recognise it

The sitemap lists URLs that redirect

Symptom: Search Console reports pages as "Page with redirect" in numbers that match a section of your site. Cause: the file was generated before a URL change. The third command above finds these in one pass.

The sitemap and the canonical disagree

Google's canonicalization guidance warns against exactly this: do not "specify one URL in a sitemap, but a different URL for that same page using rel="canonical"". Sitemap inclusion is a weak canonicalization signal, so the contradiction does not usually win — it just wastes the signal.

Mobile and desktop URLs both listed

If a page has separate addresses, Google recommends "pointing to only one version in a sitemap". Listing both without annotation asks the crawler to decide something you already know.

The file exists but nothing points at it

A sitemap nobody has been told about is only found by convention. The robots.txt line costs one line; we found who declares one and whether it opens varies more than you would expect.

What a sitemap will not do

It will not get a page indexed. It makes a page discoverable, which is a different and much weaker claim, and it does nothing at all for a page that is discoverable already through your own links. On a small site with clean internal linking, the sitemap's realistic value is as a checklist you can diff against, not as a traffic input.

It also cannot rescue a page that is blocked, broken or deliberately excluded. Listing a URL that returns a redirect, a 404 or a noindex does not override any of those. Stop when the URL count in Search Console matches the count in your file and the discovered pages are the ones you meant. There is no further state.

The step after this one is telling engines that something changed, which is a different mechanism with its own failure modes — see how to get a page indexed faster. If you want the whole chain from crawl to citation rather than one file, the diagnosis path starts here.

Common questions

Do I need a sitemap at all?

Not if your site is small and every page is reachable from your own links. It becomes useful when the site is large, when pages are poorly linked, or when you want per-section coverage reporting. Deciding to create a sitemap anyway costs almost nothing, which is why the answer is usually yes in practice and no in principle.

Where should the sitemap file live?

At the site root, because a sitemap "affects only descendants of the parent directory" unless submitted through Search Console. A file at /blog/sitemap.xml cannot speak for /products/.

Can I use an RSS feed as a sitemap?

Yes. Google accepts RSS 2.0 and Atom 1.0 feeds submitted as sitemaps, with one caveat worth repeating from the documentation: a feed "only provides information on recent URLs". It is a good freshness channel and a poor inventory.

How many URLs can one sitemap hold?

50,000, or 50MB uncompressed, whichever you hit first. Past that you split the file and submit a sitemap index. Most sites are nowhere near either number, and the ones that are usually discover it through a validation error rather than a count.