What a sitemap is for
An XML sitemap is a list of URLs you would like search engines to know about. That is the whole job.
It is a discovery aid. It helps a crawler find pages that are poorly linked, newly published, or buried deep in the structure. It does not make pages rank, it does not guarantee indexing, and submitting a URL does not oblige anyone to index it.
This matters because of how often a sitemap is treated as a remedy. A page that is not indexed is rarely waiting to be discovered — it is usually being discovered and then declined, for reasons the sitemap cannot address.
A minimal, valid sitemap looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/blue-widgets</loc>
<lastmod>2026-09-14</lastmod>
</url>
</urlset>The limits
A single sitemap file may contain at most 50,000 URLs and must not exceed 50MB uncompressed. Sites larger than that split across multiple files and list them in a sitemap index, which itself may reference up to 50,000 sitemaps.
The file may be gzipped, and the 50MB limit applies to the uncompressed size.
Splitting is worth doing well before you hit the ceiling. Separate sitemaps by section — products, articles, categories — and Search Console will report indexing coverage per file. That turns the sitemap from a formality into a diagnostic: if one sitemap's indexed count is far below the others, you have localised the problem to a section rather than a site.
Which URLs belong in it
One rule covers most of it: a sitemap should contain exactly the URLs you want indexed, and nothing else.
That means every URL in it should be:
- Canonical. Not a duplicate that canonicalises elsewhere. Listing a non-canonical URL sends contradictory signals.
- Indexable. Returns 200, not blocked by robots.txt, not carrying
noindex. - The final destination. Not a URL that redirects. A sitemap full of 301s is a sitemap that has not been regenerated since a migration.
Commonly included by mistake:
- Paginated series beyond page 1, where the pages add nothing
- Tag and filter URLs generated by a CMS
- Staging or development URLs left behind by a copied config
- Pages set to
noindex— a direct contradiction: *index this* and *do not index this*, at once
The last one is worth dwelling on. It is not merely untidy. You are asking for one thing in the sitemap and the opposite in the page, and the resulting Search Console warnings obscure the problems that matter.
The tags Google ignores
The sitemaps protocol defines four child elements. Google uses one of them.
| Tag | Status |
|---|---|
<loc> | Required. The URL |
<lastmod> | Used — if it is accurate |
<changefreq> | Ignored by Google |
<priority> | Ignored by Google |
<priority> is the one people spend time on. Setting your homepage to 1.0 and everything else to 0.5 accomplishes nothing at Google. It is a relative hint within your own site that was never a ranking input.
<lastmod> is genuinely useful, on one condition: it must be truthful. If every URL's lastmod updates on every build — a common CMS default — the value carries no information and gets discounted. If it only changes when the content actually changes, it is a real signal about what to re-crawl.
That is a bug worth checking for specifically. It is easy to ship and invisible until someone looks.
Submitting it
Three things to do, in order.
Reference it in robots.txt. One line, and every crawler that reads robots.txt finds it:
Sitemap: https://example.com/sitemap.xmlSubmit it in Google Search Console under Sitemaps. This is what gives you per-sitemap coverage reporting, which is the main reason to bother.
Submit it in Bing Webmaster Tools as well, if Bing traffic matters to you. It is a separate system.
Resubmitting after every content change is unnecessary. Crawlers re-fetch sitemaps on their own schedule.
Reading it as a diagnostic
The most valuable thing a sitemap gives you is a denominator.
Search Console reports how many of a sitemap's URLs are indexed. Because you built the file, you know exactly what the number should be. That comparison is the fastest indexing diagnostic available:
- Submitted 1,000, indexed 950. Normal. Some pages will always be declined.
- Submitted 1,000, indexed 300. A quality or duplication problem, not a discovery one. Google is finding these pages and choosing not to index them.
- Submitted 1,000, indexed 1,000, but traffic is flat. Indexing is not the constraint. Look at rankings and intent instead.
Without a clean sitemap, none of those comparisons are possible, because you never know whether a missing page was declined or simply never found.
Common failure modes
The sitemap 404s after a plugin change. The Sitemap: line in robots.txt still points at the old path. Costs nothing to check, and goes unnoticed for months.
It was generated once and never regenerated. It lists URLs that no longer exist and omits everything published since.
Every URL shares one lastmod, updated on each deploy. Described above — the field becomes noise.
It includes URLs on a different host. A sitemap may only list URLs on the same domain as the sitemap itself, unless cross-submission is set up deliberately in Search Console.
Two sitemaps disagree. A CMS generates one, a plugin generates another, and they list different sets. Pick one, delete the other, and make robots.txt point at the survivor.
Frequently asked questions
Does an XML sitemap improve rankings?
No. It helps search engines discover URLs. Discovery is a prerequisite for indexing, and indexing is a prerequisite for ranking, but the sitemap itself is not a ranking factor.
How many URLs can one sitemap contain?
Up to 50,000 URLs and 50MB uncompressed. Larger sites split across multiple sitemaps referenced from a sitemap index file. Splitting by section also gives you per-section indexing reporting in Search Console.
Should I set priority and changefreq?
Google ignores both. Only loc and lastmod are used, and lastmod only when it is accurate — if it updates on every build regardless of whether content changed, it is discounted.
Why are my sitemap URLs not indexed?
Sitemap submission is a request, not an instruction. If a large share is unindexed, the cause is usually duplication, thin content or a canonical pointing elsewhere — not discovery. Check the specific reasons in Search Console's Pages report.
Get your sitemap and indexation set up properly
A sitemap is easy to generate and easy to get subtly wrong — redirects left in it, noindex pages listed, a lastmod that means nothing. None of it errors. It just makes the one report that would tell you what is happening unusable.
If you would rather have it built correctly and wired to Search Console, the Technical SEO Starter Setup covers sitemaps, crawl directives and indexation together — $497, one-off, no retainer.