How to create a sitemap, and the “Couldn’t fetch” sitemap error.

A sitemap is an XML file that tells search engines the addresses of a site’s pages in a single file, and it usually sits at the root of the site under the name sitemap.xml. Most content management systems generate it automatically; once created, it is submitted through Search Console and its address is declared in the robots.txt file. The “Couldn’t fetch” warning, by contrast, means Google could not retrieve the file itself: most often the address is wrong, the file is blocked by robots.txt, or the server did not respond.

A sitemap tells Google “these pages exist”; it does not say “index these pages.” Google states plainly that it does not guarantee every address in the sitemap will be crawled or indexed. In the same document it adds that in most cases a site benefits from having a sitemap. A sitemap is a tool that makes discovery easier; it does not fix content problems, but it speeds up being found and makes it easier to read in Search Console which page is missing from the index and why.

For a short dictionary definition, see the sitemap entry. This guide explains how a sitemap is created, how it is submitted, and what the frequently searched “Couldn’t fetch” warning means. If you would like to check together whether the sitemap is set up correctly on your site, SEO consulting starts with this file.

Does every site need a sitemap?

By Google’s own criteria, no. A site with roughly 500 pages or fewer, whose pages are well connected to one another through internal links, and which does not carry a lot of video, image or news content, can be found without a sitemap. Large sites, new sites that receive few links from outside, and sites with rich media or news content, on the other hand, need a sitemap more, according to Google.

In practice a sitemap is set up on almost every site, because it costs little and gives Search Console a list of the site’s pages. That list is the written answer to the question “which of my pages do I want in the index,” and every later reading of the index is made against it.

How do you create a sitemap?

There are three ways. The first is for the content management system to generate the sitemap automatically; most systems do this either natively or through a plugin, and update the sitemap as pages are added. The second is for the build tool that generates the site to output the sitemap together with the pages; this site works that way. The third is to write the sitemap by hand for a site of a few pages; it is the most fragile route, because someone has to remember the sitemap with every new page.

Whichever route you choose, the file usually sits at the root of the site under the name sitemap.xml. You can see for yourself whether your site has one by typing your domain followed by “/sitemap.xml” into your browser’s address bar. The file that opens is a list of page addresses arranged one below the other.

What should a good sitemap contain?

• Only the main addresses — pages you want to appear in search results and that give themselves as their own canonical address. Redirected addresses, addresses returning 404, or addresses excluded from the index should not be in the sitemap.
• Full addresses — complete addresses that start with “https://” and include the domain; Google wants full addresses, not relative paths.
• UTF-8 encoding — so that addresses containing Turkish characters are not corrupted.
• Size limit — at most 50,000 addresses or 50 MB uncompressed per file; larger sites split the sitemap and combine the parts with an index file.
• An honest date — Google uses the lastmod (last modified) field only if it is consistently and verifiably accurate; a fake date that changes every day leads to the date not being read at all.
• Unnecessary fields — Google ignores the priority and changefreq fields; their presence does no harm, but it gains nothing either.

How do you submit a sitemap to Google?

Two routes are used together. The first is to enter the sitemap’s address in the Sitemaps report in Search Console and submit it; the report then shows whether the sitemap was read and how many addresses were found in it. If Search Console is not set up, it has to be set up first; we described the steps in the Search Console guide.

The second is to add a line to the robots.txt file that starts with “Sitemap:” and gives the full address of the sitemap. This line tells not only Google but every crawler that reads it where the sitemap is. This site’s robots.txt file has that line, and it points to the full address of the sitemap. We explained how this differs from IndexNow, another way to speed up discovery, in a separate comparison.

What does the “Couldn’t fetch” sitemap error mean?

This warning says Google could not retrieve the sitemap file itself; the problem is not in the sitemap’s content but in reaching the file. According to Google’s help page, the usual causes are:

• The sitemap is blocked by robots.txt.
• The submitted address is wrong and the server returns 404.
• The server did not respond at that moment.
• A manual action has been applied to the site.
• The site’s crawl demand is low.

Google writes that it retries a sitemap it could not fetch over several days. The order of checks is this: click the sitemap’s row in the report and read the error text in the details; then give the sitemap address to the URL Inspection tool and check whether crawling is allowed and whether the page can be fetched; fix the problem and resubmit the sitemap. Trying for yourself whether the address opens in a browser is the fastest first check.

A different case is the “has errors” warning on a sitemap that was read. Here the file was retrieved, but lines were found in it that could not be parsed. Google states that it still queues for crawling the addresses that could be read without errors; in other words, the sitemap does not become entirely useless, but it is read incompletely until the faulty lines are fixed.

How is this site’s sitemap generated?

First-hand evidence: this site’s sitemap is not written by hand; it is generated in the same build as the pages, and it follows two rules. The first rule concerns the date. Each page’s “when did this last change” information lives in the dateModified field of the page’s own structured data, and the lastmod date in the sitemap is derived directly from there. So for the same address the page cannot state one date and the sitemap another; the two sources cannot drift apart structurally. And the date moves forward only when the page’s content actually changes, not with every build.

The second rule concerns scope: only pages actually generated in that build can enter the sitemap. This rule was born of a defect. An audit on 22.08.2026 found that the sitemap was derived from the intention of “which pages should exist”: a directory page whose content existed only in Turkish had been written into the sitemap in three languages, and a tool page that had not yet been generated was in the sitemap as well. Both promised Google a page that did not exist, in other words a 404. Since that day the sitemap has been derived not from intention but from the pages actually sitting on disk.

A sitemap is a promise: every address in it says “there is a page here, and it is current.” A sitemap that does not keep its promise cannot be trusted.

Can a sitemap replace internal links?

No. Google’s criterion says so from the other direction: a small site whose pages are well linked to one another can be found without a sitemap, which means the main route of discovery is links. A page that sits only in the sitemap and receives links from no other page will be found, but the site itself has not declared it important. Such pages can show up in Search Console under “Crawled – currently not indexed”; we explained how to read that row in a separate guide. A sitemap is a list; which page is important is something the site’s own links say.

How do you set up a sitemap on a multilingual site?

On a site that publishes in more than one language, the sitemap can also carry additional information linking each page’s language versions to one another. This is a way of telling Google about the relationship between translations once more, separately from inside the pages, and its setup has points that need care; we covered the details in the multilingual sitemap guide.

A final reminder: a sitemap helps only if the rest of the site is sound. If pages in the sitemap carry noindex, are blocked by robots.txt, or point to another page as their main address, the sitemap sends a contradictory message. We gathered all of these obstacles under nine headings in the guide to not showing up on Google.

If you want to find out together why your site doesn’t show up on Google, SEO consulting audits every layer from crawling to indexing and makes the fix in the source code.