L'essentiel, en trois lignes
Le HTTPS pèse très peu dans le classement, Google l'a annoncé ainsi dès l'origine. Il reste indispensable, pour une raison qui n'a rien à voir avec le référencement : sans lui, les navigateurs signalent votre site comme non sécurisé et vos visiteurs partent. L'attention doit porter sur trois points : la migration, le contenu mixte, et la surveillance du certificat.
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.
Traduction pratique : 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.
Alors pourquoi c'est indispensable quand même
Parce que l'enjeu s'est déplacé du classement vers la confiance. Les navigateurs signalent explicitement les pages non chiffrées comme non sécurisées, et affichent un avertissement dès qu'un formulaire y est présent. Un visiteur qui voit « non sécurisé » à côté de votre adresse repart avant d'avoir lu quoi que ce soit. Vous ne perdez pas des positions, vous perdez des gens : c'est bien pire, et cela ne se voit pas dans un outil de suivi.
La migration est une vraie migration
C'est le point le plus sous-estimé, et la source de la plupart des accidents. 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. 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. 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. 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. 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. 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.
Changer de protocole, c'est changer toutes vos adresses
Le plan de redirections se prépare avant la bascule, jamais après. Et le certificat se surveille, sous peine de rendre le site inaccessible un dimanche matin.
Inventaire, redirections en une étape, contrôle du contenu mixte.
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.
| Version | Ce qu'elle devrait faire |
|---|---|
http://exemple.fr |
Rediriger en 301 vers la version retenue |
http://www.exemple.fr |
Rediriger en 301 vers la version retenue |
https://exemple.fr |
Servir le site, ou rediriger, selon votre choix |
https://www.exemple.fr |
L'autre branche du même choix |
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, dilue la valeur et ralentit chaque visite. Testez les quatre variantes après la bascule, cela prend deux minutes.
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. Le navigateur bloque alors certaines ressources ou affiche un avertissement.
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 : 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 : 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 meilleur remède est structurel
Hébergez vos ressources sur votre propre domaine plutôt que de les appeler ailleurs. Polices, feuilles de style, bibliothèques : servies depuis chez vous, elles suivent automatiquement le protocole de la page et le problème disparaît définitivement. C'est le choix que j'applique sur ce site et sur les sites que je construis, pour cette raison et pour la performance.
Le certificat expiré, la panne la plus évitable
C'est le sujet dont personne ne parle et qui coûte le plus cher quand il arrive.
Un certificat a une durée de validité. À 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. C'est la seule vraie protection.
- Ajoutez une surveillance externe. Un service qui vous alerte quelques semaines avant l'expiration, et qui 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
Source : billet officiel Google Search Central du 6 août 2014 annonçant le HTTPS comme signal de classement, décrit comme « très léger », affectant moins de 1 % des requêtes mondiales et pesant moins que la qualité du contenu. Constat sur le certificat expiré relevé en août 2026 lors de la documentation de la fiche Yooda de ce lexique.