Protocole de transfert hypertexte sécurisé de (HTTPS) est une version chiffrée de HTTP, qui est le principal protocole utilisé pour le transfert de données sur le World Wide Web.
HTTPS protège la communication entre votre navigateur et votre serveur contre toute interception et falsification par des attaquants. Cela confère confidentialité, intégrité et authentification à la grande majorité des WWW trafic.
Tout site Web qui affiche une icône de verrouillage dans la barre d’adresse utilise HTTPS.
Dans cet article, vous apprendrez:
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 non fiable ou FAI. 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 chiffre HTTP les demandes et les réponses 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 la façon dont HTTPS les travaux enverraient 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’y entreront pas.
Maintenant, beaucoup de choses se produisent lorsqu’un HTTPS la connexion est établie. Principalement, HTTPS repose sur TLS (Transfer Layer Security) cryptage pour sécuriser les connexions.
La seule façon d’activer HTTPS sur votre site Web est d’obtenir un TLS certificat et installez-le sur votre serveur. Vous le rencontrerez également en tant que SSL ou SSL/TLS certificat 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.
TLS les certificats sont délivrés par les autorités de certification (Californie). Le rôle de Californie est d’être un tiers de confiance dans la relation client-serveur. Fondamentalement, tout le monde peut émettre TLS mais seulement les autorités de certification approuvées publiquement sont prises en charge par les navigateurs.
Vous pouvez vérifier tous les sites Web TLS certificat et sa délivrance Californie 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 lorsque nous entrons dans différents types de normes de validation pour TLS certificats, ce qui distingue principalement les certificats gratuits et payants.
DV, OV et EV: Qu’est-ce que cela signifie et lequel choisir?
Gratuit TLS certificats fournis avec votre hébergement et CDN les plans 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 suffisante 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.
Sites Web utilisant un DV TLS le certificat semble sécurisé, mais vous ne verrez pas la ligne « Délivré à: » lorsque vous cliquez sur l’icône de verrouillage.
Le plus courant DV TLS le certificat provient d’un organisme sans but lucratif Californie appelé Cryptons. C’est ce que la plupart des entreprises proposent gratuitement et automatiquement renouvelable. TLS certificats utilisent.
Il n’y a rien de mal avec les certificats DV uniquement, après tout, c’est le seul type de TLS certificat qui peut être émis automatiquement à l’échelle. cependant, HTTPS est aussi solide que le certificat sous-jacent qui authentifie le serveur avec lequel vous parlez.
Si votre site Web autorise les connexions ou les paiements, vous devez investir dans un TLS certificat qui offre la validation de l’organisation (OV) ou une validation étendue (EV). Ces deux types diffèrent dans le processus de vérification avec le EV être plus rigoureux.
Si vous cherchez à en acheter un seul, je vous recommande d’aller directement EV TLS certificat. C’est la plus fiable et elle ne coûte pas beaucoup plus cher que OV.
Caractère générique et SAN TLS certificats
Laissant de côté les normes de validation, passons à une autre catégorie de TLS certificats.
Caractère générique et SAN les certificats sont utilisés pour sécuriser plusieurs (sous) domaines à la fois. Si vous avez acheté un standard EV TLS 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) tout en SAN les certificats ont également la possibilité de sécuriser d’autres domaines (exemple.com, blog.exemple.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 de HTTPS attacher à SEO:
- 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 annoncé cette HTTPS est un facteur de classement léger depuis 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 à un monde plus rapide HTTPS adoption.
Meilleure sécurité et confidentialité
Nous en avons déjà parlé. Mais comment est-ce lié à SEO?
Lorsque vous atterrissez sur un site Web non sécurisé, vous voyez 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 le vois sur un 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 de SEO.
Préserve les données de référence
Si votre site Web est toujours activé HTTP et que vous utilisez des services d’analyse Web comme Google Analytics, j’ai de mauvaises nouvelles pour vous: aucune donnée de référence n’est transmise de HTTPS à HTTP pages.
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 représente une opportunité gaspillée de création de liens.
Sidenote.
Si vous êtes intéressé par les erreurs de suivi courantes de Google Analytics, consultez cet article.
Permet l’utilisation de protocoles modernes qui améliorent la sécurité et la vitesse du site
Sur papier, HTTPS est plus lent que HTTP en raison des fonctions de sécurité supplémentaires. Cependant, ayant HTTPS est la condition préalable à l’utilisation des 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 comme TLS 1,3 et HTTP/ 2. Et en dehors d’une meilleure expérience utilisateur, Google considère la vitesse de la page comme un facteur de classement léger similaire à HTTPS:
Au niveau du classement, c’est un tout petit facteur, très similaire au boost de classement https. Celui-là n’est pas surprenant. Vous faites cela principalement pour permettre aux utilisateurs de convertir.— Gary Illyes socialement distant (@methode) 28 avril 2020
Cela dépend de votre scénario.
1. Vous lancez un nouveau site Web
Vous avez gagné à la loterie. Aller avec HTTPS depuis le début et vous n’aurez jamais à vous soucier de HTTP et les erreurs associées à la migration.
Tout ce que vous devez faire est d’avoir un bon hébergeur qui vous guidera tout au long du processus et qui prendra en charge les dernières HTTP et TLS versions de protocole. Après tout est opérationnel, mettre en place HSTS comme la 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
- Quelle sorte de CMS tu utilises
- Votre hébergement /CDN fournisseurs
- Vos capacités techniques
Bien que je pense que les propriétaires de petits sites Web fonctionnant sur CMS et un hébergement solide peut faire la migration lui-même, il y a beaucoup de variables en jeu.
Je vous suggère de vérifier la documentation de votre CMS/ serveur / hébergement /CDN et procéder en conséquence – et avec prudence. Il y a pas mal d’étapes à exécuter donc créer ou suivre une liste de contrôle de migration et n’essayez pas de vous intégrer à 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 à l’épreuve du temps.
Même si vous avez coché le tout HTTPS liste de contrôle de migration, il est probable que vous rencontriez toujours des problèmes.
En fait, en 2016, nous avons analysé 10 000 domaines de premier rang pour divers HTTPS erreurs et a constaté ce qui suit:
- 90,9% des domaines avaient un sous-optimal HTTPS la mise en oeuvre
- HTTPS ne fonctionnait pas correctement 65,39% des domaines
- 23,01% des domaines utilisaient des redirections 302 temporaires au lieu de 301 permanents
Bien que beaucoup de choses aient changé et se soient améliorées depuis, je vous recommande de vérifier les cinq HTTPS erreurs de migration ci-dessous. Cela ne prendra pas longtemps et la plupart d’entre eux ne sont pas si difficiles à réparer.
Erreur 1: HTTP pages 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 restes HTTP en explorant soigneusement le site Web. Cela ne devrait pas être nouveau si vous vous en tenez à HTTPS liste de contrôle de migration. Assurez-vous simplement que le robot dispose de toutes les URL sources afin qu’il ne laisse pas de pages derrière.
Si vous utilisez l’Audit de site d’Ahrefs, je recommande 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:
Exporter la liste des HTTP URL et redirigez-les pour terminer la migration.
POINTE
Les pages qui ne figurent pas dans votre plan du site et qui n’ont aucun lien pointant vers elles sont impossibles à découvrir en explorant. Cela peut souvent arriver avec des PPC pages de destination. Une façon de les trouver consiste à exporter le fichier URL liste de vos gestionnaires d’annonces comme Google Ads ou FB Chef d’entreprise.
À partir de là, assurez-vous que les pages orphelines ont été migrées correctement. Et n’oubliez pas de les mettre à jour dans les tableaux de bord de votre campagne vers la plus récente HTTPS format.
Erreur 2: HTTPS pages avec HTTP contenu
Cette erreur se produit lorsque le premier HTML le fichier est chargé à l’aide HTTPS mais ses fichiers de ressources (images, CSS, JavaScript) n’a pas été mis à jour pour HTTPS encore.
S’il s’agit d’un problème sur votre site Web, vous le constaterez à la fois dans l’aperçu 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
Ne pas mettre à jour vos liens internes vers HTTPS provoque des redirections inutiles. C’est évidemment mieux que d’atterrir sur un HTTP page, 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’aucun HTTP les pages sont laissées en utilisant les conseils sous l’erreur # 1.
Erreur 4: balises non mises à jour pour HTTPS
Il existe deux types de balises que vous utilisez sur votre site Web et dont l’URL doit également être mise à jour HTTPS: Tags canoniques et tags 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. Pointant cela vers un HTTP la version peut certainement envoyer un mauvais signal à Google et sera très probablement ignorée.
Si vous utilisez des balises Open Graph pour optimiser vos publications sur les réseaux sociaux, URL les balises sont requises par Facebook. Ils doivent être identiques aux URL canoniques.
Pour rechercher des pages avec HTTP canonique et OG , configurez ce filtre personnalisé dans l’Explorateur de pages:
Encore une fois, tout ce qui reste à faire 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 statistiques 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 renvoient 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 bien pour les backlinks externes, car contacter des webmasters avec des demandes de modification de liens 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 le URL affecté par la chaîne de redirection. Vous souhaiterez remplacer les liens de ces pages par des URL renvoyant 200 HTTP code d’état. Si vous cliquez sur le nombre de liens entrants, vous les verrez tous:
Exemple de rapport Inlinks dans l’Audit du site d’Ahrefs. Ici, vous devez accéder à l’ensemble de ces quatre pages et modifier leurs liens de https://blog.example.com/123/ à https://example.com/blog/987/.
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, cette priorité est moindre, car nous avons déjà rompu la chaîne de redirection. Celles-ci seraient marquées comme des redirections 301 standard dans le 3XX Redirige le rapport 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, Rapports Google qu’entre 88 et 99% du temps de navigation dans Chrome est consacré à HTTPS sites Internet.
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 à 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 y a encore beaucoup à désirer en termes de qualité de TLS soutien cependant. Comme vous l’avez appris ici, HTTPS la configuration 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? Ping moi sur Twitter.
