How to Submit a Sitemap to Google (Search Console, 2026)

To submit a sitemap to Google, open Search Console, go to Indexing > Sitemaps, type the path of your sitemap file and click Submit. Google fetches the file, reports a status (Success, Couldn't fetch or Has errors) and starts using the URLs for discovery. The other route is a Sitemap: line in robots.txt, which needs no account at all. Both tell Google where the list is; neither makes Google index anything.

What you need before you submit

Three things:

1. A verified Search Console property. Either a Domain property (yoursite.com, covers every subdomain and protocol) or a URL prefix property (https://www.yoursite.com/, covers that prefix only).
2. A sitemap that is actually reachable. Open its URL in a browser. You should see XML, not a 404 page and not your site's HTML design wrapped around some XML.
3. A file within the limits. One sitemap file holds at most 50,000 URLs and 50 MB uncompressed. More than that needs a sitemap index file pointing at several sitemaps.

If you are not sure where your sitemap lives, most platforms put it at /sitemap.xml, WordPress with Yoast or Rank Math uses /sitemap_index.xml (plain WordPress serves /wp-sitemap.xml), and Shopify, Wix and Squarespace generate /sitemap.xml for you. The sitemap finder checks the usual locations and robots.txt in one go.

Before submitting, run the file through the sitemap validator. It is faster to fix a stray & or a wrong namespace now than to wait a day for Search Console to say "Has errors".

Submitting in Search Console, step by step

1. Sign in to Search Console and pick the property.
2. In the left menu, click Indexing, then Sitemaps.
3. Under Add a new sitemap, type the path of the file. For a URL prefix property the field already shows the prefix, so you type only sitemap.xml. For a Domain property type the full URL, for example https://www.yoursite.com/sitemap.xml.
4. Click Submit.
5. The file appears in the Submitted sitemaps table below. The Status column says "Success", "Couldn't fetch" or "Has errors", and the Discovered pages column shows how many URLs Google found in it once it was read.

Two details trip people up here.

The sitemap must sit under the property. A URL prefix property for https://www.yoursite.com/ cannot submit https://yoursite.com/sitemap.xml (no www) or http://www.yoursite.com/sitemap.xml (http). Search Console rejects it or reports it under the wrong property. A Domain property has no such problem.

A sitemap only covers URLs at or below its own location. https://www.yoursite.com/news/sitemap.xml may list URLs under /news/, not under /products/. Put the file at the root unless you have a reason not to. The exception is cross-submission through robots.txt, covered next.

The robots.txt route

Add a line to https://www.yoursite.com/robots.txt:

User-agent: *
Disallow: /wp-admin/

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

Rules for the line:

• The URL must be absolute, with protocol and host.
• It can appear anywhere in the file and is independent of the User-agent groups.
• You can list several Sitemap: lines.
• A sitemap referenced from robots.txt may live on another host, which is the official way to host sitemaps for several subdomains in one place.

Google, Bing and the other engines read this line when they fetch robots.txt, so it works for every engine at once. What you do not get is feedback: no status, no discovered count, no error messages. Use both: the robots.txt line for discovery everywhere, the Search Console submission for the report.

What the statuses mean

Status	Meaning	What to do
Success	Google fetched and parsed the file. Discovered pages shows the URL count.	Nothing. Check the Page indexing report for what happened to the URLs.
Couldn't fetch	Google could not retrieve the file at all, or has not tried yet.	Wait a day for a new submission. Then check the URL, robots.txt, firewall and property prefix.
Has errors	Google fetched the file but found problems: invalid XML, HTML instead of XML, URLs on another host, too many URLs.	Click the row to see the error list, fix the file, submit again.

Both failure states, including the exact error messages Google uses, are worked through in Sitemap could not be read or Couldn't fetch.

"Success" does not mean indexed. It means Google read the list. The table also shows Last read, the date Google last fetched the file, which is the figure to watch after you change it.

How long until discovered pages shows a number

Usually minutes to a day. A new submission sometimes shows "Couldn't fetch" or a dash in the Discovered pages column for the first day even though the file is fine, then flips to "Success" on the next attempt. Do not delete and resubmit during that window; it just restarts the wait.

To see what Google did with the URLs, open Indexing > Pages and change the filter at the top from "All known pages" to your sitemap. The report then shows indexed and not indexed counts for the submitted URLs only, with the reason for each excluded group. Expect this report to lag the sitemap read by days.

Resubmitting after changes

The old way, a GET request to google.com/ping?sitemap=..., was switched off at the end of 2023. Hitting it now does nothing.

What works in 2026:

• Keep lastmod accurate. Google says it uses <lastmod> when the values are consistently correct, and it re-reads submitted sitemaps on its own schedule. A sitemap whose lastmod values only change when pages really change is the signal Google trusts. Setting every URL to today's date on each build destroys that trust. The details are in lastmod best practices.
• Submit the same path again in the Sitemaps report if you want to nudge a re-read. It records a new submission date. Google's documentation says resubmitting does not speed up crawling of the URLs themselves.
• Update the sitemap index file's lastmod when a child sitemap changes, so Google knows which child to re-read.

What does not work: removing the sitemap and adding it back every morning, or submitting a dozen copies under different names. Google reads the file when it decides to, and the URLs inside are crawled on their own priority.

Sitemap index files

For more than 50,000 URLs, or simply to split the site by section, create a sitemap index:

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

Submit only the index. Search Console lists it with a count of child sitemaps, and clicking it shows each child with its own status and discovered count. An index cannot reference another index; Google reports nested indexes as an error. Structure and limits for big sites are in sitemap index files for large sites.

Common mistakes

Submitting the HTML sitemap. The "Sitemap" page in your site's footer is for people. Search Console wants the XML file and reports "Has errors" with a message that the sitemap appears to be an HTML page.

Relative URLs. Every <loc> must be absolute: https://www.yoursite.com/page, not /page.

Wrong host in the URLs. URLs on yoursite.com in a sitemap served from www.yoursite.com are flagged as not allowed. Match the canonical host exactly, including protocol.

The sitemap is blocked by robots.txt. A Disallow: /sitemap rule, or a catch-all that happens to match, stops Google reading it. Test the sitemap URL in the robots.txt tester with Googlebot as the agent.

The file is behind a firewall rule. CDN bot protection that challenges every non-browser request returns a challenge page or a 403 to Googlebot. Allow Googlebot by its verified IP ranges, not by user agent alone.

URLs that should not be there. Redirects, 404s, noindex pages, canonicalised duplicates and parameter variants waste the file and generate confusing "submitted" exclusions in the Page indexing report. A sitemap should list only live, indexable, canonical URLs.

Expecting the sitemap to override everything else. Google treats the sitemap as a hint about what exists. Internal links, content quality and site history decide what gets crawled and indexed. The full format reference is in the XML sitemap guide.

What happens after the submission

Google reads the file, adds new URLs to its crawl queue, and uses lastmod to decide whether known URLs are worth fetching again. Crawling follows days later, indexing some time after that if the page qualifies, and the Page indexing report catches up after that.

If you would rather not watch the report by hand, TurboIndex reads the sitemaps you submitted in Search Console (or the ones listed in robots.txt), notices new and changed URLs, checks each one with its own crawler, TurboIndexBot, before anything is sent, and then asks Google about every URL through the URL Inspection API over the following two weeks. What the crawler requests and how to control it is on the TurboIndexBot page.

What to do next

1. Validate the file and fix any error it reports.
2. Add the Sitemap: line to robots.txt.
3. Submit the file in Search Console under Indexing, Sitemaps.
4. Check back the next day: the status should read Success with a discovered count that matches your URL count.
5. After a week, filter the Page indexing report by the sitemap and work through the not indexed reasons, largest group first.