Heures de bureau SEO – 24 décembre 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 24 décembre 2021.

Contenu payant et cloaking

00:49 "En ce qui concerne les données payantes avec du contenu payant. […] Nous avons un site Internet. Nous avons fait beaucoup d'articles, et tout est accessible à Google. Et nous aimerions y ajouter un paywall, mais […] seulement […] montrer le contenu payant à Google avec les extraits de données structurés dont vous disposez. Est-ce considéré comme du camouflage ?

Donc, je vérifie s'il s'agit de Googlebot, et je montre [ensuite] seulement […] les données structurées – […] les données payantes. Mais alors pour l'utilisateur régulier […], je ne montre pas les données structurées, ça va ? »

John n'a pas vu le problème avec cette solution : « C'est bien. Cela , techniquement, serait toujours considéré comme une dissimulation, car vous montrez quelque chose de différent, mais d'après nos politiques, c'est acceptable. Parce que les utilisateurs, […] s'ils passent par le paywall, […] verraient le contenu que vous montrez à Googlebot.

Problèmes d'indexation potentiels

03:38 "Je publie du contenu de haute qualité, j'ai soumis un sitemap et je demande parfois l'indexation à partir de Google Search Console. Mais j'ai toujours un problème pour indexer le nouveau contenu, ou il est indexé [avec un retard]. […] C'est un bug de Google, ou c'est une nouvelle mise à jour de l'algorithme ?

John a répondu: "Il n'y a pas de bogue de notre côté à cet égard. […] Nous n'indexons tout simplement pas tout le contenu , et certains sites génèrent beaucoup de contenu. Et si on n'indexe pas tout […], ça peut aller. Mais peut-être voulez-vous que tout soit indexé, et nous ne pouvons pas tout faire tout le temps.

La partie délicate […] est que, dans le passé, […] beaucoup de sites Web n'étaient techniquement pas si géniaux. Il était un peu plus clair quel type de contenu n'était pas indexé. De nos jours, les sites Web sont techniquement corrects, et c'est […] comme si la barre de qualité était un peu plus haute […]. N'importe qui peut publier quelque chose qui, théoriquement, pourrait être indexé, mais […] nous devons nous assurer que nous indexons les bonnes choses qui sont réellement utiles et pertinentes pour les utilisateurs. Nous devons donc parfois laisser certaines choses non indexées.

Mise à jour des avis sur les produits – langues et pays concernés

14:01 "À propos de la mise à jour des avis sur les produits. […] Même si la mise à jour ne concerne que les sites Web anglophones, je voyais également des mouvements dans la recherche allemande. Je me demandais s'il pourrait également y avoir un effet sur les sites Web dans d'autres langues par cette mise à jour des avis sur les produits ou tout autre type […] ? »

Comme l'a dit John, « Mon hypothèse était que c'était mondial et dans toutes les langues […]. Mais généralement, nous essayons de pousser l'équipe d'ingénierie à prendre une décision à ce sujet, afin que nous puissions la documenter correctement dans le billet de blog. Je ne sais pas si cela s'est produit avec la mise à jour des avis sur les produits. […] Cela ressemble à quelque chose que nous pourrions faire dans plusieurs langues et qui ne serait pas lié uniquement à l'anglais. Et même si c'était l'anglais au départ, cela semble être quelque chose de pertinent à tous les niveaux, et nous devrions essayer de trouver des moyens de l'étendre également à d'autres langues au fil du temps. Je ne suis donc pas particulièrement surpris que vous voyiez les changements en Allemagne […].

Après avoir appris que l'article du blog de Google ne mentionnait que la mise à jour affectant les sites Web en anglais, John a précisé :

«Avec ce type de mises à jour, nous essayons de démarrer avec une langue ou un emplacement et de voir ce que nous devons modifier, puis nous nous développons à partir de là. […] Avec quelque chose qui est plus lié au contenu, il faut généralement un peu plus de temps pour s'étendre à différentes langues […].

Localisation des pages pour les pays anglophones

17:53 « Connaissez-vous d'autres moyens de localiser le même ensemble de pages pour différents pays anglophones ? […] Nous avons plusieurs sous-domaines avec un domaine de premier niveau .jo, comme peut-être des sous-domaines d'Australie, de Nouvelle-Zélande, et nous avons défini le pays dans le backend JSA et utilisons également hreflang au niveau de la page. […] Nous n'avons pas trouvé d'autres moyens de nous aider à localiser ces sous-domaines. Avez-vous de bonnes méthodes ou des moyens que nous pouvons améliorer ? »

Voici comment John a abordé ce sujet :

« Je pense que vous avez couvert les principaux. C'est le ciblage géographique dans la Search Console et les paramètres hreflang.

Le ciblage géographique fonctionne au niveau d'un sous-répertoire ou d'un sous-domaine, toutes les pages s'y trouvent.

Hreflang est sur une base par page. Si vous avez une page d'accueil pour un pays et différentes pages de produits pour le même pays, chacune de ces pages devra être croisée avec hreflang.

L'autre chose que j'essaie toujours de recommander est d'avoir une sorte de plan de sauvegarde, […] quelque chose comme une bannière basée sur JavaScript que vous pouvez afficher lorsque vous reconnaissez que l'utilisateur est sur la mauvaise version d'un site. Par exemple, si un utilisateur d'Australie se retrouve sur la page d'Angleterre, vous pouvez afficher une bannière JavaScript indiquant "Hé, nous avons ici une version australienne de cette page". Vous pouvez y aller directement. L'avantage d'une bannière basée sur JavaScript est que vous pouvez la bloquer avec robots.txt afin qu'elle ne s'affiche pas du point de vue de l'indexation. Et si vous ne redirigez pas automatiquement, […] [les moteurs de recherche] pourront traiter ces deux versions indépendamment.

Si ces pages sont essentiellement les mêmes, il peut arriver que nous traitions l'une de ces pages comme la version canonique. Par exemple, si vous avez une page pour la Nouvelle-Zélande et l'Australie, et que tout le contenu est le même, la seule chose qui est légèrement différente est la devise sur la page, alors […] nous plions ces pages ensemble et en choisissons une comme un canonique, et l'utiliser comme base pour la recherche.

Si vous avez un hreflang, sur ces pages également, nous utiliserons toujours le hreflang pour afficher la bonne version de l'URL. Mais le contenu indexé proviendra uniquement de la version canonique, et tous les rapports dans la Search Console concerneront la version canonique. Cela rend parfois les choses un peu délicates, surtout si vous avez un site Web plus grand avec […] le même contenu pour différents pays.

Ajouter du contenu dynamique aux pages

25:0 "Mon site Web contient des millions de pages, comme des pages de catégories, de sous-catégories et de produits, de commerce électronique […]. Nous avons ajouté du contenu dynamique, car [avec] des millions de pages […] [il est] difficile d'ajouter un contenu séparé ou […] un contenu unique sur chaque page. Nous avons ajouté […] du contenu basé sur des modèles sur les pages de catégories, les pages de sous-catégories et les pages de produits. […] Ce serait bon pour les performances de notre site Web ou non, ou devrions-nous mettre à jour le contenu de chaque page ? […] ».

Voici comment John a répondu :

« L'ajout dynamique de contenu pertinent à une page […] peut avoir du sens parce que […] [il] s'agit essentiellement de faire […] une recherche dans la base de données et d'ajouter du contenu en fonction de cela. […] Cela dépend vraiment de la façon dont vous avez configuré cela.

La principale chose que j'éviterais est que vous vous retrouviez dans une situation où vous ajoutez artificiellement du contenu à une page dans l'espoir que cette page se classe mieux pour les mots-clés que vous ajoutez artificiellement. […] Lorsque les utilisateurs s'y rendront, ils se demanderont 'Pourquoi ces mots-clés aléatoires sont-ils sur cette page ?' […] S'assurer que vous avez réellement un bon contenu pertinent pour ces mots-clés clés, c'est plutôt ce sur quoi je me concentrerais […].

Lorsqu'on lui a également demandé s'il était nécessaire d'écrire un contenu pertinent pour chaque page pour que Google considère les pages comme apportant de la valeur, John a répondu :

"Cela devrait être quelque chose sur la page qui est pertinent. Et s'il s'agit d'une page de catégorie, alors les produits que vous y avez répertoriés sont très pertinents […] et généralement, vous avez une description de cette catégorie. […] Ce n'est pas que vous devez écrire un article Wikipédia en bas sur tous ces produits et d'où ils viennent […] mais un peu d'information qui est pertinente pour la page, ça compte.

Rendu et indexation des fichiers JavaScript

28:28 « Mon site Web […] [utilise] Réagir avec le rendu côté client, […] lorsque nous désactivons JavaScript et le navigateur, ma page est totalement vide. Cela peut être la cause d'un classement inférieur ou peut-être de la mauvaise performance de la page Web ? »

La réponse de John a été : « Cela ne devrait pas être le cas. […] Pour la recherche, nous faisons du rendu, et nous traitons le JavaScript sur les pages. S'il est visible dans un navigateur normal et que vous ne faites rien de particulièrement mauvais, nous pourrons alors indexer ces pages normalement. Vous pouvez revérifier avec l' outil Inspecter l'URL de la Search Console pour voir si le contenu est réellement visible lorsque Googlebot essaie de rendre la page, et si le contenu est visible, alors vous devriez être prêt .

Indexation des URL générées par la recherche sur un site Web

30:11 "Nous avons déjà ajouté un champ de recherche sur notre site Web , de sorte que l'utilisateur vient sur notre site Web et effectue une recherche là-bas, et cela génère une URL unique pour chaque recherche. Ces URL doivent être indexables ou non ?"

Comme l'a dit John, " généralement pas. […] Il y a deux raisons principales à cela.

D'une part, il est très facile de se retrouver dans une situation où vous avez un autre million d'URL qui ne sont que des recherches différentes, ce qui ne vous apporte aucune valeur. Nous l'appelons un espace infini […]. C'est quelque chose que vous voulez éviter.

L'autre chose que vous voulez éviter, c'est que les gens fassent des spams dans le champ de recherche et essaient d'indexer ces choses , ce qui pourrait être quelque chose comme rechercher leur numéro de téléphone, et […] leur type d'entreprise […]. Soudain, la page de recherche de votre site Web se classe pour ce type d'entreprise et affiche son numéro de téléphone, même si vous n'avez aucun contenu correspondant à ces requêtes, […] ils le font pour essayer d'être visibles dans les résultats de recherche. Je bloquerais ce genre de pages de recherche avec robots.txt. De cette façon, vous pouvez être sûr que nous ne pourrons indexer aucun contenu. »

Sites de référencement comme YMYL

31:55 "Une entreprise de référencement serait-elle classée comme un site Web Votre argent ou Votre vie , ou est-elle uniquement liée à des sites Web de conseils médicaux et financiers ?"

Selon John, "[…] Je ne pense pas que les sites Web de référencement soient si essentiels à la vie des gens. De toute évidence, si vous travaillez dans une société de référencement, vous êtes lié à cela, mais ce n'est pas que le site Web lui-même soit un site Web de type Your Money ou Your Life. […] Tous les sites Web qui vendent quelque chose n'entrent pas dans cette catégorie.

Ce que je recommanderais ici, c'est plutôt que d'essayer aveuglément de voir "Ce type de site Web appartient-il à cette catégorie spécifique ?", […] lisez d'où vient cette catégorie, à savoir les directives de l'évaluateur de qualité, et comprenez un peu plus ce que Google essaie de faire pour comprendre ces différents types de sites Web . […] Cela vous donnera un peu plus d'informations générales sur ce qui se passe réellement […].

Mise en œuvre de données structurées en fil d'Ariane

39:56 "En ce qui concerne les données structurées en fil d'Ariane, doivent-elles être exactement les mêmes que les fils d'Ariane qu'un visiteur verrait sur une page ? Je vois parfois une version condensée du fil d'Ariane sur la page, tandis que les données structurées sont un chemin de fil d'Ariane complet. Les deux options sont-elles acceptables ? »

Comme l'a dit John, "[…] Nous essayons de reconnaître si les données structurées sont visibles sur une page ou non. Et si ce n'est pas le cas […], il faut se demander « Est-ce que ça a encore du sens de montrer ça dans les résultats de recherche ? ”

Si vous faites quelque chose comme afficher une version plus courte d'un fil d'Ariane sur une page, et que nous ne pouvons pas faire correspondre cela, cela pourrait être un peu hasardeux, si nous prenons réellement ce balisage de fil d'Ariane et l'utilisons.

Si vous prenez des miettes individuelles ou […] les éléments individuels de la liste de fil d'Ariane, et que vous n'en montrez que quelques-uns mais pas tous, il se peut que nous ne les prenions que. Il se peut que nous ramassions encore le reste parce que nous voyons […] beaucoup de correspondances de fil d'Ariane.

Il n'est pas garanti que nous serons en mesure de récupérer et d'utiliser le fil d'Ariane complet que vous avez si vous ne l'affichez pas sur la page , et cela est similaire à d'autres types de données structurées.

Je pense que la principale exception […] est […] le balisage FAQ, où vous avez des questions et des réponses, où […] la partie importante est que la question est réellement visible, et la réponse peut être quelque chose comme une section réduite sur un page, mais […] doit au moins être visible.

Traduire seulement certaines pages d'un site Web

44:00 "Nous gérons un site avec moins de 300 pages d'index, toutes en anglais. Nous cherchons à traduire environ la moitié de ces pages en espagnol qui seront placées dans le sous-répertoire sur le même domaine, comme /ES, et étiquetées comme des versions linguistiques alternatives du contenu en anglais. Est-il acceptable de ne traduire qu'une partie du contenu de la page, ou devrions-nous tout traduire pour refléter exactement le site Web anglais et avoir les meilleures chances de classement dans d'autres endroits ? »

John a déclaré : « C'est bien de simplement traduire quelques pages sur un site Web. Nous examinons la langue des pages individuellement. Si vous avez des pages en espagnol, nous regardons simplement ces pages en espagnol, quand quelqu'un fait une recherche en espagnol. Ce n'est pas vrai que nous dirions : « Il y a beaucoup plus de pages en anglais que de pages en espagnol ici. Par conséquent, le site espagnol est moins important. […] Ce sont des pages espagnoles, et elles peuvent bien se classer en espagnol. […] Pour les utilisateurs, parfois, il est logique de faire traduire le plus de contenu possible. Mais généralement, c'est quelque chose que vous améliorez progressivement au fil du temps, où vous commencez avec certaines pages, vous les localisez bien et ajoutez plus de pages […].

Les annotations hreflang sont également sur une base par page. Si vous avez des pages en anglais et en espagnol, et que vous les liez, c'est parfaitement bien. Si vous avez des pages uniquement en espagnol, c'est très bien - vous n'avez pas besoin de hreflang. Quelques pages juste en anglais, ça va aussi. De ce point de vue, cela semble être une façon raisonnable de commencer.

Budget de crawl et URL générées automatiquement

46:12 "Le site Web dont je parle est un site Web WordPress. Il génère automatiquement plusieurs URL indésirables. […] Existe-t-il un moyen d'arrêter le robot d'exploration pour trouver ces URL ? Je sais que je peux le "noindexer", et ce ne sont pas des URL indexées. Mais ensuite, je peux les voir sur la console de recherche sous la partie exclue. […] C'est un site d'information, nous avons des milliers d'URL. […] Cela va-t-il affecter le budget rampant ?

John s'est renseigné sur la taille du site Web et on lui a dit qu'il comptait entre 5 000 et 10 000 URL.

Compte tenu de cela, John a déclaré: « Je ne m'inquiéterais pas du budget rampant. […] Nous pouvons explorer ce nombre de pages assez rapidement, généralement en quelques jours. L'autre chose […] est le 'noindex' est une balise meta sur la page. Nous devons explorer la page pour voir la balise meta, ce qui signifie que vous ne pouvez pas éviter que nous vérifions les pages "noindex". […] Si nous voyons qu'il y a un 'noindex' sur la page, alors généralement avec le temps, nous crawlons ces pages moins souvent. Nous revérifierons toujours de temps en temps, mais nous ne vérifierons pas autant qu'une page normale qui est autrement indexée. L'autre approche consiste à utiliser robots.txt. Avec le fichier robots.txt, vous pouvez bloquer complètement l'exploration de ces pages. L'inconvénient est que parfois l'URL elle-même peut être indexée dans les résultats de recherche, pas le contenu de la page […].

Jean a également donné l'exemple suivant :

"Si vous […] avez un site Web d'informations sur le football et que vous avez des articles bloqués et des articles autorisés à explorer, alors si quelqu'un recherche des informations sur le football, il trouvera les versions indexables de vos pages, et il peu importe qu'il y ait d'autres pages bloquées par robots.txt. Cependant, si quelqu'un effectue explicitement une requête sur le site pour ces pages bloquées, vous pourrez alors voir ces URL dans la recherche […]. Dans une situation comme la vôtre, […] je ne me soucierais pas du crawl budget.

John a également ajouté : « D'un point de vue pratique, le « noindex » et le robots.txt seraient en quelque sorte équivalents. […] Ce contenu n'apparaîtrait probablement pas dans les résultats de recherche, et nous aurions encore besoin de le crawler s'il y avait 'noindex', mais les nombres sont si petits qu'ils n'ont pas vraiment d'importance. On peut toujours l'indexer avec une URL s'ils sont bloqués par robots.txt […] ».

Concernant la méthode préférée, John a déclaré : « Je choisirais celle qui est la plus facile à mettre en œuvre de votre côté. Si […] vous avez WordPress et que vous pouvez simplement avoir une case à cocher sur le message qui dit « Cette page n'est pas indexée », c'est peut-être l'approche la plus simple [...]. »

Explorer des URL avec des paramètres

54:25 "Nous voyons dans nos fichiers journaux, et prouvant également qu'il s'agit de Googlebot via IEP, beaucoup d'explorations du bot organique aux URL de paramètres UTM, Google Display et campagnes d'applications universelles. […] Nous ne voyons aucun lien provenant de n'importe où vers ces URL. […] Avez-vous une idée de l'endroit ou de la raison pour laquelle cela pourrait se produire ? »

John a répondu que "le seul endroit où, avec Googlebot, nous explorons également les pages que vous répertoriez dans les campagnes publicitaires […] est pour la recherche de produits. Si vous avez configuré un flux de recherche de produits ou un flux Merchant Center […], nous explorerons également ces pages pour Googlebot afin de nous assurer que nous pouvons les récupérer pour Merchant Center. Si vous y avez balisé des URL, […] nous conserverons ces URL balisées et les retraiterons.

Il se peut aussi que d'autres personnes soient en mesure de soumettre ce genre de produits, […] ce n'est peut-être pas forcément vous qui les soumettez, mais peut-être quelqu'un qui travaille en votre nom ou a également la permission de le faire.

Si nous trouvons des liens vers ces pages quelque part, nous essaierons de les explorer. Si vous avez marqué des liens internes dans un site Web, nous essaierons toujours de les récupérer et de les explorer. Si vous avez des choses configurées en JavaScript, vous avez peut-être des URL de suivi avec ces paramètres configurés quelque part, et lorsque nous traitons le JavaScript, il semble qu'il s'agisse d'un lien vers ces URL de suivi, nous pourrions également traiter cela. […] Il me semble qu'il ne s'agit pas de cas individuels […], mais plutôt d'un grand nombre de ces URL, et cela ressemble beaucoup au côté Merchant Center des choses.