Blog/How to Submit a Sitemap to Google (and When It Actually Helps) (2026)

How to Submit a Sitemap to Google (and When It Actually Helps) (2026)

How to submit a sitemap to Google via Search Console or robots.txt, the format limits Google enforces, the dead ping endpoint, and 'Couldn't fetch' fixes.

IndexBolt Team·

You submit a sitemap to Google in one of two ways: add it in Google Search Console's Sitemaps report, or reference it with a Sitemap: line in robots.txt. The third method still taught in older tutorials — the sitemap ping endpoint — was deprecated in June 2023 and now returns errors. Submission hands Google your URL inventory for discovery and recrawl scheduling; it does not guarantee indexing, and it does not let you set a crawl schedule.

This guide walks both submission routes step by step, lists the format rules Google enforces, separates what submission does from what it doesn't, identifies the site profiles where sitemaps matter most, and fixes the two failure states that follow submission: "Couldn't fetch" and URL pileups in "Discovered – currently not crawled".

TL;DR — Quick Summary

  • Two supported routes: the Search Console Sitemaps report (submission plus monitoring) and the Sitemap: directive in robots.txt (submission only)
  • The ping endpoint is dead — deprecated June 2023; requests to it return errors, so remove it from plugins and scripts
  • Format limits: 50,000 URLs and 50 MB uncompressed per file; larger inventories split under a sitemap index file
  • lastmod is the field Google uses — when it is consistently accurate; priority and changefreq are ignored
  • Submission buys discovery and recrawl hints — never an indexing guarantee, never schedule control
  • Sitemaps matter most on large sites, new sites with few links, sites with weak internal linking, and inventories containing orphan pages
  • Hygiene rule: only canonical, 200-status URLs, with lastmod that changes only when content changes — faked freshness gets the field ignored

How Do You Submit a Sitemap in Google Search Console?

You submit a sitemap in Search Console by opening Indexing → Sitemaps, entering the sitemap's path in the "Add a new sitemap" field, and clicking Submit. The report then tracks fetch status, parse errors, and discovered-URL counts for every sitemap you have submitted.

  1. Verify the property in Google Search Console — submission requires ownership
  2. Generate the sitemap and confirm it is reachable in a browser (most CMSs serve one at /sitemap.xml by default)
  3. Open Indexing → Sitemaps in the left navigation
  4. Enter the path relative to the property root — sitemap.xml or sitemap_index.xml — and click Submit
  5. Read the status column: Success (fetched and parsed), Has errors (parsed with problems), or Couldn't fetch (not retrieved — fixes below)
  6. Return after a few days and check the discovered-pages count; the Pages report can then filter indexing states per sitemap

Submit the sitemap index file once and Google follows it to every child sitemap — individual children need no separate submission. Google's reference on building and submitting a sitemap documents the same flow plus the format details below.

An XML sitemap submitted here keeps paying reporting dividends: per-sitemap indexed counts are the fastest way to spot which section of a site Google is declining.


How Do You Submit a Sitemap Through Robots.txt?

The second route is a single line in robots.txt: Sitemap: https://example.com/sitemap.xml. The directive takes an absolute URL, is valid anywhere in the file, repeats for multiple sitemaps, and is read by every major search engine — not just Google.

The robots.txt route trades monitoring for reach. It announces the sitemap to Google, Bing, and every other compliant crawler without any account, but it produces no reporting: no fetch status, no error list, no discovered-URL counts. Use both routes together — robots.txt for engine-wide announcement, Search Console for the diagnostics — and keep the two pointing at the same file.


Why Should You Stop Pinging the Sitemap Endpoint?

Google deprecated the sitemap ping endpoint in June 2023, and requests to it now return errors. The announcement in Google's Search Central blog ended a channel that had run since 2005 — and a long tail of plugins, CI scripts, and "instant indexing" tutorials still fire GET requests at a URL that answers with an error page.

Remove the ping from anything that still sends it. The replacement is not another endpoint; it is the lastmod field: Google refetches submitted sitemaps on its own schedule and uses accurate lastmod values to decide which URLs to recrawl. A changed page gets announced by its updated lastmod on Google's next sitemap fetch — that is the whole freshness mechanism.


What Format Rules Does Google Enforce?

A sitemap file holds at most 50,000 URLs and 50 MB uncompressed; bigger inventories split into multiple files referenced by a sitemap index, which itself lists up to 50,000 sitemaps. Gzip compression is allowed, but the 50 MB limit applies to the uncompressed file.

Google reads fewer fields than the protocol defines:

FieldGoogle's treatment
<loc>Required — the URL itself
<lastmod>Used for recrawl scheduling, while the values stay consistently accurate
<changefreq>Ignored
<priority>Ignored

Generating priority and changefreq is wasted effort; tuning them is doubly so. The one field worth engineering is lastmod, and its rule is strict: the timestamp changes when the page content meaningfully changes, and never otherwise. Generators that stamp every URL with the file's regeneration time teach Google the field is unreliable site-wide, which forfeits the recrawl benefit submission exists to provide.


What Does Submitting a Sitemap Actually Do?

Submission delivers exactly two things: discovery — Google learns every listed URL exists, including pages no link would have surfaced — and recrawl hints, because accurate lastmod values tell Google which known URLs changed. Both feed crawling; neither commands it.

What submission does not do draws the boundary:

  • No indexing guarantee. Every listed URL passes through the same selective search engine indexing evaluation as any other URL; Google indexes the subset it judges valuable.
  • No schedule control. Google decides when to fetch each URL. A sitemap entry carries no urgency, and every entry carries the same weight.
  • No ranking effect. A sitemap moves URLs into the pipeline; it moves nothing up the results.

For a single URL that cannot wait for Google's schedule, the per-URL channels — ranked in how to submit a URL to Google — are the right tool; the sitemap is the inventory layer underneath them.

Sitemap submitted, URLs still waiting?

A sitemap invites a crawl on Google's schedule — IndexBolt submits your URLs directly into Google's crawl systems and gets them crawled in hours. Pay per URL, 100 free credits to start, no credit card required.


When Do Sitemaps Matter Most?

Sitemaps matter most where link-based discovery is weakest: large sites, new sites, sites with thin internal linking, and inventories containing orphan pages. On these profiles the sitemap is primary discovery infrastructure; everywhere else it is cheap insurance.

  • Large sites — deep pages sit many clicks from the homepage, and per-section sitemaps double as diagnostics for which sections Google neglects
  • New sites — with few external links pointing in, the sitemap is often Google's first complete view of the URL inventory; the full launch sequence is in our guide to a new website not showing in Google
  • Sites with weak internal linking — URLs reachable only through navigation dead ends get announced by the sitemap instead
  • Inventories with orphan pages — pages linked from nowhere are invisible to crawling without a sitemap entry

A small, densely linked site gets discovered fully without a sitemap. Maintenance costs are near zero, so it belongs on every site anyway — but expect it to change outcomes only on the four profiles above.


What Does Sitemap Hygiene Require?

A clean sitemap lists only canonical, indexable, 200-status URLs with truthful lastmod values. Every entry that violates this wastes crawl attention and muddies the per-sitemap reporting that makes Search Console diagnostic.

Exclude four kinds of URLs: redirected URLs (list the target instead), noindexed URLs, robots.txt-blocked URLs, and 404s. Each is an invitation to fetch a page you have told Google not to use.

Keep lastmod honest. Faked freshness — bumping every date on regeneration to bait recrawls — backfires in one move: Google compares the claim against fetched reality, stops trusting the field for the whole site, and your genuinely updated pages lose their recrawl signal along with the fakes.

Before submitting, run the file through the XML Sitemap Validator to catch malformed XML, size violations, and non-canonical entries in one pass.


How Do You Fix "Couldn't Fetch" and Sitemap Pileups?

"Couldn't fetch" means Google did not retrieve the file, and the cause is one of five: a wrong path, a robots.txt block, a server failure, malformed output, or a report that has not caught up with a fresh submission.

  1. Wrong path — open the exact submitted URL in a browser; a 404 means the path in Search Console does not match where the file lives
  2. Robots.txt block — a Disallow rule matching the sitemap URL stops Googlebot from fetching it; allow the path
  3. Server failure — 5xx responses or timeouts on the sitemap URL; oversized dynamically generated files are the usual culprit, and splitting them fixes both problems
  4. Malformed output — the URL returns HTML (an error page, a login redirect) or broken XML instead of the sitemap; validate and fix the generator
  5. Fresh submission — a just-submitted sitemap can display "Couldn't fetch" before the first fetch completes; recheck the next day before changing anything

The second failure state arrives after a successful fetch: the sitemap reads Success while its URLs pile up in "Discovered – currently not crawled". That is not a sitemap problem — discovery worked; crawl demand is the bottleneck. The repair levers are stronger internal links, a pruned URL inventory, and direct submission, worked through in our guide to fixing "Discovered - Currently Not Crawled".


Frequently Asked Questions

How often should you resubmit a sitemap to Google?

Never on a schedule. Google refetches submitted sitemaps periodically on its own, and resubmitting an unchanged file triggers nothing. Resubmit only when the sitemap's URL changes; for content changes, updating lastmod inside the file is the signal Google reads.

Where should the sitemap file live?

At the site root — https://example.com/sitemap.xml — which lets it cover every URL on the host. Reference the same absolute URL in robots.txt and submit the same path in Search Console, so both routes and the file never disagree.

Does submitting a sitemap guarantee indexing?

No. Submission guarantees Google learns the URLs exist. Indexing stays selective: every listed URL is crawled on Google's schedule and evaluated against quality thresholds, and large sites routinely see a meaningful share of sitemap URLs excluded with states like "Crawled - currently not indexed".

Should you split one sitemap into several?

Yes, once a site has distinct sections — products, categories, posts — even far below the 50,000-URL cap. Per-section sitemaps under one index file turn Search Console's per-sitemap counts into a section-by-section indexing report, which is the fastest way to localize a coverage problem.

Discovery done — now get the crawl

When sitemap URLs sit unfetched for weeks, IndexBolt moves them into Google's crawl systems directly — crawled in hours, pay per URL. Start with 100 free credits, no credit card, and credits never expire.

Ready to get your URLs indexed?

Start with 100 free credits. No credit card required.