Https et SEO - Tout ce que tu as besoin de savoir

HTTPS  protège la communication entre votre navigateur et votre serveur contre l'interception et la falsification par des attaquants. 

Cela garantit la confidentialité, l'intégrité et l'authentification de la grande majorité du trafic WWW actuel. Tout site Web qui affiche une icône de verrouillage dans la barre d'adresse utilise HTTPS .

Dans cet article, vous apprendrez les éléements suivant expliqué par ahrefs :

• 1. Les bases de HTTP et HTTPS
• 2. Fonctionnement des certificats TLS
• 3. Comment HTTPS aide le référencement
• 4. Comment configurer HTTPS

Tout d'abord, permettez-moi de simplifier et d'illustrer la communication entre le client (navigateur) et le serveur lorsqu'il y a un attaquant entre les deux.

Comme vous pouvez le voir, les attaquants peuvent récupérer des données sensibles comme les informations de connexion et de paiement ou injecter du code malveillant dans les ressources demandées.

Les attaques réseau potentielles peuvent se produire n'importe où avec un routeur ou un FAI non fiable . Tout réseau WiFi public est donc vulnérable à de telles attaques. Heureusement, il semble que le grand public en soit conscient (utilisation croissante des VPN).

Cependant, le fardeau de sécuriser l'expérience de navigation de chacun est et devrait être sur les webmasters.

C'est là que l'adoption de HTTPS entre en jeu.

HTTPS crypte les requêtes et réponses HTTP afin qu'un attaquant interceptant ne voit que des caractères aléatoires au lieu des détails de la carte de crédit, par exemple.

Une analogie avec le fonctionnement de HTTPS serait d'envoyer des objets de valeur dans une boîte à combinaison verrouillée indestructible. Seules les parties d'envoi et de réception connaissent la combinaison et si les attaquants s'en emparent, ils n'entreront pas.

Maintenant, beaucoup de choses se produisent lorsqu'une connexion HTTPS est établie. Principalement, HTTPS s'appuie sur le cryptage TLS (Transfer Layer Security) pour sécuriser les connexions.

La seule façon d'activer HTTPS sur votre site Web est d'obtenir un certificat TLS et de l'installer sur votre serveur. Vous le rencontrerez également en tant que certificat SSL ou SSL / TLS mais ne vous inquiétez pas, c'est la même chose. SSL est encore une terminologie largement utilisée même si nous utilisons tous techniquement son successeur TLS .

Les certificats TLS sont émis par les autorités de certification ( CA ). Le rôle de l' autorité de certification est d'être un tiers de confiance dans la relation client-serveur. Fondamentalement, n'importe qui peut émettre des certificats TLS , mais seules les autorités de certification approuvées publiquement sont prises en charge par les navigateurs.

Vous pouvez vérifier le certificat TLS de chaque site Web et son autorité de certification émettrice en cliquant sur l'icône de verrouillage dans la barre d'adresse de votre navigateur.

Vous pouvez cliquer sur le certificat pour en savoir plus. L'important ici est la ligne «Délivré à:». C'est alors que nous entrons dans différents types de normes de validation pour les certificats TLS , ce qui distingue principalement les certificats gratuits et payants.

DV , OV et EV : qu'est-ce que cela signifie et lequel choisir?

Les certificats TLS gratuits fournis avec votre hébergement et les  plans CDN ne font que la validation de domaine ( DV ). Cela valide qu'un propriétaire de certificat contrôle un nom de domaine donné. Une telle technique de validation de base est assez bonne pour les blogs et les sites Web qui ne traitent pas d'informations sensibles, mais n'est pas idéale pour ceux qui le font.

Les sites Web utilisant un certificat DV TLS semblent sécurisés, mais vous ne verrez pas la ligne «Délivré à:» lorsque vous cliquez sur l'icône de verrouillage.

Le plus commun DV TLS certificat provient d'un but non lucratif CA appelé Crypter Let . C'est ce que la plupart des entreprises proposant des certificats TLS gratuits et renouvelables automatiquement utilisent.

Il n'y a rien de mal avec les certificats DV uniquement, après tout, c'est le seul type de certificat TLS qui peut être automatiquement émis à grande échelle. Cependant, HTTPS n'est aussi puissant que le certificat sous-jacent qui authentifie le serveur auquel vous parlez.

Si votre site Web autorise les connexions ou les paiements, vous devez investir dans un certificat TLS qui offre une validation d'organisation ( OV ) ou une validation étendue ( EV ). Ces deux types diffèrent dans le processus de vérification, l' EV étant plus rigoureux.

Si vous cherchez à en acheter un seul, je vous recommande d'aller directement au certificat EV TLS . C'est le plus fiable et il ne coûte pas beaucoup plus cher que l' OV .

Certificats génériques et SAN TLS

Laissant de côté les normes de validation, passons à une autre catégorie de certificats TLS .

Les certificats génériques et SAN sont utilisés pour sécuriser plusieurs (sous) domaines à la fois. Si vous avez acheté un certificat TLS EV standard pour example.com, vous auriez besoin d'un certificat distinct pour blog.example.com.

Les certificats génériques peuvent sécuriser un nombre illimité de sous-domaines (example.com, blog.example.com, docs.example.com) tandis que les certificats SAN ont également la possibilité de sécuriser d'autres domaines également (example.com, blog.example.com, different.org) ).

Ces types sont combinés avec les types de validation afin que vous puissiez voir toutes sortes de combinaisons lorsque vous parcourez les options offertes par les autorités de certification. Ils vous guideront également tout au long du processus de validation.

Presque tous les avantages du HTTPS sont liés au référencement :

• Signal de classement léger
• Meilleure sécurité et confidentialité
• Préserve les données de référence
• Permet l'utilisation de protocoles modernes qui améliorent la sécurité et la vitesse du site

Signal de classement léger

Google a annoncé  que HTTPS était un facteur de classement léger  en 2014. Cela ressemble plus à un bris d'égalité qu'à quelque chose qui ferait monter en flèche votre classement si les autres variables des facteurs de classement restaient inchangées.

Il s'agit essentiellement de la contribution de Google à une adoption HTTPS mondiale plus rapide .

Meilleure sécurité et confidentialité

Nous en avons déjà parlé. Mais comment est-ce lié au SEO ?

Lorsque vous atterrissez sur un site Web non sécurisé, vous verrez quelque chose comme ceci:

Cela ne crée pas vraiment de confiance, non? Je suis conscient de mon parti pris professionnel, mais je fais personnellement attention à cela et je me fais rapidement une mauvaise première impression si je vois cela sur n'importe quel site Web.

Je suppose que la migration vers HTTPS peut améliorer le temps de séjour  et empêcher le pogo de coller. Bien que ce ne soient que des facteurs de classement théorisés (non confirmés), faire en sorte que les gens `` collent '' lorsqu'ils atterrissent sur votre site Web est quelque chose que vous souhaitez, indépendamment du référencement .

Préserve les données de référence

Si votre site Web est toujours sur HTTP et que vous utilisez des services d'analyse Web comme Google Analytics, j'ai une mauvaise nouvelle pour vous: aucune donnée de référence n'est transmise de HTTPS aux pages HTTP .

Comme la plupart du Web fonctionne sur HTTPS ces jours-ci, la source du trafic de référence (clics sur les liens d'autres sites Web) sera étiquetée comme directe dans la plupart des logiciels d'analyse.

Un inconvénient est que cela rend vos données en désordre et asymétriques. Un autre est que vous ne pouvez pas voir vos meilleures sources de référence, ce qui est une occasion gaspillée de  création de liens pour l'autorité de domaine.

Permet l'utilisation de protocoles modernes qui améliorent la sécurité et la vitesse du site

Sur le papier, HTTPS est plus lent que HTTP en raison des fonctions de sécurité supplémentaires. Cependant, avoir HTTPS est la condition préalable pour utiliser les dernières technologies de sécurité et de performances Web.

En d'autres termes, outre la sécurité, HTTPS permet également à votre site Web d'améliorer la vitesse de sa page  lorsque vous utilisez des protocoles tels que TLS 1.3  et HTTP / 2 . Et en plus d'une meilleure expérience utilisateur, Google considère la vitesse de la page comme un facteur de classement léger similaire au HTTPS. 

Cela dépend de votre scénario.

1. Vous lancez un nouveau site Web

Vous avez gagné à la loterie. Optez pour HTTPS depuis le début et vous n'aurez jamais à vous soucier de HTTP et des erreurs associées à la migration.

Tout ce que vous devez faire est d'avoir un bon fournisseur d'hébergement qui vous guidera tout au long du processus et qui prend en charge les dernières versions des protocoles HTTP et TLS . Une fois que tout est opérationnel, implémentez HSTS  comme dernière étape pour sceller la sécurité.

2. Vous avez déjà un site Web compatible HTTPS

Le fait que vous lisiez cet article me dit qu'il n'est probablement pas configuré correctement. Suivez les conseils de la section suivante  pour rechercher les erreurs courantes.

3. Vous avez toujours un site Web fonctionnant sur HTTP

Il faudra un certain temps pour que tout soit préparé et fait. La complexité de la migration dépend:

• La taille et la complexité de votre site Web
• Quel type de CMS que vous utilisez
• Vos fournisseurs d' hébergement / CDN
• Vos capacités techniques

Bien que je pense que les propriétaires de petits sites Web fonctionnant sur un CMS populaire et un hébergement solide peuvent effectuer eux-mêmes la migration, de nombreuses variables sont en jeu.

Je vous suggère de vérifier la documentation de votre CMS / serveur / hébergement / CDN et de procéder en conséquence - et avec prudence. Il y a beaucoup d'étapes que vous devez exécuter, alors créez ou suivez une liste de contrôle de migration  et n'essayez pas de vous adapter à d'autres activités.

Si tout cela vous semble trop technique, faites appel à un professionnel. Cela vous fera gagner des heures, épargnera vos nerfs et garantira une mise en œuvre pérenne.

Même si vous avez coché toute la liste de contrôle de la migration HTTPS , il est probable que vous rencontrerez toujours des problèmes.

En fait, en 2016, nous avons analysé 10 000 domaines de premier rang pour diverses erreurs HTTPS et constaté ce qui suit:

• 90,9%  des domaines avaient une mise en œuvre HTTPS sous-optimale
• HTTPS ne fonctionnait pas correctement sur 65,39%  des domaines
• 23,01%  des domaines utilisaient des redirections 302 temporaires au lieu de 301 permanentes

Bien que beaucoup de choses aient changé et se soient améliorées depuis, je vous recommande de vérifier les cinq erreurs de migration HTTPS courantes ci-dessous. Cela ne prendra pas longtemps, et la plupart d'entre eux ne sont pas si difficiles à réparer.

Erreur 1: pages HTTP restantes

Tout d'abord, vous devez vous assurer que toutes les pages de votre site sont déjà sur HTTPS .

Vous pouvez découvrir les pages HTTP restantes en explorant soigneusement le site Web. Cela ne devrait pas être nouveau si vous vous en tenez à une liste de contrôle de migration HTTPS . Assurez-vous simplement que le robot dispose de toutes les sources d' URL requises afin qu'il ne laisse pas de pages derrière.

Si vous utilisez le site Audit d'Ahrefs , je recommanderais la configuration suivante:

Une fois l'opération terminée, ouvrez la dernière analyse, accédez à l'Explorateur de pages et appliquez le filtre suivant:

Exportez la liste des URL HTTP et redirigez-les pour terminer la migration.

Erreur 2: pages HTTPS avec contenu HTTP

Cette erreur se produit lorsque le fichier HTML initial est chargé à l'aide de HTTPS mais que ses fichiers de ressources (images, CSS , JavaScript) n'ont pas encore été mis à jour en HTTPS .

S'il s'agit d'un problème sur votre site Web, vous le constaterez à la fois dans la vue d'ensemble de l'analyse et dans le rapport sur les pages internes. Toutes les erreurs, avertissements et notifications dans Site Audit contiennent une description du problème et des conseils sur la façon de le résoudre.

Erreur 3: les liens internes ne sont pas mis à jour vers HTTPS

La non mise à jour de vos liens internes  vers HTTPS entraîne des redirections inutiles. C'est évidemment mieux que d'atterrir sur une page HTTP mais nous avons déjà traversé cette erreur. Il est facile de repérer ces liens et de les corriger.

Vous trouverez ce problème sous le rapport Liens dans Site Audit:

Réécrivez simplement les URL sur https: // et vous avez terminé. Ceci n'est applicable que si vous vous êtes déjà assuré qu'aucune page HTTP n'est laissée en utilisant le conseil sous l'erreur # 1.

Erreur 4: balises non mises à jour vers HTTPS

Il existe deux types de balises que vous utilisez peut-être sur votre site Web et dont les URL doivent également être mises à jour en HTTPS : les balises Canonical et les balises Open Graph.

Les balises canoniques  indiquent à Google ce que vous considérez comme la page la plus fiable parmi un tas de pages similaires ou en double. Faire remarquer qu'une version HTTP peut certainement envoyer un mauvais signal à Google et sera très probablement ignoré.

Si vous utilisez des balises Open Graph  pour optimiser vos publications sur les réseaux sociaux, les  balises URL sont requises par Facebook. Ils doivent être identiques aux URL canoniques.

Pour rechercher des pages avec des balises HTTP canoniques et OG , configurez ce filtre personnalisé dans l'Explorateur de pages:

Encore une fois, tout ce qui reste est de les réécrire sur https: // étant donné une migration complètement terminée.

Erreur 5: redirections ayant échoué

Les redirections peuvent être délicates. Il y a beaucoup de choses qui pourraient mal tourner, des redirections interrompues aux chaînes et boucles de redirection.

Heureusement, il est facile de repérer ces erreurs avec Site Audit. Il vous suffit de consulter le rapport sur les redirections et de passer en revue tous les problèmes.

Après avoir cliqué sur le bouton "Afficher les URL concernées", vous verrez un rapport similaire à celui-ci, juste avec plus de colonnes et de paramètres par défaut:

La meilleure chose ici est que vous verrez vraiment toutes les URL affectées - celles redirigées, celles à l'intérieur de la chaîne de redirection et celles qui pointent vers celles redirigées.

Il y a deux choses que vous devez faire ici.

La première consiste à fractionner les redirections, dans ce cas:

https://blog.example.com/123/> -> Redirection 301 ->> https://example.com/blog/987/

Cela garantirait que tous les backlinks pointant vers https://blog.example.com/123/ et https://example.com/blog/123/ ne seraient redirigés qu'une seule fois. C'est très bien pour les backlinks externes car contacter les webmasters avec des demandes de modification de lien serait très inefficace et assez ennuyeux.

Nous pouvons cependant faire mieux en interne.

Vous devez vous efforcer d'obtenir le moins de redirections. C'est alors que le nombre de colonnes de liens entrants entre en jeu.

Les liens entrants sont des URL qui pointent vers l' URL affectée par la chaîne de redirection. Vous souhaiterez remplacer les liens de ces pages par des URL qui renvoient un code d'état HTTP 200 . Si vous cliquez sur le nombre de liens entrants, vous les verrez tous:

Bien sûr, encore une fois, l'étape suivante consisterait à vérifier les liens entrants des URL au sein de la chaîne de redirection. Cependant, c'est une priorité inférieure car nous avons déjà rompu la chaîne de redirection. Celles-ci seront marquées en tant que redirections 301 standard dans le rapport sur les redirections 3XX lors de la prochaine analyse.

Dernières pensées

J'espère qu'ensemble, nous pourrons rendre la navigation sur le World Wide Web plus rapide et plus sûre.

Selon w3techs.com , 59,4% des sites Web de leur échantillon d'enquête utilisent HTTPS par défaut. En comparaison, Google signale  qu'entre 88 et 99% du temps de navigation dans Chrome est consacré aux sites Web HTTPS .

Ce que je retiens de ces données est que la grande majorité des sites Web populaires avec un trafic considérable sont déjà passés au HTTPS . Si vous vous interrogez sur la grande différence entre ces deux points de données, j'attribuerais cela aux sites Web chinois qui ne sont pas inclus dans les données de Google.

Il reste cependant beaucoup à désirer  en termes de qualité de prise en charge TLS . Comme vous l'avez appris ici, la configuration HTTPS ne se termine pas avec le processus de migration. Suivre les tendances en matière de performances et de sécurité Web et mettre en œuvre les nouvelles fonctionnalités profite à toutes les personnes impliquées.

Avez-vous des questions ou des commentaires? merci