Damien HernandezSur cette page
HTTPS est-il un facteur de classement ?
Oui, mais un signal faible. En août 2014, Google annonçait sur son blog Search Central un signal « très léger », qui touchait moins de 1 % des requêtes mondiales et pesait moins que la qualité du contenu. Aujourd’hui, Google range HTTPS parmi les composantes de l’expérience sur la page. Son effet le plus concret est ailleurs : la documentation de Google sur la canonicalisation, mise à jour le 10 juillet 2026, indique que Google préfère la page HTTPS à la page HTTP équivalente. Cette préférence tombe dans quatre cas : certificat invalide, ressources non sécurisées autres que des images, page HTTPS qui redirige vers HTTP, ou balise canonical qui pointe vers la version HTTP. Un HTTPS mal tenu ne rapporte donc rien, et peut renvoyer Google vers l’ancienne adresse.
Faire contrôler les redirections et la configuration HTTPS de votre site →
Comment passer un site en HTTPS sans perdre de trafic ?
Google traite le passage de HTTP à HTTPS comme un déplacement de site avec changement d’URL, au même titre qu’une migration. Chaque URL HTTP doit répondre par une redirection 301 vers son équivalent HTTPS exact, pas vers l’accueil. Les liens internes, les balises canonical, le sitemap XML et les annotations hreflang passent tous en https, sinon chaque lien interne coûte une redirection. Reste l’en-tête HSTS (HTTP Strict Transport Security, RFC 6797 de novembre 2012) : il demande au navigateur de ne plus jamais appeler le site en clair. Le site hstspreload.org conseille de monter sa durée par paliers, de cinq minutes à un mois, en vérifiant les pages à chaque étape. Une fois la durée longue servie, revenir en HTTP devient impossible pour les visiteurs déjà passés.
Comment vérifier la configuration HTTPS d’un site ?
Trois commandes suffisent pour l’essentiel. La première suit les redirections depuis la version HTTP, la deuxième lit les en-têtes de la version HTTPS, la troisième affiche l’émetteur et les dates du certificat :
curl -sIL http://exemple.fr/
curl -sI https://www.exemple.fr/
openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr | openssl x509 -noout -issuer -datesTestez les quatre variantes de l’adresse : http et https, avec et sans www. Chacune doit aboutir à la même URL HTTPS en une ou deux redirections. Dans la Search Console, le rapport HTTPS signale les pages servies en clair. Côté code source, cherchez les appels en http:// vers des scripts ou des feuilles de style : ce contenu mixte fait partie des cas où Google peut écarter la version HTTPS.
Cas mesuré : un HSTS « preload » qui ne précharge rien
Relevé du 5 novembre 2026. Sur un site vitrine de conseil en référencement, les quatre variantes de l’adresse d’accueil ont été interrogées. La version http sans www répond 301 vers https sans www, qui répond 301 vers https avec www : deux sauts, dans l’ordre que hstspreload.org exige (passer en HTTPS sur le même hôte avant de changer d’hôte). La version http avec www va directement à la bonne adresse. Les réponses HTTPS, redirection comprise, portent l’en-tête Strict-Transport-Security avec max-age=63072000, soit deux ans, includeSubDomains et preload. Pourtant, l’API de statut de hstspreload.org répond « unknown » : le domaine n’a jamais été soumis, et la directive preload ne produit aucun effet. Le certificat Let’s Encrypt couvre le domaine nu, www et le sous-domaine de messagerie, en TLS 1.3, du 13 octobre 2026 au 11 janvier 2027. Le code source de l’accueil n’appelle aucune ressource en http:// (relevé : curl sur les quatre variantes, openssl s_client, API de statut de hstspreload.org, 5 novembre 2026).
Le préchargement HSTS vaut pour tous les sous-domaines, y compris ceux qui ne sont pas publics. hstspreload.org prévient qu’un retrait met des mois à atteindre les utilisateurs. Vérifiez d’abord que chaque sous-domaine, messagerie et outils internes compris, répond en HTTPS.
Questions fréquentes
Quelle différence entre SSL et TLS ?
TLS a succédé à SSL. On parle encore de « certificat SSL » par habitude, mais les connexions HTTPS actuelles reposent sur TLS, dont la version 1.3 est décrite par la RFC 8446 d’août 2018.
Un certificat gratuit suffit-il pour le SEO ?
Aucune documentation de Google ne favorise un certificat payant. Ce qui compte pour Google, c’est un certificat valide : un certificat invalide fait partie des cas où il peut écarter la version HTTPS comme canonique.
Que se passe-t-il si le certificat expire ?
Les navigateurs affichent une alerte de sécurité avant la page, et Google peut cesser de préférer la version HTTPS. Avec des certificats de 90 jours, seul un renouvellement automatique et surveillé évite l’incident.
Qu’est-ce que le contenu mixte ?
Une page HTTPS qui charge des scripts, des feuilles de style ou d’autres ressources en http://. Google cite les dépendances non sécurisées, hors images, parmi les raisons de ne pas retenir la page HTTPS comme canonique.
HTTPS ralentit-il un site ?
La négociation TLS ajoute un échange au premier contact, mais HTTPS est aussi la condition d’HTTP/2 dans les navigateurs. Mesurez plutôt que de supposer : le temps de connexion TLS se lit dans les variables de curl.
Sources primaires
- [1]Google Search Central, HTTPS as a ranking signal, août 2014consulter ↗
- [2]Google, consolider les URL en double, mise à jour le 10 juillet 2026consulter ↗
- [3]Google, expérience sur la page dans les résultats de rechercheconsulter ↗
- [4]Google, déplacer un site en changeant les URLconsulter ↗
- [5]IETF, RFC 9110, HTTP Semantics, juin 2022consulter ↗
- [6]IETF, RFC 8446, TLS 1.3, août 2018consulter ↗
- [7]IETF, RFC 6797, HTTP Strict Transport Security, novembre 2012consulter ↗
- [8]hstspreload.org, conditions et retrait de la liste de préchargement, consulté le 5 novembre 2026consulter ↗
- [9]Chromium Blog, A secure web is here to stay, février 2018consulter ↗
- [10]Let’s Encrypt, FAQ, durée de vie des certificats, consultée le 5 novembre 2026consulter ↗
Faire expliquer ce terme par une IA
prompt pré-rempliOuvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Comment fonctionne HTTPS ?
HTTPS ajoute une couche TLS sous les requêtes HTTP. Avant le premier octet de page, le navigateur et le serveur négocient une connexion : le serveur présente un certificat signé par une autorité de certification, le navigateur vérifie qu’il correspond bien au nom de domaine, puis les deux s’accordent sur des clés de chiffrement. Les données échangées, des identifiants de connexion aux informations de paiement saisies dans un formulaire, deviennent illisibles pour un intermédiaire du réseau. La version actuelle, TLS 1.3, est décrite par la RFC 8446 de l’IETF (août 2018). Le certificat a une durée de vie courte : ceux de Let’s Encrypt, l’autorité gratuite la plus répandue, valent 90 jours selon sa propre documentation. Le renouvellement doit donc être automatique, sinon le site affiche un jour une alerte de sécurité.