XML Sitemaps: What They Do and How to Build One That Works
The short version
- A sitemap is a list of URLs you want crawled. It is a suggestion, not an instruction.
- Only canonical, indexable, 200-status URLs belong in it.
- Google reads
<loc>and<lastmod>. It ignores<priority>and<changefreq>entirely. - A sitemap helps discovery. It does not make a page rank, and it does not force indexing.
A sitemap is the most misunderstood file in technical SEO. Half the people who have one believe it guarantees their pages get indexed. The other half generated one years ago with a plugin and have never opened it since. Both groups are usually sitting on a file that is quietly working against them.
This guide covers what the file is actually for, what belongs inside it, and how to tell whether yours is doing anything useful.
1. What a sitemap is for
An XML sitemap is a list of URLs on your site, written in a format search engines can parse. That is the whole idea. You are handing Google a reading list and saying: these are the pages I care about, here is when each one last changed.
It matters most in three situations. A brand new site with almost no inbound links, where crawlers have nothing to follow. A large site where some pages sit five or six clicks from the home page and rarely get reached. And a site with pages that are not linked from anywhere obvious, like a landing page you only ever send traffic to from email.
If your site is twenty pages, all linked from a clear menu, and it has been online for years, the sitemap is doing very little for you. That is fine. It costs nothing to have one and it gives you a useful report in Search Console. Just do not expect it to move the needle.
2. What a sitemap is not for
This is where the disappointment usually comes from. Submitting a URL in a sitemap does not mean Google will index it. Google decides what to index based on whether the page looks worth having, and no amount of listing it in a file changes that judgement.
It also has nothing to do with ranking. There is no sitemap signal that lifts a page up the results. The <priority> tag, which looks like it should do exactly that, is ignored. Google confirmed years ago that it reads neither <priority> nor <changefreq>, because too many sites set every page to priority 1.0 and changefreq daily. The tags survive in the spec and in plugin output, but nothing reads them.
And it will not rescue a page that is blocked. If a URL is disallowed in robots.txt, listing it in a sitemap does not grant access. The two files are read separately, and robots.txt wins. See noindex vs disallow for what that actually does to a page.
3. What belongs in the file
The rule is simpler than most guides make it. A URL belongs in your sitemap if, and only if, all four of these are true:
- It returns a 200 status code.
- It is the canonical version of that page, matching its own canonical tag.
- It is indexable, with no noindex tag on it.
- It is not blocked by robots.txt.
Anything failing one of those tests is sending a mixed signal. You are telling Google a page is important enough to list, while another part of your site tells it the opposite. Google resolves the contradiction by trusting the page, not the sitemap, and your sitemap loses a little credibility each time.
4. What to keep out
The usual offenders, in rough order of how often they turn up:
- Redirected URLs. The old address of a page you moved. List the destination instead.
- Paginated archive pages where page two onward adds nothing a person would search for.
- Tag and category pages that hold three posts and no original writing.
- Parameter URLs from filters and sorting, which multiply into thousands and all say roughly the same thing.
- Login, cart, checkout and account pages. Nobody searches for your checkout.
- Images and PDFs in your main sitemap. If you want images crawled, use a dedicated image sitemap.
A tight sitemap of 200 genuinely good URLs is worth far more than a bloated one with 5,000 where most are junk.
5. The tags, and which ones matter
A minimal, correct sitemap looks like this. Nothing else is required:
<?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-09-11</lastmod>
</url>
<url>
<loc>https://example.com/guides/</loc>
<lastmod>2026-09-11</lastmod>
</url>
</urlset>
Two things to get right. <loc> must be the full absolute URL including the protocol, and it must match your canonical exactly. If your canonical is https://example.com/page/ with a trailing slash, the sitemap needs the trailing slash too. A mismatch there is one of the most common and most invisible errors on the list.
<lastmod> is the one optional tag worth filling in properly, because Google does use it as a hint about what to recrawl. The catch is that it has to be honest. If your CMS stamps today's date on every URL every night, Google learns within a few weeks that your lastmod means nothing and stops paying attention to it. Only update the date when the content genuinely changed. A fixed typo is not a change worth stamping.
6. Size limits and sitemap index files
One sitemap holds a maximum of 50,000 URLs or 50MB uncompressed, whichever you hit first. Past that, split the file and list the parts in a sitemap index, which is just a sitemap of sitemaps:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-posts.xml</loc>
<lastmod>2026-09-11</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-09-11</lastmod>
</sitemap>
</sitemapindex>
Splitting by content type rather than arbitrary chunks is worth doing even well below the limit. When Search Console tells you 400 URLs are not indexed, knowing they are all in sitemap-products.xml narrows the problem immediately. Split into anonymous blocks of 50,000 and you learn nothing.
7. Where to put it and how to announce it
Put it at the root: https://example.com/sitemap.xml. It does not have to live there, but everyone looks there first and there is no reason to be creative.
Then tell crawlers about it in two places. First, a line in robots.txt, which every major crawler reads:
Sitemap: https://example.com/sitemap.xml
That line is independent of any User-agent block, so it can sit at the top or the bottom of the file on its own. The robots.txt generator adds it for you if you paste your sitemap URL in.
Second, submit it in Google Search Console under Sitemaps. That is the only way to get the report back telling you how many URLs were discovered and how many made it into the index, which is the whole reason to bother.
8. How to tell whether it is working
Open the Sitemaps report in Search Console. You want status Success and a discovered-URL count in the same ballpark as the number of pages you actually have. If it reads 12 and your site has 400 pages, the file is truncated or malformed. If it reads 40,000 and you have 400 pages, something is generating parameter URLs.
Then open the Pages report and filter by your sitemap. This is the useful part. It splits your URLs into indexed and not indexed, and gives a reason for each exclusion. Discovered - currently not indexed usually means Google looked and decided the page was not worth the trouble, which is a content problem, not a sitemap problem. Crawled - currently not indexed means it read the page and still passed. Duplicate without user-selected canonical means your canonical tags need attention, covered in the canonical guide.
None of those are fixed by editing the sitemap. That is the point worth taking away: the sitemap is a diagnostic instrument far more often than it is a fix.
9. Mistakes that turn up again and again
- Listing the http version after moving to https, or the www version on a non-www site. Every URL then redirects, and the whole file is one long redirect chain.
- Leaving a staging sitemap live with staging URLs in it. Instant confusion, and sometimes a staging site in the index.
- Blocking the sitemap in robots.txt. It happens when someone disallows a folder the sitemap happens to sit in.
- Never regenerating it. A sitemap from 2023 on a site that publishes weekly is worse than none, because it actively misrepresents the site.
- A byte order mark or stray whitespace before the XML declaration. The file then fails to parse and Search Console reports a generic fetch error.
Where to go next
If your sitemap is clean and pages still are not indexed, the problem is upstream. Check that nothing is blocking crawlers first, then look at whether the pages themselves are worth indexing. The technical SEO audit covers that sequence in order.