Étiquette : robots.txt

Bing Webmaster Tools lance un nouveau Testeur de robots.txt

a annoncé un testeur amélioré du fichier robots.txt avec de nouvelles fonctionnalités qui améliorent les tests et le diagnostic du fichier robots.txt.

Bing Webmaster Tools lance un Testeur de fichier robots.txt amélioré

 

Le testeur de fichier Robots.txt de Webmaster Tools répond à un besoin important parce que se tromper sur un robots.txt peut entraîner des résultats inattendus. La production d’un fichier robot.txt parfait est essentielle et une priorité absolue pour le référencement.

Un fichier robots.txt est l’une des rares façons dont un éditeur dispose pour exercer un contrôle sur les moteurs de recherche.

Comme le dit Microsoft Bing, depuis l’aube de l’ère du moteur de recherche, les webmasters ont été à la recherche d’un outil fiable et efficace pour favoriser et contrôler leur relation avec les robots web/crawlers /spiders.

Alors que le protocole d’exclusion des robots donne le pouvoir d’informer les robots web et les crawlers quelles sections d’un site Web ne doivent pas être traitées ou scannées, le nombre croissant de moteurs de recherche et de paramètres ont forcé les webmasters à rechercher leur fichier robots.txt parmi les millions de dossiers sur leurs serveurs d’hébergement, les éditant sans conseils et enfin supprimant les Heads alors que le problème de ces crawler indésirables persiste encore.

C’est pourquoi Bing déclare dans son communiqué :

Chez Bing, nous comprenons cette frustration de nos utilisateurs et nous avons donc mis à jour notre nouvel outil Testeur de robots.txt amélioré.

Le testeur de robots.txt aide les webmasters non seulement à analyser leur fichier robots.txt et à mettre en évidence les problèmes qui les empêcheraient d’être crawlés de manière optimale par Bing et d’autres robots; mais, les guide également étape par étape de la récupération du dernier fichier au téléchargement du même fichier à l’adresse appropriée.

Les webmasters peuvent soumettre une URL à l’outil de test de robots.txt et il fonctionne comme Bingbot et BingAdsBot, pour vérifier le fichier robots.txt et vérifier si l’URL a été autorisée ou bloquée en conséquence.

Les webmasters peuvent soumettre une URL à l’outil de test de robots.txt et il fonctionne comme Bingbot et BingAdsBot, pour vérifier le fichier robots.txt et vérifier si l’URL a été autorisée ou bloquée en conséquence.

Non seulement cela, mais la fonctionnalité de test vérifie l’URL que nous avons soumis par rapport au contenu de l’éditeur et donc, une fois que les modifications sont apportées dans l’éditeur, vous pouvez facilement et instantanément retester l’URL pour vérifier les erreurs.

Le système vérifie les instructions autoriser/bloquer pour les agents utilisateurs respectifs et affiche le fichier robots.txt dans l’éditeur avec 4 variantes, c’est-à-dire :

Le webmaster peut modifier le fichier txt et/ou télécharger le même pour être mis à jour hors connexion. S’il y a eu des modifications au fichier robots ailleurs et mis à jour, le webmaster peut utiliser la dernière option Fetch pour obtenir le dernier fichier robots de la propriété.

Le webmaster peut modifier le fichier txt et/ou télécharger le même pour être mis à jour hors connexion.

L’option de téléchargement fournit un processus étape par étape de mise à jour du fichier qui comprend le téléchargement du fichier modifié, le téléchargement du même sur la racine des domaines qui peut être vérifié pour une version en direct et enfin demander à Bing de mettre à jour le même.

Source : Microsoft Bing

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 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.

Google n\'est pas un moteur de recherche selon le Parlement Européen

Selon l’association EDRi qui rapporte l’information, l’Union Européenne vient d’adopter un texte législatif qui établit que n’est pas un moteur de recherche comme nous le pensions tous jusqu’à maintenant.

Google n\'est pas un moteur de recherche selon le Parlement Européen

Ainsi, après deux années de procédures et de négociations entre le Parlement Européen et le Conseil de l’Union Européenne, le texte final adopté signifierait aussi que , et DuckDuckgo ne sont pas des moteurs de recherche.

Rappelons ici que l’EDRi (European Digital Rights) est une association belge qui regroupe 35 organisations de défense des libertés numériques dans 21 pays européens. L’objectif est de lutter pour la défense des droits des citoyens au sein de l’Union européenne en sensibilisant les gouvernements et l’opinion publique.

Alors, pourquoi Google n’est pas un moteur de recherche aux yeux du Parlement Européen ?

Selon la définition adoptée  (PDF) par les députés européens, un moteur de recherche explore tous les sites web, ce que ne ferait pas Google. Selon eux, \ »Google ne recherche pas et/ou n’indexe pas le web obscur (dark web ou deep web) tel que Tor, tout comme il ne visite pas les pages qui lui interdisent l’accès via le fichier robots.txt du site\ ».

Finalement,

en principe dans tous les sites Web

C’est donc l’emploi de l’expression clé “en principe dans tous les sites Web” qui est techniquement ce qui disqualifie tous les moteurs de recherche tels qu’on les connaît aujourd’hui d’être des moteurs de recherche, selon la définition de l’UE.

Car, Google, pour ne citer que lui en tant que leader de la recherche internet, choisirait de ne pas rechercher les sites Web de Tor et serait également en conformité avec les demandes des fichiers “robots.txt”, par lesquels les propriétaires de sites Web demandent au moteur de recherche de ne pas indexer leurs pages.

Comme le note l’EDRi

Google privilégie l\'indexation des pages HTTPS par défaut


Google favorisera les pages HTTPS par défaut

En d’autres termes, le référencement HTTPS devient maintenant la priorité pour Google, après en avoir fait un critère de classement avec un tout petit \ »boost\ » au départ.

Toutefois, les pages HTTP ne seront probablement pas pour l’instant affectées dans les résultats de recherche. Google ne cherche qu’à fournir plus de pages sécurisées dans ses résultats, mais on peut s’attendre à ce que l’étape suivante, comme il l’a fait avec le mobile-friendly, sera de déclasser les pages non-sécurisées.

Ainsi, maintenant, lorsqu’un site web aura deux pages aux contenus identiques dont l’une est en HTTP et l’autre en page sécurisée HTTPS dans ses résultats de recherche. Et ce, mêmes si cette page HTTPS ne bénéficie d’aucune redirection à partir d\’une autre page HTTP.

Comme le dit John Mueller (voir tweet ci-dessus) de chez Google, le référencement HTTPS s\’imposera à long terme.

Mais, pour l\’instant, pour que cette indexation par défaut puisse se faire, certains critères devront être remplis.

Critères de l’indexation du HTTPS par défaut

Comme le dit Google, lorsque deux URL associées au même nom de domaine semblent avoir le même contenu, mais sans avoir le même protocole de diffusion, la priorité sera accordée à l\’URL HTTPS, si cette dernière remplit les conditions suivantes :

  • Elle ne contient pas de dépendances non sécurisées.
  • Son exploration n\’est pas bloquée par un fichier robots.txt.
  • Elle ne redirige pas les internautes vers ou via une page HTTP non sécurisée.
  • Elle ne possède pas de lien \ »rel=\ »canonical\ »\ » vers la page HTTP.
  • Elle ne contient pas de balise Meta \ »noindex\ » pour les robots.
  • Elle ne comprend pas de liens sortants à partir de l\’hôte redirigeant vers des URL HTTP.
  • Le sitemap répertorie l\’URL HTTPS, ou ne mentionne pas la version HTTP de l\’URL.
  • Le serveur dispose d\’un certificat TLS valide.

Donc, en ce qui concerne Google, la version HTTPS de votre site, si vous en avez, sera prioritaire par défaut.

Mais, en ce qui concerne les autres moteurs de recherche, vous pouvez les forcer à considérer vos pages HTTPS comme prioritaires en configurant votre site HTTP de sorte qu\’il redirige vers la version HTTPS équivalente et en mettant en œuvre l\’en-tête HSTS (HTTP Strict Transport Security) sur votre serveur.

Qu’est-ce que le HTTP Strict Transport Security (HSTS)

Le HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (comme un navigateur web), compatible, qu\’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS).

La politique est donc communiquée à l\’agent utilisateur par le serveur via la réponse HTTP, dans le champ d\’en-tête nommé « Strict-Transport-Security ». La politique spécifie une période de temps durant laquelle l\’agent utilisateur doit accéder au serveur uniquement de façon sécurisée.

Ainsi, lorsque la politique HSTS est active pour un site web, l\’agent utilisateur compatible opère comme suit :

  • Si la sécurité de la connexion ne peut être assurée (par exemple, le certificat TLS est auto-signé), celui-ci affiche un message d\’erreur et interdit à l\’utilisateur l\’accès au site à cause de cette erreur.

La politique HSTS aide à protéger les utilisateurs de sites web contre quelques attaques réseau passives (écoute clandestine) et actives. Une attaque du type man-in-the-middle ne peut pas intercepter de requête tant que le HSTS est actif pour ce site.

C\'est quoi le contenu dupliqué pour Google ?

Le contenu dupliqué ou contenu en double est aussi l’un des sujets récurrents du référencement Web abordés par les .

Qu\'est-ce que Google entend par contenu dupliqué ou en double ?

Et ce, en raison du fait qu’il existe différentes sortes de contenus en double dont certains peuvent être pénalisés par et d’autres pas.

Le dernier Hangout de John Mueller sur le “duplicate content”

Par définition, et selon Google

Alors, voici quelques précisions de John Mueller :

  • Le contenu dupliqué touche à peu près tous les sites web, quelle que soit leur taille.
  • Selon John Mueller, le contenu en double, c’est un même contenu sur un même site. C’est aussi un même contenu avec un même chemin d’accès dans des URLs avec et sans WWW.
  • N’est pas un contenu dupliqué un contenu traduit ou adapté à partir d’une autre langue (ce n’est pas une raison pour ne pas citer la source). Il en est de même avec différentes pages ayant un même titre et/ou une même description, ainsi que le contenu dans les applications.
  • John Mueller confirme ce qu’avait déjà dit Gary Illyes en Mars 2015, à savoir que le contenu dupliqué n’est pas en soi une cause de pénalité.
  • Les contenus dupliqués sont une perte de temps de stockage et de ressources serveurs.
  • Si une page est dupliquée, Google ne conserve qu’une seule copie.
  • Un contenu dupliqué pour 2 localisations dans deux pays différents n’est pas une cause de pénalité.

La pénalité de contenu dupliqué est donc un mythe.

Comment gérer les contenus dupliqués

Selon Google, les mesures suivantes vous permettent de résoudre les problèmes de contenu en double de manière proactive et de vous assurer que les visiteurs accèdent au contenu que vous souhaitez leur présenter.

  • Utilisez les redirections 301 : si vous avez restructuré votre site, utilisez des redirections 301 (\ »RedirectPermanent\ »
  • Soyez cohérent :http://www.example.com/page/, http://www.example.com/page ni http://www.example.com/page/index.htm.
  • Utilisez des domaines de premier niveau :

    Google peut supposer que le site ”http://www.example.de”“http://www.example.com/de” ou http://de.example.com.

  • Soyez prudent en diffusant votre contenu :Guest blogging), Google affichera systématiquement la version jugée la plus appropriée pour les internautes pour chaque recherche donnée, qui pourra correspondre ou non à celle que vous préférez.

    notamment en guest blogging) inclut un lien renvoyant vers votre article original.

  • Utilisez Search Console pour indiquer à Google comment indexer votre site : vous pouvez indiquer à Google votre domaine favori (par exemple, http://www.example.com ou http://example.com).
  • Limitez les répétitions :l\’outil de gestion des paramètres
  • Évitez la publication de pages incomplètes :Meta noindex pour bloquer leur indexation.
  • Apprenez à maîtriser votre système de gestion de contenu :
  • Limitez les contenus similaires :

  • rel=\ »canonical\ » ou des redirections 301.

Si votre site a été retiré des résultats de recherche, après avoir apporté les modifications nécessaires et vous être assuré que votre site respectait ses consignes SEO, envoyez une demande de réexamen à Google.

Google demande de ne pas bloquer l\'accès de Googlebot aux fichiers

a commencé à envoyer à de nombreux webmasters des messages d’alerte par email les notifiant de l’impossibilité pour Googlebot, le robot d’indexation de , d’explorer librement certains fichiers. 

Ce qui pourrait impacter le référencement de leurs sites web.

Google envoie des notifications aux sites bloquant l’accès aux fichiers CSS et JavaScript

Ces fichiers généralement mentionnés par Google concernent les CSS et autres JavaScripts qui n’autorisent pas l’accès à leurs données.

Voici un exemple de message reçu par certains webmasters :

Plus particulièrement, Googlebot ne peut accéder à vos fichiers JavaScript ou CSS

Le message d’alerte indique également avec insistance que le blocage des fichiers Javascript et/ou CSS “peut entraîner des classements qui ne soient pas optimaux”.

Alors que Google a fait savoir, après un changement de ses consignes aux webmasters, de ne plus jamais bloquer Googlebot lors de ses visites d’exploration et d’indexation. Notamment via le fichier robots.txt.

Voici d’ailleurs ce qu’il dit dans ses consignes :

Pour nous aider à comprendre le contenu de votre site de manière exhaustive,

Comment découvrir les ressources bloquées par robots.txt

Les ressources bloquées sont aussi mises en évidence dans la section “Index Google” -> “Ressources bloquées” dans votre Console.

Le message d’alerte dans Google Search Console fournit aussi les détails sur la façon de résoudre le problème en proposant toutefois de mettre à jour la règle du fichier robots.txt pour débloquer la ressource.

Et ils sont aussi nombreux, les webmasters qui utilisent , qui ont reçu des avertissements pour avoir utilisé “abusivement” l’instruction “Disallow: /wp-content/plugins” dans leur fichier robots.txt.

Voici les différents types d’instructions qui peuvent générer un message d’alerte dans Google Search Console et par email :

Disallow: /.js$*

Disallow: /.inc$*

Disallow: /.css$*

Disallow: /.php$*

Disallow: /wp-content/plugins

Disallow: /wp-content/cache

Disallow: /wp-content/themes

Disallow: /cgi-bin/

Disallow: /wp-content/uploads/

Disallow: /wp-includes/css/

Disallow: /wp-includes/js/

Disallow: /wp-includes/images/

Ce que demande donc Google dorénavant, c’est qu’il n’y ait plus dans aucun fichier robots.txt d’instructions du type “Disallow: /nomdufichier” ou “Disallow: /nomdurepertoire/”.

Si vous en avez dans votre fichier robots.txt, supprimez-les immédiatement, remplacez-les par \ »Allow: /\ » et le problème sera résolu. Sinon, votre référencement pourrait en souffrir comme Google le mentionne dans ses notifications.

Testez votre fichier robots.txt

L\’outil de test du fichier robots.txt vous indique si votre fichier robots.txt empêche nos robots d\’explorer des URL spécifiques sur votre site.

  1. Depuis la page d\’accueil de la Search Console, sélectionnez le site dont vous souhaitez tester le fichier robots.txt.
  2. Sous l\’en-tête \ »Exploration\ » du tableau de bord de gauche, sélectionnez l\’Outil de test du fichier robots.txt.
  3. Apportez des modifications à votre fichier robots.txt en ligne dans l\’éditeur de texte.
  4. Faites défiler le code du fichier robots.txt pour localiser les avertissements relatifs à la syntaxe et les erreurs de logique signalés. Le nombre d\’avertissements relatifs à la syntaxe et d\’erreurs de logique s\’affiche immédiatement sous l\’éditeur.
  5. Saisissez une extension de l\’URL ou un chemin d\’accès dans la zone de texte en bas de la page.
  6. Dans la liste déroulante à droite de la zone de texte, sélectionnez le user-agent que vous souhaitez simuler.
  7. Cliquez sur le bouton TEST après avoir choisi le robot pour lancer la simulation.
  8. Vérifiez si le bouton TEST indique Acceptée ou Bloquée pour savoir si nos robots d\’exploration peuvent ou non explorer cette URL.

L\'Outil mobile-friendly de Google est le seul à valider la compatibilité mobile d\'un site

Il y a peu, a annoncé faire du site mobile-friendly un facteur de classement. Sur ce, il a lancé son outil mobile-friendly test afin que chaque webmaster puisse bien vérifier que Google accordera à son site le label \ »site mobile\ ».

Testez la compatibilité mobile de votre site avec le mobile-friendly test de Google



avec l\’outil mobile-friendly de Google pour vous rassurer.

Awesome ! This page is mobile-friendly.

Outil de test mobile-friendly

John Mueller et le label mobile-friendly

dénommé PageSpeed Insights afficherait le contraire. Selon, John Mueller, deux raisons à cela :

1. Trop de fichiers bloqués par robots.txt :

2. Cacher des fichiers à Googlebot : Le cloaking (dissimulation de fichiers) fait depuis toujours partie des consignes aux webmasters de Google. Et il provoque toutes sortes de problèmes.

version-Googlebot\ » du contenu exploré (souvent la page desktop) qui est pourtant différente de celle affichée aux utilisateurs sur mobile. Si Googlebot-smartphone explore et voit une page desktop (pour ordinateur), la page ne sera alors pas considérée comme étant mobile-friendly.

Explorer comme Google

site mobile\ » à votre site web.

Quand Google décide-t-il de ralentir ou d\'arrêter l\'indexation d\'un site ?


lors du SMX East de New York

Exploration et indexation par GoogleBot


noindexnofollow\ » ainsi que le fichier \ »robots.txt\ ».

Selon +Gary Illyes

  • Délai de connexion au serveur

  • Les codes de statut HTTP des serveurs : va également arrêter ou ralentir son exploration quand il obtient des codes de statut serveur dans la classe des 500 (500 à 520).

    Les codes d\’erreur 5xx du serveur

Google : Comment gérer les différentes versions d\'un site multilingue ?

+Zineb Ait Bahajji dans son récent post sur Webmaster Central.



  • Montrer à chacun de vos visiteurs le même contenu
  • Offrez la possibilité à vos visiteurs de choisir

Il faut ici noter que Google utilise uniquement le contenu visible de votre page pour déterminer la langue utilisée. .

Qu\’en est-il des contenus dupliqués dans ces cas ?

Selon Google

.

Si vous proposez toutefois du contenu aux mêmes utilisateurs sur des URL différentes (par exemple, si à la fois example.fr/ et example.com/fr/ affichent du contenu en français

Google ajoute les erreurs d\'indexation mobile dans son Webmaster Tools


Dans une annonce sur son blog officiel, Google annonce être aujourd\’hui



Et ce, alors que les utilisateurs sur ordinateurs ne rencontrent pas ces mêmes erreurs.

Sans oublier, comme le mentionne Google, que ces erreurs entravent gravement l\’expérience utilisateur.

Bon, il va y avoir du boulot !

C\’est donc pour participer à l\’identification de ces erreurs que Google a ajouté un onglet dénommé \ »Smartphones\ » dans son Webmaster Tools. Certaines de ces erreurs mobiles reportées dans cet espace concernent :

  • Erreurs de serveurs : qui arrivent lorsque GoogleBot reçoit un code de réponse indiquant une erreur lors d\’une tentative d\’exploration d\’une page web.
  • Erreurs non trouvées et 404 :  lorsqu\’un internaute demande une page qui n\’existe pas, le serveur renvoie une erreur 404 (Introuvable). Ce code de réponse HTTP indique explicitement aux navigateurs et aux moteurs de recherche que la page n\’existe pas.
  • Redirection incorrecte : c\’est une erreur spécifique aux smartphones qui survient lorsqu\’une page web normal redirige les utilisateurs mobiles vers une page incorrecte , et donc non pertinente. Exemple typique : lorsque toutes les pages web redirigent les utilisateurs mobiles du site vers la page d\’accueil du site mobile.
  • URLs bloquées : c\’est lorsque le fichier robots.txt du site interdit explicitement GoogleBot-mobile d\’explorer pour les smartphones. Si vous trouvez un tel message dans votre webmaster tools, vérifiez la configuration de votre serveur et votre robots.txt.

Pour vérifiez vos erreurs d\’exploration sur Google Webmaster Tools, depuis le tableau de bord du site, vous cliquez sur \ »Exploration\ », puis sur \ »Erreurs sur l\’exploration\ ».

Découvrez comment Bien référencer son site internet sur Google
Découvrez comment Bien référencer
son site internet sur Google