Heures de bureau SEO, 11 mars 2022

Publié: 2022-03-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 11 mars 2022.

Masquer le contenu
1 Une seule page peut-elle influencer l'ensemble du domaine ?
2 Trop de liens internes peuvent nuire à votre site Web ?
3 Diagnostiquer les problèmes d'exploration pour les petits sites Web
4 Pourquoi les synonymes font une différence dans le classement
5 Combiner plusieurs types de résultats enrichis sur une page
6 Comment s'assurer qu'un paywall ne déclenchera pas de pénalité de cloaking
7 Les liens dans certaines sections d'une page sont-ils plus importants pour Google ?
8 L'indexation mobile-first vous aide-t-elle à vous classer plus haut ?

Une seule page peut-elle influencer l'ensemble du domaine ?

6:50 « […] nous avons récemment ajouté une page à notre site qui génère constamment un trafic et un engagement importants […]. Ma question pour vous est la suivante : une seule page avec un engagement et un trafic extrêmement élevés peut-elle avoir une influence sur le domaine dans son ensemble ? […] »

John a répondu : « Je ne pense pas que nous utiliserions l'engagement comme facteur. Mais il se trouve que, généralement, les pages d'un site Web sont interconnectées avec le reste du site Web. Et grâce à ces liens internes sur le site Web, nous transmettons certains des signaux. Donc, si nous voyons qu'une page est une très bonne page et que nous aimerions l'afficher souvent dans la recherche, peut-être qu'elle contient également divers liens externes, cela nous donne beaucoup de contexte supplémentaire sur cette page. Et nous pouvons en quelque sorte transmettre une partie de cela au reste du site Web. Donc généralement, c'est une bonne chose.

Ce que je pourrais surveiller, c'est si cela stimule l'engagement pour le genre de choses qui vous tiennent à cœur. C'est juste quelque chose que j'ai parfois vu, où une page peut être très visible pour certaines requêtes, mais quand vous regardez les requêtes, vous vous dites, eh bien, je ne veux pas vraiment me classer pour ça. Mon sujet est autre chose. Donc, cela pourrait être quelque chose juste pour jeter un regard prudent sur les mesures.

La personne a ensuite demandé si un mauvais score Core Web Vitals dans une section d'une page pouvait affecter le reste du domaine. Si vous n'êtes pas familier avec les mesures qu'elle a mentionnées : la plus grande peinture de contenu (LCP) et le décalage de mise en page cumulé (CLS), je vous recommande de lire nos guides sur Qu'est-ce que la plus grande peinture de contenu et Qu'est-ce que le décalage de mise en page cumulé.

8:28 "[…] pour Core Web Vitals, nous donnons la priorité à nos pages à haute recherche pour les améliorations de produits, [...]. Un sous-ensemble de pages avec un LCP ou un CLS médiocre, disons uniquement la page vidéo du site qui ne sont pas les pages principales ou secondaires ou même tertiaires générant du trafic de recherche sur le site, peut-il avoir un impact sur le reste du site. Core Web Vitals global score? […] "

John a répondu : « Habituellement, ce ne serait pas un problème. Je pense donc qu'il y a là deux aspects. D'une part, pour les Core Web Vitals, nous examinons un échantillon du trafic vers ces pages, qui est effectué via, je ne sais pas, la fonctionnalité Chrome User Experience Report . Je crois que c'est documenté quelque part du côté de Chrome. Mais c'est essentiellement une partie du trafic vers votre site Web. Cela signifie donc que, pour la plupart, les choses que nous regarderons le plus sont vraiment les pages qui obtiennent le plus de visites. Donc, si vous avez des pages aléatoires sur le côté que personne ne regarde jamais, et qu'elles sont vraiment lentes, alors celles-ci n'entraîneront pas votre site vers le bas . Et dans l'autre sens également - si ces pages aléatoires étaient vraiment rapides, elles ne tireraient pas votre site vers le haut. Même s'il y a beaucoup de pages aléatoires, si, dans l'ensemble, elles n'obtiennent tout simplement pas beaucoup de trafic, nous ne nous en soucions pas vraiment. […] les choses que les gens voient doivent avoir une bonne expérience utilisateur. Donc, si la plupart des gens voient une certaine partie de votre site, c'est sur cette partie que nous voulons nous concentrer.

L'autre chose est qu'avec la mise à jour Page Experience, en fonction de la quantité de données dont nous disposons pour un site Web, nous pouvons le diviser en différentes sections. Et nous essayons de le faire en comprenant quelles pages d'un site Web sont essentiellement similaires. Et cela peut être par type de modèle ou quelque chose comme ça, ce qui signifie que si nous pouvons voir que, par exemple, pour un site de commerce électronique, toutes les pages de produits sont très rapides, et peut-être que nous avons suffisamment de données pour regarder les pages de produits séparément, alors nous pouvons faire en sorte que ce groupe de pages le traite lui-même. Et s'il existe un autre type de page sur le site qui contient suffisamment de données et qui est un peu lente, alors nous dirons, eh bien, ce type de page est plus lent. C'est donc la deuxième partie là-dedans, si vous avez un type de page qui est très lent et que nous avons suffisamment de données pour que ce type de page comprenne, eh bien, c'est juste cette partie du site Web, alors juste cette partie sera être affecté par les Core Web Vitals et la mise à jour de l'expérience de la page.

Trop de liens internes peuvent nuire à votre site Web ?

12:50 " Ainsi, dans les heures de bureau précédentes, vous avez dit un jour que l'utilisation de trop de liens internes sur la même page pouvait diluer leurs valeurs, et peut-être que Google ne serait pas en mesure de comprendre la structure du site. Alors, à votre avis, quel est le nombre de liens internes idéaux par page pour un site de commerce électronique, peut-être avec des millions de pages ?

John a répondu : « Je ne pense pas qu'il y ait un nombre optimal. La partie à laquelle je ferais attention est que lorsque vous explorez le site Web, vous pouvez toujours reconnaître qu'il existe une structure. Donc, surtout avec un site de commerce électronique que vous pouvez toujours reconnaître : voici la page d'accueil principale, voici les catégories de premier niveau, les catégories de deuxième niveau, vous pouvez en quelque sorte toujours reconnaître cette structure afin qu'il soit clair comment le contexte est de pages individuelles . […] il est plus difficile de reconnaître la structure si chaque page est liée à toutes les autres pages. Et si vous avez des millions de pages sur votre site Web, vous n'aurez pas des millions de liens sur chaque page. Donc, de ce point de vue, je ne vois généralement aucun problème avec les sites de commerce électronique, simplement parce que, je ne sais pas, le CMS de commerce électronique a tendance à être configuré de cette façon de toute façon, que vous avez différents niveaux de catégories puis la page de produit individuelle à un moment donné. "

Diagnostiquer les problèmes d'exploration pour les petits sites Web

25:47 " Nous avons examiné les rapports Crawl Stats dans la Search Console et avons essayé d'identifier s'il pourrait y avoir un problème technique avec Google qui explore notre site Web. Quels sont certains des signaux ou des choses à identifier qui nous indiqueront si Google a du mal à explorer quelque chose ou si Googlebot est distrait par des fichiers qui ne sont pas pertinents […] ?

John s'est assuré que la personne qui posait la question gérait un site Web relativement petit, puis il a répondu : " Ok, je suppose que le rapport Crawl Stats ne vous sera pas utile dans ce cas [pour un petit site Web] car, avec le Crawl Rapport de statistiques, vous regardez vraiment une vue globale de l'exploration de votre site Web. Et généralement, cela a plus de sens si vous avez quelque chose comme, je ne sais pas, quelques centaines de milliers de pages. Ensuite, vous pouvez regarder cela et dire, oh, eh bien, en moyenne, l'exploration est lente. Alors que si vous avez un site Web qui a, je ne sais pas, environ 100 pages environ, alors essentiellement, même si l'exploration est vraiment, vraiment lente, alors ces 100 pages, nous pouvons toujours obtenir cela, comme, une fois par jour, dans le pire des cas, peut-être une fois par semaine. Ce ne sera pas un problème technique en ce qui concerne l'exploration.

Il s'agit essentiellement de comprendre que le site Web offre réellement quelque chose d'unique et de précieux que nous devons indexer. Donc, moins de problème concernant le côté crawl et plus concernant le côté indexation. L'exception ici serait s'il y a vraiment un gros problème technique avec votre site Web. Mais c'est quelque chose que vous verriez tout de suite parce que vous vérifieriez probablement chacune de ces URL et remarqueriez, oh, Google ne peut pas les explorer du tout. Une erreur est renvoyée ou une [balise] noindex est renvoyée. Et ce serait très évident. Donc, mon hypothèse, en particulier pour un site Web plus petit, est qu'il s'agit vraiment de s'assurer que Google comprend la valeur du site Web et qu'il sait qu'il est logique d'indexer autant que possible. Parce que le côté rampant ne sera pas le facteur limitant. C'est vraiment plus comme, eh bien, vous devez d'abord convaincre Google qu'il devrait en fait essayer d'explorer.

Pourquoi les synonymes font une différence dans le classement

39:34 "Pourquoi pourrait-il y avoir de minuscules différences dans les synonymes [...] qui font une si grande différence dans la position de classement ?"

La personne a présenté les exemples de synonymes suivants : "modifier la vidéo" et "éditeur de vidéo".

John a répondu : "Donc, de notre point de vue, cela peut être tout à fait normal, et c'est quelque chose où, d'une part, nous essayons de comprendre des choses comme les synonymes dans une requête, mais nous essayons également d'examiner le contexte complet de la requête. Et surtout en ce qui concerne les synonymes, nous pouvons supposer que quelque chose est principalement un synonyme, mais cela ne signifie pas que c'est complètement un synonyme. Et surtout lorsque vous regardez quelque chose comme « éditer une vidéo » par rapport à « éditeur de vidéo », les attentes du côté de l'utilisateur sont un peu différentes. D'une part, vous souhaitez éditer une vidéo. D'autre part, vous voudrez peut-être télécharger un éditeur vidéo. Et cela semble très similaire, mais le genre de choses que les utilisateurs veulent là-bas sont légèrement différentes. Donc, de mon point de vue, il est logique que nous affichions différents classements là-bas. Et nous avons la même chose avec des orthographes de mots légèrement différentes. Comme si vous avez la version britannique ou américaine d'un mot anglais, si vous avez un mot ou une lettre avec un accent et qu'il n'a pas d'accent, nous comprenons que ce sont pour la plupart les mêmes, mais nous comprenons aussi qu'ils ' re légèrement différent. Et nous essayons d'afficher des résultats de recherche qui en tiennent compte. »

Combinaison de plusieurs types de résultats enrichis sur une page

42:06 « Nous avons vu que la plupart des sites Web de recettes ne fournissent pas d'informations très utiles dans mon pays, et nous essayons de changer cela en fournissant des informations plus utiles et en allant jusqu'à ajouter une FAQ à chaque recette. Quelle est la meilleure façon d'ajouter ces FAQ ?

John a répondu : « […] de mon point de vue, c'est à vous de décider. La seule chose à laquelle je ferais attention dans des cas comme celui-ci, où vous avez plusieurs types de résultats riches potentiellement pertinents pour vos pages, c'est que certains de ces types, nous pouvons les combiner, et certains d'entre eux, nous ne pouvons pas vraiment les combiner. Bien. Je ne sais pas précisément quand il s'agit de recettes, si on peut les combiner, ou si on doit essentiellement choisir l'une ou l'autre. Et si vous remarquez qu'aucun autre site Web de recettes ne contient l'extrait de recette riche et la section FAQ en bas, nous ne pouvons probablement pas les combiner. Et puis, il est probablement préférable pour vous de choisir le type de type de résultat enrichi que vous voulez vraiment afficher et de vous concentrer uniquement sur ce type.

Comment s'assurer qu'un paywall ne déclenchera pas de pénalité de cloaking

43:43 " Google explique, dans ses directives d'abonnement et de contenu payant, qu'un schéma spécifique doit être ajouté à une page afin de partager le contenu payant dans l'index et de ne pas déclencher de pénalité de cloaking. Après l'avoir mis en œuvre, cependant, le test des résultats enrichis ne semble pas l'identifier, et ne risquons-nous pas par inadvertance une pénalité de dissimulation ? »

John a déclaré : "Je suppose donc que le test des résultats enrichis le montrera, mais je ne l'ai pas réellement vérifié, car le test des résultats enrichis, pour la plupart, se concentre sur ce que Google afficherait réellement dans les résultats de recherche en tant que type de résultats enrichis. . Et essentiellement, le contenu du paywall n'est probablement pas l'une des choses que nous montrerions comme un type de résultat riche spécifique. Il est donc possible que nous ne le montrions pas dans ce test. Une façon simple de le faire est de créer une page de test très simple et de tester cette page individuellement. L'autre test que vous pouvez effectuer pour vous assurer que Google voit réellement le contenu complet avec le balisage est le test d'inspection d'URL normal, où vous pouvez faire une esquisse en direct de la page et vous pouvez regarder le code HTML généré pour cela. page. Et vous pouvez copier cela dans un éditeur et revérifier pour vous assurer que les données structurées que vous souhaitez afficher y sont réellement affichées. C'est donc un peu la direction dans laquelle je me dirigerais là-bas.

Les liens dans certaines sections d'une page sont-ils plus importants pour Google ?

45:11 « […] les liens dans certaines sections d'un site sont-ils vus différemment ? Par exemple, si une page est liée dans un en-tête ou un pied de page et donc incluse sur chaque page d'un site, Google affiche-t-il ces liens différemment des liens dans le corps de la page ?

John a répondu : « Nous ne faisons pas vraiment de distinction là-bas. Donc, si des éléments [pages] sont liés dans votre pied de page et qu'ils sont liés sur l'ensemble du site Web, alors, de notre point de vue, vous avez ces liens sur l'ensemble de votre site Web. Ce n'est pas le cas que nous dirions, oh, les liens dans un pied de page ont moins de poids ou ne sont pas aussi utiles, nous les ignorerons, ou quelque chose comme ça. Donc, de ce point de vue, en ce qui concerne les liens, nous les voyons essentiellement comme des liens sur une page.

C'est légèrement différent quand il s'agit de texte là-dedans dans la mesure où nous essayons de comprendre quel est le contenu principal de la page. Et en ce qui concerne le classement par rapport aux autres contenus de votre site Web, nous essaierons de nous concentrer sur la section de contenu principal de la page. Mais les liens, de notre point de vue, nous aident simplement à mieux comprendre la structure d'un site. Et qu'ils soient dans l'en-tête, ou dans le pied de page, ou la barre latérale, ou le contenu principal, cela ne change vraiment rien pour nous.

L'indexation mobile-first vous aide-t-elle à vous classer plus haut ?

46:33 " L'indexation mobile-first aide-t-elle avec les classements de recherche ? Notre site Web est toujours exploré par Googlebot desktop. Et nous ne pouvons pas comprendre pourquoi il ne passe pas au mobile d'abord. Nous avons parcouru la documentation et le dépannage de Google, mais rien ne saute aux yeux. Le passage à une application Web progressive et à une assistance hors ligne vous aiderait-il ?

John a répondu : " Donc, tout d'abord, l'indexation mobile d'abord ne change rien au classement. Il n'est donc pas nécessaire de forcer un quelconque passage à l'indexation mobile d'abord. C'est purement une question d'indexation et de sélection du contenu que nous utiliserions sur un site Web. Donc, de ce point de vue, je ne m'en soucierais pas. Si votre site Web fonctionne correctement sur mobile, à un moment donné, il sera basculé. Je crois qu'il reste encore quelques sites que nous n'avons pas encore changés. Mais pour la plupart, nous avons changé, je suppose, la plupart des sites. Et ceux qui restent, nous continuons à les revérifier. Quand ils sont prêts et quand nous pensons qu'ils sont prêts, nous allons simplement les changer.

Mais ce n'est pas le cas que vous remarquiez un changement de classement à moins que la version mobile ne soit significativement différente de la version de bureau. Et ce serait aussi une raison pour nous de ne pas passer à l'indexation mobile-first. Et si la version mobile est très différente et que nous avons utilisé l'indexation mobile d'abord pour votre site, nous indexerions essentiellement votre contenu en fonction de la version mobile. Et s'il y a plus de contenu sur une version de bureau, nous l'ignorerions. Donc, de ce point de vue, je n'essaierais pas de forcer cela. Passer à une application Web progressive est quelque chose que vous pouvez faire, mais je ne pense pas que cela affecterait l'apparence de l'indexation mobile d'abord sur votre site Web. Et généralement, lorsqu'il s'agit d'applications Web progressives, ce sont des sites Web de framework JavaScript. Et cela apporte tout un ensemble d'autres défis qui vont avec, dans la mesure où vous devez vous assurer que Google peut réellement voir votre contenu, car JavaScript est quelque chose que nous pouvons généralement rendre et gérer correctement, mais ce n'est pas toujours aussi simple qu'un pur statique Page HTML.