Should you really create a sitemap for old HTTP URLs when migrating to HTTPS?

Why does Google recommend a sitemap for old HTTP URLs?

During an HTTP to HTTPS migration, each URL changes its protocol. For Google, this technically represents a new address, even if the content remains the same. The engine must therefore transfer all the signals accumulated by the old version (authority, backlinks, crawl history) to the new one.

A sitemap containing old HTTP URLs allows Googlebot to crawl these addresses more quickly and discover the associated 301 redirects. Without this sitemap, the bot could take several weeks to re-crawl all the old URLs, delaying the consolidation of signals on the new HTTPS addresses.

How does this signal transfer work in practice?

Google detects the permanent 301 redirect between the old HTTP URL and the new HTTPS. At that moment, the algorithm begins to merge the signals: the PageRank transmitted by the backlinks, engagement metrics, content age.

This process is not instantaneous. According to official statements, it can take several weeks or months depending on the site's crawl frequency. By submitting a sitemap of the old URLs, you compel Googlebot to explore these redirects as a priority rather than waiting for the next natural crawl.

What is the difference compared to a standard sitemap containing only HTTPS URLs?

A standard HTTPS sitemap helps Google discover and index the new addresses. However, it does not necessarily trigger a priority crawl of the old HTTP URLs that still carry historical signals.

By creating a temporary sitemap with the old addresses, you explicitly indicate to Google: "These URLs still exist (via 301), crawl them now to transfer the signals". This is a form of manual prioritization of the crawl budget on critical redirects.

• An HTTP sitemap speeds up the detection of 301 redirects during a protocol migration
• The transfer of SEO signals is never instantaneous, even with properly configured permanent redirects
• This practice specifically applies to HTTP to HTTPS migrations, not to typical site structure overhauls
• Google remains vague on the actual time gain: "accelerating" can mean a few days or several weeks depending on the size of the site
• A temporary sitemap should be removed after migration to avoid cluttering Search Console with outdated URLs

Is this recommendation consistent with real-world observations?

On well-executed HTTPS migrations, practitioners indeed find that sites that submitted an HTTP sitemap recover more quickly in the SERPs. The period of fluctuation — where organic traffic temporarily drops — seems reduced by 30 to 50% in duration.

However, this correlation does not prove causation. Sites that take the time to create an HTTP sitemap are also those who carefully manage other aspects of the migration: tested redirects, no 301 chains, immediate internal link updates. It's hard to isolate the impact of the sitemap alone. [To be verified]

What limits should be set for this practice?

Google speaks of "accelerating" the transfer, not guaranteeing it. On a site with 10,000 pages crawled daily, the impact will be marginal or even negligible. The bot already visits often, so it will naturally detect 301s in a few days.

Conversely, on a site with a tight crawl budget (deep pages, low authority), forcing the passage via sitemap can unblock the situation. The real issue is that Google does not provide any numbers, no benchmarks. "Accelerating" remains a vague promise without associated metrics.

In what cases is this technique completely useless?

If you have already updated all your internal links to HTTPS URLs and your linking points exclusively to the new addresses, Googlebot will naturally discover the new URLs through regular crawling. The HTTP sitemap then becomes redundant.

Similarly, if your site enjoys intensive daily crawling (news, fast-paced e-commerce), Google will revisit the old HTTP URLs within 24-48 hours regardless. Adding a sitemap will not change the speed of signal transfer, which is mainly dependent on the natural re-crawl frequency.

What should you concretely do during an HTTPS migration?

Generate a sitemap.xml file containing all your old HTTP URLs, even those that are no longer directly accessible. This file should point to addresses with the http:// protocol, not https://. Submit it in Search Console as a distinct temporary sitemap.

At the same time, create a second sitemap with only the new HTTPS URLs. This will become your main sitemap once the migration is complete. Keep both active for 4 to 8 weeks, allowing Google to extensively crawl the redirects.

What technical mistakes sabotage this strategy?

The classic mistake: submitting an HTTP sitemap before the 301 redirects are in place. As a result, Google crawls the old URLs, encounters 404s or temporary 302s, and signals do not transfer. The migration goes awry.

Another trap: leaving the HTTP sitemap active indefinitely. After 2-3 months, it will only pollute your coverage reports with outdated URLs. Remove it properly once Search Console confirms that the new HTTPS URLs are predominantly indexed.

How to verify that the signal transfer is operating correctly?

Monitor in Search Console the ratio between crawled HTTP URLs and indexed HTTPS URLs. If after 3 weeks you still see 80% crawling on the old HTTP addresses, it means that the redirects are not detected or that the crawl budget is saturated.

Use a tool like Screaming Frog to check that no redirect chains have slipped in (HTTP → HTTPS → HTTPS with www, for example). Each additional jump dilutes the transfer of PageRank and slows down the consolidation of signals.

• Configure all 301 redirects from HTTP to HTTPS before submitting the sitemap
• Create two distinct sitemaps: one for old HTTP URLs, one for new HTTPS URLs
• Submit the HTTP sitemap in Search Console as a temporary file
• Update all internal links to point directly to HTTPS
• Monitor coverage reports for 404 errors or redirect chains
• Remove the HTTP sitemap after 6-8 weeks once the transfer is stabilized