Migration HTTP vers HTTPS

En bref — Une migration HTTP→HTTPS consiste à déplacer chaque page du site de l’adresse non sécurisée http:// vers sa version sécurisée https://. Vous installez un certificat, puis redirigez chaque ancienne URL vers sa nouvelle version afin de ne rien casser ni perdre de positions. Bien exécutée, l’opération est sûre ; les dégâts viennent d’une mise en œuvre négligée.

Ce que vous faites réellement

Le passage des URL HTTP à HTTPS modifie leurs URL canoniques. Il exige donc des redirections permanentes côté serveur et des signaux canoniques cohérents. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes La configuration HTTPS doit également présenter un certificat TLS valide et éviter les ressources mixtes. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Vos pages utilisent actuellement des adresses commençant par http://. Vous voulez les faire passer à https://, la version sécurisée et chiffrée qui affiche le cadenas sans déclencher l’avertissement « Non sécurisé » de Chrome. Le contenu, les noms d’hôte, les chemins et les chaînes de requête restent identiques, sans changer simultanément de CMS ni d’hébergeur. Seuls les premiers caractères de chaque URL changent.

Puisque les pages elles-mêmes ne bougent pas, il s’agit de la migration de site la plus douce, mais uniquement si tout le reste demeure inchangé. Regrouper des sous-domaines, restructurer les URL, réécrire le contenu ou changer de plateforme en même temps constitue une opération différente et plus risquée. Consultez la remarque ci-dessous. Même limitée au protocole, l’opération reste une migration et mérite de la rigueur.

La règle la plus importante

Redirigez chaque ancienne URL http:// vers son équivalent exact https:// avec une redirection 301. Une 301 est permanente : elle indique aux moteurs que la page réside désormais ici et qu’ils doivent tout transférer. Google a confirmé que les 301 ne font perdre aucune valeur de classement ; un basculement propre conserve donc le trafic.

Les problèmes commencent lorsque des redirections manquent ou que les pages chargent encore une image ou un script depuis l’ancienne adresse http://. Ce « contenu mixte » peut casser certaines parties de la page dans le navigateur. Le vrai travail n’est pas le basculement lui-même, mais l’élimination de toutes les références aux anciennes adresses.

La procédure en bref

1. Prenez un instantané du site actuel : liste complète des pages et positions, afin de pouvoir comparer après la migration.
2. Obtenez et installez un certificat. Un certificat gratuit comme Let’s Encrypt convient parfaitement au SEO.
3. Testez d’abord sur une copie si possible, pour éviter les surprises le jour du lancement.
4. Basculez : redirigez chaque ancienne URL vers sa version sécurisée, actualisez les liens internes et le sitemap, puis corrigez tout chargement restant en http://.
5. Vérifiez Search Console. La solution la plus simple est une propriété de domaine, qui couvre automatiquement toutes les variantes http / https / www sans vérification séparée.
6. Conservez les redirections au moins un an, idéalement indéfiniment, et surveillez le trafic pendant quelques semaines. Une légère fluctuation est normale.

Si vous renommez aussi les URL, fusionnez des sous-domaines, changez de CMS ou modifiez le contenu, arrêtez-vous : l’opération est plus vaste et plus risquée qu’un simple changement de protocole. Utilisez le guide complet de migration de site et intégrez-y le passage à HTTPS.

Pour la version technique complète — choix du certificat, correspondance de milliers d’URL, quatre propriétés Search Console, fenêtres de suivi et plan de retour — passez à l’onglet Avancé. Pour comprendre d’abord la place de HTTPS comme signal de classement, consultez le hub HTTPS.

En bref — Le passage de HTTP à HTTPS est une migration de site limitée au protocole : mêmes hôte, chemins, chaînes de requête, contenu et plateforme ; seul le schéma change. C’est la migration la moins risquée si ces conditions sont toutes respectées, mais elle exige la même discipline que tout déplacement de site. Enregistrez l’état du site HTTP, choisissez et installez un certificat TLS — un certificat DV gratuit obtient le même faible signal que n’importe quel certificat payant, car Google regarde le schéma et non l’émetteur — puis répétez l’opération en préproduction. Au basculement, appliquez une 301 côté serveur, URL par URL ; les 301 ne font pas perdre de PageRank. Rendez chaque page canonique vers sa propre URL HTTPS, actualisez tous les liens internes, sitemaps et hreflang, et éliminez le contenu mixte bloquable avant qu’il casse les scripts. Ajoutez une propriété de domaine dans Search Console, couvrant toutes les variantes de schéma et d’hôte, ou vérifiez séparément les propriétés HTTPS si vous souhaitez segmenter les données. Envoyez le sitemap HTTPS et n’utilisez pas l’outil Change of Address, réservé aux changements de domaine. Conservez les redirections au moins un an, comme minimum et non comme date d’expiration. Surveillez Crawl Stats et l’indexation : une baisse qui se résorbe accompagne la transition ; une baisse persistante signale une panne. Préparez un plan de retour, mais réparez d’abord HTTPS, car le cache, HSTS, les cookies et les Service Workers peuvent rendre un vrai retour à HTTP dangereux. Considérez le preload HSTS comme lent et risqué à annuler, sans le présenter comme littéralement irréversible.

Le hub HTTPS explique pourquoi utiliser HTTPS et esquisse la migration. Cet article en est le compagnon détaillé, consacré à ce qui fait réussir ou échouer l’exécution.

Commencer par dimensionner le risque : une migration limitée au protocole

Google traite les changements de protocole comme des déplacements de site avec changement d’URL. Des fluctuations temporaires de classement ou de rapports sont possibles, sans délai garanti. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes La sécurité du transport et le traitement par la recherche sont liés, mais distincts. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Les migrations de site présentent différents niveaux de danger. Changer de domaine, de structure d’URL ou de CMS/plateforme modifie l’identité des URL et comporte un risque réel. Un basculement limité au protocole n’est peu risqué que si tout le reste demeure stable. Vérifiez les points suivants avant de le traiter comme une redirection à règle unique.

• Noms d’hôte — aucune consolidation www / sans www, ni changement de sous-domaine pendant le basculement.
• Chemins et chaînes de requête — aucune restructuration d’URL, modification de slug ou suppression de paramètres dans la même version.
• Contenu — aucune réécriture, fusion ou suppression simultanée de pages.
• Plateforme et rendu — aucune migration parallèle de CMS, framework ou hébergement.

Lorsque ces quatre points sont respectés, le domaine, les chemins et le contenu restent identiques ; seul le schéma change. C’est pourquoi Google précise que vous “don’t need to use the Change of Address tool” (traduction) « n’avez pas besoin d’utiliser l’outil Change of Address » : aucune nouvelle adresse n’est à déclarer.

Conséquence essentielle : les URL correspondent une à une et de façon déterministe (http://example.com/x → https://example.com/x). Une seule règle serveur suffit généralement et la table de redirection se déduit d’elle-même. À l’inverse, une migration de domaine ou de plateforme exige de vérifier manuellement la destination de chaque ancienne URL. Ce cadre indique où investir l’effort — certificat, contenu mixte, Search Console — et où ne pas en perdre, comme le choix des destinations.

Si vous changez aussi de domaine ou de plateforme, arrêtez-vous : c’est une migration cumulée dont les risques se multiplient, et le protocole devient le moindre souci. Suivez le guide complet de migration de site et intégrez-y HTTPS.

Étape 1 — Établir une référence du site HTTP actif

Impossible d’évaluer une migration sans état « avant ». Tant que le site fonctionne en HTTP, enregistrez les éléments suivants.

• Un crawl complet du site actif : conservez chaque URL 200, mais surtout chaque redirection existante et sa destination. Après le lancement, recommencez et comparez ; toute URL auparavant en 200 devenue 404 est une régression.
• Un instantané des positions des mots-clés suivis, comme référence en cas de baisse.
• Un export Search Console : performances, requêtes, pages, clics, impressions, rapport d’indexation et Crawl Stats. Les données GSC ne passent pas de la propriété HTTP à la propriété HTTPS ; cet export est l’unique historique « avant ».
• Le profil de backlinks, afin d’identifier les URL ayant le plus d’autorité externe et nécessitant particulièrement une redirection propre en un seul saut.
• Le robots.txt et les directives noindex actuels, pour vérifier qu’ils ne bloquent pas silencieusement le site HTTPS.

Étape 2 — Choisir et installer le certificat TLS

La vérité SEO qui évite des dépenses inutiles : le signal de classement examine le schéma de l’URL, pas le certificat. Gary Illyes le décrit ainsi : “basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (traduction) « il regarde essentiellement les cinq premiers caractères de l’URL et, si c’est HTTPS, accorde un avantage minime ». Pour le SEO, un certificat gratuit de validation de domaine (DV) — Let’s Encrypt par défaut — procure donc exactement le même signal qu’un certificat OV ou EV payant. OV et EV apportent une identité organisationnelle, pas des positions. Ne promettez ni hausse de classement ni avantage propre à un type de certificat ou à un algorithme de clé : Google décrit lui-même un signal léger et minime, pas un levier justifiant un surcoût.

Les points techniques à réussir sont les suivants.

• Portée. Un certificat monodomaine couvre un nom d’hôte. Un wildcard (*.example.com) ne couvre qu’un niveau : il fonctionne pour foo.example.com, mais pas pour foo.bar.example.com. Les sous-domaines plus profonds exigent un certificat multidomaine (SAN) ou supplémentaire.
• Robustesse de la clé. Google recommande de “generate a 2,048-bit RSA key pair” (traduction) « générer une paire de clés RSA de 2 048 bits ». Une clé plus courte est vulnérable à la force brute ; une clé plus longue gaspille des ressources.
• Renouvellement automatique. L’expiration du certificat est l’incident post-migration le plus courant. Automatisez le renouvellement — Let’s Encrypt est conçu pour cela — et surveillez la date. Google préfère généralement HTTPS comme version canonique, mais cette préférence est conditionnelle : certificat invalide, dépendances non sécurisées, redirection HTTPS→HTTP ou canonical HTTP peuvent la ramener à l’URL HTTP, sans que HSTS puisse l’imposer. Evidence for this claim Google generally prefers HTTPS as the canonical version of a page, but that preference is conditional: an invalid certificate, insecure dependencies, an HTTPS-to-HTTP redirect, or an HTTP canonical tag can flip Google's choice back to the HTTP URL. HSTS is a browser-only mechanism and cannot override Google's canonical selection. Scope: Describes Google's conditional HTTPS canonical preference, not a guarantee that certificate problems are search-invisible. Confidence: high · Verified: 2026-07-17 Google: Consolidate duplicate URLs Un certificat expiré est donc à la fois une urgence UX et sécurité — l’avertissement plein écran détruit la confiance — et un risque pour la préférence canonique HTTPS s’il persiste. Corrigez-le rapidement. Pour les certificats expirés, autosignés, incompatibles avec le nom d’hôte ou à chaîne incomplète, consultez les certificats TLS/SSL.

Étape 3 — Répéter en préproduction

Effectuez d’abord tout le basculement sur une copie de préproduction. Vérifiez les points suivants.

• La règle fonctionne pour chaque forme de chemin, y compris les chaînes de requête, les variantes avec slash final et www / sans www.
• Aucune boucle de redirection : une règle renvoyant HTTPS vers HTTP peut enfermer tout le monde, vous compris.
• Les pages s’affichent correctement, sans contenu mixte bloquable dans la console DevTools.
• Les balises canonical produisent déjà https:// en préproduction.

Empêchez l’indexation de la préproduction par authentification ou avec un noindex que vous devez retirer. Laisser en production un noindex réservé à la migration est une erreur classique. Google le souligne : retirez les blocages noindex ou robots.txt qui ne servaient que pendant la migration.

Étape 4 — Gérer les redirections à grande échelle

Pour un changement de protocole, la correspondance est déterministe : utilisez une règle, et non une immense table.

• Côté serveur, une à une et permanentes (301). Chaque URL http:// mène au même chemin en https://. Configurez-le sur le serveur ou à l’edge (Apache, Nginx ou CDN), pas dans l’application ni en JavaScript client, afin que les robots voient une 301 serveur propre.
• Aucune chaîne. Si http://a redirigeait déjà vers http://b, ne créez pas http://a → http://b → https://b. Modifiez les règles d’origine afin que l’ancienne URL atteigne la destination HTTPS finale en un saut. Google suit jusqu’à dix sauts, mais “advise[s] redirecting to the final destination directly.” (traduction) « conseille de rediriger directement vers la destination finale ». Chaque saut supplémentaire gaspille du budget de crawl et du temps.
• Jamais de redirection massive vers l’accueil. Les URL non appariées doivent elles aussi atteindre leur propre équivalent HTTPS. Tout envoyer vers / est l’erreur qui fait réellement perdre des positions.
• Vérifiez par crawl. Après le lancement, recrawlez la liste HTTP et confirmez que chaque URL renvoie une seule 301 vers la bonne URL HTTPS, sans 302, chaîne ni 404.

Étape 5 — Réaligner les signaux canonical, sitemap et hreflang

Les redirections font l’essentiel, mais ne demandez pas à Google de compenser des signaux internes négligés. Actualisez-les directement.

• Canonical. Chaque page doit comporter un rel="canonical" autoréférent vers sa propre URL https://. Google indique : “Each new URL should have a self-referencing rel=“canonical” <link> tag.” (traduction) « Chaque nouvelle URL doit comporter une balise link canonical autoréférente. » Un canonical vers http:// combat la migration. Alignez tous les signaux sur HTTPS.
• Liens internes. Modifiez les modèles et contenus vers https://, ou utilisez des chemins relatifs. Ne laissez pas des milliers de liens http:// compter sur la redirection : chaque lien interne http:// ajoute un saut inutile aux utilisateurs et aux robots.
• Sitemaps XML. Régénérez-les avec les seules URL HTTPS canoniques et indexables, actualisez lastmod, puis envoyez le nouveau sitemap dans GSC.
• Hreflang. Chaque annotation doit viser la version HTTPS de chaque variante. Mélanger http et https crée un problème SEO international silencieux et difficile à diagnostiquer.
• Données structurées et URL Open Graph. Passez en HTTPS og:url, les références canoniques JSON-LD et toute URL absolue codée en dur.

Étape 6 — Éliminer le contenu mixte avant le lancement

Le contenu mixte désigne une page HTTPS chargeant une sous-ressource en HTTP. C’est la régression la plus fréquente au lancement. La terminologie actuelle — l’ancienne distinction « actif/passif » reste visible dans de vieux outils — classe les ressources selon la réaction du navigateur.

• Contenu mixte bloquable — scripts, feuilles de style, iframes, XMLHttpRequest / fetch, anciennement « actif ». Les navigateurs les bloquent complètement, car un script altéré peut réécrire toute la page. C’est ce qui casse réellement le site : une feuille de style ou un bundle JS bloqué rend la page inutilisable. Corrigez-le d’abord.
• Contenu mixte actualisable — images, audio et vidéo, anciennement « passif ». Les navigateurs modernes passent de plus en plus automatiquement ces requêtes à HTTPS et les bloquent si cela échoue, au lieu de simplement avertir. Le fait qu’une ressource « se charge encore » dépend du navigateur et ne constitue pas une garantie. Corrigez-la ensuite.
• Il existe des exceptions. Certains contextes de navigateur ou d’intégration, comme des ressources chargées par plugin ou d’anciens éléments <applet> / <embed>, ne suivent pas parfaitement ces règles. Testez dans les navigateurs réellement utilisés par votre public.

Détectez ces ressources en crawlant le site HTTPS avec Ahrefs Site Audit ou Screaming Frog, en observant la console Chrome DevTools ou en collectant des rapports CSP. Comme filet transitoire, l’en-tête Content-Security-Policy: upgrade-insecure-requests demande au navigateur de transformer les sous-ressources http:// en https:// avant la requête. Il ne prouve cependant pas que chaque endpoint HTTPS existe ni qu’il se comporte comme sa version HTTP, et ne remplace ni la correction des URL sources ni les tests réels. Un lien d’ancrage ordinaire vers une page HTTP n’est pas du contenu mixte : il ne fait que naviguer.

Étape 7 — Couvrir correctement le site dans Search Console

Cette étape est souvent sous-estimée, mais relève d’un choix et non d’une liste universelle. Les propriétés avec préfixe d’URL de Search Console suivent http://example.com, http://www.example.com, https://example.com et https://www.example.com comme quatre propriétés séparées ne partageant pas leurs données. Vous n’êtes pas obligé de vérifier les quatre.

• Une propriété de domaine agrège automatiquement tous les protocoles et sous-domaines. Ajoutez-en une pour couvrir le basculement sans autre manipulation. C’est le choix le plus simple pour la plupart des sites.
• Les propriétés avec préfixe d’URL segmentent les données par protocole et hôte exacts. Conservez-les ou ajoutez-les uniquement si cette segmentation est souhaitée, par exemple pour comparer le trafic HTTP résiduel au site HTTPS actif. C’est un choix de rapport, pas une obligation.

Dans les deux cas, procédez comme suit.

• Envoyez le nouveau sitemap HTTPS dans la propriété utilisée, domaine ou préfixe HTTPS.
• N’utilisez pas l’outil Change of Address. Google est explicite : “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (traduction) « Si vous passez votre site de HTTP à HTTPS, vous n’avez pas besoin d’utiliser l’outil Change of Address. » Il est réservé aux changements de domaine.
• Conservez les propriétés HTTP déjà vérifiées. Elles montrent le traitement des redirections et la disparition des anciennes URL de l’index : c’est un signal de suivi utile.
• Réexaminez le fichier de désaveu s’il existe : ses entrées référencent des URL HTTP et il est propre à chaque propriété.

Pour diagnostiquer des URL individuelles, le rapport HTTPS de GSC signale les raisons liées au certificat, aux redirections, au canonical, aux robots et au sitemap. Utilisez-le comme outil diagnostique échantillonné, pas comme inventaire complet : il est échantillonné et ignore les paramètres de requête lors de la correspondance. Consultez le guide du rapport HTTPS de GSC.

Étape 8 — Fenêtres de suivi : transition ou panne

Attendez-vous à une “temporary fluctuation in site ranking during the move” (traduction) « fluctuation temporaire du classement pendant la migration ». C’est normal et ne justifie pas une annulation précipitée. Il faut distinguer une baisse transitoire d’un dysfonctionnement.

• Une baisse qui se résorbe en quelques jours ou semaines correspond au remplacement des URL HTTP par leurs versions HTTPS dans l’index. Selon Google, la majorité des pages d’un site petit ou moyen migre en quelques semaines ; un grand site demande davantage de temps.
• Une baisse persistante signifie qu’un élément est cassé : blocage robots.txt, noindex de préproduction, canonical vers http://, liens internes HTTP en masse ou chaînes de redirection.

Aucun délai de récupération n’est fixe. Suivez séparément les indicateurs suivants plutôt que d’attendre un unique chiffre de fin.

• TLS et comportement du navigateur — validité et chaîne du certificat, plus console DevTools de pages représentatives, sans erreur de contenu mixte ni avertissement. Les métriques de recherche ne le révèlent pas.
• Crawl Stats de GSC — Googlebot doit récupérer les URL HTTPS avec une répartition saine des réponses, principalement 200 et les 301 des anciennes URL. Une hausse de 5xx indique que le serveur supporte mal la charge.
• Rapport d’indexation — les URL HTTPS passent à « Indexée » et les URL HTTP à « Page avec redirection ». Ce croisement est attendu.
• Inspection d’URL — sur quelques pages essentielles, confirmez un canonical HTTPS et un rendu sans contenu mixte.
• Journaux serveur — preuve des URL réellement visitées par les robots et des statuts reçus. Des accès HTTP brefs sont normaux ; des chaînes ou boucles ne le sont pas.
• Analyses et résultats commerciaux — le trafic « direct » peut augmenter lorsque les données de référent HTTPS→HTTP disparaissent. Faites pointer vos liens sortants vers HTTPS et suivez conversions et chiffre d’affaires indépendamment : le retour des positions ne garantit pas celui des résultats.

Surveillez activement pendant 2 à 4 semaines à titre indicatif, puis plus légèrement jusqu’au remplacement complet dans l’index. Les grands sites ou ceux peu crawlés prennent plus longtemps, sans date de fin garantie.

Étape 9 — Conserver les redirections et ajouter HSTS avec prudence

• Conservez les 301 sur le long terme. Google recommande de les garder “as long as possible, generally at least 1 year” (traduction) « aussi longtemps que possible, généralement au moins un an » : il s’agit d’un minimum recommandé par Google, et non d’une date d’expiration après laquelle leur suppression devient sans risque. En pratique, conservez-les pendant toute la vie du site : les liens externes et favoris vers les anciennes URL http:// ne disparaissent jamais totalement.
• HSTS est une couche supplémentaire, pas un remplacement. L’en-tête Strict-Transport-Security ordonne aux navigateurs de toujours utiliser HTTPS pour votre domaine, ce qui résout le « problème de la première requête » : celle d’un nouveau visiteur part encore en HTTP avant l’exécution de la 301, créant la fenêtre recherchée par une attaque de suppression SSL. Mais lorsqu’un navigateur respecte HSTS, il effectue une redirection interne 307 propre au navigateur, invisible aux robots d’exploration. Les moteurs ont toujours besoin de votre 301 côté serveur. Les deux sont nécessaires.
• Traitez le preload HSTS comme lent et risqué à annuler, pas comme une porte littéralement sans retour. L’inscription à la liste de préchargement intégrée aux navigateurs exige un max-age d’au moins un an, includeSubDomains — la règle s’applique alors à tous les sous-domaines, et tout sous-domaine qui n’est pas totalement prêt pour HTTPS cesse de fonctionner — ainsi que preload. Elle ferme la brèche même pour les nouveaux visiteurs. La suppression est réellement possible via hstspreload.org, mais elle est lente : la modification doit suivre les cycles de publication des navigateurs, et ceux qui utilisent encore l’ancienne liste continuent d’imposer HTTPS jusqu’à leur mise à jour. C’est un risque opérationnel, pas une irréversibilité absolue. L’avertissement de Google est sans détour : “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (traduction) « N’activez pas HSTS tant que vous n’êtes pas certain que l’exploitation de votre site est assez robuste pour ne jamais déployer HTTPS avec des erreurs de validation de certificat. »

Étape 10 — Prévoir un plan de retour (et en connaître les limites)

Même une migration peu risquée mérite une porte de sortie, mais lorsqu’un problème survient, la réaction par défaut consiste à réparer HTTPS, pas à revenir à HTTP. Un « retour » n’est qu’un filet de sécurité limité, jamais une inversion garantie : les 301 mises en cache par les navigateurs et CDN, les cookies marqués Secure, les Service Workers enregistrés pour l’origine HTTPS et la politique HSTS/preload peuvent rendre le rétablissement de HTTP dangereux ou simplement inefficace pour une partie des visiteurs, même après un lancement bien exécuté.

Avant le basculement :

• Programmez le lancement pendant une période de faible trafic : Google conseille explicitement de “time your move to coincide with lower traffic, if possible.” (traduction) « faire coïncider le déplacement avec une période de trafic plus faible, si possible ». Une période calme expose moins d’utilisateurs aux incidents du jour J et vous laisse le temps de réagir.
• Maintenez le service HTTP derrière la redirection. Ne supprimez pas l’écouteur HTTP : il doit rester actif pour que les 301 puissent partir de là et qu’une annulation de la règle de redirection reste possible si le site HTTPS est gravement défaillant.
• N’activez pas HSTS le premier jour. HSTS, et plus encore le preload, rend un retour à HTTP beaucoup moins viable. Dès qu’un navigateur a mis la politique en cache, il refuse de communiquer en HTTP avec votre domaine, indépendamment de la configuration du serveur. N’ajoutez HSTS qu’après une période de stabilité du site HTTPS.
• Définissez à l’avance vos critères d’arrêt, par exemple des 5xx sur tout le site, une boucle de redirection ou un blocage massif dû au contenu mixte. S’ils sont atteints, procédez dans cet ordre : (1) pouvez-vous corriger directement le défaut HTTPS — mauvais certificat, ressource absente, canonical incorrect ? Généralement oui, et c’est plus rapide et plus sûr qu’un retour. (2) Seulement si HTTPS est inutilisable, annulez temporairement la règle de redirection, en sachant que le résultat sera incomplet : les redirections, cookies et Service Workers déjà mis en cache ne s’effacent pas parce que le serveur a changé de configuration.

Diagnostiquez calmement au lieu de déboguer en direct, et considérez le « retour à HTTP » comme une option d’urgence que vous espérez ne jamais employer, pas comme une annulation courante et propre.

Résumé par IA

Version condensée de l’onglet Avancé :

• C’est une migration limitée au protocole, sous conditions. Même hôte, chemins, chaînes de requête, contenu et plateforme ; seul le schéma change. C’est la migration la moins risquée si ces cinq éléments restent stables : les URL correspondent une à une et une règle unique suffit généralement. Pas d’outil Change of Address, réservé aux changements de domaine. Si un autre élément change aussi, traitez l’opération comme une migration cumulée.
• Établissez d’abord une référence : crawl complet — chaque 200 et redirection existante —, instantané des positions, export GSC — les données ne passent pas à la propriété HTTPS —, profil de backlinks et état actuel de robots/noindex.
• Certificat : le signal de classement dépend du schéma. Un certificat DV gratuit, comme Let’s Encrypt, obtient le même signal léger qu’un certificat payant ; OV/EV achète une identité, pas des positions. Ne promettez aucun gain lié au type de certificat ou à l’algorithme de clé. Clé de 2 048 bits, portée wildcard limitée à un niveau et renouvellement automatisé. Google préfère généralement HTTPS comme canonical, mais sous conditions : mauvais certificat, dépendances non sécurisées, redirection HTTPS→HTTP ou canonical HTTP peuvent inverser cette préférence, sans que HSTS puisse l’empêcher.
• Répétez en préproduction : toutes les formes de chemin redirigent, aucune boucle ni contenu mixte bloquable, canonical déjà en HTTPS ; retirez tout noindex propre à la migration avant la production.
• Basculement : une 301 côté serveur et une à une pour chaque URL — sans perte de PageRank —, aucune chaîne, arrivée directe sur la destination HTTPS finale, jamais de redirection massive vers l’accueil ; puis actualisez canonical autoréférents, liens internes, sitemaps, hreflang et URL OG/JSON-LD.
• Contenu mixte : les termes actuels sont bloquable — scripts, styles, iframes, XHR, bloqués entièrement par les navigateurs et à corriger en premier — et actualisable — images, audio, vidéo, convertis automatiquement en HTTPS ou bloqués en cas d’échec. L’ancienne distinction actif/passif est historique. La CSP upgrade-insecure-requests est un filet transitoire, pas la preuve que l’endpoint HTTPS existe. Les liens d’ancrage vers des pages HTTP ne sont pas du contenu mixte.
• Search Console relève d’un choix, pas d’un nombre universel. Ajoutez une propriété de domaine, qui agrège automatiquement toutes les variantes de schéma et d’hôte. Les propriétés avec préfixe d’URL (http, https, http-www, https-www) ne servent qu’à une segmentation facultative. Envoyez le sitemap HTTPS et examinez le fichier de désaveu. Le rapport HTTPS de GSC est un diagnostic échantillonné qui ignore les paramètres de requête, pas un inventaire complet.
• Surveillez chaque système séparément, sans fenêtre fixe : comportement TLS/navigateur, Crawl Stats, indexation des pages, inspection d’URL, journaux et résultats analytiques/métier racontent chacun une partie différente. Une baisse qui se résorbe en quelques jours ou semaines correspond à la transition ; une baisse qui persiste révèle une panne — blocage oublié, canonical perdu, liens internes HTTP ou chaînes.
• Conservez les redirections au moins un an comme minimum, pas comme date d’expiration ; la plupart des sites les gardent indéfiniment. HSTS provoque une 307 interne au navigateur que les robots ne voient jamais : il complète la 301, sans la remplacer. Le preload est lent et risqué à annuler ; la suppression via hstspreload.org est possible, mais il ne faut pas s’y précipiter.
• Plan de retour, avec limites : réparez d’abord HTTPS, généralement plus vite et avec moins de risques. Lancez à faible trafic, gardez HTTP actif, n’activez pas HSTS le premier jour et définissez des critères d’arrêt ; malgré cela, redirections, cookies et Service Workers en cache peuvent rendre un véritable retour à HTTP incomplet.

Documentation officielle

Documentation de première main pour planifier et exécuter la migration.

Google

• Déplacements de sites avec changements d’URL : procédure de migration, avec 301 côté serveur, redirections en un saut, canonical autoréférents, « conserver les redirections au moins un an », « pas d’outil Change of Address pour HTTP→HTTPS » et « faire coïncider le déplacement avec une période de trafic plus faible ».
• Regrouper les URL en double : préférence conditionnelle de Google pour HTTPS comme canonical. Un mauvais certificat, des dépendances non sécurisées, une redirection HTTPS→HTTP ou une balise canonical HTTP peuvent inverser cette préférence.
• Activer HTTPS sur vos serveurs (web.dev) : certificats, clés de 2 048 bits, 301 vers le canonical HTTPS, HSTS et cookies.
• Pourquoi HTTPS est important (web.dev) : arguments de sécurité et de fonctionnalités navigateur en faveur du basculement.
• Corriger le contenu mixte (web.dev) : contenu mixte bloquable ou actualisable — facultativement bloquable —, termes actuels pour l’ancienne distinction actif/passif, et upgrade-insecure-requests.
• HTTPS comme signal de classement (2014) : billet d’origine sur le « signal très léger » et précisions d’implémentation de Google — type de certificat, URL relatives, absence de blocage HTTPS dans robots.txt.
• Comprendre l’expérience sur la page : place de HTTPS et du rapport HTTPS de GSC.

Certificats et configuration

• Let’s Encrypt : certificats DV gratuits et automatisés, avec renouvellement intégré.
• Test de serveur SSL Labs : évaluez votre configuration TLS après l’installation.
• hstspreload.org : critères du preload HSTS et avertissements sur sa suppression.

Chrome / Chromium

• Un Web sécurisé est là pour durer (2018) : Chrome 68 marque tous les sites HTTP comme « non sécurisés », échéance qui a poussé la plupart des sites à migrer.

Citations des sources

Déclarations officielles qui déterminent la conduite d’une migration. Chaque lien profond mène directement au passage cité dans la page source.

Google — redirections et PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” (traduction) « Les redirections 301 et autres redirections permanentes n’entraînent aucune perte de PageRank. » — Google Search Central. Accéder à la citation
• “Keep the redirects for as long as possible, generally at least 1 year.” (traduction) « Conservez les redirections aussi longtemps que possible, généralement au moins un an. » — Google Search Central. Accéder à la citation
• “Each new URL should have a self-referencing rel=“canonical” <link> tag.” (traduction) « Chaque nouvelle URL doit comporter une balise link canonical autoréférente. » — Google Search Central. Accéder à la citation

Google — particularités du passage HTTP→HTTPS

• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (traduction) « Si vous faites passer votre site de HTTP à HTTPS, vous n’avez pas besoin d’utiliser l’outil Change of Address. » — Google Search Central. Accéder à la citation
• “Expect temporary fluctuation in site ranking during the move.” (traduction) « Attendez-vous à une fluctuation temporaire du classement du site pendant le déplacement. » — Google Search Central. Accéder à la citation

Google — HSTS et certificats (web.dev)

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (traduction) « Utilisez HTTP Strict Transport Security (HSTS) pour éviter le coût de la redirection 301. » — web.dev (Google). Accéder à la citation
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (traduction) « N’activez pas HSTS tant que vous n’êtes pas certain que l’exploitation de votre site est assez robuste pour ne jamais déployer HTTPS avec des erreurs de validation de certificat. » — web.dev (Google). Accéder à la citation

Gary Illyes — un signal fondé sur le schéma

• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (traduction) « Il regarde essentiellement les cinq premiers caractères devant l’URL et, si c’est HTTPS, elle bénéficie d’un avantage minime. » — Gary Illyes, Google, 2016 (via Search Engine Land). Lire l’article

Quelle voie suivre ?

« Est-ce que je change autre chose que le schéma ? »

• Seulement http:// → https:// — mêmes hôte, chemins, chaînes de requête, contenu et plateforme → suivez la procédure de cet article, limitée au protocole. Une règle de redirection, aucun outil Change of Address.
• Changement également de domaine, noms d’hôte/sous-domaines, structure d’URL, contenu ou CMS/plateforme → arrêtez-vous. Il s’agit d’une migration cumulée plus risquée : suivez la procédure complète de migration de site et intégrez-y HTTPS.

« De quel certificat ai-je besoin ? »

• Seuls le schéma HTTPS et le signal de classement vous importent → un certificat DV gratuit, par exemple Let’s Encrypt. Même signal léger qu’un certificat payant : ne payez pas davantage dans l’espoir d’améliorer vos positions.
• Vous souhaitez afficher le nom de l’organisation ou travaillez dans un secteur réglementé → OV/EV, en sachant qu’il achète une identité, pas du SEO.
• Plusieurs sous-domaines → un wildcard ne couvre qu’un niveau ; les sous-domaines profonds exigent un certificat SAN/multidomaine.

« Une baisse de classement apparaît après le lancement : paniquer ou attendre ? »

• Elle survient dans les deux premières semaines et se résorbe progressivement → attendez. L’index remplace HTTP par HTTPS, ce qui est normal.
• Elle ne se résorbe pas après plusieurs semaines → quelque chose est cassé. Vérifiez dans l’ordre : blocage oublié dans robots.txt → noindex persistant → canonical encore en http:// → liens internes encore en http:// → chaînes de redirection → contenu mixte bloquant les pages.

« Dois-je activer HSTS maintenant ? »

• C’est le jour du lancement ou la migration n’a pas encore prouvé sa stabilité → non. HSTS rend un retour à HTTP bien moins viable.
• HTTPS fonctionne sans incident depuis un certain temps et le renouvellement est automatisé → ajoutez l’en-tête.
• Vous envisagez la liste de preload ? → uniquement si vous êtes certain de ne pas devoir revenir en arrière ; la suppression est possible, mais lente et risquée sur le plan opérationnel, sans être littéralement impossible.

« Dois-je valider les quatre propriétés Search Console ? »

• Vous voulez seulement assurer la continuité, sans données segmentées → non. Ajoutez une propriété de domaine, qui couvre automatiquement toutes les variantes de schéma et d’hôte.
• Vous voulez comparer le trafic HTTP résiduel au site HTTPS actif → conservez ou ajoutez les propriétés avec préfixe d’URL correspondantes ; cette segmentation est facultative.

« Ai-je besoin de l’outil Change of Address ? »

• HTTP → HTTPS, même domaine → non. Google le dit explicitement.
• Changement du domaine lui-même → oui, mais il s’agit d’une autre migration.

« Une ancienne URL n’a pas d’équivalent HTTPS évident : vers où la rediriger ? »

• Lors d’un changement de protocole, il existe toujours un équivalent → même chemin en https://, en un saut.
• La page a réellement disparu → c’est une décision de contenu — 404/410 ou redirection vers la page pertinente la plus proche —, pas une raison de tout envoyer vers l’accueil.

Checklist de migration HTTP → HTTPS

Avant — référence et préparation

• Crawl complet du site HTTP actif enregistré — chaque 200, chaque redirection existante et sa destination.
• Instantané des positions, export GSC — performances, indexation des pages, Crawl Stats — et profil de backlinks archivés.
• Directives robots.txt et noindex actuelles consignées.
• Certificat TLS obtenu — un DV gratuit suffit —, clé de 2 048 bits et renouvellement automatique configuré.
• Portée du wildcard vérifiée par rapport à la profondeur des sous-domaines.
• Basculement complet répété en préproduction : toutes les formes de chemin redirigent, aucune boucle ni contenu mixte bloquable, canonical en HTTPS.
• Lancement programmé pendant une période de faible trafic.
• Confirmation d’une migration réellement limitée au protocole : hôte, chemins, chaînes de requête, contenu et plateforme sont inchangés.

Le basculement

• Chaque URL HTTP est redirigée par une 301, côté serveur et une à une, vers son équivalent HTTPS.
• Aucune chaîne : les anciennes URL atteignent la destination HTTPS finale en un saut.
• Aucune redirection massive vers l’accueil pour les URL non appariées.
• Chaque page comporte un rel="canonical" autoréférent vers son URL HTTPS.
• Liens internes, sitemaps XML et hreflang actualisés vers HTTPS, sans dépendre des redirections.
• og:url, JSON-LD et URL absolues codées en dur actualisés vers HTTPS.
• Contenu mixte bloquable — scripts, styles, iframes, XHR — corrigé ; ces ressources sont entièrement bloquées.
• Contenu mixte actualisable — images, médias — corrigé, sans dépendre de l’actualisation automatique du navigateur ; CSP upgrade-insecure-requests employée comme filet transitoire, pas comme correction.
• Tout blocage noindex ou robots.txt propre à la migration supprimé.

Search Console et après

• Propriété de domaine ajoutée dans GSC — choix recommandé —, ou propriétés HTTPS avec préfixe d’URL validées séparément si des données segmentées sont réellement souhaitées.
• Nouveau sitemap HTTPS envoyé ; anciennes propriétés HTTP conservées et validées pour le suivi, si elles existaient.
• Outil Change of Address non utilisé — réservé aux changements de domaine.
• Fichier de désaveu éventuel examiné pour les URL HTTP.
• Redirections conservées au moins un an comme minimum, pas comme date de retrait — idéalement pendant toute la vie du site.
• Écouteur HTTP maintenu sous la redirection — filet de sécurité limité, pas annulation garantie.
• HSTS non activé le jour du lancement ; ajout seulement après stabilisation de HTTPS.
• Comportement TLS/navigateur, Crawl Stats, indexation des pages, inspection d’URL, journaux et résultats analytiques/métier surveillés pendant 2 à 4 semaines — sans date de fin fixe ; une baisse qui ne se résorbe pas révèle une panne.

Procédure opérationnelle standard : exécuter la migration

Une procédure reproductible. Attribuez un responsable à chaque phase et ne sautez pas la répétition en préproduction.

Avant le jour J — une semaine avant : référence et construction

1. Crawlez le site HTTP actif ; exportez la liste complète des URL avec leurs codes d’état et redirections existantes.
2. Exportez GSC — performances, indexation des pages, Crawl Stats — et enregistrez les positions et backlinks.
3. Obtenez et installez le certificat DV en préproduction ; validez la chaîne avec SSL Labs.
4. Construisez la règle 301 unique côté serveur — http → https, chemin et requête préservés.
5. Actualisez les modèles afin que canonical, liens internes, sitemaps, hreflang et OG/JSON-LD produisent HTTPS.
6. Recherchez le contenu mixte en préproduction ; corrigez tout le contenu bloquable, puis actualisable.

Jour J — lancement pendant une période de faible trafic 7. Déployez le certificat en production et confirmez que HTTPS présente une chaîne valide. 8. Activez la règle 301. Vérifiez immédiatement quelques URL : chacune doit renvoyer une seule 301 vers la bonne URL HTTPS. 9. Confirmez que l’accueil et les principaux modèles s’affichent sans erreur de contenu mixte dans la console. 10. Retirez tout blocage noindex/robots.txt propre à la migration.

Après le lancement — première heure au premier jour 11. Recrawlez l’ancienne liste d’URL HTTP ; confirmez des 301 en un saut, sans chaîne, 404 ni boucle. 12. Ajoutez une propriété de domaine dans GSC — choix recommandé —, ou validez séparément les propriétés HTTPS avec préfixe d’URL uniquement si vous souhaitez segmenter les données ; envoyez le sitemap HTTPS. 13. Surveillez les journaux serveur et les taux d’erreur pour détecter les pics de 5xx sous la nouvelle charge.

Après le lancement — 2 à 4 premières semaines 14. Surveillez quotidiennement Crawl Stats et l’indexation des pages dans GSC : URL HTTPS → « Indexed », URL HTTP → « Page with redirect ». 15. Vérifiez par sondage les pages clés dans l’inspection d’URL : canonical déclaré = HTTPS, rendu sans erreur. 16. Comparez avec votre référence ; distinguez une baisse en voie de résorption — transition — d’une baisse persistante — panne — et corrigez cette dernière. 17. Examinez le fichier de désaveu pour les URL HTTP.

Après le lancement — de la stabilité au suivi continu 18. Une fois HTTPS stable et le renouvellement automatisé, ajoutez l’en-tête HSTS. 19. N’envisagez le preload que si vous êtes certain de ne pas devoir revenir en arrière ; sa suppression est possible, mais lente et risquée sur le plan opérationnel. 20. Conservez les 301 et l’écouteur HTTP au moins un an — un minimum, pas une date de retrait —, idéalement sans limite. En cas d’incident, réparez HTTPS avant d’envisager un retour à HTTP ; cache, cookies et Service Workers peuvent rendre ce retour incomplet.

Procédures par situation

Petit site — quelques centaines d’URL — sur hébergement mutualisé Obtenez un certificat Let’s Encrypt gratuit — la plupart des hébergeurs l’activent en un clic —, ajoutez la règle 301 unique, actualisez les liens internes et le sitemap, recherchez une fois le contenu mixte dans DevTools et validez la propriété de domaine HTTPS dans GSC. L’opération tient en un après-midi. Le principal risque est une ressource http:// codée en dur et oubliée : recherchez-la.

Grand site — plus de cent mille URL — derrière un CDN Placez la 301 à l’edge — CDN ou proxy inverse — afin d’appliquer une règle unique à grande échelle, plutôt qu’une logique propre à chaque application. Établissez une référence rigoureuse : le crawl « avant » et l’export GSC sont votre seul filet. Le croisement des index sera plus long que sur un petit site ; surveillez Crawl Stats pour les 5xx sous charge et les chaînes créées par l’empilement d’anciennes redirections HTTP. Recrawlez par lots pour confirmer les 301 en un saut.

Site doté d’une couche de redirection existante — migrations passées, URL personnalisées Le piège est l’empilement : http://old → http://new → https://new. Réécrivez les règles à la source afin que chaque ancienne URL atteigne la destination HTTPS finale en un saut. Recherchez explicitement les chaînes après le lancement : c’est là que l’autorité se perd.

Site international avec hreflang Chaque annotation hreflang et chaque lien de retour doit référencer les variantes HTTPS. Un cluster hreflang à moitié migré — certains http, d’autres https — casse silencieusement le ciblage. Régénérez toutes les annotations depuis une source de vérité unique en HTTPS.

Vous avez déjà basculé, les positions ont chuté et ne se redressent pas Procédez dans l’ordre : (1) un élément est-il bloqué dans robots.txt ou porte-t-il encore un noindex ? (2) Les canonical visent-ils https:// ? (3) Les liens internes sont-ils en HTTP ? (4) Existe-t-il des chaînes ou boucles ? (5) Du contenu mixte bloquable casse-t-il les pages, ou un mauvais certificat ramène-t-il la préférence canonical de Google vers HTTP ? La plupart des récits où « HTTPS a détruit mes positions » relèvent d’un de ces cinq cas, pas du changement de protocole. Corrigez directement le problème HTTPS ; ne revenez pas d’abord à HTTP.

Ce qu’il ne faut pas faire

• Tout rediriger vers l’accueil. C’est l’erreur de migration la plus dommageable. Chaque ancienne URL doit atteindre son propre équivalent HTTPS. Google déconseille explicitement d’envoyer de nombreuses anciennes URL vers une destination unique et non pertinente comme l’accueil.
• Utiliser une 302 au lieu d’une 301. Une 302 signifie « temporaire » et indique que le déplacement n’est pas permanent. Utilisez une 301 afin que les moteurs transfèrent entièrement l’URL et son autorité.
• Créer des chaînes. http://a → http://b → https://b gaspille budget de crawl et temps. Redirigez directement vers la destination HTTPS finale.
• Laisser les liens internes en http://. Compter sur la 301 pour les « nettoyer » impose une redirection à chaque clic et crawl internes. Corrigez les liens.
• Conserver des canonical vers http://. Un canonical autoréférent pointant vers l’ancien schéma combat la migration et perturbe la sélection canonique.
• Ignorer le contenu mixte bloquable jusqu’après le lancement. Une feuille de style ou un bundle JS bloqué peut réellement casser les pages dès le premier jour. Corrigez ce contenu avant le basculement.
• Utiliser l’outil Change of Address pour un changement de protocole. Il sert aux changements de domaine. Google confirme qu’il est inutile ici.
• Supposer que les quatre propriétés GSC doivent être validées. Ce n’est pas le cas : une seule propriété de domaine agrège toutes les variantes de schéma et d’hôte. La vraie erreur consiste à ne valider que l’ancienne propriété HTTP sans aucune propriété couvrant HTTPS.
• Activer HSTS ou le preload le jour du lancement. Cela rend un retour à HTTP beaucoup moins viable si le site HTTPS est défaillant. Attendez que HTTPS ait prouvé sa stabilité.
• Laisser un noindex propre à la migration en production. Un blocage noindex ou robots.txt ajouté pour protéger la préproduction, puis oublié, désindexe silencieusement le nouveau site.
• Supprimer immédiatement l’écouteur HTTP. Maintenez-le pour que les 301 disposent d’un point de départ et qu’une annulation de la règle reste au moins possible.
• Considérer le maintien de HTTP comme un retour garanti. Redirections, cookies et Service Workers en cache peuvent rendre le rétablissement de HTTP dangereux ou incomplet : réparez d’abord HTTPS et ne revenez en arrière qu’en dernier recours.

Migration HTTP → HTTPS — aide-mémoire

Redirections et correspondance

Certificats

Signaux à réorienter

Contenu mixte et HSTS

Propriétés GSC Une propriété de domaine agrège automatiquement toutes les variantes de schéma et d’hôte ; c’est le choix recommandé. Les propriétés avec préfixe d’URL (http://example.com · http://www.example.com · https://example.com · https://www.example.com) n’offrent qu’une segmentation facultative, et ne constituent pas une exigence universelle.

Forcer la 301 — côté serveur

Effectuez la redirection de protocole dans la configuration du serveur ou de l’edge, pas dans le code de l’application. Testez d’abord en préproduction : une règle incorrecte peut créer une boucle qui bloque tout le monde.

Apache (.htaccess)

# 301 every HTTP request to the same path on HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Nginx

# Dedicated port-80 server block that 301s to HTTPS, preserving host + path
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Vérifier qu’une URL renvoie une 301 propre en un saut

Confirmez que chaque ancienne URL renvoie directement une 301 vers son équivalent HTTPS, sans 302 ni chaîne.

macOS / Linux

# Show every hop and status code for one URL
curl -sIL http://example.com/some/page \
  | grep -Ei '^(HTTP/|location):'
# Want a single 301 -> https://example.com/some/page -> 200, no extra hops

Windows (PowerShell)

# Follow redirects and print each status + Location
$r = Invoke-WebRequest -Uri "http://example.com/some/page" -MaximumRedirection 10
$r.BaseResponse.ResponseUri.AbsoluteUri   # final URL should be https://

Rechercher le contenu mixte restant dans le HTML

Recherchez dans une page rendue les sous-ressources non sécurisées — scripts, styles, images et iframes.

macOS / Linux

curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Console Chrome DevTools — signaler les sous-ressources non sécurisées de la page active

Collez le code dans la console d’une page HTTPS pour répertorier chaque élément qui pointe encore vers http:// — les liens d’ancrage ordinaires, qui ne sont pas du contenu mixte, sont ignorés :

[...document.querySelectorAll('[src],link[href],iframe[src]')]
  .map(el => el.src || el.href)
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('Insecure sub-resource:', u));

Vérifier par lots une liste d’URL après le lancement — 301 en un saut

Fournissez la liste d’URL HTTP enregistrée et signalez tout résultat qui n’est pas une 301 propre en un saut.

macOS / Linux

# urls.txt = one http:// URL per line (from your pre-migration crawl)
while read -r u; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -I "$u")
  loc=$(curl -sI "$u" | awk -F': ' 'tolower($1)=="location"{print $2}' | tr -d '\r')
  echo "$code  $u  ->  $loc"
done < urls.txt

Pour balayer tout un site, un crawler comme Ahrefs Site Audit ou Screaming Frog est plus rapide qu’un script URL par URL ; ces extraits restent pratiques pour des contrôles ponctuels et la CI.

Auditer la correspondance de migration avant le lancement

Act as a technical SEO reviewing an HTTP-to-HTTPS migration. I will provide a crawl
of live HTTP URLs, the current redirect export, the proposed HTTPS URL list, and a
staging crawl.

For every old URL, determine whether it maps one-to-one to the same host, path, and
query on HTTPS. Flag redirect chains, loops, 302s, homepage dumps, missing targets,
HTTP canonicals, HTTP internal links, HTTP sitemap or hreflang entries, blockable
mixed content, and staging noindex/robots blocks.

Return a table with old URL, observed status, first target, final target, expected
target, issue, severity, owner, and retest. Separate launch blockers from normal
post-launch index settling. Do not recommend the Change of Address tool for this
protocol-only move.

Diagnostiquer une baisse après le lancement

Compare the pre-launch crawl and Search Console exports with the post-launch crawl,
logs, Page Indexing, Crawl Stats, and URL Inspection samples. Test for blocked
crawling, surviving noindex, HTTP canonicals or internal links, redirect chains or
loops, 5xx responses, and mixed-content rendering failures. Explain which evidence
shows normal HTTP-to-HTTPS canonical crossover and which evidence shows a broken
migration. Give the smallest reversible fix and a validation query for each finding.

Cadre d’une migration limitée au protocole

Considérez le passage HTTP→HTTPS comme quatre systèmes liés, et non comme la simple installation d’un certificat :

1. Transport : HTTPS présente un certificat valide et une chaîne complète sur chaque nom d’hôte requis.
2. Routage : chaque URL HTTP renvoie une redirection permanente côté serveur vers son équivalent HTTPS exact. La 301 sert de pont et préserve le sens de l’URL ; Google affirme que les redirections permanentes ne font perdre aucun PageRank.
3. Signaux : canonical, liens internes, sitemaps, hreflang et références d’URL structurées s’accordent tous sur HTTPS, au lieu de forcer les robots à redécouvrir le déplacement par des redirections.
4. Observation : état de référence enregistré, crawl après lancement, journaux et Search Console distinguent le croisement attendu des index d’une panne technique.

Une migration limitée au protocole reste peu risquée uniquement si hôte, chemin, comportement des requêtes, contenu et rendu demeurent équivalents. S’ils changent en même temps, séparez les travaux en migrations distinctes afin que chaque panne ait une cause identifiable.

Outils de vérification de la migration

• Vérificateur de redirections : inspectez le parcours complet d’une URL HTTP et confirmez qu’elle atteint l’URL HTTPS correspondante en un saut.
• Vérificateur groupé de codes d’état HTTP : retestez l’ensemble d’URL enregistré avant le lancement pour repérer redirections permanentes, destinations cassées, boucles et états inattendus.
• Vérificateur de canonicalisation : vérifiez que la page HTTPS finale déclare le canonical HTTPS prévu au lieu de renvoyer vers HTTP.

Exportez les résultats avant et après le lancement. Le résultat d’un outil est surtout utile lorsqu’il peut être comparé à la correspondance d’URL approuvée, plutôt que jugé isolément.

Tests de mise en production de la migration

Test 1 : répétition en préproduction

• Objectif : prouver que contenu et signaux sont prêts pour HTTPS avant que les redirections n’affectent utilisateurs ou robots.
• Méthode : crawler des chemins et modèles représentatifs en préproduction ; inspecter canonical, liens internes, hreflang, sitemaps, directives robots et URL des ressources rendues.
• Résultat attendu : pages au rendu équivalent, signaux HTTPS, aucun contenu mixte bloquable ni blocage de crawl ou d’index propre à la migration.
• Critère d’échec : signaux HTTP, ressources bloquées, erreurs de certificat ou restriction noindex/robots persistante.
• Action suivante : suspendre le lancement et corriger le modèle source ou la configuration.

Test 2 : rejeu des redirections une à une

• Objectif : confirmer que le routage de production préserve la destination de chaque ancienne URL.
• Méthode : rejouer le crawl d’URL HTTP enregistré dans le vérificateur groupé d’états, puis comparer les premières et dernières destinations à la correspondance approuvée.
• Résultat attendu : chaque ancienne URL renvoie une redirection permanente vers son équivalent HTTPS exact, dont la réponse finale est saine.
• Critère d’échec : chaîne, boucle, 302, envoi vers l’accueil, chemin ou requête modifiés, destination 4xx ou 5xx.
• Action suivante : corriger la règle de redirection source ; maintenir l’écouteur HTTP disponible pour un retour jusqu’à la réussite du rejeu.

Test 3 : contrôle des signaux de recherche après lancement

• Objectif : vérifier que les robots reçoivent un récit cohérent de la migration.
• Méthode : inspecter les principales URL HTTPS et surveiller journaux, Crawl Stats et indexation des pages par rapport à la référence enregistrée.
• Résultat attendu : les URL HTTPS sont crawlées et choisies comme canonical, tandis que les URL HTTP apparaissent de plus en plus comme redirigées ; les erreurs de réponse restent dans la référence habituelle du site.
• Critère d’échec : canonical HTTP persistants, blocage généralisé du crawl, boucles ou hausse significative des 5xx.
• Action suivante : appliquer la correction réversible prédéfinie ; ne pas activer HSTS avant la stabilité de la version HTTPS.

Ressources qui méritent votre temps

Mes conférences

• Mieux vaut prévenir que guérir avec HTTPS — SMX East 2016 (SlideShare) : mon analyse approfondie de TLS, des échecs courants d’implémentation HTTPS et des pièges de migration — 302 au lieu de 301, canonical HTTPS manquants, erreurs TLS SNI pouvant entraîner une désindexation dans Bing/Baidu et perte des données de provenance, le « trafic sombre », sur les liens HTTPS→HTTP. Avertissement habituel : il s’agit de ma compréhension de ces systèmes, et les statistiques d’adoption datent de 2016.

Mes articles connexes

• Guide du débutant en SEO technique : la place des migrations et de HTTPS dans une vision d’ensemble.

Dans le reste du secteur

• Google, Déplacements de sites avec changements d’URL : procédure canonique de migration — 301 côté serveur, redirections en un saut, conservation pendant au moins un an, pas d’outil Change of Address pour HTTP→HTTPS.
• Google, Activer HTTPS sur vos serveurs et Corriger le contenu mixte : documentation d’implémentation la plus utile et concentrée.
• Let’s Encrypt : certificats DV gratuits et automatisés avec renouvellement intégré ; tout ce qu’exige le signal de classement.
• Test de serveur SSL Labs : évaluez votre configuration TLS une fois le certificat installé.
• hstspreload.org : vérifiez l’éligibilité et lisez les avertissements sur la suppression avant d’adopter le preload.
• HSTS — définition et utilisation (Kinsta) : guide pratique couvrant le risque d’enfermement lié au preload.
• HTTPS Is Easy (Troy Hunt) : courte série vidéo qui démystifie la configuration de TLS depuis zéro.

Statistiques à citer

• Les redirections 301 ne font perdre aucun PageRank. Déclaration catégorique de Google, qui réfute le mythe selon lequel le passage à HTTPS coûte de l’autorité de liens et définit toute l’approche de migration. Source
• Conservez les redirections au moins un an. Minimum recommandé par Google, pas une échéance après laquelle leur suppression est sûre ; la plupart des sites les gardent indéfiniment. Source
• Toutes les pages HTTP sont marquées « Not Secure » depuis Chrome 68 — juillet 2018. Cette échéance a transformé la migration HTTPS d’option en prérequis. Source
• Environ 89 % des sites Web utilisent désormais HTTPS. L’enjeu est de ne pas rester à la traîne, pas de gagner des positions — W3Techs, 2026 ; confirmez le chiffre actuel.
• Googlebot suit jusqu’à “10 hops” (traduction) « 10 sauts » dans une chaîne de redirection, mais Google conseille d’atteindre directement la destination finale ; ce plafond justifie la règle « aucune chaîne ». Source

Testez-vous : migration HTTP vers HTTPS

Cinq questions rapides sur l’exécution d’une migration HTTP→HTTPS. Choisissez une réponse pour chacune, puis vérifiez.

Journal des modifications