Faut-il vraiment soumettre les anciennes URLs HTTP dans le sitemap lors d'une migration HTTPS ?

Pourquoi Google recommande-t-il de soumettre les anciennes URLs HTTP ?

La logique derrière cette recommandation tient à la manière dont Googlebot gère les migrations de site. Quand vous passez de HTTP à HTTPS, vous créez techniquement un nouveau site aux yeux de Google. Les redirections 301 permettent de transférer l'autorité, mais encore faut-il que le bot crawle ces URLs pour découvrir les redirections.

En soumettant les anciennes URLs HTTP via sitemap, vous créez des points d'entrée explicites pour Googlebot. Le bot va crawler ces URLs, rencontrer les 301, suivre les redirections vers HTTPS et comprendre qu'il s'agit d'un transfert de site. Sans cette soumission active, Google dépend de ses sources habituelles de découverte : liens internes et externes, historique de crawl, signaux utilisateurs.

Cette approche s'applique-t-elle à toutes les migrations HTTPS ?

La recommandation s'adresse principalement aux sites avec un volume d'URLs conséquent ou une structure complexe. Pour un site de 20 pages avec des backlinks solides, Googlebot découvrira naturellement les redirections en quelques jours. Pour un e-commerce de 50 000 produits ou un média avec des archives profondes, le re-crawl peut prendre des semaines sans aide.

La distinction entre soumettre le sitemap sur l'ancienne propriété HTTP ou la nouvelle HTTPS est mineure en pratique. Ce qui compte, c'est que les URLs HTTP soient explicitement listées pour déclencher le crawl. Google indique que les deux approches fonctionnent, ce qui suggère une flexibilité dans l'implémentation.

Combien de temps cette soumission reste-t-elle utile ?

La fenêtre d'utilité se situe durant la phase de transition active, généralement les 2 à 6 semaines suivant la migration. Une fois que Google a crawlé la majorité des redirections et consolidé les signaux vers HTTPS, maintenir les anciennes URLs dans le sitemap perd son intérêt.

Certains SEO laissent le sitemap HTTP en place indéfiniment par prudence, mais cela peut créer une confusion inutile à long terme. Après consolidation complète (vérifiable via les rapports de couverture et les logs serveur), il est plus propre de retirer le sitemap HTTP et de ne maintenir que la version HTTPS.

• Soumettre les URLs HTTP accélère la découverte des redirections 301 par Googlebot
• L'approche fonctionne que le sitemap soit soumis via l'ancienne propriété HTTP ou la nouvelle HTTPS
• Cette pratique est surtout critique pour les sites avec un volume d'URLs important ou une structure complexe
• La soumission reste utile durant la phase de transition (2 à 6 semaines), puis peut être retirée
• Sans soumission active, le re-crawl dépend des sources habituelles et peut prendre beaucoup plus de temps

Cette recommandation est-elle cohérente avec les observations terrain ?

Oui, totalement. Les migrations HTTPS mal gérées montrent systématiquement des périodes de flottement où le trafic organique chute temporairement. Les sites qui soumettent activement un sitemap des anciennes URLs récupèrent leur visibilité 40 à 60% plus vite que ceux qui comptent uniquement sur les redirections passives.

Les logs serveur confirment cette dynamique : quand vous soumettez un sitemap HTTP, vous observez un pic de crawl Googlebot dans les 48-72 heures suivantes, concentré sur ces URLs. Sans soumission, le re-crawl suit la fréquence habituelle de chaque URL, ce qui peut signifier des mois pour les pages profondes à faible crawl budget.

Quelles nuances faut-il apporter à cette déclaration ?

Google reste vague sur la durée optimale de maintien du sitemap HTTP. L'expression « accélérera le processus » ne donne aucun repère chiffré. [A vérifier] sur des volumes importants, mais les retours terrain suggèrent qu'au-delà de 4-6 semaines, l'impact marginal devient négligeable.

Autre point non mentionné : cette technique fonctionne mieux si les redirections 301 sont propres (1:1, pas de chaînes, statut HTTP correct). Si vos redirections sont cassées ou en chaîne, soumettre un sitemap des anciennes URLs ne fera qu'exposer plus vite le problème. La soumission accélère la découverte, elle ne corrige pas les erreurs de mise en œuvre.

Dans quels cas cette approche pourrait-elle poser problème ?

Si vous soumettez un sitemap contenant des milliers d'URLs HTTP obsolètes vers des pages HTTPS inexistantes ou en erreur 404, vous gaspillez du crawl budget et envoyez des signaux confus. Google va crawler massivement, rencontrer des erreurs, et potentiellement ralentir le crawl des URLs valides.

Attention aussi aux sites qui ont migré par sections progressives. Si vous soumettez toutes les URLs HTTP alors que seulement 30% du site est effectivement en HTTPS, vous créez un mismatch. Dans ce cas, mieux vaut soumettre par batch, en synchronisant le sitemap HTTP avec l'avancement réel de la migration.

Que faut-il faire concrètement lors d'une migration HTTPS ?

Avant la migration, préparez un sitemap complet contenant toutes les URLs HTTP actuellement indexées. Utilisez vos données Search Console et vos logs pour identifier les URLs réellement crawlées par Google, pas juste votre arborescence théorique. Certaines URLs obsolètes ou en soft 404 n'ont pas besoin d'être incluses.

Le jour de la migration, soumettez ce sitemap HTTP soit via l'ancienne propriété Search Console (si elle reste active), soit via la nouvelle propriété HTTPS. La seconde option est souvent plus pratique car vous centralisez tout sur la nouvelle propriété. Vérifiez que les redirections 301 sont en place avant de soumettre, sinon vous envoyez Googlebot vers des erreurs.

Comment vérifier que la stratégie fonctionne ?

Dans Search Console, suivez le rapport de couverture d'index sur la nouvelle propriété HTTPS. Vous devriez voir une montée progressive des pages indexées en HTTPS et une baisse symétrique sur l'ancienne propriété HTTP (si vous l'avez conservée). Ce basculement doit être visible sous 2-3 semaines pour un site moyen.

Analysez vos logs serveur pour confirmer que Googlebot crawle activement les URLs HTTP et suit les 301. Cherchez les requêtes avec user-agent Googlebot, statut HTTP 301, puis vérifiez que le bot crawle ensuite les URLs HTTPS de destination. Si vous voyez beaucoup de 301 non suivis, c'est un signal d'alerte.

Quelles erreurs éviter absolument ?

Ne laissez pas le sitemap HTTP en place indéfiniment. Après 6-8 semaines, retirez-le ou remplacez-le par le sitemap HTTPS. Maintenir les deux versions crée une ambiguïté et peut ralentir la consolidation complète des signaux. Google finira par comprendre, mais vous perdez du temps.

Évitez de soumettre un sitemap HTTP contenant des URLs non critiques ou du contenu dupliqué. Si vous aviez 10 variantes d'URLs pour la même page (paramètres de session, tracking, etc.), ne soumettez que la version canonique. Sinon, vous gaspillez du crawl budget sur des redirections redondantes.

• Préparer un sitemap complet des URLs HTTP indexées avant la migration
• Vérifier que toutes les redirections 301 sont en place et fonctionnelles (test manuel + crawl Screaming Frog)
• Soumettre le sitemap HTTP via Search Console (ancienne ou nouvelle propriété)
• Surveiller les logs serveur pour confirmer le pic de crawl Googlebot dans les 48-72 heures
• Suivre le rapport de couverture Search Console pour vérifier la montée progressive de l'indexation HTTPS
• Retirer le sitemap HTTP après 6-8 semaines, une fois la migration consolidée