HTTPS et référencement

Ce que Google a réellement dit

L'annonce date du 6 août 2014, et sa formulation mérite d'être rappelée parce qu'on la cite rarement en entier. Google y présente le HTTPS comme un signal « très léger », affectant moins de 1 % des requêtes mondiales, et pesant moins que d'autres signaux comme la qualité du contenu. Google précisait vouloir éventuellement le renforcer avec le temps, pour encourager la généralisation du chiffrement.

Autrement dit, passer en HTTPS ne fera pas monter votre site. Si un prestataire vous vend une migration comme un levier de classement, il vous vend quelque chose que Google a lui-même relativisé il y a plus de dix ans.

La migration est une vraie migration

Le protocole fait partie de l'adresse : http://exemple.fr/page/ et https://exemple.fr/page/ sont deux URL distinctes aux yeux d'un moteur.

Passer en HTTPS revient donc à changer l'intégralité des adresses du site d'un coup. C'est exactement ce qu'est une migration, avec les mêmes exigences et les mêmes risques.

1. 1. Inventorier toutes les adresses actuelles

   En croisant une exploration complète, l'export de la Search Console sur 16 mois et votre sitemap. Les trois, aucune n'étant exhaustive seule.

2. 2. Rediriger en 301, adresse par adresse

   Chaque page HTTP vers son équivalent exact en HTTPS. Jamais une redirection globale vers la page d'accueil, qui équivaut à supprimer toutes vos pages.

3. 3. Mettre à jour les canoniques et le sitemap

   Toutes vos balises canoniques doivent désigner la version chiffrée. Un sitemap qui liste encore les anciennes adresses envoie un signal contradictoire.

4. 4. Corriger les liens internes en dur

   Les liens absolus écrits en HTTP dans vos contenus provoquent un saut de redirection à chaque clic. Un remplacement en base règle le problème.

5. 5. Déclarer la nouvelle version dans la Search Console

   Et surveiller la courbe d'indexation pendant plusieurs semaines. Une validation par enregistrement DNS couvre d'emblée toutes les variantes et évite ce genre de manipulation.

Une baisse temporaire de quelques semaines est normale : Google réexplore et réattribue. Une chute brutale et durable indique un problème dans le plan de redirections. Le diagnostic est sur perte de trafic après refonte.

Le piège des quatre versions

Une erreur discrète et très répandue. Après une migration mal cadrée, un site peut exister sous quatre adresses simultanément.

Trois de ces quatre adresses doivent rediriger vers la quatrième, et en une seule étape. C'est le détail qui distingue une migration propre d'une migration bâclée. Une chaîne du type HTTP sans www vers HTTP avec www puis vers HTTPS avec www ajoute des sauts inutiles et ralentit chaque première visite. Google la suit sans perte de valeur, jusqu'à dix sauts selon sa documentation, mais chaque saut est une requête de plus pour le robot comme pour le visiteur. Testez les quatre variantes après la bascule, cela prend deux minutes.

Une fois les redirections en place et vérifiées, ajoutez l'en-tête Strict-Transport-Security (HSTS). Il demande au navigateur de ne plus jamais tenter la version HTTP du site pendant la durée indiquée, ce qui supprime le saut de redirection pour les visiteurs qui reviennent. Commencez par une durée courte, quelques jours, avant de passer à un an. Tant que l'en-tête est actif, un retour en arrière vers le HTTP devient impossible pour ces visiteurs.

Le contenu mixte, la panne silencieuse

Une page servie en HTTPS qui appelle des ressources en HTTP crée ce qu'on appelle du contenu mixte. Chrome tente de charger les images, les sons et les vidéos en HTTPS et les abandonne si cette version n'existe pas. Les scripts et les feuilles de style appelés en HTTP sont bloqués d'office.

Le problème est qu'il ne se voit pas forcément. Une image manquante se remarque, un script de suivi bloqué ne se remarque pas du tout, et vous perdez vos statistiques pendant des semaines sans le savoir. Une feuille de style bloquée, elle, casse tout l'affichage d'un coup.

Comment le repérer : ouvrez une page dans votre navigateur, affichez la console de développement, et regardez les avertissements. Les ressources problématiques y sont listées nommément. Faites-le sur plusieurs types de pages, pas seulement l'accueil, car le contenu mixte vient souvent d'un gabarit particulier ou d'un contenu ancien.

Les sources les plus fréquentes sont les images insérées à la main dans d'anciens articles, les scripts externes appelés en HTTP, les polices et bibliothèques chargées depuis un service tiers, et les contenus intégrés comme les vidéos ou les cartes.

Le certificat qui expire

Un certificat a une durée de validité, et elle raccourcit. Le CA/Browser Forum, qui fixe les règles communes aux autorités de certification et aux navigateurs, l'a plafonnée à 200 jours pour les certificats émis depuis le 15 mars 2026. Le plafond passera à 100 jours le 15 mars 2027, puis à 47 jours le 15 mars 2029. Un renouvellement fait à la main une fois par an n'est donc déjà plus possible. À son expiration, le navigateur affiche un avertissement de sécurité bloquant, que la quasi-totalité des visiteurs ne franchit pas. Votre site devient inaccessible en pratique, du jour au lendemain, et rien ne vous prévient si vous n'avez pas mis en place de surveillance.

Ce n'est pas un risque théorique. En documentant la fiche Yooda de ce lexique, j'ai constaté que les applications de cet éditeur servaient un certificat expiré depuis plus de deux mois. Un acteur historique du SEO français, dont le site vitrine était par ailleurs parfaitement à jour. Si cela peut arriver à un éditeur d'outils, cela peut arriver à n'importe qui.

• Automatisez le renouvellement. La plupart des hébergeurs le proposent aujourd'hui sans surcoût, via le protocole ACME qu'utilise Let's Encrypt. Avec des durées de 100 puis 47 jours, c'est la seule vraie protection.
• Ajoutez une surveillance externe. Let's Encrypt n'envoie plus d'e-mail avant l'expiration depuis juin 2025, il faut donc un service tiers qui vous alerte avant l'échéance et vérifie aussi que le site répond. Le coût est dérisoire face à une journée d'indisponibilité.
• Vérifiez toutes les variantes. Un certificat couvrant le domaine mais pas ses sous-domaines laisse des applications entières en défaut, ce qui est exactement le cas que j'ai rencontré.

Ce qu'il reste à faire après la bascule

• Vérifier les quatre variantes d'adresse, chacune redirigeant en une seule étape vers la version retenue.
• Contrôler le contenu mixte sur plusieurs types de pages, via la console du navigateur.
• Mettre à jour vos outils de mesure, la Search Console et tout service tiers configuré sur l'ancienne adresse.
• Prévenir vos partenaires les plus importants, pour qu'ils actualisent leurs liens. Les redirections font le travail, mais un lien direct vaut mieux qu'un lien redirigé.
• Conserver les redirections indéfiniment. Elles ne coûtent presque rien et les retirer casserait les liens externes qui pointent encore vers vos anciennes adresses.

Questions fréquentes