What to Put in an XML Sitemap

An XML sitemap is a list of the pages you want search engines to find, handed to them directly instead of making them discover everything by following links. It will not rocket you up the rankings, but it helps the right pages get crawled — and it quietly reveals problems you did not know you had.

What a sitemap is and is not

A sitemap is an XML file listing your important URLs, each optionally tagged with when it last changed. You submit it in Search Console and reference it from robots.txt. It is a discovery aid: it tells crawlers "these pages exist and here is when they changed", which is especially useful for large sites, new sites with few inbound links, and pages buried deep in the structure.

What it is not: a ranking booster, or a guarantee of indexing. Listing a page does not force Google to index it — it only helps Google find it. The decision to index still depends on quality and crawlability.

Only include pages you actually want indexed

This is the rule most sitemaps break. Your sitemap should contain the canonical, indexable, 200-OK version of each page you want in search — and nothing else. Leaving junk in sends mixed signals and wastes crawl budget.

Keep these out of the sitemap:

• Pages that return errors or redirect (list the final destination, not the redirect).
• Pages blocked by robots.txt or marked noindex — including them contradicts your own instructions.
• Non-canonical duplicates. If two URLs show the same content, list only the canonical one.
• Login, admin, cart, thank-you and other utility pages.

A clean sitemap where every URL is a page you genuinely want found is worth far more than a giant one full of redirects and duplicates.

The fields that matter

Each entry can carry a few tags, but only some earn their keep:

• <loc> — the full URL. Required, and it should exactly match your canonical version (same protocol, same trailing-slash convention).
• <lastmod> — when the page last meaningfully changed. Google does use this if it is accurate. The catch: if every page claims to have changed today, Google learns to ignore your lastmod entirely. Only update it on real content changes.
• <priority> and <changefreq> — largely ignored by Google now. Harmless to include, but do not expect them to do anything.

So the honest minimum is accurate <loc> values and an honest <lastmod>.

Size limits and splitting

A single sitemap can hold up to 50,000 URLs or 50 MB uncompressed. Past that, split into multiple sitemaps and list them in a sitemap index — a sitemap of sitemaps. Large sites often split by section (products, articles, categories), which also makes it easier to see in reporting which section has indexing trouble.

Let it generate itself

The best sitemap is one you never edit by hand. On a database-driven site, generate it dynamically so new pages appear automatically and lastmod reflects real update times. A hand-maintained list rots the moment someone adds a page and forgets the sitemap.

Submit, then watch it

Once it is live, reference it from robots.txt and submit it in Google Search Console. Then actually read the coverage report — it tells you how many submitted URLs were indexed, and flags the ones that were not and why. That gap between "submitted" and "indexed" is one of the most useful diagnostics you have.

Validating that your sitemap is well-formed and every URL resolves, checking for broken links among those URLs, confirming none of them redirect, and running a broader audit of the site all run from your browser. Together they turn the sitemap from a file you forget about into an early-warning system for crawl and indexing problems.