A sitemap is an inventory published by a site owner. It can make important public URLs easier to discover, but the presence of a URL in the file says nothing by itself about whether that URL was crawled or indexed (Google, "Learn about Sitemaps"). Its practical value is narrower: it publishes the URLs the site prefers as canonical (Google, "Build and Submit a Sitemap").
Treat the file as an inventory
Google defines a sitemap as a file that describes pages and other files on a site, their relationships, and information such as modification dates. Its guidance says that a sitemap can help discovery, especially on large or complex sites, while a well-linked site may already expose most important pages through navigation (Google, "Learn about Sitemaps").
A listed URL establishes only that the publisher put it in the sitemap. Google explicitly says that sitemaps do not guarantee that every listed item will be crawled or indexed (Google, "Learn about Sitemaps"). The file should therefore be evaluated as an inventory, not as evidence of search performance.
This framing also makes omissions easier to reason about. If a page matters but is missing, first ask whether the publishing pipeline left it out and whether ordinary crawlable links expose it elsewhere. If a retired or duplicate URL remains, the sitemap may be describing a site that no longer exists in that form.
Consistency matters more than decoration
Google tells publishers to use fully qualified URLs and to list the canonical versions they prefer, rather than every alternate URL that reaches the same content (Google, "Build and Submit a Sitemap"). A sitemap filled with mixed hosts, HTTP and HTTPS variants, or duplicate locations may still be parseable, but it is not a clear inventory.
The optional lastmod value needs similar discipline. Google says it uses that value when it is consistently and verifiably accurate, and that it should reflect the last significant update to the page rather than a routine change such as a copyright-date edit (Google, "Build and Submit a Sitemap"). A build timestamp copied onto every URL may be valid XML while conveying little about which content changed. If the publishing system cannot produce meaningful dates, omitting them is clearer than manufacturing freshness.
Google also ignores the XML priority and changefreq values (Google, "Build and Submit a Sitemap"). Time spent tuning those fields for Google is better spent reconciling the URL list with the site's actual canonical content.
Submission is still a hint
A publisher can make a sitemap available to Google through Search Console, its API, or a Sitemap line in robots.txt (Google, "Build and Submit a Sitemap"). Google describes submission as a hint and says it does not guarantee that Google will download the sitemap or use it when crawling the site's URLs (Google, "Build and Submit a Sitemap"). A robots.txt reference is useful discovery evidence, but it does not prove that a sitemap was submitted through a private Search Console property or processed by any particular crawler.
How MachineRead reads the map
There is no standalone sitemap score. MachineRead uses sitemap evidence within the LLM Text & Markdown Access and Search Discovery Hints report groups.
Within those groups, MachineRead looks for /sitemap.xml and for sitemap locations named in robots.txt. It parses a limited set of XML sitemap and sitemap-index responses, records URL and lastmod conditions, and samples for issues such as duplicate entries, off-site locations, non-HTTPS URLs, and pages that do not return an accessible, indexable response.
A clean sample is evidence about the files and URLs inspected during that audit, not a complete crawl of every entry. Likewise, a missing robots.txt reference means MachineRead did not observe that submission route; it does not establish whether the sitemap was submitted through Search Console or another private channel.
What this check can and cannot establish
The check can establish whether MachineRead found a parseable XML sitemap at the locations it inspected, what the sample contained, whether robots.txt named a sitemap, and whether selected URL and date conditions were present.
It cannot establish complete site coverage, private submission status, crawler processing, indexing, ranking, traffic, citations, or later use by an automated client. It also cannot infer that an unlisted page is unreachable without examining the site's links and other discovery routes.
Keep the map tied to the site
Generate the sitemap from the same source that determines published canonical URLs. On each release, compare additions, removals, redirects, host changes, and meaningful modification dates with that source. If the sitemap is split into indexes, check the child files as well as the index.
When MachineRead flags an entry, inspect the returned URL and the sitemap generator before treating the symptom as a search problem. Correct the public inventory first. What a crawler does with that inventory requires separate evidence.
Works Cited
Google. "Build and Submit a Sitemap." Google Search Central, updated 8 July 2026, https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap. Accessed 7 Aug. 2026.
Google. "Learn about Sitemaps." Google Search Central, updated 10 Dec. 2025, https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview. Accessed 7 Aug. 2026.
See also
- Methodology reference - documents sitemap evidence within the public check groups
- Launch post - explains the audit's evidence boundaries
- Related: search discovery and canonical URL