Part of the SiteMap Series
In the previous lesson, you saw how JavaScript sites force a discovery problem: making sure the engines see URLs at all. Site migrations introduce a different kind of friction. The URLs are known. The discovery is not the issue. The challenge is orchestration: coordinating the sitemap, the redirects, the canonical tags, and the content rollout in a sequence that preserves indexing of what should stay indexed and replaces it with what should replace it.
Migrations are high-stakes scenarios for SEO because the wrong sequence of changes can cost rankings that took years to build. The sitemap plays a specific role in this orchestration. It signals to the engines which URLs are canonical right now. During a migration, that signal changes in coordination with everything else changing. The sitemap should reflect the destination state, not lag behind the redirects or get ahead of them.
This lesson covers what counts as a sitemap-affecting migration, the three-phase pattern that minimises the risk, how the sitemap interacts with redirects and canonical tags during the cutover, when to retire the old sitemap reference, how to handle lastmod for migrated content, and the Search Console mechanics that vary depending on what kind of migration you are doing.
What counts as a sitemap-affecting migration
Several kinds of changes count as migrations from a sitemap perspective. Each shares the same underlying problem (URL relationships need to change in coordination) but differs in scope.
URL restructuring within the same domain. Reorganising your taxonomy, moving products into different categories, changing URL slugs, switching from /blog/post-name/ to /insights/post-name/. The domain stays the same; the path structure changes. The sitemap needs to update to reflect the new paths.
Domain migrations. Moving from example.com to example.io, or from a subdomain to a primary domain. Every URL on the site changes. The sitemap, the redirects, and the Search Console configuration all need coordinated updates.
HTTPS migration. Moving from HTTP to HTTPS. Most sites have completed this already, but it still happens for legacy systems. From a sitemap perspective, it is equivalent to a domain migration (every URL changes, every redirect needs to fire) even though the change is just the protocol.
Platform migration with URL changes. Moving from WordPress to a headless setup, from Shopify to BigCommerce, from one CMS to another in a way that affects URL structures. The sitemap needs to be rebuilt on the new platform, and the URL relationships need to be preserved through redirects.
Subdomain consolidation. Merging blog.example.com and www.example.com into a single www.example.com/blog/. The blog URLs all move; the rest of the site stays the same. The sitemap on the destination domain needs to include the new blog paths; the sitemap on the source subdomain becomes a redirect signal during the transition.
What does not count as a sitemap-affecting migration: content updates that do not change URLs, new pages being added (those are normal content additions), redesigns that change only visual presentation. The sitemap-affecting migrations are specifically the ones where existing URLs change or move.
The three-phase migration sitemap pattern
Migrations are most reliable when treated as three phases with the sitemap updates timed to each phase. Rushing the sitemap update creates signal mismatches; lagging the update slows down indexing of the new URLs.
Phase 1: Pre-migration.
Before any URLs change, prepare the new sitemap and validate the 301 redirect map.
The new sitemap should be ready to deploy as part of the migration. It should contain only the new URLs (the destinations), not the old URLs that will redirect to them. Generate it from the new content source so the URL structure matches what will be live after cutover.
The redirect map should be a complete one-to-one mapping from old URLs to new URLs. Every URL currently in your sitemap should have a destination in the redirect map. Run the map through validation (test that each old URL successfully resolves to the intended new URL via a 301).
Phase 2: Cutover.
This is migration day. The redirects deploy, the new sitemap goes live, and the new content becomes accessible at the new URLs.
The order matters. The redirects should be in place first, so any traffic hitting the old URLs is routed to the new ones immediately. The new sitemap goes live at the same time, so when the engines re-crawl, they see the new URL list and the working redirects together. The Search Console submission updates as the new sitemap deploys.
Phase 3: Post-migration.
The migration is technically complete, but the indexing transition takes weeks. During this time, the old sitemap reference is kept submitted (covered next), the redirect log is monitored, and Search Console reports are watched for indexing of the new URLs.
The three-phase pattern minimises the window during which any signal is inconsistent. The redirects are live before the sitemap signals new URLs; the new sitemap is live before the old sitemap is retired; the new URLs are accessible before the engines are told about them.
How the sitemap interacts with redirects and canonical tags
During a migration, three signals must agree about what the canonical URL is for each piece of content.
The sitemap lists the new URLs (the destinations) as canonical.
The canonical tags on the new pages point to themselves (the new URLs are canonical).
The 301 redirects send the old URLs to the new ones, which the engines use to consolidate signals.
When all three agree, the engines update their index efficiently. The new URLs get indexed in place of the old ones, ranking signals consolidate to the new URLs, and the transition completes within a few weeks for most sites.
When the signals conflict, the engines get confused, and indexing slows. The common conflicts:
Sitemap lists old URLs, redirects point to new URLs. The engines see a sitemap entry for an old URL, crawl it, get a 301 to the new URL, and treat the sitemap signal as outdated. The new URL gets indexed eventually, but the sitemap is sending the wrong signal in the meantime.
Sitemap lists new URLs, redirects not yet deployed. The engines see new URLs in the sitemap, try to crawl them, and get 404 responses because the destinations are not live yet. The new URLs are flagged as not found. When the redirects finally deploy, the engines have to re-discover the URLs and remove the not-found flags.
Sitemap lists new URLs, canonical tags still point to old URLs. The engines see a new URL in the sitemap, crawl it, find a canonical tag pointing to the old URL, and follow the canonical. The new URL’s sitemap signal is ignored because the canonical tag overrides it.
The fix in every case is to align the three signals before the migration goes live. The sitemap, the redirects, and the canonical tags should all be updated as a coordinated set, not as independent changes.
When to retire the old sitemap
The old sitemap (the one that listed the URLs before the migration) plays a role during the post-migration window. It signals to the engines that the URLs in it are being retired, and combined with the 301 redirects, it accelerates re-crawling and consolidation.
For most migrations, keep the old sitemap submitted to Search Console for a few weeks after the cutover. The engines use it to re-crawl the old URLs and process the redirects. Once most of the old URLs have been re-crawled and the new URLs are appearing in indexing reports, the old sitemap has done its work.
The retirement timing depends on site size and crawl frequency. Small sites might see most old URLs re-crawled within 2-4 weeks. Large sites can take 2-3 months. Search Console’s Sitemaps report shows when the old sitemap has been fully processed; the lastmod values on the old sitemap entries help signal urgency.
Once you retire the old sitemap, two options exist. Remove it from Search Console entirely (the cleanest option). Or replace it with a static placeholder that 301 redirects to the new sitemap (some implementations do this to keep any external references to the old sitemap URL working).
What to avoid: keeping the old sitemap submitted indefinitely. Once the redirects have been processed and the indexing has consolidated, the old sitemap is just noise in Search Console.
Setting lastmod during a migration
Lastmod during a migration is one of the few cases where bumping lastmod for a URL whose content has not actually changed is the right move.
The reasoning is that from the engines’ perspective, the URL is new. They have not seen it before (or they have seen it before the migration as a different URL). Setting lastmod to the migration date signals “this URL is new and worth crawling soon.” Setting lastmod to the original content date (which might be years old) signals “this URL is stable; deprioritise re-crawling.”
For URLs whose content actually changes during the migration (rare but possible), use the new content’s update date.
For URLs whose content is unchanged but URL structure changed, use the migration date for the first sitemap submission, then return to the actual content update date on subsequent updates. This works because the migration date serves as a “discover this URL urgently” signal once, then normal lastmod behaviour resumes.
This pattern is one of the few cases where bumping lastmod for a non-content change is appropriate. The migration creates a real need for re-crawling that justifies the signal.
How to submit your sitemap during migration
Search Console mechanics during a migration vary by migration type.
For URL restructuring within the same domain. Submit the new sitemap to the existing Search Console property. The property URL has not changed. The old sitemap stays submitted for a few weeks, then gets retired.
For domain migrations. Use the Change of Address tool in Search Console. The tool tells Google that example.com is moving to example.io, which accelerates the consolidation of signals. Submit the new sitemap to a new Search Console property for the destination domain. Keep the old property to monitor the transition.
For HTTPS migrations. HTTPS counts as a separate property in Search Console. Set up the HTTPS property, submit the sitemap with HTTPS URLs to it, and keep the HTTP property to monitor the redirect rollout. The Change of Address tool is not strictly required for HTTPS migrations (Google handles HTTP-to-HTTPS as an upgrade), but it can be used.
For platform migrations within the same domain. Same as URL restructuring within the same domain, assuming the domain stays the same. The new platform generates a new sitemap with the new URL structure (if URLs are changing) or the same URL structure (if not).
For subdomain consolidation. Submit the new (consolidated) sitemap to the destination subdomain’s property. The source subdomain’s property gets retired after the redirect-driven consolidation is complete.
Bing Webmaster Tools mirrors most of this. The platform has a Site Move tool equivalent to GSC’s Change of Address. The same coordination principles apply.
Common gotchas to avoid
Five issues come up regularly with migration sitemaps.
1. Updating the sitemap before redirects are deployed
The sitemap lists the new URLs, but the actual URLs are not live yet. Engines try to crawl them, hit 404s, flag them as not found. When the redirects deploy later, the engines have to re-process. The fix is to deploy redirects first, then update the sitemap as part of the cutover.
2. Leaving old URLs in the new sitemap
The new sitemap somehow includes URLs from the old structure that have been 301-redirected. The engines see canonical signals (sitemap entry) conflicting with the redirect, and the sitemap signal gets ignored. The fix is to regenerate the sitemap from the new content source after migration, not by patching the old sitemap.
3. Retiring the old sitemap too quickly
The old sitemap is removed from Search Console within days of the migration. The engines lose the explicit signal that those old URLs are now redirecting, and re-crawling slows. The fix is to keep the old sitemap submitted for at least 4 to 6 weeks for most sites, longer for large sites.
4. Sitemap-canonical conflicts after migration
The sitemap lists new URLs. The new pages have canonical tags that still point to the old URLs (because the canonical tags were not updated as part of the migration). The engines follow the canonicals and effectively ignore the sitemap signals. The fix is to audit canonical tags as part of the cutover, ensuring they point to the new URLs (self-referencing) rather than the old ones.
5. Skipping the Change of Address tool for domain migrations
Domain migrations work without the Change of Address tool, but they work faster with it. Skipping it because it feels like an extra step costs weeks of consolidation time. The fix is to use the tool, even if the redirects and sitemaps are perfect on their own.
Where this leaves us
You can now plan a sitemap during a migration in a way that preserves indexing of what should stay indexed and accelerates the engines’ discovery of the new URLs. The principles of canonical URL listing and accurate lastmod from earlier modules still apply; the migration scenario adds the orchestration layer that coordinates the sitemap with redirects and canonical tags.
Multi-region and subdomain architecture come next. These setups create a different kind of sitemap question: how do sitemaps work across multiple domains, subdomains, and regional setups? The hreflang work from Module 3 is part of the answer, but only part. The other part is sitemap discoverability across an architecture where the URL space is split intentionally rather than accidentally. The next lesson covers the patterns that work.
Up next: How to Set Up Sitemaps for Multi-region or Subdomain Sites →
This is Module 4: Lesson 4 of The Sitemap Series, a Technical SEO series on sitemaps from first principles, built for the AI Search era.