Heures de bureau SEO – 8 octobre 2021

Ceci est un résumé des questions et réponses les plus intéressantes des heures de bureau Google SEO avec John Mueller le 8 octobre 2021.

Le nombre de pages indexées par rapport à l'autorité du site

03:52 « Ainsi, vous avez recommandé à plusieurs reprises dans le passé que les grands sites […] se concentrent sur un plus petit ensemble de pages […]. Le site sur lequel je travaille en ce moment, nous avons […] environ 1 000 pages qui ne génèrent aucun trafic, qui sont anciennes, donc j'ai recommandé de les supprimer. Mais il y a une question que notre équipe de développement a eu l'impression que plus Google a indexé de pages de votre site, plus il attribue une autorité élevée au site et qu'il est réticent à supprimer des pages. Pourriez-vous nous éclairer là-dessus ?

Comme l'a dit John, « Ce n'est certainement pas le cas si vous avez plus de pages indexées que nous pensons que votre site Web est meilleur. […] Parfois, il est logique d'avoir beaucoup de pages indexées. Parfois, ce sont des pages utiles à indexer comme ça. Mais ce n'est pas un signe de qualité en ce qui concerne le nombre de pages indexées. Et surtout si vous parlez de […] 1 000, 2 000, 5 000 pages, c'est un nombre assez faible pour nos systèmes en général. Et ce n'est pas que nous dirions que 5 000 pages valent mieux que 1 000 pages. Pour nous, c'est un peu comme, eh bien, c'est un petit site Web, et nous nous débrouillons avec ce que nous pouvons en tirer. Et bien sûr, un petit site Web est relatif. Ce n'est pas comme dire que c'est un site Web non pertinent. C'est peut-être petit, mais ça peut quand même être très utile […] ».

Évaluer l'objectif principal d'un site Web

10:03 « La dernière fois, nous avons parlé de quelques problèmes avec le site Web […] – c'est un site Web de commerce électronique où nous avons des éléments informatifs et des éléments transactionnels. […] Votre conseil était de séparer un peu ce contenu en pages orientées transaction et orientées information. J'ai donc une autre question à ce sujet. Si vous avez, disons, un site Web de commerce électronique et que vous avez un énorme blog, ou un magazine, ou quelque chose comme ça, où vous avez beaucoup d'informations, mais c'est une ancienne section. Et d'autre part, vous avez toutes ces pages de produits, et catégories, etc. Alors cet énorme bloc avec des informations purement informatives donnerait-il à l'ensemble du site Web une touche ou un caractère informatif de sorte que Google dise, oh, nous ne savons pas si c'est […] quelque chose où les gens peuvent obtenir des informations plutôt que d'acheter des choses, ou est cette évaluation faite sur une base par page ? »

John a déclaré: «[…] Je crois comprendre qu'il s'agit davantage d'une chose au niveau de la page. […] Beaucoup de sites Web ont juste un mélange de différents types de contenu. Et puis vous essayez de déterminer laquelle de ces pages correspond à l'intention du chercheur et essayez de les classer de manière appropriée. […]

Je veux dire, vous voyez souvent cela avec les sites Web d'actualités. […] Ils ont les événements récents, mais ils ont aussi des sections pour les événements plus anciens qui ont eu lieu, ou […] pour d'autres grands événements, ils ont en quelque sorte une section d'archives isolée. Et ce sont des intentions très différentes, si vous voulez quelque chose qui se passe vraiment maintenant ou si vous voulez une sorte de recherche informationnelle, un contenu de type evergreen.

[…] Nous devons en quelque sorte le regarder page par page , et ne pas dire, oh, c'est un site Web de recherche parce qu'il y a du contenu de recherche ici ».

Redirection de liens

13:21 « Nous constatons que les gens créent des liens vers […] notre, disons, sous-catégorie de pages. Et le problème est que […] notre contenu va et vient, ce qui signifie que parfois, il y a plus de contenu apparaissant dans certaines catégories. Parfois, le contenu est supprimé. Ainsi, des sous-catégories peuvent être créées et peuvent également disparaître. Et nous voyons un tas de renvois à partir de backlinks parce qu'ils renvoient à des sous-catégories qui n'existent plus. Ma question ici est : est-il acceptable de rediriger […] ces liens vers la catégorie parent ? Et si nous le faisons, comment le faisons-nous – avec 302, par exemple ? Comme une redirection temporaire, car à l'avenir, cette sous-catégorie pourrait être à nouveau peuplée de contenu, […] ce n'est pas une redirection permanente ».

John a répondu : "Donc, si nous voyons cela se produire à plus grande échelle que vous redirigez vers le niveau parent, nous verrions probablement cela comme un soft 404. […] Et au lieu d'un code 404, vous redirigez, et c'est peut-être mieux pour les utilisateurs, mais nous le voyons comme un 404. […] Si cela a du sens du point de vue de l'utilisateur de rediriger, alors j'irais tout simplement.

[…] En ce qui concerne 301 ou 302, je ne pense pas que cela ait de l'importance ici, car soit nous verrions cela comme un soft 404, soit nous le verrions comme une question de canonisation. Si c'est un soft 404, alors le code n'a pas d'importance. S'il s'agit d'une question de canonisation, cela dépend de l'URL que nous affichons dans les résultats de recherche. Et généralement, celui de niveau supérieur aura de toute façon des signaux plus forts, et nous nous concentrerons sur celui de niveau supérieur. Donc, peu importe si c'est un 301 ou un 302 dans ce cas.

[…] Si nous le voyons comme un soft 404, […] nous ralentirions l'exploration de cette URL particulière parce qu'il n'y a rien ici […]. Si nous le voyons comme une redirection […], nous n'avons pas besoin de l'explorer tous les jours, car nous nous concentrons sur l'URL principale. Donc, je pense que dans ces deux cas, nous ralentirions l'exploration de cette URL jusqu'à ce que nous obtenions de nouveaux signaux qui nous disent, en fait, c'est peut-être quelque chose de nouveau. […] Ce serait comme un lien interne, ou un fichier sitemap […]. Et ce serait le signe le plus fort pour nous de ramper à nouveau. Mais je pense que le ralentissement de l'exploration serait similaire dans tous ces cas.

[…] Je pense que [la mise à jour] des plans de site ne suffit probablement pas. Je ferais vraiment en sorte que le maillage interne soit également clair ».

Récupération à partir des mises à jour principales

18:34 "Donc, il y a environ un an, nous avons constaté une diminution significative du trafic. Après l'audit, […] tous les signaux indiquaient que le site avait des problèmes de qualité de site. Nous avons pu résoudre ces problèmes en février de cette année. Et lors de la mise à jour principale de juin, nous avons constaté quelques augmentations. Mais ce n'est toujours pas au niveau où nous étions avant la diminution d'il y a environ un an. Ma question est donc les problèmes de qualité du site, si tel a été le cas, est-ce la reprise à laquelle nous pouvons nous attendre, ou pouvons-nous nous attendre à une plus grande reprise si nous pensons avoir résolu tous les problèmes identifiés […] ? »

John a dit : « […] Ce n'est pas tant que nous considérerions cela comme une situation où vous devez réparer quelque chose. Mais plutôt […] si vous travaillez à améliorer la pertinence de votre site Web, alors […] vous avez un meilleur site Web. Ce n'est donc pas que […] nous allons le remettre à l'état précédent. […] Ce n'est pas le même ou comparable à avant, donc il serait un peu difficile de s'attendre à ce qu'il redevienne l'état dans lequel il était avant […].

[…] Avec les mises à jour de base, nous ne nous concentrons pas tellement sur des problèmes individuels, mais plutôt sur la pertinence du site Web dans son ensemble . Et cela peut inclure des éléments tels que la convivialité et les publicités sur une page, mais il s'agit essentiellement du site Web dans son ensemble. Et généralement, cela signifie aussi l'orientation du contenu, la façon dont vous présentez les choses, la façon dont vous expliquez clairement aux utilisateurs ce qui se cache derrière le contenu, comme quelles sont les sources […] . Si vous voulez vraiment que Google considère votre site Web comme quelque chose de bien meilleur, vous devez probablement aussi travailler sur le contenu .

[…] Pensez aux endroits où il pourrait y avoir du contenu de mauvaise qualité, où les utilisateurs pourraient être confus lorsqu'ils vont sur mon site Web. Et cette confusion est-elle quelque chose que nous pouvons résoudre avec des problèmes techniques, avec des changements UX ? Ou devons-nous réellement changer une partie du contenu que nous présentons ? »

Liens dans les messages invités

28:24 "[…] Si [un site Web a] une publication d'invité et que Google ne sait pas s'il est payé ou non, comment Google déterminera-t-il alors qu'il [devrait] prendre ce lien ou graver ce lien ? Quelle est la réponse pour que nous soyons à l'abri sous tous les angles ? »

Selon John, "[…] Nos conseils pour les liens et les publications d'invités sont qu'ils ne doivent pas être suivis . […] Je ferais juste très attention à ce que les liens ne soient pas suivis afin que vous sensibilisiez, que vous parliez de ce que vous faites, que vous le fassiez pour que les utilisateurs puissent accéder à votre page. Mais essentiellement, c'est une publicité pour votre entreprise. Donc de ce point de vue, je leur ferais juste un non-suivi ».

Le prix du produit comme facteur de classement

32:25 "S'il existe deux sites de commerce électronique concurrents qui vendent exactement le même produit - un site Web propose le produit à 500 $, l'autre à 100 $, tous les signaux SEO sont égaux. Le site Web le moins cher aurait-il de meilleures chances d'être classé parce qu'il y a une telle différence de prix pour exactement le même produit ? »

John a déclaré: "Donc, uniquement du point de vue de la recherche sur le Web, non. Ce n'est pas le cas que nous essayions de reconnaître un prix sur une page et de l'utiliser comme facteur de classement. Il n'est donc pas vrai que nous dirions que nous allons prendre le moins cher et le classer plus haut […].

Cependant, un grand nombre de ces produits se retrouvent également dans les résultats de recherche de produits, ce qui peut être dû au fait que vous soumettez un flux ou parce que nous reconnaissons les informations sur les produits sur ces pages. Et les résultats de la recherche de produits, je ne sais pas comment ils sont classés. Il se peut qu'ils tiennent compte du prix ou de choses comme la disponibilité […].

Donc, d'un point de vue de la recherche sur le Web, nous ne prenons pas en compte le prix. Du point de vue de la recherche de produits, c'est possible . Et la partie la plus délicate, je pense, en tant que référenceur, c'est que ces différents aspects de la recherche sont souvent combinés dans une seule page de résultats de recherche, où vous verrez des résultats Web normaux, et peut-être que vous verrez des résultats de produits sur le côté, ou peut-être vous verrez un mélange de cela […] ».

Déplacement d'URL entre les sitemaps

34:04 « Si nous avons 200 fichiers de plan de site et que 20 % à 30 % des URL passent d'un fichier à l'autre chaque semaine, à quel point cela peut-il être grave ? Ou devrions-nous strictement conserver nos URL dans le même fichier pour toujours ? »

“[…] Notre recommandation est généralement de conserver la même URL dans le même fichier sitemap . La principale raison en est que nous traitons les fichiers sitemap à des rythmes différents. Donc, si vous déplacez une URL d'un fichier sitemap à un autre, il se peut que nous ayons la même URL dans nos systèmes à partir de plusieurs fichiers sitemap. Et si vous avez des informations différentes pour cette URL, comme des dates de changement différentes, par exemple, nous ne saurions pas quel attribut utiliser réellement.

Donc, de ce point de vue, si vous l'avez toujours dans le même fichier sitemap, il est beaucoup plus facile pour nous de dire, oh, nous avons les informations pour cette URL ici, et nous pouvons faire confiance à ces informations car elles ne sont que là. C'est donc quelque chose que j'essaie d'éviter […] ces URL se mélangeant au hasard. Mais en même temps, cela ne va généralement pas interrompre le traitement de votre fichier sitemap. Et cela n'aura certainement pas d'effet de classement sur votre site Web. Il n'y a donc rien dans notre système de plan de site qui corresponde à la qualité d'un site Web ».

Contenu multirégional

38:13 "Je travaille dans le secteur de l'actualité. Mon équipe cherche à étendre notre présence internationale et a travaillé à la mise en place de sous-répertoires multirégionaux. Pour la plupart, les pages des différentes éditions multirégionales se ressembleront. La page d'accueil et les pages de section comme la politique ou le mode de vie auront un contenu similaire moins quelques éléments uniques à la région.

Les articles sont délicats. Il n'y a pas grand-chose que nous puissions différencier entre les sous-répertoires multirégionaux en dehors des modules avec des liens connexes, ce qui nous inquiète des problèmes de contenu en double. Comment Google gère-t-il le contenu en double dans l'espace des actualités ? […] Le contenu reste le même, mais les éléments du modèle sont différents. Devrait-il n'y avoir qu'un seul site canonique sur tous les sites Web multirégionaux ? »

La réponse de John a été : « […] Il semble que ce soient des régions différentes au sein d'un même pays, et c'est le même contenu linguistique. […] Si ce sont des pays différents, alors vous avez l'aspect du ciblage géographique, qui joue un rôle si ce sont des langues différentes. Donc, si vous travaillez, disons, en Europe, et que vous couvrez l'Allemagne, la France, l'Italie ou quelque chose comme ça, alors vous avez aussi des langues différentes.

[…] Mais si vous parlez à l'intérieur d'un même pays, d'un même contenu linguistique, alors […] c'est un peu plus facile parce que vous n'avez pas à vous soucier de toutes ces connexions techniques. Mais d'un autre côté, les problèmes de contenu dupliqué sont beaucoup plus visibles. Et lorsqu'il s'agit de contenu dupliqué, l'aspect délicat sur des sites comme ceux-ci est que vous finissez essentiellement par rivaliser avec vous-même. Et si vous avez un article de presse que vous publiez sur […] cinq ou six sites Web régionaux différents, alors tous ces différents sites Web régionaux essaient de se classer pour exactement le même article. Et cela pourrait avoir pour conséquence que cet article ne se classe tout simplement pas aussi bien qu'il le pourrait autrement.

Donc, à cause de cela, je recommanderais d'essayer de trouver des URL canoniques pour ces articles individuels afin que vous puissiez vraiment dire "Eh bien, j'ai cet article sur mes cinq sites Web régionaux, mais c'est ma version préférée que je veux voir dans chercher'. Et puis nous pouvons concentrer toute notre énergie, tous nos signaux, sur cette version préférée, et nous pouvons essayer de la classer un peu mieux. Il n'est pas nécessaire que ce soit toujours la même version. Il se peut donc que vous ayez un article de presse qui se trouve dans une région en quelque sorte canonique, un article de presse différent est plus canonique pour une autre région. La façon dont vous choisissez la région que vous choisissez comme canonique dépend entièrement de vous. […] Habituellement, vous essayez de déterminer où est-ce le plus pertinent et choisissez celui-là comme version canonique. Voilà pour les articles individuels eux-mêmes.

Pour les catégories, les sections et les pages d'accueil, il semble que ce serait quelque chose où le contenu est plus unique et plus spécifique aux régions individuelles. Et à cause de cela, j'essaierais de garder ces niveaux d'index séparés. Donc, si vous avez cinq sites Web régionaux différents, leur page d'accueil, leurs sections de catégorie, ils seraient tous indexés individuellement. Et les articles de presse eux-mêmes seraient mappés sur l'une de ces différentes régions. C'est donc un peu l'approche que nous préconisons là-bas […].

Et cette approche fonctionne également […] sur différents noms de domaine. Donc, si vous avez différents domaines pour des régions individuelles, mais que tout cela fait partie du même groupe de discussion, vous pouvez toujours effectuer ce changement canonique entre les différentes versions. Si vous le faites dans le même domaine avec des sous-répertoires, c'est bien aussi ».

Redirection lors d'un déplacement de site

44:34 "Quel est le meilleur plan d'action à prendre lorsque vous devez rediriger 301 toutes les URL vers un nouvel ensemble d'URL ? Le nombre de pages dépassera le million et vous souhaitez minimiser l'effet bac à sable ? S'il y a un effet bac à sable, combien de temps cela pourrait-il durer ? Allons-nous perdre un classement que nous ne retrouverons peut-être jamais ? Nous prévoyons de faire une redirection individuelle et nous avions demandé des redirections par lots, mais ce n'est pas une possibilité, donc les pages, les images, les URL, etc. devraient basculer en même temps ».

Comme l'a dit John : "Pour moi, cela ressemble à une situation de déplacement de site traditionnelle. Vous passez d'un domaine à un autre, et vous redirigez toutes les URL de votre ancien site vers un nouveau, et nous devons nous en occuper […]. Il n'y a certainement rien de défini comme un effet bac à sable de notre côté lorsqu'il s'agit de déplacer un site . Donc, si vous devez faire un déplacement de site, faites un déplacement de site et redirigez toutes vos pages. C'est souvent l'approche la plus simple qui consiste simplement à rediriger toutes les pages à la fois. Nos systèmes sont également un peu adaptés à cela pour essayer de le reconnaître. Ainsi, lorsque nous voyons qu'un site Web commence à rediriger toutes les pages vers un site Web différent, nous essaierons de retraiter cela un peu plus rapidement afin que nous puissions traiter ce site aussi rapidement que possible. Et ce n'est certainement pas le cas qu'on dise, oh, ils font un déménagement de site, donc, on va ralentir les choses […] ».

API et budget de crawl

46:13 "J'ai un site Web qui se connecte aux API côté client pour obtenir des données. Ces URL sont-elles incluses dans le budget d'exploration ? Si vous interdisez ces URL, […] cela créerait-il des problèmes ? »

"[…] Si ces API sont incluses lors du rendu d'une page, alors oui, elles seraient incluses dans l'exploration, et elles seraient comptabilisées dans votre budget d'exploration essentiellement parce que nous devons explorer ces URL pour afficher la page. Vous pouvez les bloquer par robots.txt si vous préférez qu'ils ne soient pas explorés ou utilisés lors du rendu. Totalement à vous si vous préférez faire cela. Surtout si vous avez une API qui est assez coûteuse à maintenir ou qui prend beaucoup de ressources, alors parfois, cela a du sens.

La partie délicate, je suppose, est que si vous interdisez l'exploration de votre point de terminaison API, nous ne pourrons pas utiliser de données sur les retours d'API pour l'indexation. Ainsi, si le contenu de votre page provient uniquement de l'API et que vous n'autorisez pas l'exploration de l'API, nous n'aurons pas ce contact. […] Si l'API fait juste quelque chose de complémentaire à la page, comme peut-être dessine une carte ou […] un graphique d'un tableau numérique que vous avez sur une page, […] alors peut-être que ce n'est pas grave si ce contenu est 't inclus dans l'indexation. L'autre chose est que parfois, le fonctionnement d'une page lorsque l'API est bloquée n'est pas trivial. En particulier, si vous utilisez JavaScript et que les appels d'API sont bloqués à cause de robots.txt, vous devez gérer cette exception d'une manière ou d'une autre. Et selon la façon dont vous intégrez le JavaScript sur la page, ce que vous faites avec l'API, vous devez vous assurer qu'il fonctionne toujours. Donc, si cet appel API ne fonctionne pas, et que le reste du rendu de la page s'interrompt complètement, nous ne pouvons pas indexer grand-chose car il ne reste plus rien à rendre.

Cependant, si l'appel de l'API s'interrompt et que nous pouvons toujours indexer le reste de votre page, cela pourrait parfaitement convenir. […] Je pense que c'est plus délicat si vous exécutez une API pour d'autres personnes, car si vous interdisez l'exploration, vous avez en quelque sorte cet effet de second ordre que le site Web de quelqu'un d'autre pourrait dépendre de votre API. Et selon ce que fait votre API, tout à coup, leur site Web n'a pas de contenu indexable. Et ils pourraient même ne pas le remarquer parce qu'ils n'étaient pas au courant que tout à coup, vous avez ajouté une interdiction ici. Et cela pourrait provoquer des sortes d'effets indirects […] ».

Cache JavaScript et Google

49:36 "Il y a donc deux pages qui proviennent du même domaine. L'URL est un peu différente, qui fait partie de la même structure de répertoires. Et […] ils sont générés par NextJS. NextJS est donc un framework de réaction rendu côté serveur. Et ils sont indexés, mais je vois une page dans le cache de Google, et la deuxième page n'est pas dans le cache de Google. Et je vois le même schéma quelle que soit la façon dont je génère la page […]. La plupart de mes pages sont dans le cache de Google, mais maintenant je suis inquiet car je passe actuellement de ma pile technologique basée sur Java, qui génère toutes ces pages, à Google NextJS. […] Lors du débogage, j'ai découvert que c'était aussi un problème avec l'ancienne pile Java que nous utilisions.

La question est donc en deux parties. En gros, pourquoi ce comportement ? Et deuxièmement, ce comportement aura-t-il un impact sur mon classement ? Je vois ces pages apparaître dans les résultats de recherche qui ne sont pas dans le cache de Google ».

John a répondu : « […] Les pages de cache sont complètement séparées de ce que nous indexons. Donc s'il y a une page de cache ou pas, ça n'a pas du tout d'importance pour le classement, ça n'a pas du tout d'importance pour l'indexation . Parfois, il y a des raisons techniques pour lesquelles nous n'avons pas de page de cache. Parfois, nous n'avons tout simplement pas de page de cache pour les URL individuelles. L'autre chose est que si la page utilise un framework JavaScript, il est parfois délicat de savoir si JavaScript s'exécute ou non sur une page de cache, car la page de cache est hébergée sur un domaine Google. Selon le type de JavaScript que vous avez, où il extrait les fichiers JavaScript, parfois, le JavaScript ne peut pas s'exécuter sur le domaine Google.

[…] La page cache n'est pas la page rendue. Il s'agit essentiellement du fichier HTML que nous avons demandé et d'une copie de celui-ci. Et si le fichier HTML montre quelque chose, c'est bien. S'il utilise JavaScript et que le JavaScript ne s'exécute pas car il s'agit d'une page de cache, c'est tout aussi bien. Vous ne le voyez tout simplement pas dans la page de cache. Donc, si la page de cache ne s'affiche pas, je ne m'en soucierais pas. Ce n'est pas le signe d'un problème. Et souvent, […] vous ne pouvez pas contrôler s'il y a une page de cache ou non. J'ignorerais simplement cela ».

https://www.youtube.com/watch?v=Vd0rEQrwHDc