An XML sitemap that lists redirected URLs, noindex pages, or canonical addresses pointing to other resources sends conflicting signals to search engines. This is often observed after a redesign: the file is technically valid, but it points to pages that Google should not explore. Optimizing a site’s structure with an effective sitemap starts with this cleanup, not with the automatic generation of the file.
XML Sitemap after a Redesign: Conflicting Signals to Correct
When migrating a site or reorganizing the structure, the CMS often regenerates the sitemap without checking the actual status of the URLs. This results in a file that contains old addresses redirected with 301, pages that have been set to noindex since the redesign, and sometimes URLs that return a 404 or 410 error.
The concrete problem: Google receives a list of URLs presented as valid and then discovers that they are not. The crawl budget is wasted, and the indexing of new pages is delayed.
The post-redesign check should follow a simple logic. Extract all URLs from the sitemap, run them through a crawler (Screaming Frog, Sitebulb, or equivalent), and cross-reference three columns: HTTP code, indexing directive, declared canonical URL.
Any URL that does not return a 200, has a noindex, or whose canonical tag points elsewhere must be removed from the file. You can see how the site yvazur.ch structures its own sitemap to illustrate a clean approach to this sorting.
Lastmod Tag in the Sitemap: When It’s Better to Remove It Than to Keep It
The lastmod tag is the main usable signal for Google in an XML sitemap. But this utility relies on a strict condition: the date must correspond to a real and significant modification of the content, structured data, or internal links of the page.
In practice, many CMSs update this date with every deployment, even when nothing has changed on the page. A simple footer change, an update of the copyright year, a cache rebuild – and all dates are set to the current date.
The Ground Reflex That Avoids the Trap
If your CMS cannot provide a reliable date related to a real content modification, it is better to completely remove the lastmod tag rather than keep it with misleading values. Google eventually ignores inconsistent dates, and in this case, their presence only adds noise.
Conversely, on an editorial site where each article is genuinely updated (adding paragraphs, refreshing data), a reliable lastmod accelerates the consideration of changes. It’s a concrete lever for pages that evolve regularly.
Priority and Changefreq Tags: What the XML Sitemap No Longer Does
There are still sitemaps packed with priority and changefreq tags, sometimes configured carefully. Google ignores these two elements. Their presence brings no SEO benefit.
Rather than wasting time calibrating priorities that no one reads, it is better to focus the effort on the consistency between four elements:
- The URL present in the sitemap must be the canonical version declared in the page’s source code
- This same URL must be accessible (code 200), without intermediate redirection
- The internal linking of the site must point to this URL, not to a variant with or without a trailing slash, with or without www
- The page must not carry any noindex directive if it appears in the sitemap
A sitemap consistent with the internal linking and canonical tags does more for indexing than any priority setting.
Sitemap and Orphan Pages: A Frequently Neglected Use Case
The sitemap does not replace internal linking, but it plays a specific role for pages that receive no links from the rest of the site. We are talking about orphan pages: they exist, they are indexable, but no navigation path allows access to them.
This case frequently occurs on e-commerce sites (product sheets removed from the catalog but still online), blogs with deep archives, or sites that have undergone several successive redesigns without a link audit.
How to Handle Orphan Pages in the Sitemap
The first question is whether these pages deserve to be indexed. If so, two parallel actions:
- Include them in the XML sitemap so that search engines can discover them
- Create at least one relevant internal link to each, from a thematically close page
- Check that the canonical tag of each orphan page points correctly to itself
If these pages no longer have value (outdated content, disappeared product), it is better to remove them from the sitemap and properly deindex them with a noindex or a 410 redirect.
Submitting the XML Sitemap: robots.txt and Search Console
Generating a clean sitemap is not enough if search engines do not know where to find it. Two submission channels work in parallel.
The first is the robots.txt file. You add a line Sitemap: followed by the absolute URL of the file. This declaration is read by all compatible search engines, not just Google. It is the passive channel, which works without manual intervention after setup.
The second is Google Search Console (and its equivalent Bing Webmaster Tools). Submission via these tools allows you to track the indexing status of the listed URLs, identify crawl errors, and verify that the file is being read correctly. Feedback varies on the frequency of sitemap recrawling after submission, but the initial consideration is generally quick.
The point not to overlook: if your site exceeds the volume limit of a single sitemap file, an index sitemap that groups several segmented files (by category, by content type) remains the standard technical solution. Each child file follows the same cleanliness rules as the main file.
A well-structured sitemap does not directly improve a page’s ranking. Its role is to ensure that search engines find, crawl, and understand the right URLs. The gain is measured in indexing rates and the speed of consideration of changes, two metrics that Search Console allows you to track concretely.
