Indexation mobile first et negative SEO : Google répond à vos questions
Pourquoi retrouvons-nous encore du "GoogleBot classique" en User Agent sur un site passé en mobile first ?
Vincent Courson. Pour la même raison que l'on trouvait déjà des explorations faites avec le user-agent Googlebot smartphone bien avant le passage à l'Index Mobile-First !
De manière générale, Google peut accéder à un site avec de nombreux user-agent différents en même temps, pour y accomplir un certain nombre de tâches. Les user-agents ne sont pas mutuellement exclusifs ("si on crawle avec le user-agent A, alors on ne peut pas crawler avec le user-agent B"). Certains de ces crawls n'ont d'ailleurs rien à voir avec la recherche organique : par exemple Google va parfois vérifier le fichier robots.txt d'un site inclus dans Google News (user-agent Googlebot-News) ou encore vérifier des landing pages de campagnes Google Ads (user-agent AdsBot-Google).
Pour ce qui est de la recherche naturelle, le but du crawl d'une page est de comprendre le contenu qui sera affiché lorsque l'utilisateur navigue vers la page en question. Et cet affichage pouvant être différent en fonction de l'appareil utilisé, Google tente de comprendre ce contenu pour différents appareils : le crawl "historique" pour les desktops, et le "nouveau" crawl mobile, pour les smartphones.
Historiquement, un site pouvait déjà être crawlé avec un user-agent mobile, car Google voulait voir ce qu'il se passait pour les utilisateurs mobiles, mais la majorité du crawl se faisait avec le user-agent "classique" (le crawl mobile était très minoritaire). Or, on observe actuellement, depuis le lancement de l'Index Mobile-First, une inversion de la proportion de chaque type de crawl : maintenant que Google veut se baser sur le contenu montré aux internautes mobiles pour indexer et classer les pages dans ses résultats, la majorité des crawls se fait avec le user-agent mobile. Mais cela ne veut pas dire que l'on oublie complètement les utilisateurs desktop, et le crawler classique va donc continuer à explorer les pages, moins souvent que le mobile, mais une fois de temps en temps tout de même. Ce sont ces crawls que l'on peut donc toujours observer, même si un site est "passé en mobile-first."
Tous les user-agent des robots de Google sont listés ici.
Est-il encore nécessaire de désavouer les backlinks non désirés dans la search console après avoir été victime d'une campagne de negative SEO ?
Vincent Courson. Je ne recommande d'utiliser le fichier de désaveu que dans un unique cas : si votre site est soumis à une action manuelle pour cause de liens entrants artificiels et que vous essayez de faire lever cette action manuelle. Ce cas de figure précis est l'unique raison de la création du fichier de désaveu : donner une opportunité à un webmaster qui essaie de nettoyer son profil de backlinks d'indiquer à Google qu'il n'arrive pas à faire supprimer certains liens. Et c'est tout !
Cela fait maintenant des années que les filtres algorithmiques luttant contre les liens artificiels (Penguin) sont devenus plus "malins" qu'ils ne l'étaient à leur lancement. A l'origine, une pénalisation généralisée des liens entrants sur un site, Penguin a été depuis intégré au coeur des algorithmes de recherche de Google. Cela se traduit par une analyse des liens un par un par les filtres anti-spam, et ceux qui sont estimés faire partie de systèmes de liens par Google sont simplement "ignorés" dans les calculs de PageRank. En conséquence, un lien créé par une personne mal intentionnée pour tenter d'impacter négativement votre site ne sera pas pris en compte, même si le lien en question apparaît toujours dans la Search Console ou dans d'autres outils indépendants. Et donc, pas besoin d'utiliser le fichier de désaveu.
Sur une catégorie de site e-commerce, est-ce une bonne pratique d'utiliser la page 1 comme URL canonique ?
Vincent Courson. Lorsque deux pages ou plus présentent un même contenu, un moteur de recherche peut définir l'un de ces documents comme le document canonique pour le contenu en question : l'URL qui est la plus représentative d'un contenu parmi un ensemble de documents dupliqués sur votre site. Cette décision (canonicalisation) est prise par le moteur de recherche, mais un webmaster peut aider le moteur a faire son choix, notamment avec l'utilisation de la balise <link> rel=canonical.
Pour ce qui est des sites e-commerce, le contenu ne sera pas exactement le même sur les pages successives d'une catégorie de produits : les produits listés en page 2 ne sont pas les même que ceux listés en page 1. Pareil pour les pages suivantes. Par conséquent, étant donné la définition de "contenu canonique" exposée plus haut, nous ne recommandons pas l'utilisation de balises canonical dans le cas de pages de catégories e-commerce, où les contenus ne sont pas les même d'une page à l'autre. Nous ignorerons sans doute l'indication de canonicalisation dans un tel cas.
Nous recommandons plutôt que vous mettiez des liens appropriés entre les différentes pages d'une même catégorie, afin de faciliter la découverte et l'indexation de ces pages par les robots d'exploration. Vous pouvez au passage implémenter des indications de pagination, même si ces dernières ne sont pas strictement requises pour que Google comprenne le lien qui existe entre les différentes pages d'une même catégorie.
Faut-il baliser les events sur les pages de listing, ou sur les pages détaillant chaque événement ? Ou les deux ? Comment Google associe-t-il des événements à une page ?
Vincent Courson. Lors du balisage schema.org d'événements, nous demandons que chaque événement soit associé à une page individuelle. Chaque page doit avoir son URL unique et doit contenir le balisage "events." De cette manière, Google peut associer un événement à un emplacement spécifique sur votre site, et référencer l'emplacement en question depuis les SERPs. La documentation sur le balisage des événements se trouve ici.
Toutefois, en plus de cette correspondance particulière entre un événement et une URL unique, vous pouvez également baliser des événements sur une page qui liste plusieurs événements, en respectant les consignes suivantes :
- Chacun des événements listés doit tout de même avoir sa propre URL associée.
- Sur la page de listing, vous ne devez pas créer une seule entité de balisage qui inclut l'ensemble des événements. Si le listing présente 10 événements, vous devez mettre en place 10 balisages individuels, un pour chaque événement.
A noter que certaines autres consignes existent pour le balisage d'événements :
- Les éléments indispensables à inclure dans le balisage d'un événement sont le nom, la date, et le lieu de l'événement. Si l'événement dure plusieurs jours, la date de début est la plus importante ("startDate"), la date de fin est optionnelle ("endDate").
- Ne pas baliser des non-événements avec le balisage "Events" (comme par exemple des offres de voyage, les horaires d'ouverture de magasins, ou des promotions limitées dans le temps). Tout ce qui a une date de début et une date de fin n'est pas forcément un événement.
- Respecter les consignes de qualité propres aux données structurées.
Google Images propose une sélection d'images similaires lorsqu'on clique sur un résultat. Sur quoi Google se base-t-il pour choisir ces images similaires ?
Vincent Courson. Pour comprendre les images en général, Google utilise de nombreux signaux, tels que le texte alt ou le titre d'une image, la légende de l'image sur la page, le texte se trouvant autour de l'image sur la page web, la typologie de la page ou du site qui contiennent l'image, etc. Plus le temps passe, cependant, plus les logiciels de reconnaissance automatique d'image s'améliorent, et l'interprétation automatique de ce que contient une image est de plus en plus précise. Ainsi, à l'heure actuelle, Google se base sur un mélange d'indices contextuels et sur de la reconnaissance automatique pour savoir ce que représente réellement une image. Il n'y a pas d'utilisation des positions d'une image ou du site qui contient l'image dans l'index de Google pour déterminer ce qu'elle contient.
Ensuite, nous cherchons à montrer dans les SERPs les images que nous connaissons et qui correspondent le mieux possible à la recherche de l'internaute, que ce soit dans l'onglet "Tous" ou dans l'onglet "Images". Et cela couvre aussi la fonctionnalité "Images similaires". La sélection de ces images se fait dans un objectif de pertinence du résultat pour l'internaute au moment de sa recherche, mais avec la volonté de lui permettre de creuser plus en profondeur dans sa recherche. Lorsque l'internaute clique sur une image en particulier, nous tentons de lui montrer d'autres images qui présentent des caractéristiques similaires.
Un exemple permet de mieux expliquer la logique. Lorsqu'un internaute cherche "Fraise tagada" dans Google Images, presque toutes les images montrent les bonbons en question soit en tas, soit dans un sachet en plastique.
Si l'utilisateur clique toutefois sur la seule image qui montre les fraises dans une boîte en plastique, Google va considérer que cette présentation du bonbon est la plus intéressante pour l'internaute, et donc lui proposer dans les "images similaires" des fraises Tagada également présentées dans des boîtes, afin de lui permettre de creuser plus profondément dans cette direction particulière.
