An XML sitemap does not control crawl or indexing. Google explicitly reminds us: submitting a sitemap does not guarantee the file will be downloaded, the URLs will be crawled, or that they will be considered in the index. The sitemap is a declarative signal, not an instruction. Understanding this distinction changes how we build, maintain, and integrate it into an SEO strategy.
Lastmod tag in the XML sitemap: what Google actually uses
The majority of production sitemaps display identical lastmod dates across all URLs, or dates corresponding to the file generation. Both cases are ignored by Google. The lastmod tag only has value if it reflects a substantial and verifiable change to the main content.
What constitutes a significant change: a change in the body text, an update of structured data, an addition or removal of internal links. Conversely, changing the year in a copyright or regenerating the file without touching the content does not qualify.
We recommend a regular audit of the sitemap to check the consistency between lastmod dates and actual changes. A CMS that updates lastmod with every save (even cosmetic) creates noise. It is better to condition the update of this tag on a real diff of the rendered content. You can view the sitemap of Référencement Qualitatif to see an example of a clean structure with consistent dates.
The changefreq and priority tags have become obsolete in practice. Google no longer gives them measurable weight. Continuing to fill them out is not harmful, but spending optimization time on them is unproductive. Only the URL and the lastmod value (when reliable) matter.
XML Sitemap and IndexNow: complementarity for Bing crawl
Bing explicitly recommends combining the sitemap with the IndexNow protocol. The sitemap provides persistent coverage of all URLs. IndexNow, on the other hand, transmits individual additions, updates, or deletions in near real-time.
This combination makes perfect sense for sites with dynamic content: e-commerce catalogs with price or stock variations, directories updated daily, news sites. The sitemap remains the reference base, while IndexNow accelerates the consideration of specific changes.
- The sitemap covers the complete inventory of the site’s canonical URLs, including rarely modified pages
- IndexNow notifies Bing (and compatible engines) of a specific change without waiting for the next sitemap crawl
- The two mechanisms are complementary: one does not replace the other, and maintaining them in parallel reduces indexing delay
On the implementation side, IndexNow requires an API key hosted at the root of the site and an HTTP call with each publication or modification. Most CMSs have compatible plugins.
Sitemap segmentation for high-volume page sites
A single sitemap containing several tens of thousands of URLs poses two problems. The file becomes heavy to download for bots, and it drowns strategic pages in the mass. Segmentation by content type (articles, products, categories, static pages) via a sitemap index allows for prioritizing the submitted files.
We observe a concrete gain when segmented sitemaps are associated with a cleanup of non-canonical URLs. Including redirected URLs, noindex pages, or parameter variations in the sitemap sends a contradictory signal. The sitemap must accurately reflect the pages you want to see indexed, nothing more.
Filtering criteria before inclusion in the sitemap
- The page returns an HTTP 200 code and is not blocked by robots.txt
- The page has a self-referential canonical tag (canonical pointing to itself)
- The page is not in noindex and is not orphaned (at least one internal link points to it)
- The page contains sufficient indexable content (not an empty shell or an unfilled template)
Automating this check in the sitemap generation pipeline prevents the accumulation of dead URLs. Some crawl tools allow cross-referencing the sitemap with the actual state of the site and reporting inconsistencies.
Submitting the sitemap in Google Search Console: common errors
Submitting a sitemap via Google Search Console remains the most direct method to signal its existence. The most common mistake is submitting the file once and then never checking the associated coverage report.
The sitemap coverage report in Search Console indicates how many submitted URLs are actually indexed, how many are excluded, and for what reason. A significant gap between submitted URLs and indexed URLs signals a quality issue: duplicate content, thin pages, crawl errors, or misconfigured canonicals.
Another trap: declaring the sitemap in robots.txt with an incorrect URL (HTTP protocol instead of HTTPS, wrong subdomain). The robots.txt file must point to the exact URL of the sitemap, accessible without redirection.
Recommended verification frequency
On a site publishing several pieces of content per week, a monthly check of the coverage report is sufficient to detect deviations. On a more static site, a quarterly audit remains relevant. The goal is not to submit the sitemap more often, but to ensure that what it declares matches what Google observes during crawl.
The sitemap remains a communication tool between your site and search engines. Its value entirely depends on the rigor with which it is maintained. An outdated or inconsistent sitemap does not help SEO; it muddles it.
