Google Search Console affiche un nouveau look

a déployé un nouveau look pour Google Search Console visant à améliorer l’accessibilité et l’expérience utilisateur. Continuer la lecture de « Google Search Console affiche un nouveau look »

L’outil de test des résultats enrichis permet de choisir un user-agent

Comme on le sait maintenant, les résultats enrichis sont des résultats de recherche qui vont plus loin que le simple lien bleu cliquable.

L\'outil de test des résultats enrichis permet de choisir un user-agent

D’où l’intérêt de l’outil de test des résultats enrichis qui se concentre sur les types de données structurées qui sont éligibles pour être montrés comme des résultats enrichis.

Et vient d’annoncer dans un Tweet qu’il est désormais possible de sélectionner le robot “Googlebot pour smartphone” pour vous préparer à l’indexation orientée mobile.

En d’autres termes :

Nous sommes heureux d’annoncer un nouveau sélecteur pour desktop/mobile au test des résultats enrichis.

La nouvelle fonctionnalité vous aidera à examiner votre implémentation des en utilisant les deux agents utilisateur pour préparer l’indexation mobile-First.

 

La nouvelle fonctionnalité vous aidera à examiner votre implémentation des données structurées en utilisant les deux agents utilisateur pour préparer l’indexation mobile-First.

Google a donc mis à jour son outil de test des résultats enrichis pour permettre de faire des tests séparés sur mobile et desktop.

Et ce choix d’agent utilisateur permet donc ainsi aux propriétaires de sites de tester l’éligibilité des résultats enrichis sur leurs sites soit sur mobile, soit sur ordinateur.

Ce choix d’agent utilisateur permet ainsi aux propriétaires de sites de tester l’éligibilité des résultats enrichis sur leurs sites soit sur mobile, soit sur ordinateur.

Le résultat du test vous indique si « votre page est éligible aux résultats enrichis » et vous montre les éléments détectés sur votre page tels que le champ associé aux liens sitelink, la présence du logo, etc.

Pour rappel, un user agent ou agent utilisateur est une application cliente utilisée avec un protocole réseau particulier.

Les agents utilisateur du Web vont de la gamme des navigateurs jusqu’aux robots d’indexation, en passant par les lecteurs d’écran ou les navigateurs braille pour les personnes ayant une incapacité.

La chaîne « User-Agent » est l’un des critères utilisé pour exclure un certain nombre de pages ou une partie d’un site Web en utilisant le « protocole d’exclusion des robots » (robots.txt).

Ceci permet aux webmasters qui estiment que certaines parties de leur site Web ne devraient pas être incluses dans les données recueillies par un robot en particulier, ou qu’un robot en particulier épuise trop la bande passante, de l’inviter à ne pas visiter ces pages.

 

Se préparer à l’indexation orientée mobile

L’indexation orientée mobile (ou index mobile-first) signifie que Google utilise principalement la version pour mobile d’un site pour l’indexation et le classement.

Auparavant, lors de l’évaluation de la pertinence d’une page par rapport à la requête d’un utilisateur, l’index se référait majoritairement à la version pour ordinateur du contenu de cette page.

Toutefois, comme la plupart des internautes accèdent aujourd’hui à Google via leur appareil mobile, la version pour mobile est à présent celle qui est principalement utilisée par l’index. Et comme le confirme Google, aucun index séparé spécifique n’est créé pour le contenu pour mobile. Nous continuons à n’utiliser qu’un seul index.

Avec l\’indexation orientée mobile, Googlebot explore et indexe principalement les pages avec l’user agent pour smartphone. Google confirme aussi qu’il affichera l’URL la plus appropriée pour les utilisateurs (que celle-ci soit destinée aux ordinateurs ou aux mobiles) dans les résultats de recherche.

Et comme Google l’avait précédemment, il procédera à une transition progressive des sites afin de garantir aux propriétaires et utilisateurs de sites une expérience de qualité.

Il évalue donc chacun des sites individuellement pour voir s’ils sont prêts pour l’indexation orientée mobile, en se basant sur les bonnes pratiques, puis il procède à la transition le moment venu.

Google révèle de nouveaux détails concernant l\'index mobile-first

Après avoir annoncé que beaucoup plus de sites allaient migrer

Google révèle de nouveaux détails concernant l\'index mobile-first

En fait, ce sont 4 précisions qui ont été apportées à l’évolution de ce basculement actuellement en cours:

  1. index mobile-first

    Cependant, vous pouvez rechercher les signaux suivants qui peuvent confirmer si votre site a déjà migré :

    Cependant, vous pouvez rechercher les signaux suivants qui peuvent confirmer si votre site a déjà migré
    Images via Searchenginejournal.com
    • Une baisse importante du trafic de votre site via l’ordinateur.

    rapports de la Search Console pour indiquer quand le site a été déplacé vers le nouvel index. De cette façon, les propriétaires de sites seront en mesure de facilement comparer les données avant et après le basculement.

  2. Basculement des sites individuels qui sont “prêts” :

    déplacer des sites individuels qui sont les plus prêts

    Pour comprendre ce que signifie par “prêt”, regardez ce qui fonctionne dans la recherche mobile en ce moment.

    Un site optimisé pour la recherche mobile sera prêt pour l\'index mobile-First.

    Et donc, un site en responsive design et un contenu AMP auront la préférence de Google.

  3. Le balisage sur les sites mobiles est important :

    Google ne fera plus référence au balisage de la version desktop

    le balisage ou l’ajout des balises sur les sites mobiles sera important à l\'avenir

    Il en est de même pour le balisage Schema de données structurées.

    Par exemple, ils peuvent croire que les balises ALT ne sont pas importantes sur mobile parce que vous ne pouvez pas survoler une image avec un curseur comme vous pouviez le faire sur ordinateur.

    devez inclure le même balisage sur les 2 versions pour vous assurer que Google sera en mesure de le voir.

  4. Vous n’êtes pas encore prêts pour le mobile first ?

    un site mobile mobile-friendly prêt.

    Un bon site desktop est mieux qu\'un mauvais site mobile

8 outils gratuits d’aide au référencement sur Google

référencement sur Google.

8 outils gratuits d’aide au référencement de Google

algorithmes de Google. .

Danny Sullivan à la tête de l’équipe du Search. Mais, chaque update est censée nous emmener tout de même un pas de plus vers des résultats de recherche plus pertinents, après tout.

Cependant, il y a encore un peu de secret derrière exactement comment évalue un site Web et détermine en fin de compte quels sites afficher pour les requêtes de recherche.

Ces outils sont essentiels à votre stratégie de recherche organique, car ils vous permettent de vous concentrer sur les éléments de votre site que Google juge importants.

 

Chrome Lighthouse

Lighthouse est une version \ »Lite\ » (légère

10 mesures qui comptent pour Google.

ici.

 

Google Test My Site

Cet outil va permettre aux webmasters de “tester la vitesse de leur site sur mobile”.

Test My Site vous montrera combien de visiteurs votre site pourrait perdre en raison de votre temps de chargement lent et comparera ce temps de chargement à celui de vos concurrents dans la même thématique que vous.

Testez ici.

 

PageSpeed Insights

PageSpeed Insights fournit maintenant des informations sur la façon dont une page adhère à un ensemble de meilleures pratiques.

En d’autres termes, l\’outil PageSpeed de Google

Cet outil en ligne fournit un score et offre des conseils spécifiques pour accélérer une page Web. Il vous indique quels scripts et feuilles de style ralentissent votre site, dont les images sont trop grandes, et offre de nombreux autres conseils pour accélérer vos pages Web.

Vérifiez votre vitesse de chargement ici.

 

Safe Browsing Test

L’outil Safe Browsing Test

Vous pouvez vérifier l’état de votre site ici.

 

Google Trends

En plus de la recherche organique, Google Trends offrira des données sur les recherches effectuées dans Google News, Google Shopping, Google Images et YouTube.

Google Trends propose donc maintenant plus de données pour montrer ce que les gens dans le monde cherchent le plus sur internet.

La ligne des tendances par période vous montrera à quel point une tendance est stable, si elle monte, baisse ou est statique.

par ici pour Google Tendances.

 

Google Analytics

Certes, nous connaissons tous la frustration des données de mots clés non fournis (not provided), après que Google Analytics a retiré certaines de nos analyses les plus utiles.

données analytiques pour votre site

Google Analytics reste un outil populaire et en constante évolution

 

Google Adwords Keyword Planner

Google Keyword Plannermais ne pas compter sur lui pour des exacts).

Le nouveau planificateur est beaucoup plus concentré sur le PPC (paiement par clic), et donc pour la recherche de mots clés pour les campagnes Google Ads que le Keyword Tool précédent.

Il existe cependant des alternatives intéressantes à Google Keyword Planner.

 

Google Search Console

Si vous ne devez utiliser qu’un seul outil d’aide au SEO dans cette liste, la Search Console de Google sera celui-ci.

Dans la nouvelle Search Console, les utilisateurs vérifiés dans

De quoi l’utiliser régulièrement pour vérifier les performances de votre site et repérer les problèmes plus rapidement :

  1. Vous y découvrirez aussi si votre site a une pénalité manuelle,
  2. Vous identifierez les problèmes d\’analyse et les liens rompus,
  3. Vous verrez le nombre de pages indexées parmi celles que vous avez soumis à Google,
  4. Vous pourrez tester votre fichier robots. txt ou des .
  5. Et beaucoup plus, le tout gratuitement.

C\’est un coup d\’oeil sur la façon dont Google considère les éléments de votre site.

Pendant que vous y êtes, pensez aussi à utiliser Bing Webmaster Tools.

Il y a aussi beaucoup à gagner avec cet outil gratuit pour checker les performances de votre référencement sur Bing.

L\'index Mobile First de Google est en test dans les résultats de recherche

John Mueller de chez vient de confirmer dans un Hangout pour que Google est actuellement en train d’expérimenter son index mobile first en live dans les résultats de recherche mobile.

L\'index Mobile First de Google est en cours de test grandeur nature

Il n’a cependant pas indiqué dans son propos le pourcentage des internautes qui utilisent Mobile et qui voient ces résultats du test en live.

Ce qui voudrait aussi dire que tous les sites ayant une version mobile-friendly sont actuellement susceptibles de s’afficher dans les résultats de recherche mobile des testeurs choisis par Google.

Avec ce test, Google ne cherche uniquement pas à savoir comment l’index mobile first impacte les résultats actuels et influencent le comportement des utilisateurs. Mais, il construit aussi de nouveaux classifieurs en vue des prochains débogages.

D’après Barry Schwartz de Seroundtable, John Mueller a expliqué que ces classifieurs internes sont conçus pour labelliser et différencier les sites Web qui ont une version ordinateur équivalente pour les pages mobiles affichées et ceux qui n’en ont pas.

Ces notifications pourraient alors se faire soit via un article sur le blog officiel de Google, soit via des messages dans la Search Console et d’autres moyens.

Et, une fois de plus, aucune date précise n’a été donnée par John Mueller quant à la généralisation de l’index mobile first côté utilisateurs.

Voici la transcription intégrale du commentaire de John Mueller (vidéo : 15:38) :

Nous devons vraiment voir ce qui se passe

À un moment donné, il peut y avoir des aspects [du déploiement de l’index mobile first

Rappelons que l’index mobile first va permettre à Google d’indexer prioritairement la version mobile d’un site et le classement de ce même site sur mobile sera aussi utilisé pour son classement lors des recherches sur ordinateur.

Google : Pas de backlink ? Pas d\'indexation de votre contenu

Google : Pas de backlink ? Pas d\'indexation de votre contenu

Sauf, comme le précise Barry Schwartz, si vous utilisez la fonctionnalité “Explorer comme Google” ou la fonctionnalité “Sitemap” depuis la Search Console pour indiquer à Google l’existence de l’URL de votre contenu.

Et bien évidemment, en dehors de ces 2 options de Google, si votre URL ne reçoit aucun backlink, Google dit ne pas être en mesure de la découvrir, quelle que soit la méthode d’exploration utilisée..

Une façon pour John Mueller de dire que recevoir des liens entrants facilite aussi l\’indexation du contenu, tout comme les backlinks facilitent aussi la découverte de votre contenu par les internautes qui parcourent le Web de pages en pages.

Ceci étant dit, si vous avez soumis un fichier Sitemap au format XML à Google via la Search Console (Exploration -> Sitemaps), il n’y a pas de raison qu’il ne découvre pas les URL de vos nouveaux contenus.

A condition toutefois de ne pas avoir bloqué Googlebot.

WordPress : 20 Pirates s\'amusent à infecter et supprimer des pages

WordPress qui n’ont pas encore appliqué le récent correctif concernant une vulnérabilité critique.

WordPress : 20 Pirates s\'amusent à infecter et supprimer des pages

Il s’agit d’une affaire tellement sérieuse que a commencé à avertir certains webmasters de blogs , via la Search Console et par email, qu’il a découvert une faille de sécurité sur leurs blogs WordPress, avant de leur conseiller de les mettre à jour.

Alors, de quoi s’agit-il ? Tout est en rapport avec la version 4.7.2 de WordPress récemment lancée.

Informations sur la vulnérabilité de l’API REST

Le 26 janvier dernier, WordPress publié la version 4.7.2 dans laquelle figurait un correctif de sécurité pour une vulnérabilité critique qui permet aux pirates de modifier le contenu sur un site WordPress.

Ils n’avaient pas en ce moment là annoncé l’existence d’un correctif très important afin que les pirates ne soient pas conscients de la vulnérabilité pendant que le mécanisme de mise à jour automatique de WordPress aient mis à à jour les sites vulnérables.

Le correctif de sécurité caché, jusque là, a finalement été révélé le 1er février 2017, soit 6 jours plus tard, une période au cours de laquelle les pirates avait déjà pris connaissance de l’exploit ou faille de sécurité.

À cette période là, un grand nombre de sites Web WordPress avait déjà migré vers la version 4.7.2 (la plus récente).

Et, comme il fallait s’y attendre, à compter du 3 Février, les services de sécurité informatique ont commencé à constater une multiplication des attaques ciblant la vulnérabilité de l’API REST.

Une API compatible RESTGET), placer (PUT), publier (POST) et supprimer (DELETE) des données.

La vulnérabilité, située dans l’API REST de la plateforme, permet donc, selon Computerworld.com, à des attaquants non authentifiés de modifier le contenu de n’importe quel article ou page d’un site WordPress.

La faille a été corrigée dans la version WordPress 4.7.2, sortie le 26 janvier, mais l’équipe de WordPress ne divulgue pas publiquement l’existence de la vulnérabilité avant une semaine plus tard, afin de permettre à un grand nombre d’utilisateurs d’avoir le temps de déployer la mise à jour.

Cependant, même après que la faille soit devenue publique, beaucoup de webmasters n’avaient pas encore décidé d’appliquer le patch. Et il s’en est suivi une vague impressionnante de piratages des sites et blogs WordPress non mis à jour.

Le lundi 6 Février, l’entreprise de sécurité Web dénommée Sucuri a signalé qu’environ 67.000 pages avaient été effacées dans les 4 vagues d’attaques distinctes contre des sites WordPress.

Depuis lors, le nombre de pages supprimées a augmenté de plus 1,5 millions et il y a 20 signatures d’attaques différentes, selon les de Feedjit, l’entreprise derrière le plugin WordPress de sécurité Wordfence.

Le nombre de sites uniques touchés était alors estimé à environ 40.000, en considérant toutefois qu’un site peut avoir plusieurs pages corrompues ou supprimées.

Le Jeudi 9 Février dernier, le PDG de Feedjit a publié un autre post pour dire :

En 48 heures, nous avons constaté plus de 800.000 attaques exploitant cette vulnérabilité spécifique à travers les sites WordPress que nous surveillons.

Bref, l’heure est grave. Vous devez donc comprendre que si WordPress vous propose une version récente, vous devez absolument migrer votre site vers cette nouvelle version.

Car, les pirates profitent justement du temps d’attente de nombreux webmasters, et donc de la mise à jour souvent tardive et non immédiate, pour sévir et compromettre les sites WordPress.

connaissent déjà la faille de sécurité que permet de corriger chaque nouvelle version de WordPress

Alors, si ce n’est pas encore fait, téléchargez la version 4.7.2 de WordPress et mettez à jour votre site ou blog.

Google supprime l\'opérateur link:votredomaine.com

Google demande aux webmasters et autres référenceurs internet d’arrêter d’utiliser l’opérateur de recherche “link” qui est désormais officiellement “mort”.

Google supprime officiellement l\'opérateur link:votredomaine.com

C’est ce que déclare Searchengineland.com qui aurait reçu officiellement confirmation de la part de , et la suite de cet article vous le démontre aussi.

Continuer à utiliser la commande \ »link:www.VotreNomdeDomaine.com\ » vous affichera au fil du temps () des résultats non pertinents ou approximatifs, pour ne pas dire des résultats erronés.

Mais, en termes de référencement, la commande \ »link:VotreNomdeDomaine.com\ »

Et certains webmasters ont pris l’habitude de se servir de cette commande pour comparer le nombre de backlinks entre 2 ou plusieurs sites ou pages. Car, comme pour toutes les recherches sur Google, le nombre total de résultats (et donc de backlinks potentiels

Déjà au mois de Février 2016, des doutes subsistaient quant à la continuité de cet opérateur \ »link:www.VotreNomdeDomaine.com\ ». Mais, Google avait confirmé que l’opérateur link restait toujours valable sur .

Mais voilà, John Mueller de chez Google vient de répondre à un webmaster en lui recommandant de ne plus utiliser l’opérateur de recherche link.

via Google

des outils SEO tiers ou aller dans votre espace Google Search Console pour avoir une idée sur vos backlinks.

36 Conseils pour passer sans faute de HTTP à HTTPS ?

Depuis que a annoncé qu’il allait commencer à utiliser le HTTPS comme un signal de référencement, de nombreux sites Web ont commencé à migrer vers HTTPS.

Checklist pour migrer HTTPS

Et ce, non seulement pour des raisons de sécurité, mais aussi pour bénéficier du boost supplémentaire dans le classement dans les pages de résultats de Google.

Néanmoins, même si Google a publié les meilleures pratiques pour passer de HTTP à HTTPS, la réalité est que, dans de nombreux cas, elles ne sont pas suivies.

Ou encore certaines étapes sont manquées puisqu’il y a tant de différents domaines impliqués, ainsi que des vérifications et validations à faire avant, pendant et après le passage au .

Par exemple, Gary Illyes, Webmaster Trends Analyst chez Google, a publié un Tweet pour quelques rappels utiles appelant à vérifier et modifier le suivi et les scripts des annonces pour éviter tout blocage :

La vraie question lors d’un passage du HTTP au HTTPS n’est vraiment pas une absence totale de connaissance des webmasters, car, même si les gens connaissent certaines bonnes pratiques à prendre en considération, le problème est souvent plus dû à un manque de ressources complètes avec toutes les validations, spécifiant quand les mettre en œuvre.

Ce qui pourrait être facilement partagé et suivi par toutes les parties impliquées dans la migration, et qui sauraient dès le début quand faire quoi, afin de planifier les bonnes ressources au moment opportun.

Voici donc une checklist HTTPS qui vous indique les tâches à accomplir avant, pendant et après la migration.

 

Comment démarrer le passage de HTTP au HTTPS ?

 

  1. Certificat SSL : Achetez, configurez et testez le certificat sécurisé SSL/TLS à l’aide de SHA-2 pour SSL sur le serveur.
  2. Enregistrez et validez à la fois le en http et https dans Console, et dans les versions avec www et sans www. Si vous avez également enregistré des sous-domaines ou des sous-répertoires dans la Search Console, répliquez ces enregistrements et ces configurations avec leur version https.
  3. Installez et commencez le suivi des classements en parallèle avec le HTTPS du nom de domaine dans vos outils SEO ou logiciels de tracking.
  4. Identifiez les meilleures pages du site dans la Search Console et dans Google Analytics, ainsi que les requêtes connexes, qui vous assurent la visibilité organique et le trafic. Vous en ferez une priorité lors de la validation et du suivi référencement et des performances du site.
  5. Analysez la version HTTP du site afin d’identifier et corriger tous les liens internes brisés, ainsi que la structure actuelle avant migration.
  6. Configurez la nouvelle version du site Web afin de la modifier, tester et mettre à jour les liens dans un environnement de préparation, pour les pointer vers des URLs (pages et ressources telles que les images, js, pdfs, etc.) avec HTTPS.
  7. Mettez à jour les balises canoniques (rel=”canonical”) pour inclure des URLs absolues utilisant le protocole https.
  8. Vérifiez que toutes les réécritures et redirections déjà existantes (avec ou sans www, avec ou sans slash (barre oblique), etc.) sont également implémentées dans la version HTTPS comme elles ont l’habitude de fonctionner sur le http.
  9. Préparez et testez les règles de réécriture des redirections 301 de toutes les URL existantes identifiées (pages, images, js, etc) sur le nom de domaine http vers le https, sur le serveur.
  10. Générez un nouveau fichier Sitemap au format XML avec les URLs pour HTTPS afin de le télécharger dans la version HTTPS du nom de domaine dans la Search Console, une fois que le site aura été déplacé en HTTPS.
  11. Préparez le fichier robots.txt qui sera téléchargé sur la version HTTPS du nom de domaine lorsque le site sera déployé en répliquant les directives actuelles de la version HTTP, mais en pointant vers les URLs HTTPS si nécessaire.
  12. Préparez les modifications sur toutes les campagnes publicitaires, d’emailing ou d’affiliation pour commencer à les pointer vers les versions HTTPS des URLs dès que la migration sera faite.
  13. Vérifiez si des demandes de désaveu de liens ont été soumises par le passé afin de les soumettre à nouveau pour les versions HTTPS des URLs via la propriété du nom de domaine en HTTPS dans .
  14. Si vous migrez un gTLD (nom de domaine de premier niveau) que vous ciblez géographiquement via la Search Console (autant que ses sous-domaines ou sous-répertoires, au cas où vous les ciblez géographiquement de façon individuelle), assurez-vous de les ciblez à nouveau géographiquement avec la version HTTPS du nom de domaine.
  15. Si les paramètres des URLs sont gérées via Google Search Console, la configuration existante doit être répliquée dans le profil ou propriété HTTPS du site.
  16. Si un CDN (Content Delivery Network) est utilisé, vérifiez qu’il sera en mesure de bien servir la version du nom de de domaine du site en HTTPS et gérer le SSL lorsque la migration sera effective.
  17. Vérifiez que tous les codes des annonces publicitaires servies, les extensions tierces et les plugins sociaux utilisés sur le site fonctionneront correctement lorsqu’ils seront déplacés dans le HTTPS.
  18. Assurez-vous que la configuration existante de Web Analytics surveillera également le trafic du domaine HTTPS.

Comment vérifier pendant la migration vers HTTPS ?

 

  1. Publiez la version HTTPS du site en ligne (en mode production).
  2. Vérifiez que la structure des URLs sur la version HTTPS du site est la même que celle de la version HTTP.
  3. Vérifiez que les liens du site pointent effectivement vers les bonnes URLs HTTPS.
  4. Vérifiez que la balise canonicale (rel=”canonical”) dans le header des pages pointent également vers les bonnes URLs HTTPS.
  5. Vérifiez que la nouvelle version HTTPS canonique implémente les réécritures et redirections des versions avec ou sans www, avec ou sans slash à la fin, etc, dans la nouvelle version HTTPS.
  6. Mettez en place les redirections 301 de chaque URL du site depuis HTTP vers sa version HTTPS.
  7. Annotez la date de la migration dans votre plateforme de Web Analytics et vérifiez que la configuration a été bien définie pour suivre les performances de la version HTTPS.
  8. Vérifiez que la configuration SSL de votre serveur Web est correcte. Vous pouvez utiliser un service tel que SSLLabs pour la tester.
  9. Actualisez les paramètres du fichier robots.txt dans le nom de domaine en HTTPS avec les modifications pertinentes.

Les vérifications après passage au HTTPS

 

  1. Analysez le site pour vérifier que les URLs HTTPS sont celles qui devraient être accessibles, liées et servies sans erreurs, sans noindex erronées ni redirections ni balises canoniques erronées.
  2. Vérifiez que les règles de redirection de http et https, avec www et sans www, avec slash et sans slash sont correctement mises en œuvre.
  3. Téléchargez et vérifiez le fichier sitemap XML généré avec les versions d’URL HTTPS dans la propriété HTTPS (du nom de domaine) de Google Search Console.
  4. Mettez à jour, tant que peut se faire, les liens externes (backlinks) pointant vers le site avant de bien vérifier qu’ils sont redirigés vers la version HTTPS.
  5. Vérifiez que les plugins, ainsi que les boutons sociaux, annonces et extensions tierces fonctionnent correctement dans les versions HTTPS des URLs. Vous pouvez scanner votre site pour vérifier s’il existe encore du contenu non-sécurisé avec JitBit.
  6. Mettez en place les modifications pertinentes des campagnes publicitaires, d’emailing et d’affiliation pour qu’elles soient correctement redirigées vers la version Web HTTPS du site.
  7. Surveillez l’exploration, l’indexation, la visibilité et les erreurs des deux versions HTTP et HTTPS du site. Car, vous ne devez en aucun cas supprimer la version HTTP.
  8. Surveillez le trafic des versions HTTP et HTTPS du site, ainsi que leurs classements.
  9. Vérifiez les paramètres du fichier robots.txt dans le nom de domaine en https pour vous assurer que la configuration a été correctement mise à jour.

En principe, avec toutes ces consignes d’implémentation et de migration vers un hébergement sécurisé via HTTPS, vous devriez faire un sans faute.

Mais, il est également important de mentionner qu’une fois que vous déplacez votre site vers votre serveur HTTPS, vous pourriez considérer servir les pages via HTTP/2.

En effet, HTTP/2 (nommé initialement HTTP/2.0) est une version majeure du protocole réseau HTTP utilisé sur le World Wide Web. Il est issu du protocole expérimental SPDY (à prononcer comme le mot anglais speedy) développé par Google.

Pour la petite histoire, sachez que HTTP/2 ne demande pas de modification des applications web existantes, un effort ayant été apporté sur la rétro-compatibilité avec HTTP 1.1. Mais les applications webs existantes ou futures peuvent être développées pour bénéficier des nouveautés proposées notamment pour les gains de vitesse de transmission.

HTTP/2 conserve la majorité de la syntaxe de HTTP 1.1, comme les méthodes, les codes, les URI ou les headers. Un élément a été modifié : la manière dont la donnée est segmentée et transportée entre le client et les serveurs. Ce qui n’a pas d’impact sur les applications existantes.