Refonte de site web : le passage au HTTPS

Nous avons eu l’occasion d’effectuer un passage en HTTPS, puis une migration SEO vers une nouvelle version d’un site de e-commerce à 15 jours d’intervalle (contrainte client), cela a réduit la visibilité du site dans les pages de résultats avec différentes versions d’URL dans l’index pour une même page, et ce avec de nombreuses redirections 301 à gérer. Autant donc faire d’une pierre deux coups !

Impact SEO

Le passage en HTTPS est considéré comme un changement de site (en effet, un site peut servir un contenu différent entre HTTP et HTTPS, et ce sur la même URL). Il est donc important de tenir compte du SEO lors de ce changement de protocole : un site qui passerait en HTTPS, sans envoyer de signaux à Google de cette modification (ex : absence de redirections 301) se retrouverait donc dupliqué dans les pages de résultats. 

D'autre part, le crawler de Google peut tester l’accessibilité d’un site en HTTPS, même si ce dernier n’a pas été complètement configuré pour le HTTPS. Si votre page d’accueil répond en HTTPS malgré vous, Google pourra indexer cette page, et même la faire remonter sur la principale requête marque relative à votre site dans ses résultats de recherche.

Mixed content

Cela peut avoir des conséquences catastrophiques : dans le cas où votre site serait configuré pour le protocole HTTP, la version qui répondrait en HTTPS pourrait contenir du « Mixed content » (éléments JS, CSS appelés en HTTP sur une page répondant en HTTPS) ce qui provoquerait le non-chargement de ces ressources, ou l’affichage d’un message d’alerte.

Fig. 2. Alerte du navigateur avec des éléments HTTP appelés sur un document en HTTPS.

L’internaute pourrait se retrouver avec l’affichage de votre page d’accueil, texte noir sur fond blanc, sans aucuns éléments de style, de quoi augmenter le taux de rebond et le faire fuir rapidement. Exemple :

Fig. 3. Exemple du site yapasdequoi.com qui proposerait du mixed content en HTTPS.

Il est donc primordial d’éviter le « Mixed content » et d’envoyer un maximum de signaux permettant à Google de comprendre le passage (ou non) au protocole sécurisé. Pour rappel, l’outil de changement d’adresse proposé par Google (https://support.google.com/webmasters/answer/83106?hl=fr) n’accepte pas le changement de protocole.

Baisse de trafic ?

Dans certains cas, une baisse temporaire du trafic SEO peut être provoquée par le passage au HTTPS. Plusieurs raisons à cela :

• Délai de la prise en compte des redirections 301 par Google ;
• Duplication temporaire entre l’ancien site en HTTP vs HTTPS :
• Nouvelle URL A crawlée sur le site en HTTPS suite à la découverte de celui-ci par Google ;
• Ancienne URL A pas encore recrawlée avec la redirection 301.

Cette baisse de trafic SEO (de 5 à 15% en moyenne quand elle se produit d’après quelques constats) survient surtout sur les sites ayant un fort volume d’URL. Elle peut durer de quelques jours à quelques semaines en fonction du volume d’URL du site connues. Mais dans la majeure partie des cas, la baisse n’est pas forcément visible.

L’idéal est de faire en sorte que Google découvre au maximum les nouvelles URL en HTTPS via les redirections 301. On évitera donc de soumettre trop tôt le nouveau sitemap XML de la version en HTTPS.

Certificat et mise en place

Il sera nécessaire d’acheter un certificat de sécurité auprès d’une Autorité de Certification, pour augmenter le niveau de cryptage, vous pourrez opter pour un certificat wildcard (*.votredomaine.com) si vous souhaitez à terme utiliser d’autres sous-domaines en HTTPS (autres que « www ») sur votre domaine principal.

Il vous faudra faire installer le certificat sur votre serveur et le configurer : votre service IT peut utiliser ce générateur de configuration SSL en fonction du serveur Web utilisé et du niveau de compatibilité souhaité : https://mozilla.github.io/server-side-tls/ssl-config-generator/  

Pour tester la bonne configuration du domaine en HTTPS, voici un outil en ligne qui permet de vérifier un certain nombre de points : https://www.ssllabs.com/ssltest/   

Il existe plusieurs types de certificats :

• Certificat DV (Domain Validated) pour un seul nom de domaine ;
• Certificat OV (Organisation Validated) pour plusieurs noms de domaine ;
• Certificat EV (Extended Validation) proposant d’autres fonctionnalités.

Les certificats OV et EV permettent d’afficher le nom de l’entreprise dans la barre d’adresse. Exemple :

Fig. 4. Affichage du nom de l'entreprise dans la barre d'adresse.

Chacun de ces certificats dispose de ses propres spécificités, mais dans la majeure partie des cas, les certificats de type « Domain Validated » sont amplement suffisants.

Vous pouvez également vous tourner vers des certificats gratuits avec « Let’s Encrypt », mais ce dernier comporte quelques inconvénients (valable 90 jours uniquement, et identification incomplète puisque l’identité du titulaire du site Internet n’est pas vérifiée).

Modifications à prévoir

Voici les modifications à effectuer sur le futur site HTTPS (en préproduction), avant la phase d’ouverture du site en HTTPS à l’indexation. Le principal point d’attention concerne le Mixed Content, à savoir l’appel d’éléments en HTTP à l’intérieur d’une page HTTPS.

Ressources internes

Liens internes

Les liens internes en absolu (ex : <a href= « http://www.votredomaine.com/url »>Lien</a>) devront être mis à jour afin qu’ils pointent vers le HTTPS, cela favorisera la transmission du PageRank ainsi que le crawl vers les URL en HTTPS. Vous pouvez également utiliser d’autres formes de liens absolus :

• Protocole de la page en cours utilisé : <a href="//votredomaine.com/url">Lien</a> ;
• Protocole + domaine de la page en cours : <a href="/url">Lien</a>.

Les liens de type « Menu » souvent présents dans un template pour toutes les pages du site seront a priori simples à modifier. Cependant, la tâche peut s’avérer plus compliquée pour les liens en HTTP insérés au sein des contenus, ils devront être vérifiés et modifiés : un crawl du site en pré-production peut être utile afin de remonter les pages contenant encore des liens en HTTP si besoin (fonction « Search » du crawler Screaming Frog SEO Spider).

Astuce : Un rechercher/remplacer directement dans la table des contenus de la base de données pourra également vous permettre d’effectuer la tâche plus rapidement.

Appel des ressources statiques

Tous les fichiers qui composent vos documents doivent être appelés en HTTPS. Il sera nécessaire de modifier les URL de ces fichiers dans le code source de toutes les pages du site. Une page HTML en HTTPS appelant des ressources statiques en HTTP peut déclencher une alerte sur le navigateur de l’internaute, pouvant aboutir à une sortie du site comme nous l’avons vu précédemment.

Balise Canonical

Pour permettre à Google de mieux comprendre ce passage au HTTPS, nous vous recommandons l’utilisation d’une balise Canonical sur l’ensemble des pages en HTTPS, vers elles-mêmes.

Exemple : dans la page https://www.votredomaine.com/url, il doit y avoir dans la partie <head> du code source la balise suivante :

L’utilisation de ce signal est recommandée par les équipe de Google.

Balisages spécifiques

Il sera nécessaire de mettre à jour les balises relatives aux différents langages de marquage (Opengraph Facebook, TwitterCards, …) présents sur le site. Les balises utilisant les microdonnées (schema.org) peuvent également être passées en HTTPS.

Redirections 301

Des redirections 301 peuvent déjà exister sur le site actuel. Nous vous recommandons de mettre à jour les anciennes redirections 301 pour que celles-ci redirigent directement vers la version HTTPS, et ainsi éviter des chaines de redirections (exemple : redirections anciennes URL en HTTP à nouvelles URL en HTTPS, ou inversement). Les chaînes de redirections sont souvent fréquentes et doivent être limitées dans la mesure du possible.

Ressources externes

Les URL des scripts partenaires/ tiers pouvant être présents dans le code HTML des pages doivent être modifiées afin de passer ces dernières en HTTPS si cela est possible. Cela peut concerner plusieurs types de fichiers : tracking (Google Analytics, Xiti), réseaux sociaux, retargeting, publicité, A/B testing, etc. Tous les appels vers ces scripts externes doivent être faits en HTTPS pour éviter le « mixed content ».

Mise en production

Redirections 301

Afin de rediriger toutes les URL appelées en HTTP vers leur équivalent en HTTPS, il est recommandé d’utiliser une règle dynamique, qui peut varier en fonction des serveurs. Il peut être nécessaire de supprimer les restrictions qui avaient été faites sur le HTTPS (robots.txt, noindex) avant d’activer les redirections 301.

Serveur Apache (.htaccess ou apache.conf) :

Serveur Nginx (nginx.conf) :

Il est également recommandé de placer les règles relatives au passage en HTTPS en fin de fichier, pour ainsi éviter les chaines de redirections avec les redirections déjà en place (ex : ancienne URL en HTTP -> ancienne URL en HTTPS -> nouvelle URL en HTTPS).

HSTS

Si le site passe au HTTPS de façon définitive et sans retour en arrière potentiel, vous pouvez activer HSTS qui permettra aux navigateurs d’appeler directement la version HTTPS de votre site après une première visite (https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security).

Pour cela vous devrez renvoyer l’en-tête http suivante : Strict-Transport-Security "max-age=15768000; includeSubDomains"

Vous pourrez également soumettre votre domaine pour qu’il soit inclus à la liste des sites en HTTPS de Chrome sur https://hstspreload.org.

La mise en place du HSTS vous permettra d’éviter les attaques de type « MITM » (man-in-the-middle) https://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html qui peuvent intervenir lors des redirections 301 du protocole HTTP vers HTTPS.

Outils externes

Une fois la mise en ligne effectuée, il sera nécessaire de s’assurer que la version HTTPS est bien paramétrée dans les différents outils externes. Pour Google Analytics, il faudra mettre à jour l'URL de base par défaut dans les paramètres de propriété et de vue. Il faudra également déclarer la nouvelle version du site en HTTPS dans Google Search Console (nouvelle propriété / compte) pour remonter le plus rapidement possible des informations dans l’interface.

Fichier robots.txt

Le fichier robots.txt de la version HTTP doit également être présent sur la version HTTPS.

Sitemap.xml

Le sitemap.xml doit être mis à jour avec les URL en HTTPS. Attention toutefois de ne pas soumettre ce sitemap juste après la mise en ligne. Il sera préférable de permettre à Google de découvrir les URL en HTTPS via les redirections 301, afin d’éviter la duplication de contenu temporaire : page indexée en HTTP mais pas encore recrawlée vs page découverte en HTTPS et indexée.

Après la migration

Une fois la migration effective, il sera nécessaire de suivre les principaux KPI pour s’assurer que la migration vers HTTPS s’est bien déroulée (crawl, statistiques Google Analytics, erreurs Search Console, exploration et indexation, analyse de logs, positions, etc.). Vous l’aurez compris, les refontes sont souvent l’occasion de passer au HTTPS si ça n’est pas déjà le cas, avec un certain nombre d’éléments à prendre en compte pour conserver son trafic SEO. Ce type de migration ne pose pas de souci majeur en général, si tout est fait «  dans les règles de l'art  ». Encore faut-il que cela soit le cas...