XML sitemaps: how to build, submit and audit them

What a sitemap is and what it does

Google's definition: “A sitemap is a file where you provide information about the pages, videos, and other files on your site” and the relationships between them. Think of it as a list of addresses you hand to the crawler, next to the links it would find on its own.

The key word is discovery. A sitemap “helps search engines discover URLs on your site, but it doesn't guarantee that all the items in your sitemap will be crawled and indexed.” Google still decides whether and when to crawl each URL, and whether to index it, based on everything else it knows about the page and the site.

Does your site need a sitemap?

Google lists three situations where you might need one:

• “Your site is large.”
• “Your site is new and has few external links to it.”
• “Your site has a lot of rich media content (video, images) or is shown in Google News.”

On a large site, deep pages can be several clicks from the home page and easy for a crawler to miss. A new site has few links from other sites, so Google has fewer paths to it. Video, images and news articles often benefit from the extra details a sitemap can carry.

You might not need one if your site is small (“By small, we mean about 500 pages or fewer on your site.”) or if “Your site is comprehensively linked internally.” In that case Google can usually find every page by following links. A sitemap still does no harm, and most CMSs generate one automatically, so many small sites keep one anyway. It is also a convenient way to see indexing for exactly the URLs you care about in Search Console.

What Google officially says

The same page sets the basic rules for the file. Each of these is a direct quote:

• “Use fully-qualified, absolute URLs in your sitemaps.”
• “The sitemap file must be UTF-8 encoded.”
• “As with all XML files, all tag values must be entity escaped.”

And from the canonicalization documentation, listing a URL in a sitemap is “A weak signal that helps the URLs that are included in a sitemap become canonical.”

Sitemap formats

Google accepts three formats: XML, RSS (including mRSS) or Atom 1.0 feeds, and plain text files with one URL per line. Google “doesn't have a preference”, so pick what your platform produces most reliably. XML is the usual choice because it can carry lastmod and the extensions below, and SEO tools read it everywhere. A feed is handy for a blog, since most platforms already publish one. A text file is the simplest option when you only need a list of URLs.

XML sitemaps can be extended for specific content types:

• Image sitemaps add <image:image> entries to a page's URL. They help Google discover images it might not otherwise find, for example images loaded by scripts.
• Video sitemaps have their own tags for details about each video, such as its thumbnail and duration.
• News sitemaps have their own tags for news articles, such as the publication date and title.

Whatever the format, the same rules apply: full absolute URLs, UTF-8 encoding and the same size limits.

Anatomy of an XML sitemap

An XML sitemap has a single root element, <urlset>. Each page gets its own <url> block with a required <loc> (the URL) and an optional <lastmod> (the date of the last significant change).

The same sitemap as plain code:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/shoes/</loc>
    <lastmod>2026-10-29</lastmod>
  </url>
  <url>
    <loc>https://example.com/shoes/running/</loc>
    <lastmod>2026-10-21T09:30:00+00:00</lastmod>
  </url>
</urlset>

<priority> and <changefreq> are part of the sitemap protocol, but Google ignores both. Setting every page to priority 1.0 or changefreq daily changes nothing. Most sites simply drop them, which also keeps the file smaller.

lastmod done right

lastmod is the one optional tag Google does use, under a condition. Google uses the <lastmod> value “if it's consistently and verifiably” accurate, and it “should reflect the date and time of the last significant update to the page.”

A significant update is a change to what the page is for: the main text, prices, availability. These do not count:

• a new link or year in the footer;
• a new comment in a comments widget;
• a redeploy of the site that rebuilt every page without changing its content;
• a refreshed sidebar of related posts.

The most common way to lose Google's trust is to write the build or generation date into every lastmod. When every URL claims to have changed today, and a check shows it has not, the value tells Google nothing and it can stop relying on it. Take the date from the content itself, for example the last-edited date of the post or product in your CMS.

Use the W3C date format: either a date, 2026-10-29, or a date and time with a time zone, 2026-10-29T14:05:00+00:00.

<url>
  <loc>https://example.com/about/</loc>
  <lastmod>2026-10-29</lastmod>
</url>
<url>
  <loc>https://example.com/shoes/</loc>
  <lastmod>2026-10-29</lastmod>
</url>

<url>
  <loc>https://example.com/about/</loc>
  <lastmod>2025-03-14</lastmod>
</url>
<url>
  <loc>https://example.com/shoes/</loc>
  <lastmod>2026-10-27</lastmod>
</url>

Limits and sitemap index files

“All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs.” Whichever limit you reach first, split the URLs into several sitemap files. Gzip compression saves bandwidth, but the 50MB limit applies to the uncompressed file.

You can then list all those files in a sitemap index and “submit that single index file to Google.” An index is an XML file with <sitemapindex> as its root and one <sitemap> entry per child sitemap:

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

Even when you are well under the limits, splitting by page type pays off. In Search Console's Page indexing report you can filter by sitemap. With separate files for products, categories and articles, you can see straight away if, say, articles are indexed well while many products are not. One combined file only gives you a single total.

Which URLs belong in a sitemap

Google's rule is short: “Include the URLs in your sitemap that you want to see in Google's search results.” In practice that means canonical URLs only. Because a sitemap is a weak canonical signal, listing duplicates votes for the wrong URL and contradicts your rel="canonical" tags.

A URL blocked by robots.txt cannot be crawled, so listing it sends two opposite instructions. A noindex page in the sitemap does the same. Neither breaks the sitemap, but both make Search Console reports noisy and hide real problems.

Where to put it and how to submit it

Location and scope

Unless you submit it through Search Console, a sitemap “affects only descendants of the parent directory.” A sitemap at https://example.com/blog/sitemap.xml can only list URLs under /blog/. Google recommends the root, for example https://example.com/sitemap.xml, so the file can cover the whole host.

Three ways to tell Google

1. Search Console Sitemaps report. Enter the sitemap or index URL. This also gives you status and error reporting for that file.
2. Search Console API. Useful when you manage many sites or generate sitemaps automatically.
3. A Sitemap: line in robots.txt. It can go anywhere in the file and must contain the full URL. Other search engines read it too.

# https://example.com/robots.txt
User-agent: *
Disallow: /search/

Sitemap: https://example.com/sitemap_index.xml

Whichever route you use, submitting is “merely a hint”. It makes Google aware of the file, nothing more.

Also check that robots.txt does not block the sitemap file itself, and that the sitemap URL returns status 200 with XML, not an HTML page or a redirect to the home page.

Reading the Sitemaps report in Search Console

The Sitemaps report lists every sitemap you submitted (and, for an index, its child sitemaps) with the date Google last read it, a status and the number of URLs it found.

To see what happened to those URLs, open the Page indexing report and filter it by sitemap (all submitted pages, or one specific sitemap). You then get indexed and not-indexed counts for exactly the URLs you listed, with the reason for each excluded group: redirects, noindex, duplicates with a different canonical, Crawled - currently not indexed and so on.

Many excluded URLs usually point to a sitemap that lists the wrong URLs: redirects, non-canonical versions, noindex pages. Fix the list first. Whatever remains excluded tells you about the pages themselves, such as thin or duplicate content.

Common mistakes

• ✕Non-canonical or redirected URLsThe sitemap should only list final URLs that are their own canonical.
• ✕http URLs on an https siteEach listed URL then redirects, and the sitemap votes for the wrong version.
• ✕www and non-www mismatchThe sitemap uses one host, the site and canonicals use the other.
• ✕The same lastmod on every URLUsually the build date. It makes the value useless to Google.
• ✕A stale sitemapGenerated once, never updated: new pages missing, deleted pages still listed.
• ✕Sitemap blocked by robots.txtGoogle cannot fetch a file it is not allowed to crawl.
• ✕Sitemap URL returns HTML or 404Often a CMS route that shows the home page or an error page instead of XML.
• ✕URLs of another hostListing URLs of a different domain or subdomain without verifying ownership of both in Search Console.
• ✕One huge file over the limitsMore than 50,000 URLs or 50MB uncompressed. Split it and use an index.
• ✕Using the sitemap instead of internal linksA page that is only in the sitemap and linked from nowhere is weak. Link to important pages from your site too.

How to audit a sitemap step by step

1. Fetch the sitemap and the index. Each file should return status 200, valid XML and UTF-8 encoding. Start from the URL in robots.txt and in Search Console, and make sure they match.
2. Count the URLs in every file and check them against the 50,000 URL and 50MB limits.
3. Crawl every listed URL. Each one should return 200, be indexable and have a self-referencing canonical. Remove or replace redirects, 404s, noindex pages and duplicates.
4. Check protocol and host. All URLs should use the same https and www format as your canonicals.
5. Find what is missing. Compare a crawl of your site with the sitemap: important indexable pages that are not listed should be added, or your generator fixed.
6. Check that lastmod is plausible. Are the dates all the same? Do they move on every deploy? Spot-check a few pages against their real edit dates.
7. Compare submitted and indexed in Search Console, using the Page indexing report filtered by each sitemap. Look at the reasons for the largest excluded groups.

FAQ

Sources

• Google Search Central — Learn about sitemaps
• Google Search Central — Build and submit a sitemap
• Google Search Central — How to specify a canonical URL

Quotes checked against the official pages on 29 October 2026.