Is it really necessary to maintain two sitemaps during an HTTPS migration?

Why does Google recommend having two separate sitemaps?

The reasoning behind this recommendation is based on the detection of 301 redirects. When Google crawls the old HTTP sitemap, it discovers the original URLs, follows the redirects to HTTPS, and recognizes that it is a structured migration rather than a chaotic redesign.

The new HTTPS sitemap serves as an explicit signal of target URLs. It tells Google which pages should now be prioritized in the index. This voluntary redundancy speeds up the transfer of ranking signals (links, authority, history) from old to new URLs.

How does this dual submission speed up reindexing?

Without a dedicated HTTPS sitemap, Google must rely solely on organic discovery: crawling HTTP pages, following redirects, queuing new URLs. This process can take several weeks for large sites.

With both sitemaps active, Google immediately has the complete list of prioritized HTTPS URLs. The engine can allocate crawl budget right from the launch of the migration, without waiting to gradually discover new pages through redirects or internal linking.

What is the recommended duration for maintenance?

Mueller's statement does not specify a deadline, leaving practitioners uncertain. Field observation shows that it is advisable to maintain both sitemaps until 95% of HTTP URLs have disappeared from the index.

In Search Console, monitor the HTTP property: as long as URLs appear indexed there, keep the sitemap. Once the migration is solidified (all HTTPS URLs indexed, no HTTP traces left), you can safely remove the HTTP sitemap.

• Maintain two Search Console properties (HTTP and HTTPS) throughout the migration for parallel monitoring
• Submit the HTTP sitemap in the HTTP property, and the HTTPS sitemap in the HTTPS property—never cross them
• Ensure that 301 redirects are in place before submitting the sitemaps to avoid 404 errors
• Monitor coverage reports in both properties to quickly detect any indexing anomalies
• Wait for full stabilization before removing the HTTP sitemap—hurrying this step can slow down the migration

Is this recommendation consistent with observed practices?

Yes, and it’s one of the few Google pieces of advice that holds up in the field. HTTPS migrations with a dual sitemap show a 30 to 40% faster reindexing compared to those relying on just one HTTPS sitemap with redirects. The engine clearly treats sitemaps as prioritization signals, not merely as lists of URLs.

However, caution is necessary: this strategy works only if the 301 redirects are clean. An HTTP sitemap pointing to URLs that redirect in chains (HTTP → HTTP/www → HTTPS) creates confusion. Google wastes time resolving these multiple redirects, and the promised acceleration disappears.

What nuances should be added to this statement?

Mueller remains deliberately vague on the maintenance duration. In practice, removing the HTTP sitemap too early can block the migration midway if some URLs haven’t been recrawled yet. Removing too late poses no technical issues, but it creates unnecessary noise in your Search Console reports.

Additionally, the recommendation assumes that your HTTP sitemap is perfectly up to date. If your old sitemap contained outdated URLs, 404 errors, or inconsistent canonical tags, do not submit it as is. [To verify] Clean it up first, otherwise, you lead Google to dead ends.

In what cases does this rule not apply?

For a site with fewer than 500 pages and a dense internal linking structure, the dual sitemap strategy offers a marginal gain. Google will naturally discover the new HTTPS URLs in a few days through standard crawling. The effort of maintaining two Search Console properties is not always justified.

For heavy JavaScript platforms (SPAs in React/Vue/Angular), discovery via sitemap becomes critical since JavaScript crawling is slow. But in this case, ensure that your sitemaps point to server-rendered or pre-rendered URLs, not to empty shells that Googlebot will have to hydrate.

What should you do practically before launching the migration?

Before even considering sitemaps, ensure that your SSL certificate is correctly installed and all HTTPS pages load without mixed content errors. A sitemap pointing to broken HTTPS URLs will only alert Google to technical issues.

Next, generate a complete HTTPS sitemap that includes all priority URLs. Verify that it contains no HTTP URLs, no redirects, and no canonical links to another page. At the same time, retrieve your current HTTP sitemap and make sure it is up to date, without 404s or soft 404s.

How to manage both Search Console properties effectively?

Create or claim the HTTPS property in Search Console if you haven’t done so already. Do not delete the HTTP property: it remains your monitoring dashboard during the migration. Submit the HTTP sitemap in the old property, and the HTTPS sitemap in the new.

Set up alerts in both properties to quickly detect spikes in crawl errors. Check the coverage report each week to ensure that HTTP URLs are gradually disappearing from the index while HTTPS URLs gain traction.

When to remove the HTTP sitemap and close the property?

Wait until the HTTP property shows less than 5% of indexed URLs compared to the initial peak. This means Google has properly understood the migration and switched its index. You can then remove the HTTP sitemap, but keep the property active for an additional 2 to 3 months to monitor for any possible rollbacks.

Close the HTTP property permanently only when no HTTP URL appears in search results (use the command site:yourdomain.com in HTTP). This caution avoids unpleasant surprises if Google has cached a few HTTP URLs deeply.

• Check that all 301 redirects from HTTP to HTTPS are in place and functional (test a representative sample manually)
• Generate a clean HTTPS sitemap with no HTTP URLs, redirects, or 404 errors
• Submit the HTTP sitemap in the HTTP property of Search Console, the HTTPS sitemap in the HTTPS property—never the reverse
• Set up error alerts in both properties to react quickly in case of technical issues
• Monitor coverage reports weekly to measure the progress of index transfer
• Remove the HTTP sitemap only when less than 5% of HTTP URLs remain indexed