How to Submit Your Sitemap to Google Search Console (2026)

You shipped the site. The pages are live, the HTML is clean, the content is good. And yet site:yourdomain.com returns nothing. Google doesn’t know you exist.

A sitemap is how you hand Google a machine-readable list of the URLs you want crawled. Submitting it through Google Search Console (GSC) tells Google “this is the canonical inventory of my site — start here.” It doesn’t guarantee indexing, but it removes the discovery problem, which for a brand-new site is the slowest part.

This guide is the practical, developer-facing version: verify ownership, submit the sitemap, request indexing for your important pages, decode the confusing Couldn't fetch status, and wire the sitemap into robots.txt so every crawler finds it. No fluff, real commands.

🧑‍💻 Developer view: a sitemap is just an XML document with a list of <loc> URLs plus optional <lastmod> hints. GSC is a dashboard over Google’s crawl/index pipeline. Submitting a sitemap is a POST-like “here’s my URL list” signal — nothing magical happens, you’re just shortening the path from “page exists” to “Googlebot fetches it.”

Verify ownership

Before GSC shows you anything, you have to prove you own the site. GSC offers two property types, and the choice matters because it determines both how you verify and what data you see.

	Domain property	URL-prefix property
Covers	All subdomains + http/https	One exact origin only
Example scope	`example.com`, `www.`, `blog.`, http & https	`https://example.com/` only
Verification	DNS `TXT` record	HTML tag, HTML file, GA, GTM, or DNS
Works on `*.pages.dev`	No (can’t edit DNS)	Yes
Best for	Sites where you control DNS	Subdomains, quick start, granular data

Domain property verifies via a DNS TXT record and then covers everything under the domain — every subdomain, both protocols. It’s the cleanest option if you own the DNS zone. GSC gives you a token to add:

# Add this as a TXT record on the apex (@) of your zone
google-site-verification=AbC123dEf456GhI789jKl0mNoPqRsTuVwXyZ_example

With most registrars or Cloudflare DNS you’d add it like:

Type:  TXT
Name:  @            (or yourdomain.com)
Value: google-site-verification=AbC123...
TTL:   Auto

Verify it propagated before clicking “Verify” in GSC:

dig +short TXT yourdomain.com | grep google-site-verification
# or
nslookup -type=TXT yourdomain.com

URL-prefix property verifies a single exact origin (the protocol + host + the trailing slash all matter — https://example.com/ and https://www.example.com/ are different properties). You can verify it several ways without touching DNS:

<!-- Option A: meta tag in the <head> of your homepage -->
<meta name="google-site-verification" content="AbC123dEf456GhI789jKl0..." />

# Option B: upload a verification file to the site root
# GSC gives you something like: google1234567890abcdef.html
# It must be reachable at:
https://example.com/google1234567890abcdef.html

Confirm the file is actually served before verifying:

curl -sI https://example.com/google1234567890abcdef.html | head -n 1
# Expect: HTTP/2 200

⚠️ The pages.dev (and similar *.vercel.app, *.netlify.app, *.workers.dev) trap: you cannot create a Domain property for a subdomain you don’t control the DNS for. You don’t own the pages.dev zone — Cloudflare does — so there’s no TXT record you can add at that level. For preview/staging subdomains, use a URL-prefix property and verify with the HTML meta tag or uploaded file instead. Once you put the site on your own custom domain, switch to (or add) a Domain property.

For most production sites on a custom domain, use a Domain property. For a *.pages.dev URL or any platform subdomain, use a URL-prefix property with file/meta verification.

Submit your sitemap

If your build generates a sitemap index (most frameworks do — the Astro sitemap integration, for example, emits sitemap-index.xml pointing at one or more sitemap-0.xml chunks), you submit the index, not the individual files. Google follows the index and reads every child.

First, sanity-check that the file is actually live and well-formed:

curl -s https://example.com/sitemap-index.xml | head -n 20
# Should return XML, not an HTML 404 page

# Check the status code and content type explicitly
curl -sI https://example.com/sitemap-index.xml | grep -iE 'HTTP/|content-type'
# Expect:
#   HTTP/2 200
#   content-type: application/xml   (or text/xml)

A valid sitemap index looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-0.xml</loc>
    <lastmod>2026-06-23T00:00:00.000Z</lastmod>
  </sitemap>
</sitemapindex>

Then in GSC:

Open Search Console → your property → Indexing → Sitemaps (left sidebar).
In the Add a new sitemap field, type the path relative to your property root. For most sites that’s just sitemap-index.xml. GSC prefills the domain, so you only type the path:
```
sitemap-index.xml
```
Click Submit.
The row appears with status Success (or, often at first, a temporary state — see the next section). Click the row to see how many URLs Google discovered.

💡 Submit the index file once, not each child. Google re-reads it on its own schedule, so there’s nothing to re-submit when you publish new pages — your build just regenerates the XML and Google picks up the new <loc> entries on the next pass.

Request indexing

Submitting a sitemap gets your URLs into Google’s discovery queue. For a handful of pages you care about most (homepage, key landing pages, your best content), you can nudge Google directly with the URL Inspection tool:

Paste the full URL into the search bar at the very top of GSC (it’s labeled “Inspect any URL in…”).
GSC fetches the URL from its index and shows whether it’s already indexed.
Click Test Live URL to confirm Google can fetch the current version (this also surfaces render problems, robots blocks, and noindex tags).
If it looks good, click Request Indexing. This adds the URL to a priority crawl queue.

Inspect:  https://example.com/                 → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/pricing           → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/blog/launch-post  → "URL is not on Google" → Request Indexing

⚠️ Request Indexing is rate-limited (a small daily quota) and is meant for individual important URLs — not for force-feeding a 5,000-page site. For bulk, the sitemap is the right tool; let crawling happen at scale on its own. Manual requests are for the 5–20 pages that matter most right now.

”Couldn’t fetch” is usually a false alarm

The single most common panic moment for new site owners: you submit sitemap-index.xml, refresh, and the status says Couldn't fetch. Before you start rewriting your XML, know this: right after submission, this status is frequently temporary. Google has queued the fetch but hasn’t actually retrieved and processed it yet, and the dashboard shows a placeholder. In a large share of cases it flips to Success within hours to a couple of days with zero changes on your end.

So the first step is genuinely: wait 1–3 days and re-check.

That said, if it persists, walk this checklist — these are the real causes, and each is verifiable from your terminal:

Returns 200. The sitemap URL must respond with 200 OK, not a redirect chain, 403, 404, or 5xx.

curl -sI https://example.com/sitemap-index.xml | head -n 1
# HTTP/2 200   = good   |   anything else (301/302/403/404/5xx) is a problem

Correct content type. Serve application/xml or text/xml. If your server sends text/html (common when a SPA fallback or a 404 page is returned instead of the file), Google may reject it.

curl -sI https://example.com/sitemap-index.xml | grep -i content-type
# content-type: application/xml   = good
# content-type: text/html         = bad (you're serving an HTML page, not the sitemap)

robots.txt doesn’t block it. A stray Disallow: /sitemap or an over-broad rule can stop Googlebot from reading the file. Fetch your robots and read it:
```
curl -s https://example.com/robots.txt
# Make sure nothing disallows the sitemap path for Googlebot
```
No protocol / host mismatch (the cross-origin trap). Every <loc> inside the sitemap must be on the same protocol and host as the property and the sitemap file itself. If your property is the https://example.com URL-prefix but your <loc> entries say http:// or www.example.com, Google treats them as cross-site and ignores them. Spot-check a few:
```
curl -s https://example.com/sitemap-0.xml | grep -oE '<loc>[^<]+' | head
# Every URL should start with https://example.com/ — no http://, no bare www mismatch
```
No noindex / auth wall on the sitemap path. Staging sites often sit behind HTTP basic auth or a Cloudflare Access policy. If the sitemap requires a login, Googlebot gets a 401/403 and can’t fetch it.

If all five pass and the status still won’t clear after a week, use Test Live URL on the sitemap URL in URL Inspection — it shows you the exact response Googlebot sees, which usually pinpoints the mismatch immediately.

How long until you’re indexed

Set expectations honestly, because impatience leads people to “fix” things that aren’t broken:

Site situation	Typical time to first indexed pages
Brand-new domain, no backlinks	A few days to several weeks
New pages on an established, frequently-crawled site	Hours to a few days
Large site, thin or duplicate content	Slow / partial — Google may skip pages

Discovery (Google knowing the URL exists) is fast once the sitemap is submitted. Indexing (Google fetching, rendering, evaluating, and deciding to store the page) is the part that takes time, and it’s a quality and trust decision, not just a queue. A fresh domain with no links and no history sits lower in priority — that’s normal, not a bug. Keep publishing, earn a few links, and crawl frequency rises on its own.

💡 “Discovered – currently not indexed” and “Crawled – currently not indexed” in the Pages report are not errors. They mean Google found (or fetched) the URL but hasn’t chosen to index it yet — usually a thin-content or low-priority signal on new sites. Improve the page or earn links rather than re-submitting.

Link it from robots.txt

GSC submission tells Google. Adding a Sitemap: line to robots.txt tells every crawler — Bing, DuckDuckGo, and anything else that respects the standard — without a per-engine dashboard. It’s a one-line belt-and-suspenders move, and it’s the canonical way to advertise a sitemap.

# robots.txt
User-agent: *
Allow: /

# Absolute URL, one per line; you can list multiple sitemaps
Sitemap: https://example.com/sitemap-index.xml

A few rules that trip people up:

The Sitemap: URL must be absolute (full https://...), not a relative path.
It’s independent of the User-agent blocks — put it anywhere in the file, conventionally at the top or bottom.
You can list multiple Sitemap: lines if you split sitemaps by section or language.

Verify it’s live:

curl -s https://example.com/robots.txt | grep -i sitemap
# Sitemap: https://example.com/sitemap-index.xml

🧑‍💻 How we did it on this site: this exact setup — autogenerated sitemap-index.xml, a Sitemap: line in robots.txt, a Domain property in GSC, and a few Request Indexing nudges for the cornerstone pages. If you want to generate clean robots.txt and sitemap entries without hand-editing XML, our robots & sitemap tool does it for you. And once Google is crawling, our guide on log analysis and crawl budget shows how to confirm Googlebot is actually fetching the URLs your sitemap advertises.

Wrapping up

The whole flow, in order:

Verify ownership — Domain property (DNS TXT) if you control DNS; URL-prefix (HTML tag/file) for pages.dev and other platform subdomains.
Submit sitemap-index.xml under Indexing → Sitemaps. Submit the index, not the children.
Request Indexing for your 5–20 most important URLs via URL Inspection.
Don’t panic at Couldn't fetch — wait 1–3 days, then run the 200 / content-type / robots / cross-origin / auth checklist.
Be patient — discovery is fast, indexing a new domain takes days to weeks.
Add a Sitemap: line to robots.txt so every crawler finds it.

Next steps: generate your robots.txt and sitemap config with the robots & sitemap tool, then watch Googlebot’s behavior in your server logs with the crawl budget guide. Submission is the start of the conversation with Google — the logs tell you whether it’s listening.