How to Submit a Sitemap to Google Search Console
A sitemap is the cheapest way to tell Google that a set of pages exists. Working out how to submit a sitemap to Google takes about two minutes of clicking, and almost all of the useful knowledge sits in what comes after: what the Sitemaps report is telling you, what it is quietly not telling you, and which of its warnings deserve an afternoon of your time. Submitting a sitemap asks Google to look at a list of URLs. It does not oblige Google to keep what it finds.
Here are the steps, then the reading.
Before you submit, get the file right
A sitemap is a machine-readable list of the URLs you consider canonical, normally XML. The sitemaps protocol allows up to 50,000 URLs or 50MB uncompressed in a single file, and a sitemap index file when a site outgrows that. Most content platforms generate one automatically at /sitemap.xml or /sitemap_index.xml.
Three checks first, because each one prevents an error message later:
Open the sitemap in a browser. It should load and show either URL entries or a list of child sitemaps. If you cannot fetch it, Google cannot either.
Check the host and protocol. Entries inside the file must be absolute URLs on the same site as the sitemap itself. A file on https://example.com listing http:// URLs, or listing URLs on a different subdomain, will be read and then largely ignored.
Check what is in the list. A sitemap is a statement about which pages you want in the index. Redirects, 404s, noindexed pages and non-canonical duplicates in the file make that statement less trustworthy, and Google’s guidance on building and submitting a sitemap treats the file as a hint about what exists rather than a queue it has agreed to work through. An accurate short sitemap is worth more than a long one full of noise.
How to submit a sitemap to Google Search Console
Step 1. Open the right property. Search Console requires verified ownership. A domain property covers every subdomain and protocol. A URL-prefix property covers only URLs under that exact prefix, so a sitemap at https://example.com/sitemap.xml does not belong to a property registered as http://example.com/.
Step 2. Go to Sitemaps. It sits in the left-hand menu under Indexing, below the Pages report.
Step 3. Enter the path, not the whole URL. The field is prefilled with your property root. You add what follows it, usually sitemap.xml. Pasting the full address on top of the prefix produces a doubled URL and a fetch failure, which is the single most common way this goes wrong.
Step 4. Click Submit. Google adds the sitemap to the list and attempts a fetch. The row appears immediately with a status and a date.
Step 5. Leave it alone. A submitted sitemap stays submitted. Google re-reads it periodically on its own schedule, and resubmitting the same file daily achieves nothing beyond a new timestamp. Remove and resubmit only if you have changed the sitemap’s location.
If you do not have verified access to the property, for instance on a client site where nobody will grant it, you can still declare the sitemap by adding a Sitemap: https://example.com/sitemap.xml line to your robots.txt file. Crawlers read it there. You lose the reporting, which is most of the value, but the declaration stands. The old ping URL that once let you notify Google of a sitemap without an account has been retired, so those two routes are what remain.
What the Sitemaps report actually reports
The row you get back holds four pieces of information: the type of file, the date Google last read it, a status, and a count of discovered URLs.
Success means the file was fetched and parsed. Nothing more. It is a statement about the file, not about your pages.
Has errors means the file was fetched but part of it did not parse, usually invalid XML, an unsupported tag, or entries outside the sitemap’s own host.
Couldn’t fetch means Google asked for the file and did not receive it. Wrong path, a server error at the moment of the request, or a robots.txt rule blocking the sitemap file itself.
Then there is Discovered URLs, the number most people read as good news. It is a count of URLs Google found inside the file. It is not a count of pages crawled, and it is emphatically not a count of pages indexed. A sitemap can report thousands of discovered URLs on a site with a fraction of that number in the index, and both figures can be correct at once. That distance between the two numbers is the whole subject of why submitted is not the same thing as indexed, and reading the sitemap row as an indexing result is how weeks get lost.
The warnings worth acting on
Two are worth your attention the day they appear.
“Sitemap contains URLs which are blocked by robots.txt.” You have told Google these pages matter and simultaneously told it not to fetch them. One instruction has to give. Usually the robots file is the mistake, and often it is a broad rule written years ago for a staging directory that now catches live pages. Our piece on the robots.txt Disallow trap covers how those rules overreach and how to test one before you ship it.
Errors that stop the parse. A malformed date, a stray ampersand, an entry pointing at another domain. Fix the generator rather than the file; a hand-edited sitemap regenerates into the same state on the next publish.
Everything else is informational. A last-read date that has not moved in a fortnight is not a fault; Google reads sitemaps at a cadence it sets itself.
After submission, check the pages rather than the file
The Sitemaps report answers one question: did Google read my list. To find out what happened to the URLs on that list, you need a different view. Inside Search Console, the page indexing report breaks your URLs into indexed and not indexed with a reason attached to each group, and it can be filtered to a specific sitemap, which is the closest Search Console comes to a per-sitemap indexing rate.
The other approach is to check the URLs against live Google results directly. That is what AIndexify does: you paste URLs or upload a CSV, up to 10,000 per submission, with no Search Console connection or ownership proof required, and each URL is checked on a schedule afterwards so that submitted and indexed are reported as two separate events with the date each one happened.
When pages from an accurate, successfully read sitemap still stay out, the sitemap is no longer the problem and resubmitting it will not become the answer. The causes are directives, canonicals, thin content, crawl history, or simply not yet, and our complete guide to Google indexing works through them in the order worth checking.
A sitemap is a good, dull, permanent piece of infrastructure. Submit it once, keep it honest, and spend the attention you save on the pages themselves.
See where your pages actually stand: submit your URLs and get submitted and indexed reported back separately, with the dates attached.