The XML sitemap is one of the most mentioned files in SEO, but its actual functioning remains poorly understood. Adding a URL to this file does not guarantee its crawling or indexing by Google. The decision relies on other criteria: page accessibility, canonicalization, content quality, internal linking. Measuring the gap between what the sitemap promises and what search engines do with it allows for better calibration of optimization efforts.
XML Sitemap and Indexing: What the Tags Really Signal to Search Engines
| Sitemap Tag | Perceived Role | Actual Behavior of Google |
|---|---|---|
| <loc> | Indexing request | Discovery signal only, no guarantee of crawling |
| <lastmod> | Last updated date | Considered only if the date corresponds to a significant and verifiable content change |
| <changefreq> | Desired crawl frequency | Ignored by Google for several years |
| <priority> | Relative importance of the page | Ignored by Google, no effect on ranking |
This table summarizes a notable gap between the specification of the sitemap protocol and its exploitation by Google. Two tags out of four have no measurable effect. Only the loc and lastmod tags actually influence crawling, and even then, under strict conditions.
The lastmod tag deserves special attention. Google utilizes it when the date reflects an observable change on the page. Automatically regenerating the sitemap every night by updating all dates without modifying the content degrades the reliability of the signal. Bing adopts a similar logic: according to its documentation published in 2025, lastmod serves as a freshness signal in AI-driven search.
To delve deeper into the configuration and submission of this file, you can learn more on Kiwik, which details the technical steps related to the XML sitemap.
Ping Google with the XML Sitemap: An Obsolete Method to Eliminate
Many CMS and SEO plugins still integrate a “ping” mechanism that notifies Google of each sitemap update. This system relied on an unauthenticated notification endpoint that Google deprecated in June 2023 and then disabled. Calls to this endpoint no longer produce any effect.
The only two methods still functional for signaling a sitemap to Google are declaring it in the robots.txt file and direct submission via Google Search Console. The first is passive but permanent: the robots.txt file is regularly read by crawlers, and the line Sitemap: https://example.com/sitemap.xml is sufficient to maintain the link. The second provides feedback on the number of submitted and indexed URLs.
In contrast, Bing offers a more responsive mechanism via IndexNow, which allows real-time notification of modified URLs. This protocol, also adopted by other engines, serves as a relevant complement to the sitemap for sites with a high publication frequency.
XML Sitemap and Internal Linking: Two Complementary Navigation Signals
A well-constructed sitemap does not replace a coherent site architecture. Google discovers the majority of pages through internal linking, following links from one page to another. The sitemap acts as a safety net for orphaned pages or deep content that natural crawling might miss.
When a site has hundreds of product pages accessible only through internal search filters, the XML sitemap becomes the only means to signal their existence to search engines. However, if each page is accessible within three clicks from the homepage, the sitemap provides marginal benefit for discovery.
The value of the sitemap thus depends on the type of site:
- E-commerce sites with thousands of product listings and filtering facets benefit the most from the sitemap, as it compensates for gaps in internal linking on long-tail pages
- Showcase sites with fewer than fifty well-linked pages gain little from the sitemap for discovery, but it remains useful for monitoring the submitted/indexed URL ratio in Search Console
- News sites with high daily publication benefit from combining a classic XML sitemap and a news sitemap, the latter signaling to engines the articles published in the last 48 hours
Configuration Errors in the XML Sitemap File to Correct as a Priority
Several common errors reduce the usefulness of the sitemap without the webmaster noticing. The first is including URLs that return an HTTP 404 or 301 code. A sitemap that contains redirects or non-existent pages sends a contradictory signal: the file requests the crawling of a resource that the server refuses to serve.
The second error concerns inconsistency between canonical URLs and URLs listed in the sitemap. If a page declares a rel="canonical" tag pointing to another URL, but the sitemap references the non-canonical page, Google must arbitrate between two opposing signals. Each URL in the sitemap must correspond to the canonical version of the page.
The third common issue: sitemaps exceeding the limit of 50,000 URLs or 50 MB uncompressed. Beyond these thresholds, the file must be split into sub-sitemaps referenced by a sitemap index. Major CMSs manage this segmentation automatically, but custom solutions often overlook it.
- Check that all URLs in the sitemap return an HTTP 200 code
- Ensure that each listed URL is the canonical version of the page
- Monitor the file size and segment if necessary via a sitemap index
- Remove
changefreqandprioritytags that bloat the file without benefit
The XML sitemap functions as a declarative inventory submitted to search engines, not as a ranking lever. Its value lies in the consistency between the URLs it lists and the actual state of the site. A clean file, synchronized with the site’s structure and declared in robots.txt, covers nearly all needs. Additional efforts should focus on internal linking and the quality of the pages themselves, where positioning is truly determined.
