Most site owners treat the XML sitemap as a box to tick. A plugin generates one, it gets submitted once, and nobody opens it again until something stops ranking. That is a reasonable way to run a ten-page site. It is a bad way to run a service-area site with two hundred location pages, because on that kind of site the sitemap is one of the few places where you can see the difference between the URLs you think you publish and the URLs you actually publish.
Here is what an XML sitemap does, which parts of it Google reads, which parts it throws away, and how to get something useful out of the Sitemaps report in Search Console.
A sitemap is a hint, not an instruction
An XML sitemap is a file listing the URLs on your site that you want search engines to know about. It does not force crawling, it does not force indexing, and it does not improve the ranking of the URLs inside it. Google’s documentation says submitting a sitemap “is merely a hint” and does not guarantee that the sitemap will be downloaded or used for crawling. What a sitemap does is discovery: it gives a crawler a list of canonical URLs it might otherwise reach slowly, or not at all.
That distinction matters most when a page is missing from search results. A URL sitting in your sitemap is not evidence that Google wants to index it — only that Google has been told the URL exists. Confusing the two is how teams spend a month resubmitting a sitemap for a page being dropped for an unrelated reason.
Google is also direct about who does not need one. Search Console Help states that if you have a small site — about 500 pages or fewer — and every page is reachable by following links from your homepage, you probably do not need a sitemap or the Sitemaps report at all. Internal linking does the same job. If your site is under that threshold and pages are not getting indexed, the sitemap is almost never the cause.
The size limits are real, and they are specific
A single sitemap file is limited to 50MB uncompressed or 50,000 URLs, whichever comes first. That limit is defined by the sitemaps protocol and documented by Google Search Central. Exceed either ceiling and you must split the file into multiple sitemaps, which you can then list in a sitemap index file and submit as one URL. Sites that quietly outgrow the limit tend to find out when the newest URLs stop being discovered, because the generator truncated the file rather than failing loudly.
Two smaller rules go with it. The file must be UTF-8 encoded. And the URLs inside it must be fully qualified and absolute — https://example.com/page/, not /page/ — because Google attempts to crawl the URLs exactly as listed. A relative path in a sitemap is not a minor style issue; it is a URL that does not resolve.
There is one more placement rule that catches people who host sitemaps in a subfolder. Unless you submit it through Search Console, a sitemap only affects descendants of its parent directory. A sitemap at /blog/sitemap.xml that lists your service pages has no authority over them. Putting sitemaps at the site root avoids the whole question.
What Google ignores
Plenty of sitemap advice is spent tuning fields that have no effect. Google’s documentation is unambiguous on two of them:
Priority: Google ignores <priority> values entirely, so setting your homepage to 1.0 and your blog posts to 0.3 changes nothing about how either is treated.
Changefreq: Google ignores <changefreq> values too, which means declaring a page “daily” does not buy it more frequent crawling.
Lastmod: This one is used — but conditionally. Google uses the <lastmod> value if it is consistently and verifiably accurate, for instance by comparing it against the page’s actual last modification. The value should reflect the last significant update to the page: a change to the main content, the structured data, or the links. Google explicitly names updating the copyright date as an example of a change that is not significant.
That last point is the one worth acting on. A sitemap generator that stamps every URL with today’s date every time the file regenerates is not signaling freshness. It is producing a field that cannot be verified against the page, and a signal that cannot be verified is a signal that gets discounted. If your sitemap claims every page on the site changed this morning, you have turned a useful field into noise.
Where service-area sites break
Sites built around dozens or hundreds of near-identical city pages fail in specific, repeatable ways. These are the mechanisms, not the symptoms.
Stale URLs after consolidation: When pages are merged or retired, the sitemap keeps listing the old URLs until the generator is rebuilt, which means you are actively submitting a list of redirects as if they were destinations.
Non-canonical URLs in the file: If a URL in the sitemap canonicalizes to a different URL, you are telling Google to crawl one address while the page tells it to index another, and the sitemap loses that argument every time.
Mixed hostnames: A sitemap listing www URLs on a non-www property, or http on an https site, produces a report that looks empty for reasons that have nothing to do with the sitemap’s contents.
Noindexed URLs included by default: Most generators include everything published unless told otherwise, so thin pages you deliberately excluded from search still get submitted for crawling.
We ran into the first of these on this site recently. A set of city landing pages was consolidated into a cleaner structure, and roughly ninety redirects were put in place to route the old URLs to the new ones. Redirects are the correct fix — but until the sitemap is regenerated, the file still advertises the retired addresses. The redirect does its job for a visitor or a crawler arriving at an old URL. It does nothing to stop your own sitemap from insisting the old URL is the one you want indexed.
That is the unglamorous part of a site migration nobody schedules: the redirect map, the internal links, and the sitemap all have to be updated, and only the first one feels urgent.
The Sitemaps report shows less than you think
Three things about the Search Console Sitemaps report surprise people who assume it is a complete picture.
It only shows sitemaps you submitted through the report or the API. Sitemaps that Google discovered through a robots.txt reference do not appear. If your sitemap “isn’t listed,” it may be working perfectly and simply have been found another way. You can still submit it manually to get success and error tracking.
Redirects are not followed for the submitted sitemap URL. The report uses the exact URL you entered. If you moved your sitemap and left a redirect at the old address, the submission does not follow it — which is a quiet failure mode on a site that just finished a migration.
“Discovered pages” is a parse count, not an index count. It is the number of page URLs parsed out of the file, with duplicates counted once, and it carries no guarantee that any of them have been or will be crawled or indexed.
The report also caps at 1,000 submitted requests, and if a fetch or parse fails, Google keeps retrying for a few days before giving up on that URL. Errors affecting individual URLs inside a sitemap will not stop Google reading the rest of the file.
What to check this week
Open Search Console, go to the Sitemaps report, click your sitemap, and use “See index coverage” to filter the Page indexing report by that sitemap. You now have the only comparison that matters: URLs you submitted versus URLs Google actually indexed, with reasons attached to the gap.
Then open the sitemap file itself in a browser and check three things. Are any listed URLs redirecting? Are the hostnames identical to your Search Console property? Does the lastmod date on a page you have not touched in six months say six months ago, or today? Ten minutes of that beats another resubmission.
Sitemaps are maintenance, not strategy. They sit alongside the structural work — clean internal linking, canonical discipline, and a site build that produces sane URLs in the first place — that determines what gets crawled at all. If your pages are not being found, the sitemap is worth ten minutes of checking and rarely more; the answer is usually upstream in your technical SEO or in how the pages are linked together. The same holds for visibility in AI-generated answers: as we cover in our work on answer engine optimization, being quotable is about what the page says and how plainly it says it, not about a file format.
Sources
Primary documentation referenced in this article:
