A sitemap is a file that lists the pages on your site so search engines can find them. Submitting it to Google takes about thirty seconds once you know what to type, and the reason people get stuck is that Search Console shows a box with no explanation of what belongs in it.
What to paste in the box
The complete web address of your sitemap file, including the https part. If your sitemap lives at the root of your site, which is where we would put it, that is your domain followed by a slash and the file name. Search Console's own instruction is to test the sitemap URL first and then paste that same URL into the Add a new sitemap box and click Submit.
Two things worth knowing before you type. Google records the exact URL you specified and does not follow redirects, so a near-miss will not quietly resolve itself. And you need owner permissions on the property to submit through this report. If you do not have owner access, the robots.txt method below works without it.
One idea to drop straight away, because it causes real confusion. You are not uploading anything. Google's wording is that submitting a sitemap means telling Google where to find the file on your site, and that you cannot actually upload a sitemap to Google. The file stays on your site. You are handing over an address.
The three ways to submit a sitemap
Google currently documents three, and only three, plus a fourth option for feeds.
The first is the Sitemaps report in Search Console, described above. The second is the Search Console API, for anybody submitting programmatically. The third is your robots.txt file, and it is the one most people should also be using, because it costs nothing and needs no account access.
You add one line anywhere in robots.txt: the word Sitemap, a colon, and the full address of the file. Google says it will find it the next time it crawls your robots.txt. A few details from Google's specification are useful here. The field name is case-insensitive but its value is case-sensitive. It must be a fully qualified URL including protocol and host. You can include multiple sitemap lines and there is no limit on how many. And the line is not tied to any user agent, so every crawler that reads robots.txt can follow it.
The fourth option, if you publish an Atom or RSS feed, is WebSub, which broadcasts your changes to search engines including Google.
There used to be a fifth, and you will still find it in articles, plugins and tutorials. You could send a request to a Google URL to ping your sitemap and supposedly trigger a crawl. Google announced on 26 June 2023 that it was deprecating the endpoint, that it would stop functioning within six months, and that requests to it would return a 404 error. Google's own post now states that the deprecation is complete. Its stated reason was that the vast majority of those submissions were spam. If you are following instructions that include a ping step, those instructions are out of date, and Google notes that existing code using the endpoint causes no harm, it simply does nothing useful.
Does your site need a sitemap at all?
Possibly not, and this is worth checking before you spend an afternoon on it.
Google publishes guidance on when you might not need one. It names three conditions: your site is small, by which Google means about 500 pages or fewer counting only pages you want in search results; your site is comprehensively linked internally, meaning Googlebot can reach every important page by following links from your home page; and you do not have many videos, images or news pages that you want shown in search results.
Search Console Help is blunter still, saying that if you have a small site and can reach any page by following links from your homepage, you probably do not need a sitemap or the report, and that you should simply request indexing of your homepage instead. It also notes that if you use a hosting service such as Squarespace or Wix, they probably manage your sitemap for you.
You are more likely to need one if your site is large, if it is new and has few links pointing at it from elsewhere, or if it carries a lot of video or images you want found.
For a typical Nigerian small business site of fifteen or twenty pages with a working menu, the honest answer is that a sitemap is optional and requesting indexing of your homepage is the more useful five minutes.
What submitting a sitemap actually does, and does not do
It helps Google find your pages. That is the whole of it.
Google says this three separate times in three separate places, because the misunderstanding is so common. Submitting a sitemap is merely a hint, and does not guarantee that Google will download it or use it for crawling. A sitemap helps search engines discover URLs but does not guarantee that everything in it will be crawled and indexed. And there is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed.
Discovery is not crawling, and crawling is not indexing. A sitemap operates on the first of those three. If your pages are not being indexed, a sitemap is very unlikely to be the reason and resubmitting it will not fix it.
There is also no evidence, and no statement from Google, that having a sitemap improves your rankings. Everything Google publishes about sitemaps concerns discovery and crawl efficiency. The strongest true claim available is Google's own: in most cases, your site will benefit from having a sitemap.
The statuses, and what Couldn't fetch really means
Three statuses appear in the report. Success means the sitemap was loaded and processed with no errors and the URLs are queued for crawling. Has errors means it could be fetched but something in it is wrong, and any URLs that parsed correctly are still queued. Couldn't fetch means Google could not retrieve the file.
Most articles tell you Couldn't fetch is a server problem or a wrong address. Sometimes it is. Google's own list of causes is wider and includes two that surprise people. One is that your robots.txt is blocking the sitemap, because Google respects robots.txt when fetching sitemaps. The other is low crawl demand for the sitemap, and Google adds that the higher the quality of a site's content, the higher the crawl demand. An unresolved manual action will also stop sitemaps being read.
Google will keep retrying a failed fetch for a few days, and if it keeps failing, it stops trying that URL. Once a sitemap has been fetched successfully, Google recrawls it periodically at a pace unrelated to your site's normal crawl.
The column named Discovered pages counts the page URLs parsed out of the file, with duplicates counted once. It is not a count of indexed pages, and Google states plainly that there is no guarantee a URL discovered in a sitemap has been or will be crawled or indexed. To see how many are actually indexed, filter the Page indexing report by sitemap.
The mistakes that actually happen
The most common one is a property mismatch. Google treats the address with www and the address without it as different domains, and treats http and https as different too. A sitemap listing pages at one and submitted to a property for the other will be rejected with a URL not allowed error. Google's own examples make this explicit: for a sitemap at a www address, the same address without www is invalid, and the https version of a http address is invalid. Search Console Help warns separately that if you cannot find a sitemap you expected to see, check you are not confusing http with https or www with non-www.
Relative links inside the file are the second. Google asks for fully qualified absolute URLs and says it will try to crawl your URLs exactly as listed, so a line reading slash contact dot html rather than the full address will not work. Google documents this twice, once as advice and once as an error called URLs not followed.
Then a set of small things that break the file entirely. The XML namespace must read sitemap slash 0.9, and Google flags that people write .9 by mistake. Curly quotes pasted from a word processor break it. Unescaped ampersands break it. A sitemap index file cannot list other sitemap index files, only sitemap files.
Two pieces of housekeeping worth knowing. Deleting a sitemap from the report removes the sitemap from the report and nothing else. Google states directly that it will not forget the sitemap or any URLs listed in it, and that removing pages from Google needs a different tool. And the report only shows sitemaps submitted through the report or the API, not sitemaps Google found through your robots.txt, so an absence there does not mean anything is broken.
Limits, and the two tags that do nothing
A single sitemap file is limited to 50,000 URLs or 50MB uncompressed, whichever you hit first. That is per file rather than per site. Past either limit you split the file and optionally submit a sitemap index that points at the pieces. An index can hold up to 50,000 entries, and Google allows up to 500 sitemap index files per site. The file must be UTF-8 encoded. If you see a 10MB limit quoted anywhere, that figure is years out of date.
One point about where the file lives, which almost nobody writes. Google says you can host your sitemap anywhere on your site, but that unless you submit it through Search Console, a sitemap affects only descendants of its parent directory. A sitemap sitting at the root can therefore affect everything, which is why Google recommends putting it there.
Finally, two tags you can stop worrying about. Google states that it still does not use the changefreq or priority elements at all, and notes that priority generally does not accurately reflect the real priority of a page relative to others on the same site. Setting them is not harmful, it is simply pointless.
The lastmod tag is different and is worth filling in honestly. Google says it does use lastmod as a signal for scheduling crawls of URLs it already knows about, that it means last significant modification rather than a footer tweak, and that the value needs to match reality. Google's warning on that is unusually direct: if your page changed seven years ago but you keep saying it changed yesterday, eventually it will stop believing you.