HTTPS pour le SEO

En bref — HTTPS est la version sécurisée et chiffrée de HTTP, reconnaissable au cadenas dans le navigateur. Google a historiquement accordé un très léger avantage aux pages HTTPS, mais les vraies raisons de migrer sont que Chrome signale les sites HTTP comme « non sécurisés » et que HTTPS est désormais la norme du Web. La migration est sûre si elle est bien menée : redirigez chaque ancienne URL http:// vers sa version https:// sans rien casser au passage.

Qu’est-ce que HTTPS ?

Lorsque vous chargez un site, votre navigateur communique avec un serveur. En HTTP, cette conversation se déroule en clair : toute personne placée sur le réseau entre les deux — votre fournisseur d’accès, le Wi-Fi d’un café ou un attaquant — peut la lire ou la modifier. HTTPS chiffre cette même conversation. Le « S » signifie « Secure ». Pour l’activer, vous installez sur votre serveur un certificat TLS, encore souvent appelé « certificat SSL ».

La barre d’adresse permet de le vérifier : l’URL commence par https:// et s’accompagne généralement d’un cadenas. Dans Chrome, une page en http:// affiche au contraire la mention « Non sécurisé ».

HTTPS ne protège que la connexion. Il ne garantit pas le contenu de la page. Le cadenas signifie que les données en transit sont chiffrées ; il ne dit pas si le contenu du site est fiable, si un formulaire est légitime ou si l’entreprise qui se trouve derrière existe réellement. Des sites d’hameçonnage peuvent parfaitement utiliser des certificats HTTPS valides.

HTTPS aide-t-il le SEO ?

Un peu, historiquement. En 2014, Google a confirmé utiliser HTTPS comme signal de classement, mais un signal très faible, que son équipe décrivait alors comme un critère de départage : entre deux pages par ailleurs équivalentes, la page sécurisée pouvait passer devant. Il ne fera pas remonter une page médiocre au-dessus d’une excellente page, et les consignes actuelles de Google ne réaffirment pas un avantage direct de HTTPS sur le classement. Promettre d’importants gains « simplement en ajoutant SSL » est donc trompeur.

Les raisons qui comptent vraiment :

• Chrome affiche « Non sécurisé ». Depuis 2018, chaque page HTTP reçoit cet avertissement. Il peut faire fuir les visiteurs, indépendamment de l’avis de Google.
• C’est désormais la norme. Environ 9 sites sur 10 utilisent déjà HTTPS (W3Techs, 2026). Un site qui reste en HTTP paraît défaillant.
• Les fonctions modernes en dépendent. De nombreuses capacités des navigateurs, ainsi que les connexions plus rapides via HTTP/2, ne fonctionnent tout simplement pas sans HTTPS.

La migration risque-t-elle de nuire à mon classement ?

Non, si elle est menée avec soin. Passer de HTTP à HTTPS constitue une forme de migration de site, avec la même règle d’or que toute autre migration : rediriger chaque ancienne URL vers sa nouvelle version sécurisée au moyen d’une redirection 301. Bien exécutée, l’opération préserve le classement. Mal exécutée — redirections manquantes, liens cassés vers des images ou des scripts — elle peut faire perdre du trafic. Le changement de protocole est sûr ; ce sont les erreurs qui l’entourent qui font mal. Evidence for this claim Google recommends permanent server-side redirects during site moves and says HTTP-to-HTTPS moves do not use the Change of Address tool. Scope: Google's site-move guide supports redirect and Search Console handling; it does not guarantee that a migration with implementation errors retains traffic. Confidence: high · Verified: 2026-07-14 Google Search Central: Site moves with URL changes

Vous voulez comprendre le poids réel du signal, la migration étape par étape, le contenu mixte et HSTS ? Passez à l’onglet Avancé.

En bref — Les consignes actuelles de Google sur l’expérience sur la page indiquent que les aspects autres que les Core Web Vitals “don’t directly help your website rank higher” (traduction) « n’aident pas directement votre site à mieux se classer ». Ne promettez donc pas un gain de classement actuel grâce à HTTPS. Les éléments confirmés sont historiques : Google a annoncé en août 2014 un signal « très léger », touchant moins de 1 % des requêtes, puis Gary Illyes l’a décrit en 2015 comme un critère de départage. Ce sont des déclarations datées, pas un mécanisme actuel documenté. Séparément, Google préfère aujourd’hui les pages HTTPS comme canoniques, mais seulement sous conditions : un certificat invalide, des dépendances non sécurisées, une redirection HTTPS→HTTP ou une balise canonique HTTP peuvent inverser cette préférence, et HSTS ne peut pas la rétablir. Le vrai intérêt de HTTPS réside dans l’avertissement « Non sécurisé » de Chrome, HTTP/2, les API modernes des navigateurs et le fait qu’il s’agit désormais d’un prérequis, pas d’un levier de croissance. Une migration exige une redirection 301 pour chaque URL, la correction du contenu mixte, la mise à jour des canoniques, sitemaps et liens internes, ainsi qu’une nouvelle validation dans Search Console. L’outil de changement d’adresse n’est pas nécessaire. HSTS et sa redirection interne 307 protègent le navigateur en complément des redirections 301 du serveur, jamais à leur place.

Google promet-il actuellement un gain de classement grâce à HTTPS ?

Commençons par ce que Google dit aujourd’hui, et non en 2014. Sa documentation sur l’expérience sur la page précise qu’au-delà des Core Web Vitals, les autres aspects de l’expérience — dont HTTPS — “don’t directly help your website rank higher in search results.” (traduction) « n’aident pas directement votre site à mieux se classer dans les résultats de recherche ». C’est la consigne directe la plus récente, et elle ne permet pas de promettre un gain de classement actuel simplement parce qu’un site utilise HTTPS.

Le signal de 2014 et le « critère de départage » : des éléments historiques, pas le mécanisme actuel

L’histoire, elle, est confirmée : Google a annoncé HTTPS comme signal de classement le 6 août 2014, en indiquant très franchement son faible poids au lancement. La formulation originale était “very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content” (traduction) « un signal très léger, affectant moins de 1 % des requêtes mondiales et pesant moins que d’autres signaux comme un contenu de haute qualité ». Le billet ajoutait que Google “may decide to strengthen it” (traduction) « pourrait décider de le renforcer » au fil du temps pour encourager son adoption. Il parlait de « renforcer », pas du « boost » souvent repris par la presse SEO. Evidence for this claim Google announced HTTPS as a very lightweight ranking signal affecting fewer than one percent of global queries at launch. Scope: Google's 2014 announcement establishes the signal and its weight at launch; it does not quantify the signal's current weight. Confidence: high · Verified: 2026-07-14 Google Search Central: HTTPS as a ranking signal

Un an plus tard, en septembre 2015, Gary Illyes décrivait ce signal comme un critère de départage : “it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost” (traduction) « il agit plutôt comme un critère de départage. Par exemple, si tous les signaux de qualité sont égaux pour deux résultats, celui qui utilise HTTPS obtiendrait… ou pourrait obtenir… l’avantage supplémentaire ». La même année, il résumait clairement la priorité : “you should switch to HTTPS for users, not as a ranking signal” (traduction) « vous devriez passer à HTTPS pour les utilisateurs, pas comme signal de classement ». À la même période, John Mueller conseillait de ne pas attendre de changement visible de classement du seul fait de la migration.

Il faut donc considérer le « critère de départage » comme une explication représentative, mais datée, donnée par Illyes en 2015–2016, et non comme un mécanisme que Google documente encore. La formulation actuelle sur l’expérience sur la page est une source plus prudente et plus récente. La réponse honnête et datée à la question « HTTPS aide-t-il le SEO ? » est la suivante : Google a confirmé un signal mineur en 2014, un représentant de Google l’a décrit comme un critère de départage en 2015, et les consignes actuelles ne reprennent pas directement ce mécanisme. HTTPS est une mesure d’hygiène, pas un levier de croissance, quel que soit le poids exact du signal historique aujourd’hui.

La préférence de Google pour les canoniques HTTPS est conditionnelle

À distinguer du signal de classement de 2014, Google documente aujourd’hui une préférence de canonisation : “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as” (traduction) « Google préfère les pages HTTPS aux pages HTTP équivalentes comme canoniques, sauf en cas de problèmes ou de signaux contradictoires tels que » un certificat SSL invalide, des dépendances non sécurisées autres que des images, une page HTTPS qui redirige les utilisateurs vers ou à travers une page HTTP, ou une page HTTPS dont le rel="canonical" pointe vers la version HTTP.

Cette nuance échappe à presque tous les autres guides et contredit une simplification répandue, notamment la phrase d’Illyes en 2016 selon laquelle le signal de classement consiste “basically looking at the first five characters in front of the URL” (traduction) « essentiellement à regarder les cinq premiers caractères devant l’URL ». Ce raccourci décrit le signal de classement de 2014, pas la décision de canonisation. Les consignes de Google sont explicites : un mauvais certificat ou une redirection vers un protocole moins sûr annule la préférence HTTPS. “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (traduction) « Évitez les mauvais certificats TLS/SSL et les redirections de HTTPS vers HTTP, car ils incitent fortement Google à préférer HTTP. » HSTS ne corrige pas ce problème : “Implementing HSTS cannot override this strong preference.” (traduction) « La mise en œuvre de HSTS ne peut pas annuler cette forte préférence. »

Conséquence pratique : un certificat expiré ou mal configuré n’est pas seulement un problème d’expérience utilisateur. Il peut aussi pousser Google à indexer la page HTTP plutôt que la page HTTPS que vous souhaitez classer. Pour connaître les types d’échec de certificat et leur diagnostic, consultez les certificats SSL/TLS ; pour interpréter le rapport Search Console consacré à cette décision, consultez le rapport HTTPS.

Pourquoi HTTPS compte réellement

Une fois la question du classement écartée, le dossier en faveur de HTTPS est accablant, avec une réserve importante : HTTPS sécurise le canal de transport entre le navigateur et le serveur. Il n’audite pas le code de votre application, ne garantit pas vos points de terminaison ni l’intention de l’utilisateur. Un site HTTPS piraté, un formulaire d’hameçonnage servi en HTTPS ou une fuite de données après déchiffrement restent possibles. HTTPS est une mesure d’hygiène indispensable, pas une garantie de sécurité pour tout ce qui suit la connexion.

Dans ce cadre, les arguments pratiques sont les suivants :

• L’avertissement « Non sécurisé » de Chrome. Depuis Chrome 68, publié en juillet 2018, Chrome marque toutes les pages HTTP comme « non sécurisées ». Cette mention apparaît dans la barre d’adresse devant de vrais visiteurs : son impact potentiel sur la conversion est bien supérieur à celui d’un minuscule signal de classement.
• Le prérequis pratique de HTTP/2 et HTTP/3. Aucun navigateur courant ne propose HTTP/2 sur une connexion HTTP non chiffrée : tous le négocient uniquement via TLS, même si la spécification HTTP/2 n’impose pas elle-même le chiffrement. Comme le précise la documentation de Google, “in some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (traduction) « dans certains cas, TLS peut améliorer les performances, principalement parce qu’il rend HTTP/2 possible ». Il s’agit d’une possibilité, pas d’une garantie : le coût de TLS, la configuration du serveur et la réutilisation des connexions comptent toujours. Toutefois, le multiplexage et la compression des en-têtes de HTTP/2 rendent souvent un site HTTPS+HTTP/2 plus rapide qu’un site HTTP/1.1 non chiffré, à l’inverse de l’ancienne crainte selon laquelle TLS ajoutait nécessairement de la latence.
• Les fonctions modernes des navigateurs l’exigent. Les service workers, les API de géolocalisation, de caméra et de microphone, ainsi que les applications Web progressives, requièrent généralement un contexte sécurisé, sous réserve d’exceptions propres à chaque fonction et navigateur comme localhost. Google indique : “HTTPS is required for many new browser features, especially those required for progressive web apps.” (traduction) « HTTPS est nécessaire à de nombreuses nouvelles fonctions des navigateurs, notamment celles qu’exigent les applications Web progressives. »
• Les données de provenance et le « trafic sombre » : par défaut, pas dans tous les cas. Avec la politique Referrer-Policy moderne par défaut (strict-origin-when-cross-origin), les navigateurs suppriment entièrement l’en-tête Referer lorsqu’un lien mène d’une page HTTPS vers une destination HTTP. Une navigation au même niveau de sécurité ou vers un niveau supérieur transmet au moins l’origine. Si votre site reste en HTTP, l’attribution des visites entrantes ou sortantes peut donc être classée à tort comme « directe ». Cependant, l’en-tête Referrer-Policy propre au site peut modifier ce comportement dans les deux sens : n’en faites pas une règle absolue lorsque vous analysez les données d’un tiers.
• C’est un prérequis élémentaire. Environ 89 % des sites utilisent HTTPS (W3Techs, 2026 — une estimation indicative, pas un décompte exact et permanent). Pour le SEO, l’enjeu n’est pas le gain obtenu en migrant, mais le risque de rester visiblement à la traîne.

Migrer de HTTP vers HTTPS

Le passage de HTTP à HTTPS est une migration de site et mérite la même rigueur. Bonne nouvelle, les consignes de Google sur les migrations sont claires : “301 and other permanent redirects don’t cause a loss in PageRank” (traduction) « les redirections 301 et les autres redirections permanentes n’entraînent pas de perte de PageRank ». La crainte de perdre la popularité transmise par les liens est un mythe. Le risque réside entièrement dans l’exécution, pas dans le changement de protocole : ce sont les redirections 301 manquantes, le contenu mixte, les canoniques obsolètes et l’absence de validation de la propriété HTTPS dans Search Console qui font réellement perdre du trafic.

La discipline essentielle tient en un paragraphe : mesurez d’abord le site HTTP en production — exploration, classements, export Search Console et profil de backlinks —, obtenez un certificat TLS — un certificat DV gratuit de Let’s Encrypt transmet le même signal qu’un certificat OV ou EV payant —, redirigez en 301 chaque URL HTTP vers son équivalent HTTPS exact, rendez HTTPS canonique partout — liens internes, sitemap et hreflang, sans compter sur les redirections pour masquer des liens internes obsolètes —, corrigez le contenu mixte avant la bascule, validez de nouveau les quatre propriétés Search Console — aucun outil de changement d’adresse n’est nécessaire pour un changement de protocole — et conservez les redirections pendant au moins un an. Attendez-vous à des fluctuations temporaires : une baisse qui se résorbe correspond à la stabilisation de la migration ; une baisse persistante signale une panne.

Il s’agit de la carte des risques, pas du mode opératoire complet. Pour la séquence détaillée, la répétition en préproduction, la création des correspondances de redirection à grande échelle, le plan de retour arrière et la liste de contrôle intégrale, consultez la migration de HTTP vers HTTPS. Cette page reste volontairement synthétique afin de ne pas diverger de ce guide approfondi.

Contenu mixte

Le contenu mixte apparaît lorsqu’une page HTTPS charge une sous-ressource via HTTP. Il en existe deux formes, et cette distinction détermine les priorités :

• Contenu mixte actif — scripts, feuilles de style, iframes, XMLHttpRequest. Les navigateurs le bloquent entièrement, car un script altéré peut réécrire toute la page. C’est ce qui casse réellement un site après une migration ; corrigez-le en premier.
• Contenu mixte passif — images, audio et vidéo. Les navigateurs l’affichent généralement encore, mais dégradent l’indicateur de sécurité et émettent un avertissement.

Pour le trouver, explorez le site HTTPS avec Ahrefs Site Audit ou Screaming Frog, surveillez la console des outils de développement de Chrome ou collectez les rapports CSP. La correction proactive la plus propre est l’en-tête Content-Security-Policy: upgrade-insecure-requests, qui demande au navigateur de remplacer silencieusement les requêtes de sous-ressources http:// par https:// avant leur envoi. C’est un filet de sécurité utile pendant et après la migration. Les liens ordinaires vers des pages HTTP ne constituent pas du contenu mixte : ils déclenchent simplement une navigation.

HSTS, et pourquoi il ne remplace pas vos redirections 301

HSTS, ou HTTP Strict Transport Security, est un en-tête de réponse (Strict-Transport-Security) qui ordonne aux navigateurs de toujours utiliser HTTPS pour votre domaine, même si l’utilisateur saisit ou clique sur un lien http://. Il ferme la faille de la « première requête » : avec une simple redirection 301, la toute première requête d’un nouveau visiteur part encore en HTTP avant le déclenchement de la redirection, ce qui ouvre une fenêtre aux attaques par suppression de SSL. Selon la documentation de Google, HSTS permet d’“avoid the cost of the 301 redirect” (traduction) « éviter le coût de la redirection 301 » pour les visiteurs récurrents et “defeats attacks like SSL Stripping” — traduction : « neutralise les attaques telles que la suppression de SSL ».

Deux points doivent rester parfaitement distincts pour le SEO :

• HSTS ne remplace pas les redirections 301 côté serveur. Lorsqu’un navigateur applique HSTS, il effectue une redirection interne 307 vers HTTPS. Cette opération se déroule dans le navigateur, hors de la vue des robots. Les moteurs de recherche ont toujours besoin d’une véritable redirection 301 côté serveur pour comprendre la migration et transférer la popularité des liens. Les deux sont nécessaires.
• Le préchargement HSTS est presque permanent. Vous pouvez inscrire votre domaine dans la liste de préchargement intégrée aux navigateurs, à condition d’utiliser un max-age d’au moins un an, includeSubDomains et preload. Cela ferme la faille même pour les nouveaux visiteurs. En revanche, sortir de cette liste est lent et difficile. Google avertit : “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. » Considérez le préchargement comme une porte à sens unique.

Mythes courants

• « HTTPS apporte aujourd’hui un important gain de classement. » Non. Le signal « très léger » de 2014, qui concernait moins de 1 % des requêtes, et la description comme « critère de départage » en 2015 sont des déclarations datées. Les consignes actuelles indiquent que les aspects de l’expérience autres que les Core Web Vitals “don’t directly help you rank higher” (traduction) « ne vous aident pas directement à mieux vous classer ».
• « La migration va faire chuter mon classement. » Pas si les redirections sont correctement mises en place : les redirections 301 ne font pas perdre de PageRank. Les migrations bâclées font mal, pas le changement de protocole.
• « Il faut utiliser l’outil de changement d’adresse. » Pas pour HTTP→HTTPS ; il ne sert qu’aux changements de domaine.
• « Un certificat expiré ne nuit qu’à l’expérience utilisateur, pas au SEO. » Faux. Un mauvais certificat fait partie des conditions citées qui peuvent inverser la préférence canonique de Google en faveur de la page HTTP, en plus d’empêcher les utilisateurs d’accéder à la page.
• « HTTPS ne compte que pour les pages de paiement. » Faux. Chrome signale toutes les pages HTTP, et les API modernes exigent généralement un contexte sécurisé.
• « TLS ralentit les sites. » En pratique, c’est souvent l’inverse, car HTTPS permet HTTP/2. TLS « peut » améliorer les performances, sans pour autant les garantir.

La migration HTTP→HTTPS s’inscrit dans la discipline plus large des migrations de site. Si vous changez aussi de domaine ou de plateforme, commencez par lire ce guide, car l’empilement de migrations multiplie les risques.

Résumé par l’IA

Version condensée de l’onglet Avancé :

• Les consignes actuelles de Google ne promettent aucun gain de classement. La documentation sur l’expérience sur la page indique que les aspects autres que les Core Web Vitals “don’t directly help your website rank higher” (traduction) « n’aident pas directement votre site à mieux se classer » —, et HTTPS figure parmi ces aspects.
• Le signal de 2014 et le « critère de départage » de 2015 sont historiques. Google parlait d’un signal “very lightweight” (traduction) « très léger », touchant moins de 1 % des requêtes en 2014 ; Illyes parlait d’un critère de départage en 2015. Ce sont des déclarations datées, pas un mécanisme actuel réaffirmé. HTTPS ne doit pas être traité comme un levier de croissance.
• La préférence de Google pour les canoniques HTTPS est distincte et conditionnelle. Google préfère actuellement HTTPS, sauf en présence d’un certificat invalide, de dépendances non sécurisées autres que des images, d’une redirection HTTPS→HTTP ou d’une balise canonique HTTP. HSTS ne peut pas annuler ces signaux. Un mauvais certificat constitue donc un risque de canonisation, pas seulement un problème d’expérience utilisateur.
• HTTPS ne sécurise que le transport. Il ne protège ni la logique applicative, ni les points de terminaison, ni l’intention de l’utilisateur ; une page d’hameçonnage peut disposer d’un certificat HTTPS valide.
• Les vraies raisons d’utiliser HTTPS : l’avertissement « Non sécurisé » de Chrome sur toutes les pages HTTP depuis juillet 2018, HTTP/2 dans tous les grands navigateurs — souvent plus rapide que HTTP/1.1, même si TLS peut améliorer les performances sans les garantir —, les fonctions exigeant un contexte sécurisé, le comportement par défaut mais modifiable des données de provenance, et le fait qu’environ 89 % du Web l’utilise déjà.
• La migration reste une migration de site, présentée ici dans ses grandes lignes. Redirigez chaque URL en 301 vers son équivalent exact — sans perte de PageRank —, rendez HTTPS canonique, mettez à jour les liens internes, sitemaps et hreflang, corrigez le contenu mixte, validez de nouveau Search Console, conservez les redirections au moins un an et n’utilisez pas l’outil de changement d’adresse pour un simple changement de protocole. Les étapes détaillées figurent dans le guide consacré à la migration.
• Contenu mixte : le contenu actif — scripts et iframes — est bloqué et doit être corrigé en premier ; le contenu passif — images — déclenche un avertissement. La directive CSP upgrade-insecure-requests sert de filet de sécurité.
• HSTS ferme la faille de la première requête, mais utilise une redirection 307 interne au navigateur, invisible aux robots. Il vient en complément, et non à la place, des redirections 301 côté serveur. Le préchargement est presque permanent : ne l’activez pas à la légère.

Documentation officielle

Documentation de première main publiée par les équipes des moteurs de recherche et des navigateurs.

Google

• HTTPS comme signal de classement — annonce de 2014 — le billet original qui parle d’un “very lightweight signal” (traduction) « signal très léger ».
• Activer HTTPS sur vos serveurs (web.dev) — certificats, 301s, canoniques, HSTS et cookies.
• Pourquoi HTTPS est important (web.dev) — les arguments liés à la sécurité et aux fonctions des navigateurs.
• Corriger le contenu mixte (web.dev) — distinction entre contenu mixte actif et passif, et directive upgrade-insecure-requests.
• Migrations de site avec changement d’URL — procédure de migration, redirections et absence d’outil de changement d’adresse pour HTTPS.
• Comprendre l’expérience sur la page — place de HTTPS dans ce cadre et source actuelle pour ne pas promettre de gain direct de classement.
• Indiquer une URL canonique — préférence actuelle et conditionnelle pour HTTPS, ainsi que les exceptions qui l’annulent : mauvais certificats, dépendances non sécurisées et redirections vers HTTP.

Chrome / Chromium

• Vers un Web plus sécurisé (2016) — début du déploiement de l’avertissement « Non sécurisé ».
• Un Web sécurisé est là pour durer (2018) — Chrome 68 signale toutes les pages HTTP comme non sécurisées.

Bing / Microsoft

• Consignes Bing pour les webmasters — consignes générales ; vérifiez dans le navigateur la formulation actuelle relative à HTTPS.

Citations des sources

Déclarations publiques de Google. Chaque lien mène directement au passage cité sur la page source.

Google — annonce du signal de classement en 2014

• “We’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (traduction) « Nous commençons à utiliser HTTPS comme signal de classement. Pour l’instant, ce n’est qu’un signal très léger, qui affecte moins de 1 % des requêtes mondiales et pèse moins que d’autres signaux tels qu’un contenu de haute qualité. » — Zineb Ait Bahajji et Gary Illyes, Google. Accéder à la citation
• “But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS.” (traduction) « Mais avec le temps, nous pourrions décider de le renforcer, car nous souhaitons encourager tous les propriétaires de sites à passer de HTTP à HTTPS. » — même billet. Accéder à la citation

Gary Illyes — description comme critère de départage

• “With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.” (traduction) « Pour l’avantage de classement HTTPS, il s’agit plutôt d’un critère de départage. Par exemple, si tous les signaux de qualité sont égaux pour deux résultats, celui qui utilise HTTPS obtiendrait… ou pourrait obtenir… l’avantage supplémentaire nécessaire pour devancer l’autre. » — Gary Illyes, Google, cité par Search Engine Land. Lire l’article
• “You should switch to HTTPS for users, not as a ranking signal.” (traduction) « Vous devriez passer à HTTPS pour les utilisateurs, pas comme signal de classement. » — Gary Illyes, SMX East 2015, cité par Search Engine Land. Lire l’article
• “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 s’agit essentiellement de regarder les cinq premiers caractères devant l’URL et, si c’est HTTPS… elle bénéficiera d’un avantage minime. » — Gary Illyes, 2016, cité par Search Engine Land. Lire l’article

Google — préférence actuelle pour les canoniques HTTPS

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as the following.” (traduction) « Google préfère les pages HTTPS aux pages HTTP équivalentes comme canoniques, sauf en cas de problèmes ou de signaux contradictoires tels que ceux qui suivent. » — Google Search Central. Accéder à la citation
• “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (traduction) « Évitez les mauvais certificats TLS/SSL et les redirections de HTTPS vers HTTP, car ils incitent fortement Google à préférer HTTP. » — Google Search Central. Accéder à la citation
• “Implementing HSTS cannot override this strong preference.” (traduction) « La mise en œuvre de HSTS ne peut pas annuler cette forte préférence. » — Google Search Central. Accéder à la citation

Google — consignes sur la migration et HSTS

• “301 and other permanent redirects don’t cause a loss in PageRank.” (traduction) « Les redirections 301 et les autres redirections permanentes n’entraînent pas de perte de PageRank. » — Google Search Central. Accéder à la citation
• “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 de changement d’adresse. » — Google Search Central. 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
• “In some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (traduction) « Dans certains cas, TLS peut améliorer les performances, principalement parce qu’il rend HTTP/2 possible. » — web.dev, Google. Accéder à la citation

Chrome — déploiement de l’avertissement « Non sécurisé »

• “Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as ‘not secure’.” (traduction) « À partir de juillet 2018, avec la sortie de Chrome 68, Chrome signalera tous les sites HTTP comme “non sécurisés”. » — Emily Schechter, Chrome Security, Chromium Blog. Accéder à la citation

Liste de contrôle pour une migration HTTP → HTTPS

Version synthétique avant lancement. Pour la liste complète, la répétition en préproduction et le plan de retour arrière, consultez la migration de HTTP vers HTTPS.

Avant la migration

• Exploration complète du site HTTP en production enregistrée — toutes les réponses 200 et toutes les redirections existantes.
• Instantané des classements, export Search Console et profil de backlinks archivés.
• Certificat TLS obtenu et testé — un certificat DV gratuit convient pour le signal.

Pendant la bascule

• Chaque URL HTTP est redirigée en 301, côté serveur et individuellement, vers son équivalent HTTPS.
• Aucune chaîne de redirections — l’ancienne URL mène directement à l’URL HTTPS finale.
• Aucune redirection massive des URL sans correspondance vers la page d’accueil.
• Chaque page comporte un rel="canonical" autoréférent vers son URL HTTPS.
• Liens internes, sitemaps XML et hreflang mis à jour vers HTTPS, sans laisser les redirections compenser des URL obsolètes.
• Contenu mixte actif — scripts, styles et iframes — corrigé, car il est bloqué.
• Contenu mixte passif — images et médias — corrigé ; directive CSP upgrade-insecure-requests configurée.

Search Console et suivi

• Propriété HTTPS validée dans Search Console, ou propriété de domaine couvrant toutes les variantes.
• Nouveau sitemap HTTPS envoyé.
• Outil de changement d’adresse non utilisé — il ne sert qu’aux changements de domaine.
• Fichier de désaveu éventuel vérifié pour repérer les URL HTTP.
• Redirections conservées pendant au moins un an, idéalement durant toute la vie du site.
• Indexation et statistiques d’exploration surveillées ; une baisse qui ne se résorbe pas signifie qu’un élément est cassé.

Modèles mentaux

1. HTTPS est une mesure d’hygiène, pas un levier de croissance. Signal « très léger », moins de 1 % des requêtes, critère de départage : consacrez vos efforts de classement au contenu et aux liens. Mettez HTTPS en place parce que le Web l’exige, puis passez à autre chose.

2. Distinguez le signal de classement de 2014 de la préférence canonique actuelle. Le signal de classement de 2014 était historiquement lié au protocole ; la formule d’Illyes sur les « cinq premiers caractères » le décrit, mais reste une déclaration datée, pas le fonctionnement actuel documenté. La préférence actuelle de Google pour une canonique HTTPS est différente et conditionnelle : un mauvais certificat, des dépendances non sécurisées ou une redirection vers HTTP peuvent pousser Google à indexer la page HTTP. Un certificat cassé n’est donc pas seulement une urgence d’expérience utilisateur ; il peut aussi vous coûter la canonique HTTPS.

3. Une migration repose sur les redirections 301 ; tout le reste constitue un signal d’appui. Les redirections, qui ne font pas perdre de PageRank, assurent le véritable transfert du classement. Les canoniques, sitemaps, mises à jour des liens internes et nouvelles validations dans Search Console aident seulement Google à traiter la migration plus vite et plus proprement.

4. Il existe deux façons d’imposer HTTPS, et les deux sont nécessaires. La redirection 301 côté serveur s’adresse aux robots et transfère la popularité des liens. HSTS, qui produit une 307 interne au navigateur, protège les visiteurs humains récurrents contre la suppression de SSL. Les deux répondent à des problèmes différents ; HSTS ne remplace jamais la redirection 301.

5. Pour le contenu mixte, établissez les priorités selon le comportement du navigateur. Le contenu actif — scripts, styles et iframes — est bloqué : sa correction est nécessaire au fonctionnement et vient en premier. Le contenu passif — images et médias — ne déclenche qu’un avertissement : corrigez-le ensuite. upgrade-insecure-requests constitue le filet de sécurité pour les oublis.

HTTPS pour le SEO — aide-mémoire

Réalité du classement

Redirections et migration

Contenu mixte et HSTS

Imposer HTTPS et configurer HSTS

Exemples pour les deux piles les plus courantes. Testez d’abord en préproduction : un en-tête HSTS persiste et une boucle de redirections mal configurée bloque les utilisateurs.

Apache (.htaccess)

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

# HSTS — only add once you're confident HTTPS is solid
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Nginx

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# On the HTTPS server block, add HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Ajoutez ; preload à l’en-tête HSTS uniquement si vous comptez inscrire le domaine sur hstspreload.org : cette décision est presque irréversible.

Rechercher le contenu mixte en ligne de commande

Explorez vos pages HTTPS et recherchez dans leur code HTML les sous-ressources qui utilisent encore http://.

macOS / Linux

# Pull a page and flag insecure script/img/link/iframe sources
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

# Same idea in PowerShell
(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

Pour analyser tout un site, un robot d’exploration comme Ahrefs Site Audit ou Screaming Frog, ou la console des outils de développement de Chrome, sera plus rapide qu’un script exécuté page par page.

Ressources utiles

Mes conférences

• Mieux vaut prévenir que guérir avec HTTPS — SMX East 2016 (SlideShare) — mon analyse approfondie de TLS, des erreurs courantes de mise en œuvre de HTTPS et des pièges de la migration. La réserve habituelle s’applique : il s’agit de ma compréhension de ces systèmes, et les statistiques d’adoption datent de 2016.

Mes autres articles

• The Beginner’s Guide to Technical SEO — la place de HTTPS dans une vision plus large du SEO technique.

Sources officielles tierces

• Google : activer HTTPS sur vos serveurs et corriger le contenu mixte — l’ensemble le plus utile et le plus concentré de documents de mise en œuvre.
• hstspreload.org — vérifiez votre admissibilité avant de vous engager dans le préchargement.
• SSL Labs Server Test — évaluez votre configuration TLS.

Autres ressources du secteur

• HTTPS comme facteur de classement — Search Engine Journal — analyse du signal, de son poids réel et de son rôle de critère de départage plutôt que de levier.
• Gary Illyes de Google : HTTPS peut départager deux résultats équivalents (Search Engine Land) — premier compte rendu de la description d’Illyes comme « critère de départage ».
• Google commence à favoriser les sites HTTPS/SSL sécurisés (Search Engine Land) — couverture de l’annonce de 2014 et des premières réactions du secteur.
• HSTS : définition et mode d’emploi (Kinsta) — guide pratique qui couvre les risques et l’engagement associés à la liste de préchargement.
• Let’s Encrypt — autorité de certification DV gratuite et automatisée, largement utilisée lorsqu’il suffit d’obtenir le protocole https:// sans payer un certificat OV ou EV.
• HTTPS est simple (Troy Hunt) — courte série vidéo qui démystifie la configuration de TLS pour les débutants.

Statistiques à citer

• HTTPS est “a very lightweight signal—affecting fewer than 1% of global queries” — traduction : « un signal très léger qui affecte moins de 1 % des requêtes mondiales ». Il s’agit de la propre description de Google au lancement en 2014 : un chiffre historique, toujours utile pour ramener les attentes à leur juste mesure, mais pas une nouvelle description du mécanisme actuel. Source
• Toutes les pages HTTP sont signalées comme « non sécurisées » depuis Chrome 68, en juillet 2018. C’est la raison pratique la plus visible de migrer. Source
• Environ 89 % des sites utilisent désormais HTTPS. Il s’agit d’un prérequis élémentaire : le risque SEO est de rester à la traîne, pas l’absence d’un gain lors de la migration (W3Techs, 2026 ; vérifiez la valeur actuelle).
• Les redirections 301 ne font pas perdre de PageRank. Cette déclaration sans ambiguïté de Google réfute le mythe selon lequel la migration ferait perdre la popularité transmise par les liens. Source

Testez vos connaissances : HTTPS pour le SEO

Cinq questions rapides sur HTTPS et le SEO. Choisissez une réponse pour chacune, puis vérifiez.

Journal des modifications