XML Sitemap Guide: What to Include, Submit and Fix

An XML sitemap is a file that lists the URLs on your site you want search engines to find and crawl, often with the date each page last changed. It helps Google discover pages faster, especially on large or new sites. It does not guarantee indexing, and it only helps when it contains clean, canonical, indexable URLs.

Most sitemap problems aren't about a missing file. They come from a file that lists the wrong URLs. This guide covers what belongs in a sitemap, what Google ignores, how to submit one, and how to read the errors.

What is an XML sitemap and what does it do?

Google defines a sitemap as "a file where you provide information about the pages, videos, and other files on your site, and the relationships between them." Search engines use it to crawl a site more efficiently and to learn which pages you consider important.

A sitemap is a discovery and hint file, not a command. Google says plainly that a sitemap "doesn't guarantee that all the items in your sitemap will be crawled and indexed." Its Search Console help adds that the "discovered pages" count in the Sitemaps report comes with "no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed."

So a sitemap does three useful things:

• Discovery. It shows URLs that internal links might not reach quickly, such as new products or deep archive pages.
• Change signals. An accurate <lastmod> tells Google which pages changed since its last visit.
• Canonical hints. Google's duplicate-URL documentation calls sitemap inclusion "a weak signal that helps the URLs that are included in a sitemap become canonical."

It won't make a thin page rank, fix a noindex tag or get around a robots.txt block.

Does my website need a sitemap?

Small, well-linked sites can do without one, but most sites gain something from having it. Google says you might not need a sitemap if your site has "about 500 pages or fewer", is "comprehensively linked internally" and has few media files or news pages. Large sites, new sites with few backlinks, and sites with lots of video, images or news benefit most.

In practice, a sitemap costs almost nothing to maintain, and most platforms create one for you. Google notes that if you use a CMS such as WordPress, Wix or Blogger, it has probably already generated one. The real question is whether your sitemap is accurate, because a bad sitemap points Google at the wrong URLs.

What should an XML sitemap include?

Include only URLs you want to appear in search: canonical pages that return status 200, aren't blocked by robots.txt and don't carry a noindex tag. Every URL should be absolute, use your preferred protocol and host, and match the URL in the page's own canonical tag. Everything else is noise that wastes crawling and sends mixed signals.

Here is a minimal valid file:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/services/roof-repair/</loc>
    <lastmod>2026-09-30</lastmod>
  </url>
  <url>
    <loc>https://www.example.com/blog/how-to-spot-roof-damage/</loc>
    <lastmod>2026-10-12</lastmod>
  </url>
</urlset>

What to leave out

Audits of real sitemaps keep turning up the same kinds of URLs that don't belong there:

• Redirected URLs (301/302). List the final destination instead.
• 404 and 410 pages: deleted products, old campaign pages.
• Non-canonical duplicates: URLs with tracking parameters, sorted or filtered listings, HTTP or non-www versions.
• Noindexed pages: thank-you pages, internal search results, tag archives you've excluded.
• URLs blocked in robots.txt. Listing a URL in the sitemap while blocking it in robots.txt is a direct contradiction.
• Staging or development URLs that leaked in from a plugin or a misconfigured build.

When the sitemap and the page disagree, for example the sitemap lists /shoes?color=red while that page's canonical points to /shoes, Google has to work out which signal to trust. The canonical tag guide explains how to line those signals up.

Which sitemap tags does Google actually use?

Google uses <loc> and, when it's trustworthy, <lastmod>. Its sitemap documentation states that "Google ignores <priority> and <changefreq> values", so setting every page to priority 1.0 or "daily" changes nothing. Other search engines may read them, but you shouldn't count on them for Google.

<lastmod> is the tag that matters, and only if it's honest. Google says to use it only when it's "consistently and verifiably accurate", and that it should reflect significant changes to the main content, structured data or links. A changed copyright year in the footer doesn't count.

A common mistake is a sitemap generator that stamps every URL with the time the file was built. If every page claims to have changed today, every day, the date tells Google nothing. Set lastmod from the content's real modification date in your CMS, or leave it out.

Formats and limits

Google's build-a-sitemap guide lists the rules:

XML is the most flexible format because it supports extensions for images, video, news and alternate language versions. For multilingual sites, you can declare language versions in the sitemap instead of the page head. The hreflang guide covers the syntax, including the self-references and return links each version needs.

How do you handle large sites with a sitemap index?

Once a site passes 50,000 URLs or 50 MB, split the sitemap into several files and list them in a sitemap index. Google's large sitemaps documentation says an index can hold up to 50,000 <loc> entries, and you can submit up to 500 sitemap index files per site in Search Console.

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

Two restrictions catch people out. The referenced sitemaps must be hosted on the same site as the index, unless you've set up cross-site submission. They must also sit in the same directory as the index or deeper. An index at /public/sitemap_index.xml can't reference /sitemap-blog.xml at the root.

You don't need a huge site to split your sitemap. Separate files for products, categories, blog posts and landing pages make diagnosis much easier. When Search Console shows one file with a low indexing rate, you know which template to look at.

How do you submit a sitemap to Google?

Submit the sitemap in Search Console's Sitemaps report and reference it in robots.txt. Google lists these submission methods: the Sitemaps report, the Search Console API, a Sitemap: line in robots.txt, and WebSub for RSS or Atom feeds. Using the report together with robots.txt covers both Google and other crawlers.

Step by step:

1. Find your sitemap URL. Common locations are /sitemap.xml, /sitemap_index.xml or /wp-sitemap.xml on WordPress. Open it in a browser to confirm it loads.
2. Add it to robots.txt on its own line:

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

3. Test it. Google's Sitemaps report help suggests checking that the URL is reachable with the URL Inspection tool first.
4. Submit it. In Search Console, open Sitemaps, paste the URL into Add a new sitemap and click Submit.
5. Check the status a few days later.

Google tries to fetch a submitted sitemap right away. Crawling the URLs inside can take much longer, depending on your site.

How do you read and fix sitemap errors in Search Console?

The Sitemaps report shows one of three statuses: Success (fetched and read without errors), Has errors (fetched, but with one or more parsing errors) and Couldn't fetch (Google couldn't retrieve the file). Each status points to a different fix.

"Success" only means the file was readable. To see what happened to the listed URLs, open the Page indexing report and filter it by sitemap. If many submitted pages sit under "Discovered – currently not indexed", Google knows they exist but hasn't crawled them. The guide to that status walks through the usual causes.

A quick sitemap audit you can run yourself

1. Download your sitemap and count the URLs.
2. Crawl the list and check each URL's status code, canonical, robots meta tag and robots.txt status.
3. Flag any URL that isn't status 200, self-canonical and indexable.
4. Compare the list with your real important pages. Are key services, products or articles missing?
5. Check whether lastmod dates are real or just the build time.

If you'd rather not crawl the file yourself, a free SEORecheck audit checks whether your sitemap is found and readable and flags listed URLs that redirect, return errors, are noindexed or point their canonical elsewhere. This is one part of a wider technical SEO audit that also covers crawling, rendering and redirects.

Common sitemap mistakes, and how to avoid them

• Two competing sitemaps. An SEO plugin and the CMS core both generate one, with different URL sets. Pick one and disable the other.
• Sitemap never updates. A static file uploaded years ago still lists deleted pages. Generate it automatically from your CMS or build.
• Wrong host or protocol. The sitemap lists http:// or non-www URLs while the site serves https://www.. Every listed URL then redirects.
• Fake freshness. Every lastmod equals today. Use real modification dates.
• Over-reliance. Pages that exist only in the sitemap, with no internal links, look unimportant. Link to them from relevant pages too.
• Ignoring split reports. One giant file hides which section has the problem. Split by page type.

Key takeaways

• An XML sitemap helps Google discover and recrawl URLs. It doesn't guarantee crawling or indexing.
• List only canonical, indexable URLs that return 200. Leave out redirects, 404s, noindexed and parameter URLs.
• Google ignores <priority> and <changefreq>. Keep <lastmod> accurate or leave it out.
• Limits: 50,000 URLs or 50 MB uncompressed per file. Use a sitemap index beyond that.
• Submit in Search Console and add a Sitemap: line to robots.txt.
• "Success" in the Sitemaps report only means the file was readable. Check the Page indexing report for what happened to the URLs.

To see how sitemap findings look next to the rest of a site's issues, browse the sample report. The full sample shows affected URLs and fixes in detail.