WebRankInfo : la plus grande communauté francophone du référencement
Publié le
Olivier Duffez
Créateur de WebRankInfo,
consultant en référencement
Désormais, votre site DOIT être en HTTPS : pour la sécurité, pour inciter à la confiance, et pour l'intérêt SEO. Ce guide gratuit détaille toutes les étapes à suivre pour cette migration.
Ce dossier WebRankInfo détaille ma méthode pour migrer un site de HTTP vers HTTPS d’une façon optimale en termes de référencement. En suivant bien les étapes et les recommandations, cette migration devrait se passer dans les meilleures conditions.
Sommaire :
Il ne faut pas se lancer dans une migration sans se préparer ! Suivez bien toutes les étapes et ça se passera très bien.
Voici les 3 principales raisons :
Voici quelques conseils de bon sens :
Pour vos futurs sites, prévoyez HTTPS dès le début.
HTTPS signifie Hyper Text Transfer Procole Secure.
Version sécurisée de HTTP, HTTPS est un protocole utilisé pour faire communiquer un client (navigateur, crawler) et un serveur web en chiffrant les données à l'aide du protocole TLS (Transport Layer Security), le successeur de SSL (Secure Sockets Layer).
HTTPS permet au visiteur de vérifier l'identité du site web auquel il accède, grâce à un certificat d'authentification émis par une autorité tierce, réputée fiable (et faisant généralement partie de la liste blanche des navigateurs internet). Il garantit théoriquement la confidentialité et l'intégrité des données envoyées par l'utilisateur (notamment des informations entrées dans les formulaires) et reçues du serveur.
Ce tableau résume les différences entre HTTP et HTTPS :
Dans les paramètres de votre certificat SSL, vérifiez que votre site est enregistré pour le bon nom d'hôte. Par exemple, si vous enregistrez le certificat pour www.example.com et que votre site Web est configuré pour utiliser example.com, vous aurez une erreur de certificat pour cause de non-correspondance du nom.
Il faut une clé de sécurité de 2048 bits (Google déconseille 1024 bits)
Assurez-vous que vous utilisez les versions les plus récentes des bibliothèques TLS (certaines anciennes versions de OpenSSL sont vulnérables).
La plupart des hébergeurs proposent aussi bien des certificats gratuits (comme Let's Encrypt) que payants. Pour la plupart des cas, un certificat SSL gratuit suffit largement (c'est ce que j'utilise sur WebRankInfo).
D'autres conseils figurent en fin d'article.
Si votre serveur web accepte le mécanisme HTTP Strict Transport Security (HSTS), prévoyez de l'activer dès la mise en ligne du site HTTPS. A ce niveau, il faut d'abord vous renseigner pour savoir si c'est disponible pour vous.
Qu'est-ce que HSTS ?
Le mécanisme HSTS indique au navigateur de demander automatiquement des pages qui utilisent le protocole HTTPS, même lorsque l'internaute saisit http dans la barre d'adresse du navigateur.
Il indique également aux moteurs de diffuser des URL sécurisées dans leurs résultats (SERP). Tout cela minimise le risque de diffuser du contenu non sécurisé à vos internautes.
HSTS peut dans certains cas accélérer les choses puisque ça évite de demander au serveur de renvoyer une page HTTP (qui se ferait rediriger). Vous pouvez donc dans certains cas économiser une redirection. Par contre, vous pourrez voir un code HTTP 307, ne vous étonnez pas, ça correspond à ce cas.
Une fois HSTS activé sur votre site (après la bascule vers HTTPS), et seulement si 100% de votre site est uniquement accessible en HTTPS, vous pourrez l'inscrire ici afin de configurer le préchargement dans le navigateur Chrome.
Qu'est-ce que SNI ?
Server Name Indication, qui peut se traduire par « indication du nom du serveur », est une extension du protocole TLS. Avec le protocole SNI, le client indique le nom de l'hôte avec lequel il tente de démarrer une négociation TLS.
Assurez-vous que votre serveur Web accepte la SNI et que votre audience utilise des navigateurs compatibles de manière générale. SNI est supportée par tous les navigateurs modernes. Cependant, vous aurez besoin d'une adresse IP dédiée si vous devez accepter des navigateurs plus anciens.
Si vous utilisez un CDN, renseignez-vous sur sa compatibilité avec le protocole HTTPS et sa procédure pour passer sur HTTPS.
Si vous utilisez un outil de gestion du cache, renseignez-vous sur sa compatibilité avec le protocole HTTPS et sa procédure pour passer à HTTPS.
Si vous utilisez un CMS (WordPress, Prestashop, Magento, Joomla, Drupal, etc.), renseignez-vous sur sa compatibilité avec le protocole HTTPS.
Faites de même avec chacun des plugins ou extensions installés.
Pensez aussi aux outils tiers comme ceux web analytics, de la publicité (Google Ads, Facebook Ads, etc.), de la conversion, du ecommerce…
Je recommande très fortement de faire un crawl exhaustif de tout votre site HTTP (celui qui est en ligne accessible à tous), avant la migration. Ceci vous permettra d'avoir la liste des URL de toutes les ressources HTTP à tester (voir plus loin).
👋 Vous aurez besoin de cette liste pour utiliser mon astuce d'accélération de la migration dans Google.
Bien sûr, vous avez le sitemap des URL en HTTP, mais êtes-vous certain qu'il soit exhaustif ?
Vous pouvez le faire avec mon outil RM Tech, en activant l'option d'analyse des images.
Vérifiez tous les éléments suivants pour qu'ils utilisent la version HTTPS :
Si vous avez une application mobile, pensez aussi à mettre à jour les liens vers votre site.
Sachez que vous pouvez utiliser des URL relatives au protocole (par exemple, //example.com/script.js au lieu de http://example.com/script.js). L'avantage est que cela fonctionne quelle que soit la version du site (si l'URL qui contient ce code est en HTTPS, alors c'est la version HTTPS de la ressource qui sera utilisée, sinon ça sera HTTP).
💡 Si vous avez besoin de faire des remplacements automatisés en base de données, je vous conseille le script Search Replace DB. Attention, c'est risqué de faire des modifications directement dans la base de données. Mais c'est très efficace…
Pensez aussi aux cookies qui devront être générés de façon sécurisée. Renseignez-vous, vous pourriez avoir besoin de modifier la configuration de votre serveur, par exemple dans le fichier php.ini l'instruction session.cookie_secure = True.
Evaluez si vous allez migrer tout le site en HTTPS ou seulement une partie. Du point de vue de Google et du référencement, cela ne change rien si vous basculez vers HTTPS par étapes, pour certaines parties du site.
Faites un inventaire de toutes les URL qui doivent migrer vers HTTPS. Cette étape est majeure, vous en aurez besoin pour vérifier que tout est OK, aussi bien avant qu'après le passage à HTTPS.
Préparez les redirections de toute URL en HTTP vers son équivalent en HTTPS (fichiers .htaccess ou autres moyens).
Attention, il faut obligatoirement :
Faites la liste de vos comptes de réseaux sociaux pour lesquels vous devrez mettre à jour l'URL de votre site afin d'indiquer la version HTTPS
Faites un audit de vos backlinks pour repérer les plus stratégiques afin de demander aux personnes concernées si elles acceptent de mettre à jour leur lien pour pointer vers votre version HTTPS. Pour les nombreux cas où le lien ne sera pas mis à jour, les redirections 301 que vous mettrez en place seront indispensables.
Faites la liste de vos campagnes publicitaires pour identifier là où il faudra mettre à jour l'URL de votre site afin d'indiquer la version HTTPS.
Préparez-vous à mettre à jour les URL dans vos signatures de mail.
Planifiez la bascule : qui s'occupe de quoi, quand, sur quel environnement, à quelle date ?
Dans la Search Console de Google (idem pour Bing Webmaster Tools et autres moteurs en disposant, par exemple Yandex), prévoyez que vous aurez besoin de faire ceci une fois la mise en ligne effectuée, pour chaque sous-domaine de votre site :
Tester le nouveau site en préprod est impératif (sauf pour un petit site vitrine de quelques pages). Cette étape permet de corriger les erreurs avant la mise en production et donc d'être bien plus serein le jour de la bascule…
Vérifiez que chaque URL de l'inventaire est effectivement redirigée en une seule redirection 301 vers la bonne URL en HTTPS.
Comment faire ? Il vous faut un outil qui teste une liste d'URL (potentiellement des centaines ou des milliers). Vous ne pourrez sans doute pas utiliser un outil gratuit en ligne, ils limitent le nombre d'URL. Mon outil WebRankInfo limite à 1 seule URL…
Vous pouvez utiliser mon outil RM Sitemaps en lui fournissant l'ancien sitemap (celui qui liste des URL en HTTP), ou simplement en faisant un copier-coller de toutes les URL à tester. Vous aurez tout le détail des redirections et des codes HTTP.
Faites un audit technique exhaustif du nouveau site en préprod, sur un serveur de recette.
Tant que vous trouvez des ressources HTTP, corrigez et refaites un test.
Vérifiez que vous ne bloquez pas le crawl (fichier robots.txt) ou l'indexation (balises meta robots) des pages en HTTPS par les robots.
Ce n'est pas le moment de vous tromper ! Mais avec la préparation proposée, tout devrait se dérouler comme prévu. Suivez les étapes post-migration HTTPS, y compris la surveillance dans les mois qui suivent.
Remplacez l'ancien site par le nouveau, ou mettez en prod la version HTTPS comme vous l'avez préparée.
N'oubliez pas de mettre en ligne le code ou les outils qui gèrent les redirections (de http vers https). Conservez-les aussi longtemps que possible, voire indéfiniment.
Comme en préprod, vérifiez que chaque URL en HTTP de l'inventaire est effectivement redirigée en une seule redirection 301 vers la bonne URL en HTTPS.
Tant que ce n'est pas le cas, corrigez votre système de redirections et refaites le test.
N'oubliez pas de tester ce qui se passe avec et sans le sous-domaine www.
Faites un audit technique exhaustif du nouveau site et vérifiez que plus aucun lien ne pointe vers une URL en HTTP.
💡 Pour cela, vous pouvez utiliser mon outil RM Tech : en crawlant le nouveau site HTTPS, on ne doit trouver aucune URL en HTTP. Regardez dans le rapport d'audit généré, vous devez obtenir ceci :
Voici ce qui se passe si vous avez oublié certains liens qui pointent encore vers des URL en HTTP :
Dans le bilan des URL crawlées fourni par RM Tech, on voit ici qu'il y a des URL trouvées en HTTP, ce qui n'est pas bon. Certes, elles sont redirigées en 301, mais il ne doit plus y en avoir du tout.
Testez plusieurs URL significatives avec :
Dans Search Console, pour chaque sous-domaine de votre site :
Remarque : la demande de changement d'adresse dans Search Console n'est pas disponible (pas nécessaire) dans le cadre d'une migration avec seulement un changement de protocole.
Une fois que vous avez mis en ligne le site HTTPS et activé les redirections de HTTP vers HTTPS, il n'y a plus qu'à attendre que Google prenne en compte votre migration. Idem pour les autres moteurs…
Comment faire pour que Google désindexe rapidement le HTTP et indexe rapidement le HTTPS ? La réponse : en fournissant un sitemap des URL en HTTP.
Pourquoi ? Car quand on fournit à Google un sitemap, il a tendance à envoyer Googlebot assez rapidement pour crawler les URL qui figurent dedans.
Cerise sur le gâteau, ça vous aidera aussi à identifier où en est la transition de HTTP vers HTTPS dans l'index de Google.
Concrètement, prenez le fichier listant toutes les URL en HTTP que vous avez constitué pendant l'étape de préparation (ou à défaut le sitemap listant les URL HTTP) déclarez-le en tant que sitemap :
Ensuite, surveillez le rapport Couverture, en filtrant avec ce fichier sitemap, pour voir les URL qui restent indexées et celles qui sont marquées Exclues (car elles sont redirigées).
A lire dans la FAQ : comment savoir si Google a traité ma migration ?
Si vous utilisez Google Analytics pour la mesure d'audience, il y a quelques modifications à apporter.
Passez en HTTPS chaque vue des propriétés concernées. Dans Google Analytics, il faudra configurer chaque propriété et chaque vue en mettant "https://" au lieu de "http://".
Sauf cas particulier, vous ne devriez avoir :
Si vous utilisez AT Internet pour la mesure d'audience, c'est pareil. Allez dans "Outils > Marqueur > [onglet] Code du marqueur > Clic sur le cadenas" pour récupérer le code de suivi (aucune action à valider)
Modifiez le code de suivi (paramètre "xtsd=")
Sauf cas particulier, vous ne devriez avoir :
Vérifiez que votre certificat SSL fonctionne bien, par exemple avec Qualys Lab tool. Testez plusieurs URL de vos différents sous-domaines.
Activez HSTS si votre serveur web le supporte.
Planifiez le renouvellement de votre certificat SSL. Vérifiez que vous avez des alertes dans votre agenda pour vérifier ce renouvellement à chaque échéance.
Mettez à jour l'URL de votre site dans :
Si votre site est dans Google Actualités, prévoyez de remplir ce formulaire de changement d'adresse.
Contactez ceux qui vous font les liens les plus stratégiques pour leur demander de les mettre à jour (même s'il y a très peu de chances qu'ils réagissent).
Surveillez les erreurs indiquées dans Search Console (ainsi que tous les autres rapports), aussi bien dans l'ancienne propriété (HTTP) que dans la nouvelle (HTTPS).
Planifiez un audit technique du site de façon récurrente (toutes les semaines, tous les mois ou trimestres selon l'importance du site pour votre business).
Surveillez l'évolution du trafic (lisez mon article Comment étudier le trafic organic).
Surveillez vos fichiers logs, notamment pour repérer des erreurs inattendues.
Voici les réponses aux questions les plus fréquentes. N'hésitez pas à en poser d'autres en commentaires ou dans le forum.
Je vous recommande d'avoir un serveur de préprod (préproduction ou recette) pour tester la version HTTPS sans mise en ligne accessible au public. Si vous n'en avez pas, testez en local.
Il faut avoir un certificat SSL (gratuit ou pas), préparer la refonte (changer toutes les références aux URL HTTP pour passer en HTTPS, prévoir les redirection), tester en préprod si possible, puis tester une fois le site basculé en HTTPS.
Oui, même s'il n'y a pas de garantie à 100% que Google restera sur la version HTTP, ça sera un signal fort pour Google qu'il doit continuer à indexer la version HTTP. Il faut que vos tests soient rapides (quelques heures maximum).
Renseignez-vous : la plupart des hébergeurs proposent un certificat SSL gratuit (souvent avec Let's Encrypt). Vous pouvez aussi acheter un certificat SSL et l'utiliser sur votre site HTTPS.
Faire la migration par sections (parties de site) est très bien, ça peut aider pour tester, surtout sur les très gros sites. Dans ce cas, commencez par une section non stratégique et attendez quelques semaines avant de conclure.
Le mieux est de consulter le rapport Couverture dans la search console, d'un côté en HTTP et de l'autre en HTTPS. Progressivement, les URL indexées en HTTP vont diminuer au profit des URL en HTTPS. Vous pouvez évaluer si Google indexe encore du HTTP avec la commande site:example.com -inurl:https
Non, car ces pages sont certainement interdites d’indexation et donc non prises en compte dans le SEO. Seules les pages indexées (en HTTPS) peuvent faire profiter au site de cet avantage en termes de référencement naturel sur Google.
Pour Google (et l'impact SEO), vous pouvez choisir n'importe quel certificat "moderne", pris en charge par les navigateurs actuels.
Oui : si le même contenu est accessible à la fois avec l’URL en HTTP et en HTTPS, il est à 2 adresses différentes donc cela génère un problème de contenu dupliqué. Si vous en avez besoin, j’ai écrit un article avec les codes de redirection HTTP/HTTPS qui vous aideront à résoudre ce « duplicate content ». C’est le même genre de problème qu’une page accessible avec et sans www.
Il est probable que vous remarquiez des fluctuations pendant plusieurs semaines. Néanmoins, si vous avez tout préparé et testé, cela ne devrait pas poser de problèmes.
Si une URL en HTTP est redirigée (en une seule redirection 301) vers sa version HTTPS, Google assure qu'aucun PageRank n'est perdu. Cela ne signifie pas que c'est 100% "indolore" d'un point de vue référencement naturel car Google utilise bien d'autres critères que le PageRank.
Cela n'a aucun rapport et vous n'en obtiendrez pas plus qu'avec votre site en HTTP. Google fournit une partie des mots-clés tapés par les internautes dans la partie Analyse de la recherche sur votre Search Console.
Il n'existe pas de commande Google spéciale pour restreindre une requête à un protocole particulier (comme peut le faire par exemple la commande site: pour restreindre à un site ou une partie de site). Mais vous pouvez constater le nombre d'URL indexées dans Search Console, ce qui devrait répondre à votre demande puisque HTTP et HTTPS doivent être déclarés de façon distincte dans Search Console. De façon similaire, vous pouvez aussi avoir ce genre d'informations dans les statistiques sur les fichiers sitemaps.
Non ce n’est pas la peine. En règle générale, il n’y a qu’à mettre à jour la configuration (de vos propriétés et vues concernées) pour indiquer que votre site est en HTTPS, mais il n’y a même pas besoin de changer le code de suivi.
Il n'y a pas de durée ou de fréquence prévue, ça dépend de la taille du site et de la vitesse du serveur lors du crawl. Google migre URL par URL. Pour un petit site c'est fait en quelques heures ou jours, pour les gros ça peut durer des jours ou des semaines.
Non, il faut la conserver ! Gardez-la au moins 1 an afin de vérifier les messages ou rapports que fournit Google. Vous devriez par exemple vérifier que le nombre d’URL indexées tombe à zéro.
Car ils indiquent le nombre de fois où une URL précise (incluant son protocole) a été partagée. Certains compteurs savent additionner les valeurs obtenues dans le passé pour les URL en HTTP avec celles obtenues pour HTTPS.
Pour passer WordPress en HTTPS sur votre propre nom de domaine, vous pouvez suivre toute la méthode présentée ici. Mais si votre site est simple (sans plugins spéciaux ni Custom Post Types), vous pouvez essayer de faire la migration avec une extension.
La plus connue est sans doute Really Simple SSL. Ce plugin WordPress gratuit permet de passer à HTTPS aussi simplement que ça :
Voici les sites de références et les sources d'information officielles (ou pas) que j'ai utilisés pour ce dossier :
Cet article vous a-t-il plu ?
Remarques :
Si vous souhaitez poser une question ou détailler un problème technique, il ne faut pas utiliser le formulaire ci-dessous qui est réservé aux avis. Posez votre question directement dans le forum Gmail de WebRankInfo. L'inscription est gratuite et immédiate.
En postant un avis, vous acceptez les CGU du site WebRankInfo. Si votre avis ne respecte pas ces règles, il pourra être refusé. Si vous indiquez votre adresse email, vous serez informé dès que votre avis aura été validé (ou refusé…) ; votre adresse ne sera pas utilisée pour vous envoyer des mailings et ne sera pas revendue ou cédée à des tiers.
2 commentaires
Bonjour Olivier. Tu dis "Désormais, votre site DOIT être en HTTPS". Tu as des sources pour confirmer cette affirmation ? Est-ce que Google a menacé ou pénalise les sites en HTTP… ? Merci pour ce dossier.
C'est moi qui fais cette affirmation, c'est donc mon avis (je n'ai pas de source officielle à fournir). La raison, je l'ai indiquée en début d'article "Pourquoi migrer en HTTPS ?"
Inscription à la newsletter
Catégories
Consulting SEO
Envie d'améliorer votre référencement ?
Consultant SEO depuis 2003, j'ai une très grande expérience en audit et consulting. Que ce soit pour une demande ponctuelle, pour un audit ou du long terme, je peux vous aider.
WebRankInfo / Tous droits réservés 2022 – Mentions légales – Me contacter
M