Une page qui utilise le protocole sécurisé (HTTPS) bat-elle une page non sécurisée ?

Dans le guide du développeur de Google, il est indiqué que vous devez toujours protéger vos sites Web avec https, même si le site ne traite pas de communications sensibles.

En effet, https permet d’empêcher les intrus d’altérer les communications entre votre site et les navigateurs des utilisateurs, ce qui bloque l’utilisation abusive de votre site.

Puisque Google déclare que tous les sites Web devraient utiliser le protocole https, cela signifie-t-il qu’il l’utilise également comme facteur de classement ? C’est ce que ce test particulier vise à découvrir.

Configuration du test

Pour ce test, 5 pages identiques ont été indexées et la page numéro 3 a été sécurisée à l’aide d’un certificat ssl standard. Les 4 autres pages étaient des pages http.

Résultats

Initialement, un écho de l’ancienne page utilisant http est resté dans les serps. La version sécurisée https de la page est passée en première position tandis que la version non sécurisée de la page était en deuxième position.

Finalement, la version non sécurisée de la page a disparu et la version sécurisée est restée en première position.

Il semble très clair que Google utilise le protocole sécurisé, https, comme facteur de classement.

Avant de procéder au passage de votre site au protocole https, je tiens à vous mettre en garde : lorsque vous passez au protocole https, vous risquez de voir votre classement chuter avant d’en tirer un quelconque avantage.

Une baisse a été signalée par plusieurs membres de la SIA lors du passage au https.

La raison probable de cette baisse est que Google considère le protocole https comme un site différent. Comme vous l’avez peut-être remarqué dans notre test, au départ, les versions sécurisées et non sécurisées de la page s’affichaient, mais finalement, la page non sécurisée disparaissait.

En tant que tel, un plan clair est nécessaire avant de déplacer votre site et notez que la baisse est temporaire.

Nous recommandons d’envoyer de nouveaux liens forts sur le site sécurisé après le changement de protocole.

Commentaires de Clint sur le test n° 44

Découvrez les commentaires et les mises à jour de Clint sur Google et le protocole https comme facteur de classement dans la vidéo ci-dessous.

Test n° 44. Une page qui utilise le protocole SSL est-elle plus performante qu’une page non sécurisée ?

Ce test est en fait plus ancien. Il date de l’époque où Google essayait d’inciter (de forcer) tout le monde à obtenir un certificat SSL.

C’est à peu près au même moment que Let’s Encrypt est apparu. Et cela rendait les certificats SSL gratuits.

C’était un changement important, car les bureaux d’enregistrement faisaient payer des sommes inutilement élevées pour le SSL. Et cela changeait en fonction des normes du SSL que vous vouliez utiliser.

En fait, je pense qu’un grand nombre de ces SSL existent encore aujourd’hui, principalement pour le commerce électronique, ceux qui ont des paniers d’achat et autres.

Ils voulaient s’assurer d’obtenir les meilleurs certificats possibles pour protéger leurs clients.

Du point de vue du classement, lorsque le HTTPS est apparu, c’était un facteur de classement. Google a informé tout le monde que ce serait un facteur de classement.

Et ils savaient qu’en faisant cela, les référenceurs et les praticiens du référencement obtiendraient leurs clients, ou les propriétaires d’entreprises eux-mêmes, iraient de l’avant et tireraient parti de HTTPS afin de bénéficier des avantages du facteur de classement par rapport au simple HTTP.

Je peux vous dire dès maintenant que ce facteur de classement a disparu. Nous classons les pages, HTTP et HTTPS, mélangées dans les moteurs de recherche.

Ils ont changé la donne en vous donnant ce message non sécurisé à l’intérieur des navigateurs maintenant et en pensant que les utilisateurs vont utiliser cela pour faciliter la qualité et la confiance d’un site Web.

D’après mon expérience, cela n’a pas été le cas. Mais tous les navigateurs le font maintenant.

Il y a tellement de messages pour les contenus mixtes. Si votre site est doté du protocole HTTPS et que vous partagez l’image de quelqu’un qui n’utilise pas une URL HTTPS, vous obtiendrez un message de contenu mixte.

C’est une question de sécurité qu’ils soulèvent. Mais en fin de compte, Let’s Encrypt est gratuit. Et si je ne me trompe pas, c’est en fait un programme de Google.

Ils mettent tous ces sites web et utilisent Let’s Encrypt. Cela peut ou non devenir une autre source de données pour Google. Qui sait.

Mais pourquoi est-ce que je partage ça ?

Si je sais qu’ils ne donnent pas beaucoup plus d’avantages ? Ce n’est pas vraiment un facteur de classement maintenant. Pourquoi ? Pourquoi est-ce que je le partage ?

C’est parce que les Core Web Vitals sortent et qu’ils ont suivi exactement le même modèle avec les amplis. Ils ont suivi exactement le même modèle avec le mobile friendly.

Les SEO tombent dans ce piège à chaque fois. ” Oh, Google va nous donner quelque chose de nouveau ! YEA ! Tellement heureux ! [sarcasme]

En fin de compte, ce que Google donne, Google le reprend. Et quand vous vous adaptez et utilisez leurs nouveaux outils, ou utilisez leur mode de web qu’ils pensent vouloir, ils le suppriment simplement parce que tout le monde l’utilise maintenant.

Ils ont accompli ce qu’ils voulaient.

Et je m’attends à ce que Core Vitals suive la même voie.

L’optimisation PageSpeed avec PageSpeed Insights a suivi le même chemin. Tout le monde a commencé à améliorer ses pages, puis l’avantage de l’optimisation de la vitesse des pages a été mis de côté.

À moins que vous ne répariez un site en 10 secondes, et que vous le fassiez charger en deux secondes, vous verrez votre classement s’améliorer.

Sinon, la plupart du temps, les gens ne voient pas d’avantages en termes de classement grâce à l’optimisation de la vitesse des pages.

Ils peuvent obtenir des avantages pour les utilisateurs, mais pas pour les moteurs de recherche.

Je m’attends à ce que les Core Web Vitals aillent dans le même sens.

Ils veulent que vous corrigiez certaines choses comme le fait que la page Web saute un peu de haut en bas lorsque les utilisateurs mobiles y accèdent. C’est ce qu’on appelle le décalage cumulatif de la mise en page.

Ils veulent que la vitesse de chargement commence à être rendue lorsque les gens commencent réellement à interagir avec votre site. C’est une LCP, la plus grande douleur contenue dans les Core Web Vitals.

Ça a toujours existé.

Ils ont juste renommé toutes ces choses qui sont tous des outils qui sont toujours là et qui ont été là jusqu’à la fin, et ils prétendent qu’ils vont changer de manière significative les résultats de recherche pour cela.

Ils vous demandent à tous de le faire. Ils vont le mettre en place en mai. Puis ils vont gâcher les résultats de recherche lorsqu’ils le mettront en place en mai. Pour qu’ils puissent dire, regardez ce qui s’est passé ! Puis ils remettent tout en place et tout le monde revient à la normale.

Tout le monde dans la communauté des résultats de recherche va vous dire, regardez à quelle vitesse vous avez dû avoir votre site web ! Et regardez toutes ces personnes qui en ont profité… Et il y a toutes ces personnes qui ont échoué.

À la fin de la journée, 30 jours plus tard, tout sera inversé parce que Google devra corriger son algorithme qu’ils ont foiré quand c’était vraiment Core web Vitals et sa mise en œuvre.

Donc, il suffit de se préparer à cela.

Si vous êtes nouveaux ici, les gars, vous l’avez entendu ici en premier. Google va donner. Vous allez avoir une légère augmentation lorsque Core Vitals sortira si vous répondez à leur norme.

Ensuite, Google va vous retirer quelque chose.

Lorsque tout le monde répondra à leur norme, ils supprimeront l’avantage de classement d’avoir un site Web super rapide et entièrement végétal. Pour tout le monde.

Personne ne le saura.

Personne ne dira rien.

Personne ne leur dira rien.

Puis il y aura une nouvelle technologie que Google va mettre à jour et vous dire qu’elle va vous donner un avantage auquel vous devez vous adapter.

C’est le cercle de la vie des SEO, malheureusement.