A sitemap.xml that exists and is accessible does not guarantee it is doing its job correctly. This file, meant to help Google discover and prioritize a site's pages, can contain inconsistencies that go unnoticed for months while quietly reducing its actual usefulness. Unlike an obvious server error, these problems generally trigger no clear warning message, which explains why they often remain uncorrected.
Domain inconsistency, a subtle but common mistake
A sitemap declaring URLs in http while the site actually responds in https, or using a domain form different from the one actually served to visitors, such as with or without the www prefix, creates confusion for Google. The engine may then index pages under a URL form that is not the one the site considers canonical, which dilutes the ranking signal across several variants of the same page instead of concentrating it on a single address. This inconsistency frequently happens after an https migration or a server configuration change, when the sitemap generator was not reconfigured to follow that change.
A sitemap that includes pages it should not contain
The sitemap should only contain pages meant to be indexed, in their canonical version. Including noindex pages, redirected pages, error pages, or URLs with tracking and filtering parameters sends a contradictory signal to Google, which receives on one hand an instruction to index the page through the sitemap and on the other the opposite instruction through the noindex tag or the redirect code present on the page itself. This contradiction does not necessarily prevent indexing, but it weakens the trust placed in the sitemap as a whole.
Incorrect or missing last modification dates
The lastmod tag tells Google when a page was last modified, useful information for prioritizing recrawling of pages that genuinely changed rather than wasting crawl budget on pages unchanged for a long time. A poorly configured sitemap generator can apply the same date to every page on the site, or a date systematically updated every time the file is generated even without any real content change. Google has publicly stated it distrusts dates it deems unreliable and may simply ignore this information if it looks inconsistent, which cancels the point of this tag without the sitemap showing any visible technical error.
Size limits often forgotten
A single sitemap cannot contain more than fifty thousand URLs, nor exceed fifty megabytes uncompressed. A site approaching or exceeding these limits must split its URLs across several files, grouped through a sitemap index referencing each of them. A multilingual site with several hundred articles translated into five languages can reach this volume faster than expected, which makes this check worth doing even for a site that seems modestly sized at first glance.
A sitemap that no longer reflects the site's actual content
A sitemap generated once and never automatically updated eventually drifts away from the site's actual content: deleted pages remain listed, while new pages never appear in it. On WordPress, common SEO plugins automatically regenerate this file with every publication, but a custom PHP build without an equivalent mechanism can accumulate this gap for months without anyone noticing, until a manual check reveals the difference between the two lists.
How to actually check your sitemap
Google Search Console's Sitemaps report shows the number of URLs submitted and the number actually discovered, a significant gap between the two figures being a signal worth examining closely. Validating the XML format with a dedicated tool helps spot a syntax error that would prevent the file from being read correctly. Finally, a manual check comparing a handful of sitemap URLs against their actual status, namely whether they respond with a 200 without redirect or error, remains the simplest way to confirm the file genuinely matches the site's reality.
Points to verify before publishing: confirm that the limits of fifty thousand URLs and fifty megabytes per sitemap file remain the official figures in force at the time of publication, and check that the description of Google's behavior toward lastmod dates it deems unreliable still matches the official Google Search Central documentation.