L’User agent ou robot d’exploration des sites est librement configurable pour l’accès HTTP (S). Ce qui signifie qu’il n’y a pas seulement que les « vrais » Googlebots sur Internet, mais aussi des tiers qui espèrent bénéficier de l’appel de leurs robots d’exploration Googlebot. Continuer la lecture de « Google divulgue la liste des adresses IP de Googlebot »
Étiquette : GoogleBot
Google révèle de nouveaux détails concernant l\'index mobile-first
Après avoir annoncé que beaucoup plus de sites allaient migrer
En fait, ce sont 4 précisions qui ont été apportées à l’évolution de ce basculement actuellement en cours:
- index mobile-first :
Contrairement à ce qui a été dit dans le passé, Google a l\’intention de notifier les webmasters via la Search Console lorsqu\’un site a été déplacé vers l\’index Mobile-First.
Google a déjà commencé à basculer des sites vers le nouvel index, donc vraisemblablement la communication est toujours en cours de travail parce que personne n\’a encore été notifié.
Cependant, vous pouvez rechercher les signaux suivants qui peuvent confirmer si votre site a déjà migré :
Images via Searchenginejournal.com - Une augmentation de l\’activité de la version mobile de Googlebot
- Une baisse importante du trafic de votre site via l’ordinateur.
Il ne semble pas que la diminution du trafic via desktop devrait être une source de préoccupation. John Mueller de chez Google dit que personne n\’a remarqué qu\’un nombre important de sites a basculé vers l\’index mobile-First. Cela pourrait indiquer que la perte de trafic est négligeable.
En plus d\’envoyer des messages directs, une annotation sera ajoutée aux 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.
- Basculement des sites individuels qui sont “prêts” :
Google a l\’intention de continuer à déplacer des sites individuels qui sont les plus prêts vers l\’index mobile-First.
Pour comprendre ce que Google 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.
- Le balisage sur les sites mobiles est important :
John Mueller a aussi souligné que le balisage ou l’ajout des balises sur les sites mobiles sera important à l\’avenir, parce que Google ne fera plus référence au balisage de la version desktop d\’un site.
Il en est de même pour le balisage Schema de données structurées.
Cela a été mentionné parce que les développeurs et/ou les propriétaires de sites choisiront parfois de ne pas inclure le même balisage sur la version mobile d\’un site que la version ordinateur.
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.
Quand il y a à la fois une version mobile et une version desktop d\’un site, vous devez inclure le même balisage sur les 2 versions pour vous assurer que Google sera en mesure de le voir.
- Un bon site desktop est mieux qu\’un mauvais site mobile :
Vous n’êtes pas encore prêts pour le mobile first ?
Ce n’est pas une raison de paniquer et bricoler à la hâte un site mobile médiocre. John Mueller dit que si vous avez un bon site desktop, gardez-le tel quel pour l\’instant jusqu\’à ce que vous ayez un site mobile mobile-friendly prêt.
Sachez que la pertinence remplace tout. Si votre contenu est très pertinent pour une requête individuelle, il peut encore être mis en avant dans le nouvel index mobile first, même s’il n\’est pas sur un site mobile-friendly.
Les tout derniers conseils SEO de Google sur l\'index Mobile-First
Google avait annoncé l’année dernière être en train d’expérimenter l’index Mobile-First afin d’utiliser, désormais, les performances de la version mobile du contenu pour le classement de ce contenu tant sur mobile que sur ordinateur.
Pour Google, actuellement, les systèmes d’exploration, d’indexation et de classement de Google regardent exclusivement la version ordinateur (desktop
Le Mobile-First Index signifie alors, d’après Googleen priorité, les utilisateurs du mobile à trouver ce qu’ils cherchent.
Google déclare par la suite :
Les webmasters verront une augmentation significative de l’exploration par le robot “Smartphone Googlebot”, et les extraits dans les résultats, ainsi que le contenu sur les pages de cache Google, seront issus de la version mobile des pages.
Comme Google l’avait dit, les sites qui utilisent le responsive design ou conception adaptable avec le mobile et implémentent correctement la diffusion dynamique (qui inclut tout le contenu desktop et le balisage) .
- Assurez-vous que la version mobile du site a également du contenu important, de haute qualité. Cela inclut le texte, les images (avec les attributs alt) et les vidéos dans les formats habituels et indexables.
- Les données structurées
Elles devraient être à la fois sur la version mobile et la version desktop du site. Assurez-vous que les URL dans les données structurées sont mises à jour vers la version mobile sur les pages mobiles.
- Les métadonnées doivent être présentes sur les 2 versions du site.
- Aucune modification n\’est nécessaire pour l\’interconnexion avec des URL mobiles distinctes (sites m.-dot).
Pour les sites utilisant des URL mobiles distinctes, conservez les éléments du lien existant rel = “canonical” et link rel = “alterner” entre ces versions.
- Vérifiez les liens hreflang sur des URL mobiles distinctes. Lors de l\’utilisation des éléments de link rel = “hreflang” pour l\’internationalisation, liez séparément les URL mobiles et les URL desktop.
Le hreflang de votre URL mobile doit pointer vers les autres versions de langue/région sur d\’autres URL mobiles, et de même, les URL desktop doivent pointer vers d\’autres URL desktop en utilisant des éléments du lien hreflang.
- Assurez-vous que les serveurs hébergeant le site disposent d\’une capacité suffisante pour gérer le taux de crawling (exploration) potentiellement accru.
Cela n\’affecte pas les sites qui utilisent le responsive design et la diffusion dynamique. Sauf les sites où la version mobile est sur un hôte distinct, tels que m.example.com.
Google évaluera les sites indépendamment de leur disponibilité pour l\’indexation Mobile-First basée sur les critères ci-dessus, avant de les basculer dès qu’ils seront prêts. D’après Google, ce processus a déjà commencé pour une poignée de sites et est étroitement surveillé par l\’équipe du Search.
Google avoue cependant être prudent avec le déploiement de l\’index mobile-First.
C’est pourquoi, il pense que faire cela lentement aidera les webmasters à obtenir que leurs sites soient prêts pour les utilisateurs mobiles. Raison pour laquelle, il confirme à nouveau, qu’il ne dispose d’aucun calendrier pour quand tout cela va se terminer.
Comment corriger ou réparer l\'erreur 404 ?
Lorsque les visiteurs suivent des liens hypertextes
Les liens brisés ne sont pas seulement mauvais pour l\’expérience utilisateur
Qu’est-ce que les liens brisés affectent ?
La page d’erreur 404 ne frustre pas uniquement les moteurs de recherche et les utilisateurs. Elle aura aussi une incidence sur votre entreprise elle-même.
- Votre chiffre d’affaires :
En plus de perdre des revenus, vous perdrez aussi des clients. Un client potentiel qui ne trouve pas la page de conversion est une personne qui pourrait faire savoir à son entourage et sur les réseaux sociaux (par exemple) la mauvaise expérience vécue sur votre site.
Et au final, ce n’est pas un seul client potentiel que vous aurez perdu, mais beaucoup d’autres.
Après tout, vous ne voudriez pas perdre votre temps et effort pour créer votre site Web
- Votre taux de rebond :
Le taux de rebond est mesuré par la quantité de temps (durée
va au fil du temps générer un taux de rebond plus élevé.
Lorsque les moteurs de recherche constatent un taux de rebond élevé sur votre page, ils vont brandir un carton rouge
Par conséquent, il est très important de garder les visiteurs satisfaits quand ils visitent votre site en .
- Votre classement Google :
Comme mentionné ci-dessus, le taux de rebond peut provoquer un mauvais classement dans les pages de résultats.
Ensuite, s\’il s\’agit d\’une page non trouvée que Google sait détecter, il pourrait supprimer la page de ses SERPS comme n’étant pas une page crédible et fiable pouvant procurer une bonne expérience utilisateur.
Un autre facteur qui aura une incidence sur votre classement Google, c’est de voir votre page non indexée lors de l’exploration de Googlebot. Google utilise ses robots pour explorer votre site en entier afin de recueillir des informations précieuses sur la thématique de votre page.
Mais quand les crawlers de Google arrivent sur un lien brisé, ils ont tendance à arrêter le processus d\’indexation, ce qui peut ruiner vos chances d\’obtenir un classement plus élevé.
Les liens sortants brisés
Lorsque vous pointez des liens vers d\’autres sites à partir de votre propre site, ces liens sont appelés liens sortants. Limiter ou supprimer tous les liens morts pointant vers des pages externes peut être parfois difficile, car vous n\’avez probablement pas le contrôle sur le contenu externe que vous liez.
Et vous pourriez ne pas savoir que le contenu lié a été supprimé ou déplacé sur le site externe.
Lorsque votre site a des liens sortants brisés, c’est un mauvais signal à la fois pour vos utilisateurs et votre référencement. Googlebot explore le Web en allant de liens en liens pour collecter des données sur chaque page.
Veillez à vérifier régulièrement vos liens sortants pour vous assurer que vous ne redirigez pas les lecteurs (ou les bots) vers les pages brisées.
Comment vérifier et analyser vos liens sortants morts
Si vous avez un petit site, cette vérification des liens morts pourra se faire manuellement via l’extension Chrome “Check My Links” pour examiner manuellement chaque page de votre site et effectuer des contrôles individuellement pour détecter les liens brisés.
Cet outil vous aidera à découvrir à la fois les liens internes (liens de votre propre site) et les liens externes (liens vers d’autres sites) rompus. Gardez l\’enregistrement des occurrences des liens rompus dans une feuille de calcul ou dans un simple documents txt afin de pouvoir revenir plus tard corriger ou supprimer des liens.
Si vous avez un gros site, il ne sera probablement pas possible de vérifier manuellement chaque page pour découvrir les liens brisés. Dans ce cas, il vaut mieux investir dans des vérificateurs de liens morts payants tels que Ahref ou Semrush qui peuvent vous aider à trouver des liens cassés en vrac sur votre site.
Vous pouvez aussi utiliser Broken Link Checker qui est un outil gratuit parfait si vous avez un site de moins de 3000 pages. Au-delà de 3000 pages, une contribution vous sera demandée.
Vous entrez votre nom de domaine, vous sélectionnez “Report distinct broken links only” et vous cliquez sur le bouton “Report distinct broken links only” après avoir saisi le code de vérification affiché.
Le résultat s’affiche au bout de quelques minutes dans un tableau avec, s’il y en a, à la fois les liens internes et les liens sortants brisés. Pour chaque lien brisé par ligne, vous avez la page d\’origine (cliquez sur URL pour le lien de votre page) et de destination (cliquez sur SRC pour le lien de la page pointée).
A vous d’aller le corriger ou le supprimer dans la page d’origine sur votre site.
Liens internes morts et pages d\’erreurs 404
Les liens internes se rapportent à des liens qui vont d\’une page de votre site Web vers une autre page de votre site Web. Ces liens sont ceux sur lesquels vous avez le plus de contrôle.
Une erreur 404 se produit lorsque le contenu de votre site a été supprimé ou déplacé sans aucune redirection appropriée mise en place pour rediriger les visiteurs vers la page correcte.
Il est important de comprendre que l\’une des façons pour les moteurs de recherche d’explorer et indexer les sites est de visiter leurs liens. S\’il y a des liens morts sur votre site Web, ils peuvent arrêter l’exploration de votre site, ainsi que l\’indexation de vos pages.
Et les pages d’erreur 404 encouragent les utilisateurs à quitter votre site et passer au site suivant plutôt que d’y rester en espérant trouver l\’information dont ils ont besoin à partir d\’une page cassée pourtant visitée.
Lorsque les utilisateurs tombent sur des pages inexistantes ou déplacées sur votre site, cela peut affecter votre ratio d’utilisateurs habituels et affecter les taux de conversion de votre site Web.
Pour trouver les pages erreur 404 sur votre site résultant des liens internes cassés, vous pouvez utiliser l’outil Broken Link Check ou l’extension Chrome “Check My Links”, tous deux cités plus haut.
3 façons d\’éviter et fixer les pages d’erreur 404
- Mettez à jour plutôt que de supprimer le contenu : Au lieu de supprimer des pages, essayez de mettre à jour ou actualiser le contenu. Cela permettra d\’éviter les pages 404 indésirables évitables qui peuvent résulter de la suppression du contenu avec lequel d\’autres pages sont en liaison (liens vers votre site).
- La redirection 301 pour envoyer les visiteurs vers une nouvelle page : Si le contenu existe toujours sur votre site, mais a simplement changé d\’emplacement, ou s\’il y a eu une mise à jour de la structure de votre URL, alors redirigez les visiteurs vers la nouvelle page en utilisant la redirection 301.
- Contactez le webmaster et demandez que le lien soit mis à jour : si l\’erreur 404 se produit parce qu\’un site externe à pointer un lien vers votre contenu à l\’aide d\’une URL incorrecte, vous pouvez être en mesure de résoudre le problème en contactant et en demandant une mise à jour à l\’auteur du contenu externe ou au webmaster du site externe.
Alors que Google affirme qu’avoir des pages d’erreur 404 ne nuira pas nécessairement à votre référencement, elles peuvent gravement nuire à l\’expérience utilisateur qui peut entraîner des performances médiocres telles que des taux de rebond plus élevés.
Les moteurs de recherche essaient tant que faire se peut d\’améliorer constamment l\’expérience utilisateur. Alors, une bonne règle de base est que si c\’est mauvais pour l\’utilisateur, ce n\’est probablement pas bon non plus pour votre SEO.
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..
— John ?.o(???)o.? (@JohnMu) 28 mars 2017
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.
Google Search Console introduit le rapport d\'erreurs des pages AMP
pages Accelerated Mobile Page (AMP), Google a récemment proposé aux webmasters qui le désiraient de s’inscrire pour participer au test AMP en avant-première.
Il s’agit pour Google d’obtenir des feedbacks sur la qualité des pages légères pour un affichage rapide des contenus sur mobile.
Et pour aider ces webmasters, et plus tard tous ceux qui auront des pages mobiles allégées, Google vient de lancer le rapport d’erreurs des pages AMP dans Google Search Console (Apparence de la recherche -> Accelerated Mobile Pages).
Quitte aux webmasters de corriger les erreurs éventuelles dans leurs pages Accelerated Mobile Page (AMP) afin qu\’elles puissent être largement diffusées aux mobinautes.
Bien évidemment, pour que ce rapport s’affiche pour indiquer vos erreurs ou pour vous notifier qu’il n’existe aucune erreur, vous devez ajouter le code AMP dans le code source de vos pages web actuelles.
En général, Google aura surtout besoin de rel=amphtml de la page web et rel=canonical de la page AMP pour créer son rapport d’erreurs dans la Search Console, si erreurs il y a.
Le rapport AMP montre que les pages AMP ont été correctement indexées ou les erreurs AMP spécifiques rencontrées lorsque Google analyse les pages AMP trouvées sur votre site.
Les erreurs de connectivité, les liens brisés et les autres erreurs n\’apparaissent pas dans le présent rapport. Les pages mobiles avec des erreurs AMP notifiées dans ce rapport n\’apparaîtront pas dans les résultats de recherche Google avec les fonctionnalités spécifiques à AMP.
A savoir l’affichage dans le carrousel des résultats AMP.
Comment utiliser le rapport AMP ?
Si Google constate qu’il existe des pages de l\’AMP sur votre site, il affichera ultérieurement un graphique des pages AMP avec succès ainsi que les pages avec des erreurs AMP spécifiques.
- Pour voir les erreurs par type : la page de destination du rapport AMP affiche une liste des erreurs AMP par type d\’erreur. Cliquez sur une ligne de type erreur pour voir quelles pages ou URLs ont cette erreur.
- Pour voir toutes les erreurs AMP touchant une page : Ouvrez la page dans l\’outil de test des données structurées.
A cela s’ajoute la date de détection de chaque erreur afin de mieux repérer quand le problème a pu survenir.
Si vous avez corrigé l’erreur mais que cette erreur est toujours indiquée dans le rapport Accelerated Mobile Page (AMP), n\’oubliez pas que Google explore les pages périodiquement.
Vous pouvez attendre la prochaine visite régulière de Googlebot ou vous pouvez demander une nouvelle analyse rapide via l’outil “Explorer comme Google” via Google Search Console.
Si vous pensez soumettre un fichier Sitemap au format XML avec uniquement des liens AMP, ce ne sera pas nécessaire car il pourrait n’être qu’accessible qu\’à Google. Or, tous les services et plateformes participant au projet AMP devront tous avoir accès à la version AMP (Twitter, par exemple, ne connaît probablement pas votre URL Sitemap).
En cas d’erreur signalée dans le rapport AMP et corrigée par vous, Google se fiera à la propriété “lastmod” qui indique la date de la dernière modification de la page pour l’indexer à nouveau si elle dispose du lien alternatif amphtml.
Google entend améliorer et affiner ce rapport d\’erreurs des pages Accelerated Mobile Page au fil du temps.
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 SEO.
Et ce, en raison du fait qu’il existe différentes sortes de contenus en double dont certains peuvent être pénalisés par Google 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
Google Search 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 Google, d’explorer librement certains fichiers.
Ce qui pourrait impacter le référencement de leurs sites web.
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 à cause de restrictions dans votre fichier robots.txt. Ces fichiers nous permettent de comprendre que votre site Web fonctionne correctement. En bloquant l\’accès à ces éléments, il est donc possible que le classement du site ne soit pas optimal.
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, autorisez l\’exploration de tous les éléments de votre site, tels que les fichiers CSS et JavaScript. Notre système d\’indexation affiche des pages Web à l\’aide du code HTML de la page, ainsi que d\’éléments tels que les fichiers images, CSS et JavaScript.
Pour voir les éléments de page qui ne peuvent pas être explorés par Googlebot et pour résoudre les problèmes relatifs aux instructions dans votre fichier robots.txt, utilisez la fonctionnalité Explorer comme Google et l\’outil de test du fichier robots.txt dans les outils pour les webmasters.
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 Google Search 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.
Il semble que depuis quelques jours, Google a augmenté le nombre de messages qu\’il envoie aux webmasters sur les blocages de GoogleBot.
Et ils sont aussi nombreux, les webmasters qui utilisent WordPress, 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.
Car, Google déconseille de restreindre l\’accès à tous les fichiers existant dans votre site afin d\’améliorer leur indexation, notamment pour le mobile, et donc probablement votre classement sur Google.
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.
- Depuis la page d\’accueil de la Search Console, sélectionnez le site dont vous souhaitez tester le fichier robots.txt.
- Sous l\’en-tête \ »Exploration\ » du tableau de bord de gauche, sélectionnez l\’Outil de test du fichier robots.txt.
- Apportez des modifications à votre fichier robots.txt en ligne dans l\’éditeur de texte.
- 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.
- Saisissez une extension de l\’URL ou un chemin d\’accès dans la zone de texte en bas de la page.
- Dans la liste déroulante à droite de la zone de texte, sélectionnez le user-agent que vous souhaitez simuler.
- Cliquez sur le bouton TEST après avoir choisi le robot pour lancer la simulation.
- 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.
Google n\'indexe pas toutes les URL rencontrées durant son exploration
En dehors de tous les liens privés interdisant leur accès pour indexation, Gary Illyes de chez Google vient de faire une déclaration intéressante lors de la SMX Advanced de Seattle (2 et 3 Juin).
Gary Illyes aurait laissé entendre que Google a accès à plus de 30 mille milliards d’URL (en anglais : 30 Trillion) sur le web. Un chiffre qui, selon Barry Schwartz, aurait déjà été révélé par Google en 2013.
Mais, poursuit Gary Illyes, Google n’a pas suffisamment de serveurs pour stocker toutes ces URL. En d’autres termes, ce n’est pas parce que Google connaît l’existence d’un lien pour l’avoir exploré qu’il va forcément l’indexer.
Pendant l’exploration de Googlebot, celui-ci déciderait alors si le contenu visité mérite d’être indexé ou pas.
S’en suit le LiveTweet ci-dessous qui rapporte les propros de Gary Illyes (alias @methode) en disant qu’il y a 30 mille milliards d’URL dans l’index de Google, mais ce dernier n’a pas les moyens de les stocker toutes.
— Travis Wright (@teedubya) 3 Juin 2015
Ce à quoi répond plus tard Gary Illyes par le Tweet ci-dessous pour indiquer que Google connaît l’existence de ce nombre d’URL mais qu’il ne peut effectivement pas les indexer toutes.
— Gary Illyes (@methode) 3 Juin 2015
Bref, ce qu’il faut bien comprendre, c’est que Google ne va pas s’embêter à indexer des contenus qu’il juge complètement inutiles.
Je profite de l’occasion pour vous présenter cet autre LiveTweet ci-dessous:
When Google removed Authorship from search they did not end their interest in authority of authors and publishers – Gary Illyes at #SMX
— Mark Traphagen (@marktraphagen) 3 Juin 2015
Traduction du Tweet selon lequel Gary Illyes aurait aussi déclaré lors de cette même conférence que “lorsque Google avait supprimé l’Authorship
Comprenne qui pourra…
Google n\'exécute pas immédiatement l\'attribut rel=canonical
Selon Matt Cutts, ceux qui publient des contenus similaires ou dupliqués sur des pages différentes devraient utiliser le tag rel=canonical afin de consolider le PageRank de ces contenus et éviter tout problème avec Google.
Seulement, voilà. +John Mueller
Ce qui reviendrait à dire que la page pourrait être indexée telle quelle pendant un certain temps.
Selon John Mueller, Google traite le code rel=canonical comme une simple \ »suggestion\ » et non comme une \ »directive
Il faut donc retenir que l\’attribut rel=canonical
Et, de préférence, utilisez les redirection 301 pour les URL non canoniques.
En effet, il est judicieux de choisir parmi vos URL votre URL favorite (canonique
Vous devez être connecté pour poster un commentaire.