XML sitemaps, explained

What a sitemap is, and where it lives

An XML sitemap is a machine-readable list of the URLs on your site you want search engines to discover. It conventionally lives at yoursite.com/sitemap.xml — though the name and location are flexible as long as you declare it — and it follows the shared sitemaps.org 0.9 schema.

Think of it as a discovery aid, not a directive. It helps crawlers find pages they might miss — deep pages, freshly published ones, pages with few internal links — but it does not force indexing and it never replaces good internal linking. Listing a URL is an invitation, not a command.

The format, field by field

A sitemap is a <urlset> root containing one <url> entry per page. Each entry has one required child and a few optional ones:

• <loc> — required. The full, absolute URL of the page. Must be a canonical, indexable URL.
• <lastmod> — the date the page was last meaningfully changed, in W3C Datetime format (a plain YYYY-MM-DD is fine). This is the field Google actually reads — when it is accurate.
• <changefreq> — a hint (daily, weekly, …) at how often the page changes. Google mostly ignores it.
• <priority> — a 0.0–1.0 relative importance hint. Google ignores it entirely; it was abused too widely to trust.

The practical takeaway: keep lastmod truthful and don’t bother tuning priority or changefreq. A lastmod that lies (e.g. set to “now” on every page, every build) trains Google to ignore your lastmod altogether.

A copy-paste example

A minimal, valid sitemap — swap in your URLs and real modification dates:

<?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-08-25</lastmod>
  </url>
  <url>
    <loc>https://example.com/guides/xml-sitemaps</loc>
    <lastmod>2026-08-25</lastmod>
  </url>
  <url>
    <loc>https://example.com/pricing</loc>
    <lastmod>2026-07-14</lastmod>
  </url>
</urlset>

Serve it as application/xml (or text/xml) at a 200, UTF-8 encoded, with URL-encoded special characters in each <loc>.

Limits, and sitemap index files

A single sitemap file may hold at most 50,000 URLs and must be no larger than 50MB uncompressed. Hit either limit and you split the URLs across several sitemap files, then list those files in a sitemap index — a <sitemapindex> file that points at other sitemaps rather than at pages:

<?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-25</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-08-25</lastmod>
  </sitemap>
</sitemapindex>

You submit the index file, and the crawler follows it to each child sitemap. An index may itself reference up to 50,000 sitemaps — plenty of headroom for very large sites. You can also gzip any sitemap; the 50MB ceiling applies to the uncompressed size.

Only canonical, indexable URLs

A sitemap should list only canonical URLs that return a 200 and that you want indexed. Keep out:

• URLs that redirect (301/302) — list the destination, not the redirect.
• Pages that return 404 or 5xx.
• Pages carrying noindex — a sitemap that lists a page you also noindex sends two opposite signals.
• Non-canonical duplicates — the trailing-slash, query-param or www variants that point elsewhere via rel=canonical.
• URLs blocked in robots.txt — the crawler can’t fetch them anyway.

A clean sitemap that matches your canonicals is a strong consistency signal; a messy one wastes crawl budget and muddies which URL you actually want ranked. If you haven’t nailed down your canonicals, start with the canonical URLs guide.

Declaring and submitting it

Do both of these — they cover different crawlers:

1. Declare it in robots.txt. Add a global Sitemap: https://yoursite.com/sitemap.xml line. Any crawler that reads robots.txt then discovers it — no console needed.
2. Submit it in Search Console. Google Search Console (and Bing Webmaster Tools) let you submit the sitemap URL explicitly and report how many URLs were discovered, indexed, and any parse errors — your feedback loop.

The trio: permission, coverage, comprehension

A sitemap is one of three files that shape how machines read your site — and they answer three different questions:

• robots.txt — permission: where crawlers may go.
• sitemap.xml — coverage: which pages exist and want to be found.
• llms.txt — comprehension: the curated map that helps AI answer engines understand your site.

They complement each other rather than overlap — a site that gets all three right is legible to search crawlers and AI engines alike.

Common mistakes

• ✕A lastmod that always says “now”. Stamping every URL with the build time on every deploy makes lastmod meaningless — Google learns to ignore it. Only bump it when the page’s content actually changed.
• ✕Listing non-canonical or redirected URLs. Including redirects, duplicates or noindexed pages sends mixed signals and wastes crawl budget. List only the canonical 200s.
• ✕Blocking the sitemap in robots.txt. Disallowing the path the sitemap lives under means a crawler can’t fetch the very file you pointed it at.
• ✕Letting it go stale. A sitemap that still lists deleted pages, or never adds new ones, slowly drifts out of sync with the site. Regenerate it on build or on a schedule.
• ✕Ignoring the limits. One giant file past 50,000 URLs or 50MB is rejected — split it and use a sitemap index instead.

How to check it

After editing, fetch yoursite.com/sitemap.xml directly and confirm it returns a 200 as XML, is well-formed, and lists the URLs you expect — all canonical, all 200. Then submit it in Search Console and watch the coverage report for discovered vs. indexed counts and any errors.

AvocadoScore checks that your sitemap exists, is reachable and is declared in robots.txt — as part of the readiness scorecard and the full audit.