Guides/XML Sitemaps, Explained
Technical

XML Sitemaps, Explained

A sitemap doesn't rank your pages and doesn't guarantee they get indexed. Here's what it actually does, and how to build one correctly.

7 min read·By Vazagency·Updated July 2026

A sitemap.xml file is one of the more misunderstood parts of technical SEO — treated by some as an indexing guarantee and ignored entirely by others as pointless busywork. Neither is accurate. It's a specific, narrow tool with a specific job: telling search engines which URLs on your site you consider canonical and worth crawling. This guide covers exactly what it does, its real syntax, and how to build and maintain one correctly.

What a sitemap actually does

A sitemap is a discovery and crawl-prioritization aid, not an indexing mechanism. It's a structured list — in XML format — of the URLs on your site that you consider valid and important, optionally with metadata about each one. Submitting it gives Google a direct, explicit list to work from instead of relying entirely on discovering every URL by following links.

It's most valuable in three specific situations: a large site where internal linking alone might not surface every important page efficiently, a newer site that doesn't yet have many external links pointing into it, or a site with pages that are hard to reach through normal navigation (for example, deep archive pages). For a small, well-linked service-business site, a sitemap is still worth having — it costs nothing to maintain correctly and removes any doubt about which URLs you intend to be indexed — but it isn't going to compensate for a genuinely broken internal linking structure.

What it does not do

A sitemap doesn't influence rankings, doesn't force indexing, and doesn't override a noindex tag or a canonical tag pointing elsewhere. If a URL is in your sitemap but also marked noindex, Google will still respect the noindex — the sitemap entry doesn't win that conflict.

The actual syntax

A standard sitemap is a plain XML file. The minimum valid structure for a single URL looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/plumbing-services</loc>
    <lastmod>2026-07-20</lastmod>
  </url>
  <url>
    <loc>https://www.example.com/hvac-repair</loc>
    <lastmod>2026-06-15</lastmod>
  </url>
</urlset>
  • <urlset> is the required root element, and it must declare the sitemap protocol namespace exactly as shown.
  • <loc> is the only required child element per URL — the full, absolute URL, including the protocol (https://).
  • <lastmod> is optional but genuinely useful — the date the page's content was last meaningfully changed. Google has said it can use this signal, but only if it's kept accurate; a lastmod date that always shows "today" regardless of whether anything changed teaches Google to ignore it.
  • <changefreq> and <priority> are valid optional tags in the sitemap protocol, but Google has stated it largely disregards both, since declared values are unreliable across the web. They're not harmful to include, just not worth the effort of maintaining precisely.

Size limits and sitemap index files

A single sitemap file is capped at 50,000 URLs and 50MB uncompressed. Most local service-business sites never come close to that limit. Larger sites that do exceed it split their URLs across multiple sitemap files and reference all of them from a single sitemap index file:

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

Splitting by content type (static pages, blog posts, product pages) is a common, sensible pattern even below the size limit — it makes it easier to spot which section of the site has an indexing problem when you check Search Console's coverage data by sitemap.

What belongs in your sitemap

The rule is simple: include only canonical, indexable URLs that return a 200 OK status and that you actually want in search results. Everything else creates a contradiction between the sitemap and your other directives.

  • Include every canonical page you want indexed — service pages, location pages, blog posts, the homepage.
  • Exclude pages marked noindex — including them tells Google to crawl a page you've simultaneously told it not to index, which is a wasted, contradictory signal.
  • Exclude non-canonical duplicates and parameter-based URL variants — only the canonical version should appear.
  • Exclude redirected URLs — list the destination URL, not the old one that 301s elsewhere.
  • Exclude anything blocked by robots.txt — Google can't crawl it regardless of the sitemap entry, so including it accomplishes nothing.

Submitting and maintaining it

Submit your sitemap URL directly in Google Search Console under the Sitemaps section, and reference its location in your robots.txt file with a Sitemap: directive so any crawler checking robots.txt first can find it without a separate submission. Most modern CMS platforms and SEO plugins generate and update the sitemap automatically as content changes — verify yours does this before assuming it's current, and check the Sitemaps report in Search Console periodically for processing errors rather than assuming a successfully-submitted sitemap stays valid indefinitely as your site changes. For how sitemap submission fits into the broader discovery-to-indexing pipeline, see how search engines crawl and index a site.

Frequently asked questions

Put this into practice

More guides

Want this handled for you?

We build the SEO foundation and handle the ongoing work — no long-term contract, no guaranteed-rankings sales pitch.