Heures de bureau SEO, 4 mars 2022

Publié: 2022-03-22

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

Masquer le contenu
1 Test du balisage de schéma dans le validateur schema.org par rapport à Google Search Console
2 Raisons pour lesquelles une page peut être explorée mais pas indexée
3 La suppression des listes de produits sur un site de commerce électronique peut-elle vous désavantager ?
4 L'importance de la structure de liens internes
5 Plusieurs schémas de produits sur la page de liste de produits
6 Votre classement peut-il souffrir si vous créez des pages multilingues ?
7 Différences de contenu entre les versions mobiles et de bureau
8 Pouvez-vous héberger votre sitemap dans un cloud ?
9 L'historique d'un domaine peut-il affecter votre site Web ?

Test du balisage de schéma dans le validateur schema.org par rapport à Google Search Console

7:41 "John, donc ma première question est, Google Search Console génère une erreur […] dans l'élément de données structurées requis. Mais lorsque je vérifie la même chose sur validator.schema.org, il n'affiche aucun avertissement ni aucune erreur. Donc la première question est, est-ce le bon site pour vérifier l'implémentation AMP d'une page web ? […]"

John a répondu : « Ouais, donc ces outils de test ont des objectifs légèrement différents. C'est probablement pourquoi vous voyez cette différence. L'outil de test de schema.org consiste davantage à comprendre le balisage schema.org en général, comme dans l'ensemble, en fonction des exigences de schema.org. Et l'outil de test de la Search Console se concentre uniquement sur ce que nous pouvons extraire des données structurées et utiliser pour afficher dans la fonction de recherche. Il est donc vraiment axé sur la partie Recherche de cette histoire. Et dans la recherche, nous n'utilisons qu'une petite partie du balisage schema.org. Et parfois, nous avons des exigences légèrement différentes selon lesquelles nous avons peut-être besoin d'un élément spécifique plus que le balisage schema.org de base ne l'exigerait. Et c'est souvent pourquoi vous voyez cette différence. Et le validateur schema.org est pour le balisage théorique, et le validateur Google est vraiment pour le côté pratique de la recherche Google. "

9:20 "[…] Fondamentalement, ce n'est pas une erreur. C'est un avertissement dans la Search Console. Et lorsque je vérifie les détails dans la Search Console, cela indique simplement que vous ne le faites pas correctement. Alors, y aura-t-il un moyen possible [de résoudre le problème], ou mon équipe de développement devrait-elle le découvrir ?

John a expliqué: «Oui, si c'est un avertissement, alors je ne m'en soucierais pas. Il s'agit simplement de dire que vous auriez pu faire quelque chose de différent. […]. Ce que je ferais si vous voulez savoir quelle est exactement la différence, c'est de revérifier la documentation sur developers.google.com pour la recherche, où nous avons toutes les données structurées documentées et tous les champs obligatoires et recommandés. Et probablement l'un des champs recommandés ou facultatifs est ce qui déclenche cet avertissement.

Raisons pour lesquelles une page peut être explorée mais pas indexée

14:11 " Quelle est la raison possible pour laquelle [...] certaines pages n'ont pas été indexées, même si elles ont été explorées plusieurs fois ?

John a répondu: « Cela peut arriver. Je suppose que ce n'est pas si fréquent car, généralement, lorsque nous décidons d'explorer quelque chose, nous sommes également très heureux de l'indexer. Mais il peut arriver que nous crawlons une page et que nous décidions finalement que nous n'avons pas besoin de l'indexer.

[…] certaines situations courantes où cela peut se produire, qui ne s'appliquent peut-être pas à votre cas, sont s'il y a un code d'erreur sur la page. Nous devons d'abord l'explorer, puis nous voyons le code d'erreur. S'il y a un noindex sur la page, nous devons également le parcourir en premier, puis nous voyons le noindex. Si la page est une copie complète de quelque chose d'autre que nous avons déjà vu, nous l'explorons, nous voyons qu'il s'agit d'une copie, mais nous nous concentrons à nouveau sur la page principale. Ce sont donc des situations normales où nous explorons quelque chose et ne l'indexons pas. Mais il peut aussi arriver que nous crawlons quelque chose et qu'au moment où nous arrivons à l'indexation, nous décidions, oh, eh bien en fait, nous voulons plutôt obtenir autre chose du site Web.

15:41 "[…] quels autres facteurs [outre ceux déjà mentionnés] peuvent amener Googlebot à décider, oh, nous ne voulons pas l'indexer à la fin ?"

John a dit : « Je ne sais pas tout de suite. Je pense que la qualité globale du site Web joue certainement un rôle là-bas, mais généralement, si nous ne sommes pas convaincus de la qualité du site Web, nous n'explorerons probablement pas la page en premier lieu. C'est donc, je pense, une situation délicate. Et si vous regardez dans la Search Console, je pense que, à peu près pour chaque site, vous aurez le regroupement des sites découverts mais non indexés et également explorés et non indexés. C'est, je pense, assez courant sur tous les sites.

La personne qui posait la question voulait savoir s'il y avait autre chose qu'elle devrait examiner, à l'exception de la qualité de la page et des problèmes techniques. John leur a recommandé de ne pas trop se concentrer sur une page : « Je pense aussi qu'il est important de ne pas trop se concentrer sur cette page spécifique. Donc, si vous êtes sûr que, d'un point de vue technique, tout va bien, je ne présumerais pas que la qualité de cette page spécifique soit un problème, mais plutôt la qualité perçue de cette partie du site Web ou du tout le site lui-même. C'est en quelque sorte l'endroit où j'essaierais de voir ce que vous pouvez faire pour améliorer les choses, pas seulement cette page individuelle qui n'a pas été indexée, mais en quelque sorte quelle est la vue d'ensemble autour de cette page.

La suppression des listes de produits sur un site de commerce électronique peut-elle vous désavantager ?

21:48 « Nous gérons donc un site Web de commerce électronique, et nous sommes maintenant dans une étape où nous voulons apporter des mises à jour majeures à nos pages de catégorie. […] en un seul projet, nous voulons nous débarrasser des listes de produits. Vous avez donc les listes de produits avec la recherche à facettes, où vous pouvez filtrer les produits que vous recherchez. […] lorsque nous supprimons toute la liste des produits des pages de catégories, aurions-nous un désavantage dans les classements parce que, premièrement, tous les autres concurrents ont ce genre de listes de produits ? Et deuxièmement, je suppose que c'est un élément tellement établi pour les pages de commerce électronique que les utilisateurs s'attendent […] à avoir une sorte d'aperçu de tous les produits et les filtres leur permettent de rechercher les produits qu'ils veulent.

John a répondu : « Je n'y verrais aucun problème d'un point de vue SEO. Je pense qu'il y a différentes choses auxquelles vous voudriez faire attention, […] afin que nous puissions toujours trouver tous les produits individuels pour lesquels nous avons des liens propres là-bas. Mais si vous êtes juste en train de repenser cette page de catégorie et de la faire ressembler davantage à une page d'information, je ne m'attendrais pas à des problèmes avec cela. Je ne pense pas non plus que nous fassions quoi que ce soit de spécial avec ce genre de pages de catégorie dans la recherche de toute façon, donc de ce point de vue, vous changez simplement la conception, essentiellement.  

Je pense que ce serait différent s'il s'agissait d'une page de produit, et que vous deviez la changer complètement parce que nous essayons de reconnaître les pages de produits et de déterminer où est le prix, où est la disponibilité , ce genre de choses. Et si vous lui donniez un aspect complètement différent […], alors je pourrais imaginer que cela affecte la façon dont nous sélectionnons les pages de produits et si nous pouvons l'afficher ou non dans les résultats de recherche de produits. Mais les pages de catégories, autant que je sache, nous ne faisons rien de spécial avec elles. Donc, si vous les cachez, essentiellement, et que vous vous assurez que nous pouvons toujours trouver les liens vers les produits […] vous pouvez le faire. Mais si vous voulez les rendre plus utiles en fournissant plus d'informations à leur sujet, je pense que c'est une bonne idée.

À la fin de la question, John a ajouté qu'il est important de vérifier les changements du point de vue de l'utilisateur : "[…] vous avez mentionné 'les utilisateurs seraient-ils confus'. Je revérifierais cela. Donc, du côté SEO, je pense que c'est parfaitement bien, mais du côté utilisateur, c'est probablement quelque chose que vous voudriez tester en premier.

L'importance de la structure de liens internes

25:18 « Si vous disposez de données structurées pour la configuration du fil d'Ariane, les liens internes sont-ils toujours importants pour le référencement ? »

John a répondu: «Oui, absolument. C'est quelque chose où les liens internes sont super critiques pour le référencement. Je pense que c'est l'une des choses les plus importantes que vous puissiez faire sur un site Web pour guider Google et guider les visiteurs vers les pages que vous jugez importantes. Et ce que vous pensez être important dépend entièrement de vous. Vous pouvez décider de rendre les choses importantes là où vous gagnez le plus d'argent, ou vous pouvez rendre les choses importantes là où vous êtes le concurrent le plus fort, ou peut-être êtes-vous le concurrent le plus faible. Avec les liens internes, vous pouvez vraiment vous concentrer sur ces directions et ces parties de votre site. Et ce n'est pas quelque chose que vous pouvez simplement remplacer par des données structurées.

Donc, juste parce qu'il y a des données structurées sur une page quelque part, je ne verrais pas cela comme un remplacement pour les liens internes normaux. Même si dans les données structurées, vous fournissez également des URL, nous n'utilisons pas ces URL de la même manière que nous utiliserions des liens internes normaux sur une page. Il n'est donc certainement pas vrai que les annotations hreflang remplacent les liens entre les versions nationales, ou que les annotations fil d'Ariane remplacent les liens entre les différents niveaux d'un site Web. Vous devriez vraiment avoir des liens HTML normaux entre les différentes parties de votre site Web. Et, idéalement, vous ne devriez pas seulement avoir un ensemble de liens de base, mais plutôt l'examiner de manière stratégique et réfléchir à ce qui vous intéresse le plus, et comment pouvez-vous le mettre en évidence avec votre lien interne ?

Plusieurs schémas de produits sur la page de liste de produits

29:50 « Pour une page de liste de produits, pouvons-nous implémenter plusieurs schémas de produits sur la page de liste de produits ?

John a déclaré : « De notre point de vue politique, je ne pense pas que vous devriez faire cela, du moins la dernière fois que j'ai vérifié les politiques relatives aux données structurées, car pour les données structurées produit, nous voulons vraiment que cela s'applique au principal. élément de la page. Et si vous avez plusieurs produits sur une page, ce n'est pas que l'un d'eux soit l'élément principal de la page. Donc, de ce point de vue, vous ne devriez pas utiliser plusieurs éléments de données structurées de produits sur une page de catégorie […].

Votre classement peut-il souffrir si vous créez des pages multilingues ?

30:30 " Existe-t-il une bonne pratique pour les pages avec un langage mixte utilisé ? Par exemple, notre école internationale au Japon s'adresse aux familles japonaises et non japonaises, mais nous gardons la plupart des informations sur notre page d'accueil en anglais. Nous ajoutons également un support sur la page en japonais. […] Étant donné que notre communication dans la vraie vie est un langage mixte, avoir la page d'accueil reflétant cela semblait plus naturel. Sommes-nous punis dans la recherche si une page est une langue intentionnellement mélangée ? »

John a répondu : « Je ne dirais pas nécessairement qu'une page est punie dans un cas comme celui-là. Mais nous essayons de comprendre quelle est la langue principale d'une page, et cela nous aide à comprendre pour quel type de requêtes nous pourrions afficher cette page. Donc, je pense que c'est un peu délicat dans un cas comme celui-ci.

Nous pouvons également comprendre lorsqu'il y a plusieurs langues sur une page. Il nous est simplement beaucoup plus facile d'être clair sur le fait que, si quelqu'un effectue une recherche en anglais, c'est la bonne page à lui montrer. Je peux donc imaginer que pour quelque chose comme une page d'accueil, il est peut-être logique d'avoir ce mélange ou un léger mélange. Si vous avez une page d'accueil en anglais principal, incluez peut-être des éléments en japonais. Si vous avez une autre version principalement japonaise, avec quelques éléments en anglais, ça va. Mais cela nous aide à vraiment comprendre que, pour la plupart, il s'agit d'une page en anglais. Et si quelqu'un recherche en anglais un type spécifique d'école internationale au Japon, il est logique pour nous de dire, eh bien, voici un contenu en anglais qui, nous le savons, correspond à vos besoins et qui correspond aux requêtes que vous nous avez données. Donc, de ce point de vue, je ne dirais pas nécessairement que la page est punie, mais il est beaucoup plus difficile pour nos systèmes de déterminer comment classer correctement cette page.

L'une des choses auxquelles vous pouvez penser ici est de regarder dans la Search Console quelles requêtes vont sur votre site Web ou sur votre page d'accueil. Et pensez à laquelle de ces requêtes pourrait être affectée si Google ne comprenait pas correctement la langue. Et il se pourrait bien que si la plupart des gens recherchent votre nom ou la marque de votre école, cela ne serait probablement pas du tout affecté. D'un autre côté, si la plupart des gens recherchent des requêtes plus larges, des requêtes plus génériques, presque comme une phrase qui correspondrait à quelque chose sur votre page d'accueil, alors je peux imaginer qu'il serait un peu plus difficile pour vous d'apparaître dans les résultats de recherche pour , simplement parce que nous ne savons pas si votre page d'accueil est réellement dans la langue de cette requête […].

Une chose que vous pourriez également faire, […] est de faire en sorte que votre page d'accueil ressemble à cette version bilingue […] mais de créer des pages séparées en plus pour la langue individuelle afin que si quelqu'un recherche des informations détaillées sur une école internationale comme cela, ils peuvent toujours trouver ces pages en anglais pur ou principalement en anglais, puis, à partir de là, passer au reste de votre site Web […].

Différences de contenu entre les versions mobiles et de bureau

34:20 " S'il y a une différence entre le contenu de la version mobile et de bureau, cela signifie-t-il que Google punira le site Web et affectera le classement du site Web, ou cela signifie-t-il simplement que Googlebot peut le trouver dans la version mobile, mais il a gagné 't être en mesure de classer?

John a déclaré : « Donc, pour la plupart, nous avons déplacé la majeure partie de notre indexation vers l'indexation mobile d'abord, ce qui signifie que nous ne regarderions que la version mobile d'un site Web dans un cas comme celui-là. Donc, essentiellement, s'il y a quelque chose qui est légèrement différent sur la version de bureau d'un site Web, nous n'utiliserions même pas cela pour la recherche. Donc, ce n'est pas que nous punirions un site Web à cause d'une différence, mais plutôt, c'est comme si nous regardions simplement une version du site Web, et nous ne savons même pas ce qu'il y a sur l'autre version pour le traiter différemment .  

Et pour la poignée de sites qui sont encore en indexation de bureau, cela s'applique dans l'autre sens. Bien sûr, s'il y a […] quelque chose sur la version mobile qui n'est pas sur la version de bureau, et que vous êtes indexé par le crawler de bureau, alors nous ne le verrons pas vraiment. Nous explorons la version alternative de temps en temps, mais nous ne l'explorons pas pour recueillir plus d'informations, mais simplement pour confirmer qu'il existe une connexion entre l'URL de bureau et l'URL mobile.

Pouvez-vous héberger votre sitemap dans un cloud ?

46:20 « Nous avons une page vraiment énorme avec des millions d'URL, et […] les sitemaps sont actuellement en cours de rénovation. Et notre équipe informatique envisage de stocker […] les nouveaux fichiers de sitemap dans notre service cloud. Cela signifie de example.com/sitemaps à cloud.com/sitemaps. Et nous nous demandons, est-ce un problème si nous stockons les sitemaps dans le cloud ? Et si cela ne pose pas de problème, devons-nous également créer une redirection permanente pour l'ancienne URL de cet exemple.com/sitemap, ou comment devons-nous planifier le déplacement ?

John a déclaré : « Il est tout à fait possible d'héberger le fichier sitemap ailleurs. Vous pouvez le faire de deux manières. La première est que si vous avez vérifié ces deux domaines dans la Search Console, cela fonctionne. L'autre façon est de le soumettre avec le fichier robots.txt, où vous spécifiez 'sitemap:' puis l'URL du sitemap. Cela peut également aller dans un domaine différent. […] Je redirigerais également l'ancien fichier de plan de site vers le nouvel emplacement juste pour être propre, mais probablement même si vous supprimez simplement l'ancienne URL de plan de site et assurez-vous de soumettre la nouvelle correctement, cela devrait fonctionner.  

Ce qui pourrait être un peu délicat, c'est que je ne sais pas comment la Search Console afficherait cela directement dans l'interface utilisateur, en particulier, si le fichier de plan du site se trouve à un emplacement différent, si la Search Console afficherait les informations du plan du site dans le rapport d'indexation, par exemple. Mais c'est un problème de rapport. Ce n'est pas quelque chose qui repose sur la fonctionnalité du fichier sitemap. C'est juste que la Search Console ne l'affiche pas correctement. Et, encore une fois, c'est peut-être le cas. Je ne suis pas sûr à 100 %.

L'historique d'un domaine peut-il affecter votre site Web ?

49:40 "[…] Donc [pendant les précédentes heures de bureau SEO ] nous avons posé cette question sur le domaine avec une histoire en tant que fournisseur de services d'escorte. […] le domaine a une longue histoire car le premier instantané de ce site Web date de 1997. […] nous avons relancé notre site Web en juin de l'année dernière […]. Et le principal problème que nous rencontrons est […] que nous sommes toujours signalés [comme contenu pour adultes]. Et en plus, nous avons ce problème […] – exploré, actuellement non indexé. Et nous essayons de comprendre si l'historique du domaine peut réellement affecter le fait que nous rencontrons des problèmes d'indexation. […] nous croyons que le contenu que nous publions est de bonne qualité. C'est lié en interne, et nous essayons de construire un site de qualité. Là où nous avons du mal en ce moment, c'est la performance des pages, donc c'est en quelque sorte en cours en ce moment pour optimiser cela. Mais nous utilisons prerender.io donc ce que nous montrons pour Google est déjà une version pré-rendu. Donc, en ce qui concerne notre score Lighthouse, tout va bien. […] Que pouvons-nous améliorer ou rechercher pour comprendre pourquoi nous ne sommes pas indexés ? Je suis également heureux de partager l'URL. "

John a proposé qu'il puisse jeter un coup d'œil à l'URL plus tard, puis il a répondu: « Habituellement, le côté indexation des choses ne serait pas lié s'il y avait auparavant du contenu pour adultes sur le site Web.

Le côté indexation peut être affecté si le contenu qui s'y trouvait auparavant était très spammé. Donc, cela pourrait être quelque chose où, du point de vue de l'indexation, il faut juste un certain temps pour comprendre, oh, ce nouveau site Web n'est en fait pas du tout du spam.

Mais si c'était simplement parce qu'il y avait du contenu pour adultes auparavant, alors je pourrais imaginer que nos filtres SafeSearch sont peut-être un peu lents à le reconnaître. Je sais que nous avons pris des mesures pour accélérer cela […], ou peut-être qu'il y a quelque chose d'autre sur SafeSearch qui colle un peu.

Le côté SafeSearch est quelque chose que vous pouvez vérifier si vous effectuez une requête sur le site, puis activez et désactivez SafeSearch. Vous devriez être en mesure de voir s'il se passe quelque chose de SafeSearch ou non. Vous ne voyez pas cela en ce qui concerne l'indexation, cependant. Mais je peux y jeter un coup d'œil par la suite, et nous pourrons voir s'il y a quelque chose de super évident dont je peux vous faire part.