É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

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

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

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

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

outil de test du fichier robots.txt

  2. \ »Exploration\ »Outil de test du fichier robots.txt.
  3. é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
  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

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 Google Webmaster Central.

Ainsi, pour reprendre les exemples de +Zineb, si vous travaillez aussi à l\’international, vous devez créer une page d\’accueil pour les visiteurs américains et pour les visiteurs parlant l\’anglais et une page différente pour la France et les visiteurs parlant le français.

Pour créer un site web adapté à ce genre de situations et afficher le contenu approprié aux utilisateurs en fonction de leur langue ou de leur localisation, Zineb Ait Bahajji nous livre 3 méthodes qu\’elle détaille par la suite :

  • Montrer à chacun de vos visiteurs le même contenu : Google recommande que vous affichiez une notification basée sur les préférences de langues possibles à l\’utilisateur pour montrer que vous disposez d\’une meilleure page d\’accueil pouvant mieux lui convenir.
  • Offrez la possibilité à vos visiteurs de choisir : Vous redirigez tous vos visiteurs vers une page spécifique, avec des liens par pays ciblé, où ils pourront choisir le contenu qu\’ils veulent. Si vous utilisez cette option, pensez à utiliser l\’annotation \ »rel-alternate-hreflang x-défaut\ » afin de communiquer à Google ce que vous faites avec cette page et les liens sur la page.
  • Rediriger automatiquement en fonction de la langue et de la localisation : De façon dynamique en affichant le bon contenu ou en utilisant la redirection 302 côté serveur. Si vous choisissez cette option, Google vous recommande de configurer les annotations \ »rel=\ »alternate\ » hreflang=\ »x\ »  et de vous assurer que la page d\’accueil reste accessible pour l\’exploration et l\’indexation de votre site.

    Et surtout, offrez toujours la possibilité aux utilisateurs de passer d\’une langue à une autre, à l\’aide d\’un menu déroulant, par exemple.

Il faut ici noter que Google utilise uniquement le contenu visible de votre page pour déterminer la langue utilisée. Google indique ne pas tenir compte d\’informations linguistiques codées comme des attributs lang.

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

Selon Google, les sites Web qui fournissent du contenu pour des régions différentes et dans des langues différentes génèrent du contenu qui est parfois identique ou similaire, mais disponible sur des URL différentes. Cela ne présente en général pas de problème tant que le contenu s\’adresse à des utilisateurs différents dans des pays différents. Il recommande cependant vivement de proposer du contenu unique à chaque groupe de visiteurs.

Néanmoins, Google dit avoir conscience que cette solution n\’est pas toujours envisageable. Il n\’est généralement pas nécessaire de masquer les doublons en interdisant l\’exploration dans un fichier robots.txt ou en utilisant une balise Meta de robot \ »noindex\ ».

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 pour des utilisateurs en France), vous devez sélectionner une version préférée et rediriger (ou utiliser l\’élément lien rel=canonical) comme il se doit.

En outre, vous devez respecter les consignes sur rel-alternate-hreflang afin de garantir que la langue ou l\’URL régionale correcte est proposée aux personnes effectuant des recherches.

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.

Bon, il va y avoir du boulot !

Smartphones\ » dans son Webmaster Tools. Certaines de ces erreurs mobiles reportées dans cet espace concernent :

  • Erreurs de serveurs
  • Erreurs non trouvées et 404
  • Redirection incorrecte
  • URLs bloquées

Exploration\ », puis sur \ »\ ».

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

Google clarifie l\'utilisation de son outil de suppression de liens

Outil de suppression de liens.

Déjà, 2 semaines après sa mise à disposition, Matt Cutts avait accordé une interview à Danny Sullivan pour apporter des précisions.

Mais, ces dernières semaines, les critiques ont repris de plus belle sur la blogosphère, notamment anglosaxonne.

En Francophonie, c\’est Olivier Andrieu, spécialiste en référencement, qui s\’est fait hara-kiri pour pousser un coup de gueule sur une certaine forme d\’opacité concernant le traitement des demandes de suppression de liens. C\’est vous dire si ce sujet commence à agacer plus d\’un.

C\’est donc dans ce concert de désapprobation de l\’outil de désaveu de liens que, suite à une interpellation sur un forum officiel de Google concernant cette fois l\’outil de suppression de liens, +John Mueller, Analyste des tendances chez Google a posté une contribution sur ce même forum afin d\’essayer de clarifier l\’utilisation de cet outil.

Voici la traduction de son message :

Peut-être quelques éclaircissements peuvent aider à comprendre …

  • L\’outil de suppression d\’URL n\’est pas destiné à être utilisé pour l\’entretien normal d\’un site. Cela fait partie de la raison pour laquelle nous avons une limite quant à son utilisation.
  • L\’outil de suppression d\’URL ne supprime pas les URL de l\’index, il les supprime de nos résultats de recherche. La différence est subtile, mais c\’est une partie de la raison pour laquelle ces soumissions ne changent en rien le nombre d\’URL indexées pour votre site.
  • Le fichier robots.txt ne supprime pas le contenu de notre index, mais dans la mesure où ne ne seront plus en mesure de l\’explorer à nouveau, il ne sera plus visible sur nos pages de résultats.
  • Afin de supprimer le contenu de notre index, nous devons être capable de l\’explorer, et nous devons voir une balise meta robots noindex, ou un code résultat HTTP 404/410 (ou une redirection, etc.).

    Par conséquent, pour pouvoir explorer un contenu, l\’URL ne doit pas être en mode \ »disallow\ » (accès interdit) par le fichier robots.txt.

  • Nous traitons généralement le code 404 de la même manière que le code 410, avec une petite différence qu\’avec le code 410, l\’URL n\’a pas besoin d\’être confirmée par une nouvelle exploration de GoogleBot. Elle est rapidement retirée de notre index.
  • Dans la pratique, ce n\’est pas important mais si vous pouvez utiliser le code 410, faîtes-le afin que le contenu soit supprimé.
  • Pour les changements de site de grande taille, je vous recommande:
    • De ne pas utiliser le fichier robots.txt
    • D\’utiliser une redirection 301 pour le contenu qui a déménagé
    • D\’utiliser un code 410 (ou 404 si vous ne pouvez pas) pour les URL qui ont été retirées
    • De vous assurer que le réglage de la vitesse d\’exploration est réglé sur \ »Laisser Google décider\ » (automatique) dans Google Webmasters Tools, de sorte que vous ne limitez pas l\’exploration de notre robot
    • D\’utiliser l\’outil de suppression d\’URL uniquement pour les questions urgentes ou très flagrantes.

    Jugez-vous ces explications sur l\’outil de suppression d\’URLs assez claires et suffisantes ?