Google envoie des notifications d’exploration de Googlebot via HTTP/2

envoie actuellement une notification à certains éditeurs pour annoncer que Googlebot est en train de crawler leurs sites avec le nouveau protocole HTTP /2

Google envoie des notifications d’exploration de Googlebot via HTTP/2

Google a annoncé qu’il envoie des notifications pour faire savoir aux éditeurs que Google a commencé à explorer leurs sites Web avec le protocole avancé HTTP/2.

La notification n’est envoyée qu’à ceux dont les sites ont été mis à niveau.

 

Pourquoi HTTP/2 ?

HTTP/2 (également appelé H2) est un protocole réseau que les serveurs, les navigateurs et les bots peuvent utiliser pour transférer des données à partir d’un serveur.

HTTP/2 est plus efficace que l’ancien protocole HTTP/1.1 et est capable de transférer des données à des taux plus rapides que l’ancien protocole.

L’avantage pour les éditeurs est que cela se traduira par moins de charge serveur, ce qui signifie qu’il y a une diminution de la possibilité d’une erreur (comme une erreur de délai d’attente) lorsque Google explore un site pendant que le serveur est sous une lourde charge.

Un avantage supplémentaire est qu’avec moins de pression, le site sera en mesure de ne pas bloquer les utilisateurs qui accèdent au site.

Un avantage supplémentaire est qu’avec moins de pression, le site sera en mesure de ne pas bloquer les utilisateurs qui accèdent au site.

L’annonce que Google envoyait des notifications a été faite sur Twitter par Google Gary Illyes. Le Tweet disait :

Il suffit d’appuyer sur le bouton pour envoyer un grand nombre de messages aux sites qui ont été acceptés pour le crawl avec HTTP/2. Si quelque chose n’est pas claire, suivez le lien dans le message.

Il a été accompagné d’une capture d’écran d’un exemple d’une notification, montrant à quoi cela ressemble.

 

Il a été accompagné d’une capture d’écran d’un exemple d’une notification, montrant à quoi cela ressemble.

Un autre Tweet a indiqué que l’exploration de Googlebot via HTTP/2 arrive lentement en ligne, pas tout d’un coup.

D’après Gary Illiyes :

Le trafic du crawler H2 est progressivement monté en puissance, ce n’est pas comme si vous avez reçu le message et tout à coup tout le crawl passe à H2. Cela peut prendre quelques jours.

 

Googlebot va-t-il explorer tous les sites éligibles ?

Google déterminera si un site bénéficie de la nouvelle exploration HTTP/2.

S’il voit qu’il n’y a aucun avantage, alors Google peut décider de ne pas utiliser le nouveau protocole HTTP/2.

Selon Google :

Dans nos évaluations, nous avons trouvé peu ou pas d’avantages pour certains sites (par exemple, ceux avec des qps très faibles) lors du crawl sur H2.

Par conséquent, nous avons décidé de passer au crawl via H2 seulement quand il y a un avantage évident pour le site. Nous continuerons d’évaluer les gains de rendement et nous pourrions modifier nos critères de commutation à l’avenir.

Explorer via avec HTTP/2 dépend également de la mise en place ou non de votre serveur pour le gérer. Si vous ne savez pas si votre site peut gérer le crawl via HTTP/2 , faîtes un test sur KeyCDN.

Source : Searchenginejournal

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 nom de domaine en http et https dans Google Search 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 Google Search Console.
  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.