XML Sitemap: How to Create, Optimize and Submit It

An XML sitemap is a file that lists the pages you want search engines to discover and index, along with the date each one last changed. You generate it from your platform or with a script, place it at the root of your domain, submit it in Google Search Console and reference it in robots.txt. It does not guarantee indexing, but it shortens the path to new pages.

Most problems do not come from creating the file. They come from what goes into it. A sitemap full of redirects, blocked pages and duplicates tells Google that the site is not in order, and your Search Console report becomes impossible to read. This guide shows what a correct file looks like, what to include, how to build it on common platforms and how to check that it works. It is one piece of the foundation we build through technical SEO, together with robots.txt, canonical tags and redirects.

What is an XML sitemap, and what does it not do?

An XML sitemap is a text file in XML format that lists the canonical URLs of a website and, optionally, some details about them. Crawlers read it; visitors do not. It is not the same as an HTML “site map” page built for people, although both can exist side by side.

Its job is discovery. Google finds pages mostly by following links, and a sitemap adds a second path: an explicit list. It is most useful when:

• the site is new and has few external links;
• you have many pages and some sit several clicks away from the homepage;
• content changes often (news, stores, listings);
• some pages have weak internal links or none at all.

What a sitemap does not do: it does not force indexing, improve rankings or repair weak pages. Google’s documentation is clear that a submitted URL is not necessarily crawled or indexed. If a page is thin, duplicated or adds nothing new, it stays out of the index no matter how many sitemaps list it. For the order in which things matter on a fresh site, see our 90-day SEO plan for a new website.

What does a valid XML sitemap look like?

The minimal structure is simple. Every page gets a <url> element, and the only required tag inside it is <loc>:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/</loc>
    <lastmod>2026-03-18</lastmod>
  </url>
  <url>
    <loc>https://www.example.com/blog/sitemap-guide/</loc>
    <lastmod>2026-03-10</lastmod>
  </url>
</urlset>

The basic rules, from the sitemaps.org protocol and Google’s documentation:

1. The file is encoded as UTF-8.
2. URLs are fully qualified: protocol (https://), host and path, never relative paths.
3. Special characters in a URL (&, ', ", <, >) are written as entities (& and so on), and non-ASCII characters are encoded properly.
4. One file holds at most 50,000 URLs and 50 MB uncompressed. You can gzip it for transfer, but the limit applies to the uncompressed size.
5. A file should list URLs from one host and one protocol, unless cross-site submission is set up and verified.

Only some of the optional tags matter:

In practice you can delete changefreq and priority from your generator at no cost. If your plugin stamps every page with “weekly” and “0.8”, it does no harm, but it does no good either.

How to use lastmod correctly

lastmod should reflect the last significant change: main content, structured data or links. It should not move when the copyright year in the footer changes, when a comment is added or every time the file is regenerated. If every URL gets today’s date every day, Google is likely to treat the field as unreliable and ignore it. An accurate date, on the other hand, can help Google decide what to recrawl, especially after you refresh old articles.

Which URLs belong in the sitemap, and which do not?

The golden rule: the sitemap lists URLs you want to see in search results. Each one should return 200, be indexable and carry a canonical tag pointing to itself.

On an online store the difference shows up fast. Combined filters can create thousands of near-identical URLs. A filtered URL belongs in the file only if it answers a real search and has content of its own. More on that in our guide to canonical tags and duplicate content.

How do you create a sitemap on your platform?

You rarely write the file by hand. The right method depends on what you run.

1. WordPress. Since version 5.5, WordPress core generates a sitemap at /wp-sitemap.xml. SEO plugins (Yoast, Rank Math, All in One SEO) replace it with their own file, usually /sitemap_index.xml. Use only one, so you do not end up with two different sitemaps for the same site. Core settings are covered in our WordPress SEO checklist.
2. WooCommerce and other stores. Check that hidden products, empty categories and tag archives are excluded. Many platforms include thin tag pages by default.
3. Static or generated sites. Most generators (Eleventy, Hugo, Astro, Next.js) have plugins or built-in functions. If you write your own script, build the URL list from the same source of truth that generates the pages.
4. Custom-built sites. Ask your developer for a generator that reads from the database and follows the rules above, rather than a hand-maintained list.
5. Crawler tools. Programs such as Screaming Frog can export a sitemap from a crawl. That suits small or static sites, but you must regenerate the file after each change.

Whatever the method, open the file in a browser and check three things: it loads with a 200 status, the XML structure is valid and it contains exactly the URLs you expected.

Sitemap index files for large sites

Above 50,000 URLs, or when you want a logical split, you create a sitemap index that lists other sitemaps:

<?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>
    <lastmod>2026-03-18</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap-products.xml</loc>
    <lastmod>2026-03-17</lastmod>
  </sitemap>
</sitemapindex>

According to the protocol, an index can list up to 50,000 sitemaps. Splitting by page type also helps diagnosis: if products show a low indexing rate, you see it immediately, without filtering by hand.

How do you submit a sitemap to Google?

There are two complementary methods, and it is best to use both.

1. Open Google Search Console and select your property.
2. Go to Sitemaps in the left-hand menu.
3. In “Add a new sitemap,” type the relative path (for example sitemap.xml or sitemap_index.xml) and click Submit.
4. Check the status. “Success” means the file was read. “Couldn’t fetch” or “Has errors” need your attention.
5. Add a line with the full address to robots.txt:

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

The Sitemap: line in robots.txt is also read by other search engines, such as Bing, and does not depend on a Search Console account. If you are unsure how your file should look, our robots.txt generator builds a correct version with the sitemap line included. For more on the console itself, read the Google Search Console beginner’s guide.

One historical note: the old “ping” mechanism, a request sent to a dedicated Google address, was deprecated in June 2023 and has since stopped working, so you no longer need it. Search Console and robots.txt are the supported methods.

Special sitemaps: images, video and hreflang

Beyond the standard file, there are extensions for specific cases.

• Images and video. They can help Google find images or videos it might not otherwise discover, for example those loaded through JavaScript. For ordinary images in HTML they are usually not needed; see image SEO.
• News. Intended for news publishers.
• Language versions. hreflang annotations can live in the sitemap, using xhtml:link elements, instead of in each page’s head. This pays off when you have many languages and do not want to bloat every HTML file. The full procedure is in our hreflang guide, and the hreflang generator outputs the code.

Not every site needs these. If you run a blog and a services page, the standard sitemap is enough.

How do you check that your sitemap works?

After submitting, look at the Sitemaps report and the page indexing report in Search Console. Check:

• File status: “Success,” not “Couldn’t fetch.”
• Discovered pages: close to the number of URLs you put in the file.
• The Pages report: filter by sitemap to see how many URLs are indexed and why the rest were excluded.
• URL Inspection: for key pages, see whether Google reports the sitemap as a discovery source.

If the gap between submitted and indexed pages is large, that does not automatically mean the sitemap is wrong. The cause is often page quality, duplicates or site architecture; our guide to pages not indexed goes through them one by one.

Common sitemap mistakes

• Redirects and 404s in the file. After a migration the sitemap keeps the old addresses. Rebuild it with final URLs; the steps are in our site migration plan.
• Noindex or canonicalized pages in the sitemap. You send two opposite messages: “index this” and “do not index this.”
• HTTP instead of HTTPS, or www instead of non-www. Every URL must use the canonical version of the domain.
• lastmod refreshed on every regeneration. Google may stop relying on the field.
• File blocked by robots.txt or a firewall. The crawler gets a 403 and reports an error. This can happen when a host or CDN applies aggressive bot protection, so test the file from an outside connection.
• Two competing sitemaps. The theme generates one, a plugin another, each with different content.
• A stale file. New pages are missing for months because the file was generated once by hand.

When a sitemap will not solve the problem

Be realistic about what an XML file can do:

• It does not rescue pages with thin or duplicate content. That takes content work, not sitemap work.
• It does not replace internal links. A page that appears only in the sitemap, with no internal links, is an orphan page, and Google has few signals that it matters. We return to this in the guide on internal linking and site architecture.
• It has little visible effect on very small sites with a clear structure, which Google discovers anyway.
• It does not control what appears in search results; titles, descriptions and structured data do that.

Conclusion: next steps

A good sitemap is short, clean and updated automatically. Work through these steps in order:

1. Open your current file and compare the number of URLs with the number of pages you actually want indexed.
2. Remove redirects, noindex pages, parameter URLs and duplicates.
3. Drop changefreq and priority; keep lastmod only if you can make it accurate.
4. Submit the file in Search Console and add the Sitemap: line to robots.txt.
5. Come back after a week, open the indexing report and handle each exclusion category.

If you want someone to check your sitemap, canonicals and indexing together, see how we work in our technical SEO service or write to us through the contact page.