How to submit a sitemap in Google Search Console

Submitting a sitemap is one of the first things to do after adding a site to Google Search Console, and one of the easiest to get subtly wrong. The submission itself takes under a minute. The part that actually matters is what is inside the file, and whether you read the report afterwards.

This tutorial walks through the whole job in order: checking what belongs in the sitemap, finding its URL on your platform, submitting it, interpreting the status, and comparing submitted URLs against indexed ones so you know where to look next.

What a sitemap does (and what it does not)

An XML sitemap is a list of URLs you want search engines to know about, optionally with the date each one last changed. Google treats it as one discovery source among several: it also finds URLs by following links, from redirects and from other signals. A sitemap is most useful when a site is new and has few external links, when it is large, when content changes often, or when some pages are poorly linked internally.

• It does: help Google discover URLs faster, tell Google which URLs you consider canonical, and (through lastmod) hint which pages changed and are worth recrawling.
• It does: give you a reporting slice in Search Console, so you can see how many of the URLs you care about are actually indexed.
• It does not: guarantee crawling or indexing. A sitemap is a hint. Google still decides whether each page is worth indexing.
• It does not: replace internal links. A page that only exists in the sitemap, with no links pointing to it, sends a weak signal about its importance.
• It does not: use <priority> or <changefreq>. Google ignores both, so there is no point fine-tuning them.

Before you submit: what belongs in the sitemap

A sitemap should contain only URLs you actually want in Google's index. Every URL that does not meet that bar adds noise, and a sitemap full of redirects, 404s and noindexed pages makes your own report hard to read. Before submitting, check that each listed URL is:

• Canonical: the URL is the version you want indexed, and its rel="canonical" points to itself (not to another URL). See Google's guide on consolidating duplicate URLs.
• Returns 200: no redirects, no 404/410, no 5xx. List the final destination, not the old URL that redirects to it.
• Indexable: no noindex meta tag or X-Robots-Tag header, and not blocked by robots.txt.
• Absolute and consistent: full URLs with the same protocol and host you use everywhere else (for example always https://www. or always without www).
• Worth indexing: skip internal search results, filtered and sorted variants, cart and account pages, thin tag archives and similar.

Here is a minimal, valid XML sitemap. The only required child of <url> is <loc>; <lastmod> is optional but useful when it is accurate. Dates use W3C format, either a plain date or a full timestamp with timezone.

<?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-10-28</lastmod>
  </url>
  <url>
    <loc>https://www.example.com/guides/xml-sitemaps</loc>
    <lastmod>2026-10-15T09:30:00+00:00</lastmod>
  </url>
</urlset>

Larger sites usually split URLs across several sitemap files and list those files in a sitemap index. You submit the index once, and Google reads every child sitemap it references.

<?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-10-28</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap-posts.xml</loc>
    <lastmod>2026-11-01</lastmod>
  </sitemap>
</sitemapindex>

Finding your sitemap URL on common setups

Most platforms and SEO plugins generate the sitemap for you. Your job is to find its URL and open it in a browser to confirm it loads and lists the pages you expect. The paths below are the typical defaults; a theme, plugin or custom configuration can change them.

If none of these load, check /robots.txt: many setups declare the sitemap there with a Sitemap: line. Once you have the URL, open it and spot-check a handful of entries. If you see staging hosts, http:// URLs on an HTTPS site, or pages you know are noindexed, fix the generator settings before you submit.

Submitting the sitemap in Search Console

1. 01

   Add and verify your property

   In Search Console, add either a Domain property (verified via DNS, covers all subdomains and protocols) or a URL-prefix property. The sitemap must sit within the property you submit it to.

2. 02

   Open Indexing > Sitemaps

   In the left menu, go to Indexing, then Sitemaps. The top card is "Add a new sitemap".

3. 03

   Enter the sitemap URL

   Type the path (for example sitemap_index.xml) or the full URL, depending on how the field is prefixed for your property type. If you have a sitemap index, submit the index only, not each child file.

4. 04

   Click Submit

   The sitemap appears in the "Submitted sitemaps" table with a status, last read date and number of discovered pages. Processing can take anywhere from minutes to several days.

Also declare the sitemap in robots.txt. This lets Google and other search engines find it without a Search Console submission, and it keeps working if someone removes the sitemap from the report. The line takes an absolute URL and can appear anywhere in the file:

User-agent: *
Disallow:

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

Reading the sitemap status

Each submitted sitemap shows one of three statuses. Success means Google fetched and parsed the file without errors; it says nothing about how many URLs were indexed. Has errors means the file was read but some or all of it could not be processed; click the row to see the specific issues. Couldn't fetch means Google could not retrieve the file at all. On a freshly submitted sitemap this status sometimes appears before the first real fetch, so if the URL loads fine in a browser, give it a day before digging deeper.

Checking discovered vs indexed pages

The "Discovered pages" number in the Sitemaps report only tells you how many URLs Google read from the file. To see how many are indexed, open the Pages report under Indexing and use the filter at the top to switch from "All known pages" to "All submitted pages" or to a specific sitemap. You can also click a sitemap in the Sitemaps report and choose to see its page indexing. To spot-check a handful of sitemap URLs without inspecting each one, an index checker gives a per-URL answer. See the Page indexing report help for every field.

The filtered view splits your submitted URLs into indexed and not indexed, with a reason for each group. This is where the sitemap pays off as a diagnostic tool, because it shows the gap between what you want indexed and what Google has actually indexed. Typical patterns:

• Page with redirect, Not found (404), Excluded by 'noindex' tag, Alternate page with proper canonical tag: these URLs should not be in your sitemap. Fix the generator rather than the pages.
• Discovered – currently not indexed: Google knows the URLs but has not crawled them yet. Common on new or large sites; improve internal linking and server speed.
• Crawled – currently not indexed: Google fetched the pages and chose not to index them for now, usually a quality or duplication judgment.

For a full walkthrough of each reason, see why a page is not indexed. If many sitemap URLs sit in the "Discovered" bucket, the problem is usually how the pages are linked, which the internal linking guide covers. Keep in mind that report data lags and is sampled for large sites; for an exact per-URL answer use URL Inspection.

Keeping the sitemap healthy

A sitemap is not a one-time task. Generated sitemaps drift as the site changes, and the most common long-term problem is a file that quietly fills up with URLs that should not be there. A few habits keep it useful:

• Keep `lastmod` honest. Update it only when the main content of a page changes meaningfully. Google uses lastmod only if it is consistently accurate; setting every URL to today's date on each build teaches Google to ignore it.
• Respect the limits. A single sitemap file can hold up to 50,000 URLs and 50 MB uncompressed. Gzip is allowed for transfer, but the uncompressed limit still applies.
• Split by type. Separate sitemaps for pages, posts, products or categories make the filtered Pages report far more informative: you can see at a glance that products are indexed well but blog posts are not.
• Do not ping. Google deprecated its sitemap ping endpoint in 2023. Rely on Search Console and the robots.txt Sitemap: line instead.
• Do not resubmit on every change. Google refetches known sitemaps on its own schedule. Resubmitting is only worth it after a structural change, such as a new sitemap URL or a migration.
• Re-check after releases. After a theme change, plugin update or migration, open the sitemap and confirm it still lists the right URLs on the right host.