Heures de bureau SEO, 18 février 2022

Publié: 2022-02-28

Ceci est un résumé des questions et réponses les plus intéressantes des heures de bureau Google SEO avec John Mueller le 18 février 2022.

Masquer le contenu
1 Types de sites Web concernés par la mise à jour des avis sur les produits
2 L'utilisation de l'API d'indexation
3 EAT et les algorithmes de Google
4 Mentions de marque non liées et contenu généré par les utilisateurs
5 Googlebot et défilement infini
6 Actualiser et découvrir les données dans le rapport Crawl Stats
7 Réduction de l'exploration d'un site Web
8 Comment Google identifie les pays ciblés par les pages
9 Un grand nombre d'URL marquées comme découvertes - actuellement non indexées

Types de sites Web concernés par la mise à jour des avis sur les produits

4:03 "[…] Ma question concerne la mise à jour des avis sur les produits [...]. Je voulais comprendre comment Google identifie si une page ou un site est lié aux avis sur les produits. […] Par exemple, il y a un site de commerce électronique […] et ils ont aussi un blog où ils passent en revue leurs propres produits. Ils écrivent sur les avantages et les inconvénients de leurs produits, comparent différents produits. […] Google dira-t-il que […] ce sont aussi des avis sur les produits et peuvent être analysés par la mise à jour des avis sur les produits ? […] »

Comme John l'a expliqué, "[…] Les recommandations que nous avons pour les revues de produits [...] seraient pertinentes pour tout type de revue de produit. Donc je n'essaierais pas forcément de voir, est-ce que Google pense que mon site est un site d'avis de produits ou pas […]. Mais plutôt, si vous pensez que ces bonnes pratiques s'appliqueraient à votre contenu, alors appliquez simplement ces bonnes pratiques […] ».

L'utilisation de l'API d'indexation

6:53 "[…] [la documentation de Google] mentionne que l' API d'indexation doit être utilisée pour des pages telles que la publication d'offres d'emploi ou la diffusion d'événements. Est-il possible que nous puissions essayer cette API pour différents types de contenu, comme des articles de presse ou du contenu de blog ? »

John a répondu : « Les gens essaient. Mais essentiellement, ce que nous avons documenté est ce pour quoi nous utilisons l'API. Si vous n'avez pas de contenu qui entre dans ces catégories, l'API ne vous aidera pas là-bas ».

EAT et les algorithmes de Google

10:54 "[…] EAT est mentionné dans [ Quality Rater Guidelines ], mais je veux savoir si les vrais algorithmes [incluent] également des facteurs EAT comme l'expertise de l'auteur ?"

John a déclaré: «Je suppose qu'il y a un travail indirect effectué pour essayer de faire des choses similaires. […] Nous mettons cela dans les directives afin que nous puissions guider les testeurs de qualité pour revérifier ces choses. Et si nous pensons que c'est quelque chose d'important, alors je suppose que les gens du côté de la qualité de la recherche travaillent également pour essayer de comprendre cela d'une manière plus algorithmique.

Mais je ne verrais pas […] [qu'il y aurait] un score EAT, et vous devez en obtenir cinq ou quelque chose comme ça dessus. Il s'agit plutôt d'essayer de comprendre le contexte du contenu sur le web ».

Mentions de marque non liées et contenu généré par l'utilisateur

12:01 "[…] Je vois que les gens parlent de mention[s] de marque non liée[s] […]. Pensez-vous que c'est aussi important pour les algorithmes [de Google] […] ? »

Par des mentions de marque non liées, la personne faisait référence à des situations où d'autres sites mentionnent votre marque mais n'incluent pas de lien vers votre site Web.

John a dit : « […] Je pense que c'est un peu délicat, parce que nous ne savons pas vraiment quel est le contexte. Je ne pense pas que ce soit une mauvaise chose […] pour les utilisateurs car s'ils peuvent trouver votre site Web grâce à cette mention, c'est toujours une bonne chose. Mais je ne supposerais pas qu'il y ait un […] facteur SEO qui essaie de comprendre où quelqu'un mentionne le nom de votre site Web ».

12:58 "[…] Qu'en est-il des avis ou commentaires des utilisateurs ? Pensez-vous que c'est aussi un facteur de classement pour un article ou un produit ? »

John a répondu que "[…] Souvent, les gens écrivent sur la page dans leurs propres mots et cela nous donne un peu plus d'informations sur la façon dont nous pouvons afficher cette page dans les résultats de recherche. De ce point de vue, je pense que les commentaires sont une bonne chose sur une page. Évidemment, trouver un moyen de les maintenir de manière raisonnable est parfois délicat car les gens spamment aussi ces commentaires […]. Si vous pouvez trouver un moyen de conserver les commentaires sur une page Web, cela vous donne un peu plus de contexte et aide les personnes qui effectuent des recherches de différentes manières à trouver également votre contenu ».

Googlebot et défilement infini

24:00 "[…] Savez-vous si Googlebot est suffisamment avancé pour gérer le défilement infini , ou au moins quelque chose où le contenu continue de s'appuyer sur quelque chose ?"

Jean a dit : « Un peu […].

Ce qui se passe lorsque nous rendons une page, c'est que nous utilisons une fenêtre d'affichage assez élevée, comme si vous avez un très long écran, et nous rendons la page pour voir ce que la page y afficherait. Habituellement, cela déclencherait une certaine quantité de défilement infini dans toutes les méthodes JavaScript que vous utilisez pour déclencher le défilement infini. Tout ce qui finira par y être chargé, c'est ce que nous pourrons indexer.

[…] Selon la façon dont vous implémentez le défilement infini, il peut arriver que nous ayons cette page plus longue dans l'index. Il se peut que nous n'ayons pas tout ce qui rentrerait dans cette page. Parce que selon la façon dont vous déclenchez le défilement infini, il se peut que vous ne chargeiez que la page suivante. Ensuite, nous pourrions avoir deux ou trois de ces pages chargées sur une page avec un défilement infini, mais pas tout. […] Je recommanderais de tester cela avec l' outil d'inspection [URL] et de voir juste combien Google récupérerait ».

Actualiser et découvrir les données dans le rapport Crawl Stats

33:32 "Dans le rapport de la Search Console [ Crawl Stats ], 97 % des requêtes du robot d'exploration sont actualisées et seulement 3 % sont découvertes. Comment optimiser cela et laisser Google découvrir plus de pages ? »

John a répondu : "[…] Il est normal que […] un site Web plus ancien et plus établi ait beaucoup d'explorations de rafraîchissement , car nous examinerons le nombre de pages que nous connaissons et qui augmente avec le temps. Et le nombre de nouvelles pages qui arrivent a tendance à être assez stable. Il est assez courant, en particulier pour un site Web qui est en quelque sorte établi et qui se développe lentement, d'avoir un équilibre comme celui-ci, que la plupart de l'exploration se fait sur l'exploration de rafraîchissement et pas tellement sur l'exploration de découverte.

Je pense que ce serait différent si vous aviez un site Web […] où vous avez beaucoup de nouveaux articles qui arrivent, et l'ancien contenu devient très rapidement inutile. Ensuite, je pense que nous aurions tendance à nous concentrer davantage sur la découverte. […] Si vous avez quelque chose comme un site de commerce électronique, où vous augmentez lentement la quantité de contenu que vous avez, et la plupart de l'ancien contenu reste valide, […] la quantité d'actualisation de l'exploration [va] probablement être un peu plus haut ».

Réduction de l'exploration d'un site Web

35:09 "Au cours des dernières semaines, j'ai remarqué une énorme baisse des statistiques de crawl, de 700 à 50 par jour. Existe-t-il un moyen de comprendre à partir du rapport de la Search Console quelle pourrait être la cause de cette baisse ? Serait-ce le chargement de la page source ? Comment puis-je lire correctement la répartition de la demande d'exploration ? »

John a fourni une explication détaillée de la façon dont Google explore les sites Web et des facteurs qui affectent l'exploration : "[…] Il y a quelques éléments qui entrent dans la quantité d'exploration que nous effectuons.

[…] Nous essayons de déterminer combien nous avons besoin d'explorer un site Web pour garder les choses fraîches et utiles dans nos résultats de recherche. Et cela repose sur la compréhension de la qualité de votre site Web, comment les choses changent sur votre site Web. Nous appelons cela la demande de crawl.

D'un autre côté, il [y a] les limitations que nous voyons de votre serveur, […] site Web, […] infrastructure réseau en ce qui concerne la quantité que nous pouvons explorer sur un site Web. Nous essayons d'équilibrer les deux.

Et les restrictions ont tendance à être liées à deux éléments principaux : […] le temps de réponse global aux demandes

au site Web, et […] le nombre d'erreurs de serveur […] que nous constatons lors de l'exploration. Si nous voyons beaucoup d'erreurs de serveur, alors nous ralentirons l'exploration […]. Si nous constatons que votre serveur ralentit, nous ralentirons également le crawl […].

La difficulté avec l'aspect vitesse est que nous avons deux […] manières différentes de voir la vitesse. Parfois, cela devient déroutant lorsque vous regardez le taux de crawl. Spécifiquement pour le taux de crawl, nous regardons juste, à quelle vitesse pouvons-nous demander une URL à votre serveur ?

Et l'autre aspect de la vitesse que vous rencontrez probablement concerne tout ce qui concerne Core Web Vitals et la rapidité avec laquelle une page se charge dans un navigateur. La vitesse qu'il faut dans un navigateur n'est généralement pas directement liée à la vitesse qu'il nous faut pour récupérer une URL individuelle sur un site Web. Parce que dans un navigateur, vous devez traiter le JavaScript, extraire tous ces fichiers externes, rendre le contenu, recalculer les positions de tous les éléments de la page. Et cela prend un temps différent de la simple récupération de cette URL.

[…] Si vous essayez de diagnostiquer un changement de vitesse de crawl, alors ne regardez pas combien de temps il faut pour qu'une page s'affiche. […] Regardez simplement combien de temps il faut pour récupérer cette URL sur le serveur.

L'autre chose […] est que […] nous essayons de comprendre où le site Web est hébergé […]. Si nous reconnaissons qu'un site Web change d'hébergement d'un serveur à un autre serveur - cela pourrait être vers un autre fournisseur d'hébergement, [...] passer à un CDN ou changer de CDN [...] - alors nos systèmes reviendront automatiquement à certains taux de sécurité où nous savons que nous n'allons pas causer de problèmes et puis, étape par étape, augmenter à nouveau.

Chaque fois que vous apportez un changement plus important à l'hébergement de votre site Web, je suppose que le taux de crawl va baisser. Et puis au cours des deux prochaines semaines, cela reviendra à tout ce que nous pensons pouvoir explorer en toute sécurité sur notre site Web. C'est peut-être quelque chose que vous voyez ici.

L'autre chose est que, de temps en temps, nos algorithmes pour déterminer comment nous classons les sites Web et les serveurs […] peuvent également être mis à jour. […] Même si vous ne changez rien à votre infrastructure d'hébergement, nos algorithmes essaieront de comprendre [que] ce site est hébergé sur ce serveur, et ce serveur est celui qui est fréquemment surchargé. Nous devrions être plus prudents lors de l'exploration de ce site Web afin de ne pas causer de problèmes. C'est quelque chose qui s'installe aussi automatiquement avec le temps, généralement en quelques semaines […].

[…] Dans [Google] Search Console, vous pouvez spécifier un taux de crawl […] et cela nous aide à comprendre que vous avez des paramètres spécifiques […] pour votre site Web et nous essaierons d'en tenir compte. La difficulté avec le paramètre de vitesse de crawl est qu'il s'agit d'un paramètre maximal. Ce n'est pas un signe que nous devrions ramper autant que cela, mais plutôt que nous devrions ramper au maximum ce que vous spécifiez ici. Habituellement, ce paramètre est plus utile lorsque vous devez réduire la quantité d'exploration, et non lorsque vous souhaitez augmenter la quantité d'exploration.

[…] Une chose que vous pouvez également faire est que, dans le centre d'aide de la Search Console, nous avons un lien pour signaler des problèmes avec Googlebot. Si vous remarquez que l'exploration de votre site Web est hors de portée de ce que vous attendez, vous pouvez signaler des problèmes avec Googlebot via ce lien […] ».

Comment Google identifie les pays ciblés par les pages

56:25 "[…] En ce qui concerne le ciblage géographique, en plus d'utiliser hreflang, comment Google détermine-t-il quel [pays] vous ciblez [avec] ce site Web spécifique ou le sous-répertoire spécifique ?"

La réponse de John a été : « Nous essayons de regrouper les URL selon des modèles clairs que nous pouvons reconnaître […], par exemple, par sous-domaine ou par sous-répertoire. Si vous avez le pays dans le sous-répertoire à un endroit plus élevé dans un chemin, alors il est beaucoup plus facile pour nous de dire, tout sous ce chemin est pour ce pays, tout sous cet autre chemin est pour un autre pays.

Vous pouvez également vérifier les chemins individuels dans la Search Console […], ce qui nous facilite un peu la tâche. En pratique, je n'entends pas beaucoup de commentaires de personnes disant que cela fait une grande différence.

[…] J'essaierais de rendre […] aussi clair que possible quel pays est pertinent pour les URL individuelles, avec un chemin clair dans l'URL. Je pense que quelqu'un a également posé une question sur l'utilisation du pays comme paramètre d'URL à la fin. Théoriquement, vous pouvez le faire […]. Pour nos systèmes, il est beaucoup plus difficile de reconnaître quelles URL appartiennent à quel pays […]. Si vous utilisez hreflang, c'est moins un problème ici, car vous pouvez le faire sur une base par URL ».

Un grand nombre d'URL marquées comme découvertes - actuellement non indexées

58:25 "[…] Nous sommes un énorme site de commerce électronique et en vérifiant notre rapport d'exploration, nous avons constaté qu'il y avait d'énormes quantités d'URL dans la section [ Découverte - actuellement non indexée ] [...]. Est-ce le signe d'[un] problème [sur notre site] […] ? »

John a déclaré : « Je pense que cela dépend de la nature de ces pages et de la manière dont vous les utilisez sur votre site Web. […] Nous trouvons toutes sortes d'URL sur le Web et beaucoup de ces URL n'ont pas besoin d'être explorées et indexées, car ce ne sont peut-être que des variantes d'URL que nous connaissons déjà, ou […] un forum ou un grattoir aléatoire Le script a copié les URL de votre site Web et les a incluses de manière brisée. […] Il est tout à fait normal d'avoir beaucoup de ces URL qui sont soit explorées et non indexées, soit découvertes et non explorées, simplement parce qu'il existe de nombreuses sources d'URL différentes sur le Web.

[…] Essayez de télécharger […] un échantillon de ceux-ci, afin que vous puissiez regarder des exemples individuels, et […] classez lesquelles de ces URL sont celles qui vous intéressent et lesquelles […] sont celles que vous pouvez ignorer.

[…] Ceux qui vous intéressent, c'est quelque chose pour lequel j'essaierais de comprendre ce que vous pourriez faire pour mieux les intégrer dans votre site Web en ce qui concerne des choses comme les liens internes. Donc, s'il s'agit de produits individuels ou de catégories introuvables, essayez de déterminer ce que vous pouvez faire de manière systématique pour vous assurer que toutes ces URL sont mieux liées les unes aux autres. […] Surtout avec un site de commerce électronique plus grand, cela peut devenir délicat, car vous ne pouvez pas regarder chaque URL individuellement tout le temps.

Mais parfois, il y a des trucs que vous pouvez faire là où vous dites : tout ce qui est de première catégorie, j'y fais un lien depuis ma page d'accueil. Et je m'assure que ma catégorie de premier niveau contient au maximum […] peut-être 100 ou 200 éléments, de sorte que vous ayez un peu une fonction de forçage en termes de ce que vous donnez à Google pour explorer et indexer. Sur cette base, vous pouvez le construire un peu plus systématiquement.

[…] Dans une certaine mesure, j'accepterais simplement que Google ne puisse pas tout explorer et tout indexer. […] Si vous reconnaissez, par exemple, que […] des produits individuels ne sont pas explorés et indexés, assurez-vous qu'au moins la page de catégorie de ces produits est explorée et indexée. Parce que de cette façon, les gens peuvent toujours trouver du contenu pour ces produits individuels sur votre site Web […].

Voyez si vous pouvez explorer votre site Web vous-même afin d'avoir un peu plus de données directes sur la façon dont un site Web comme le vôtre peut être exploré. Il existe différents outils d'exploration. […] En parcourant vous-même le site Web, vous pouvez voir lesquelles de ces URL sont liées très loin de la page d'accueil et lesquelles sont liées plus près de votre page d'accueil. Et sur cette base, vous pouvez parfois modifier un peu la structure du site pour vous assurer que les choses sont raisonnablement proches ou raisonnablement stables, en ce qui concerne la distance par rapport à votre page d'accueil ».