Heures de bureau SEO, 3 juin 2022

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

Puis-je utiliser deux codes de résultat HTTP sur une page ?

1:22 "[…] Il est théoriquement possible d'avoir deux codes de résultats HTTP différents sur une page, mais que va faire Google avec ces deux codes ? Google les verra-t-il même ? Et si oui, que fera Google ? Par exemple, une 503 plus une 302.

La réponse de John était : « […] Avec les codes de résultat HTTP, vous pouvez inclure beaucoup de choses différentes. Google examinera le premier code de résultat HTTP et le traitera essentiellement.

Et vous pouvez théoriquement encore avoir deux codes de résultat HTTP ou plus s'il s'agit de redirections menant à une page finale. Ainsi, par exemple, vous pourriez avoir une redirection d'une page vers une autre page. C'est un code de résultat. Et puis sur cette autre page, vous pourriez servir un code de résultat différent. Cela pourrait donc être une redirection 301 vers une page 404 […]. Et de notre point de vue, dans ces situations en chaîne où nous pouvons suivre la redirection pour obtenir un résultat final, nous nous concentrerons essentiellement sur ce résultat final.

Et si ce résultat final a du contenu, alors c'est quelque chose que nous pourrions utiliser pour la canonisation. Si ce résultat final est une page d'erreur, alors c'est une page d'erreur. Et c'est très bien pour nous aussi.

L'utilisation d'un CDN améliore-t-elle les classements si mon site est déjà rapide dans mon pays principal ?

2:50 "[…] Nous recevons la majorité de notre trafic d'un pays spécifique. Nous avons hébergé notre site Web sur un serveur situé dans ce pays. Suggérez-vous de placer l'ensemble de notre site Web derrière un CDN pour améliorer la vitesse des pages pour les utilisateurs du monde entier, ou n'est-ce pas nécessaire dans notre cas ? »

John a répondu : « Je ne pense pas que cela aurait un grand effet sur Google en ce qui concerne le référencement.

Le seul effet où je pourrais imaginer que quelque chose pourrait arriver est ce que les utilisateurs finissent par voir. […] Si la majorité de vos utilisateurs voient déjà un site Web très rapide parce que votre serveur s'y trouve, alors vous […] faites ce qu'il faut. Mais bien sûr, si les utilisateurs d'autres endroits voient un résultat très lent, parce que la connexion avec votre pays n'est peut-être pas très bonne, alors c'est quelque chose où vous pourriez avoir des opportunités d'améliorer cela.

[…] S'il y a quelque chose que vous pouvez faire pour améliorer les choses globalement pour votre site Web, je pense que c'est une bonne idée. Je ne pense pas que ce soit critique […]. Mais c'est quelque chose que vous pouvez faire pour […] développer votre site Web au-delà de votre pays actuel.

Je devrais peut-être clarifier une chose, si l'exploration de Google est vraiment, vraiment lente, cela peut bien sûr affecter la quantité d'exploration et d'indexation à partir du site Web […]. Je n'ai pas vraiment vu cela comme un problème pour un site Web qui ne compte pas des millions et des millions de pages […].

Vous pouvez revérifier la vitesse d'exploration de Google dans la Search Console et les statistiques d'exploration. Et si cela semble raisonnable, même si ce n'est pas super rapide, alors je ne m'en soucierais pas vraiment.

Dois-je interdire les demandes d'API pour réduire l'exploration ?

5:20 "[…] Notre site dépense actuellement environ 20 % du budget de crawl sur le sous-domaine de l'API, 20 % supplémentaires sur les vignettes des vidéos. Aucun de ces sous-domaines n'a de contenu faisant partie de notre stratégie de référencement. Devrions-nous interdire l'exploration de ces sous-domaines, ou comment les points de terminaison de l'API sont-ils découverts ou utilisés ? »

Comme l'a dit John, "[…] Dans de nombreux cas, les points de terminaison de l'API finissent par être utilisés par JavaScript sur un site Web , et nous rendrons vos pages. Et s'ils accèdent à une API qui se trouve sur votre site Web, nous essaierons de charger le contenu de cette API et de l'utiliser pour le rendu de la page.

Et en fonction de la configuration de votre API et de la configuration de votre JavaScript, il se peut qu'il soit difficile pour nous de mettre en cache ces résultats d'API, ce qui signifie que nous explorons peut-être un grand nombre de ces requêtes d'API pour essayer d'obtenir une version rendue. de vos pages afin que nous puissions les utiliser pour l'indexation. C'est donc généralement l'endroit où cela est découvert. Et c'est quelque chose que vous pouvez aider en vous assurant que les résultats de l'API peuvent être mis en cache, que vous n'injectez aucun horodatage dans les URL […] lorsque vous utilisez JavaScript pour l'API […].

Si vous ne vous souciez pas du contenu renvoyé avec ces points de terminaison d'API, vous pouvez bien sûr empêcher l'exploration de tout ce sous-domaine avec le fichier robots.txt. Et cela empêchera essentiellement toutes ces demandes d'API de se produire.

[…] Vous devez d'abord comprendre, est-ce que ces résultats d'API […] font partie de […] contenu critique que je veux faire indexer de Google ? Et si c'est le cas, vous ne devriez probablement pas bloquer l'exploration. Mais si […] cela […] génère quelque chose […] qui n'est pas critique pour vos pages […], alors il peut être utile de vérifier à quoi cela ressemble lorsqu'elles sont bloquées.

Et une façon de vérifier cela est de créer une page de test distincte qui n'appelle pas l'API ou qui utilise une URL cassée pour le point de terminaison de l'API. […] Vous pouvez voir comment cette page s'affiche réellement dans mon navigateur ? Comment cela s'affiche-t-il pour Google ? »

Dois-je utiliser rel="nofollow" sur les liens internes ?

8:05 « Est-il approprié d'utiliser un attribut nofollow sur les liens internes pour éviter les requêtes inutiles des robots d'exploration vers des URL que nous ne souhaitons pas voir explorées ou indexées ? »

Voici comment John a répondu : "[…] Je pense que, pour la plupart, il est très peu logique d'utiliser le nofollow sur les liens internes. Mais si c'est quelque chose que vous voulez faire, allez-y.

Dans la plupart des cas, j'essaierai de faire quelque chose comme utiliser rel=canonical pour pointer vers les URL que vous voulez indexer ou utiliser le robots.txt pour des choses que vous ne voulez vraiment pas explorer.

Essayez de comprendre, s'agit-il plutôt d'une chose subtile […] que vous préférez avoir indexée et ensuite utiliser rel=canonical pour cela ? Ou est-ce quelque chose où vous dites - en fait, lorsque Googlebot accède à ces URL, cela cause des problèmes à mon serveur. Cela provoque une charge importante. Cela rend tout vraiment lent. C'est cher ou quoi.

Et pour ces cas, j'interdirais simplement l'exploration de ces URL. […] Avec le rel=canonical, évidemment, nous devrons d'abord explorer cette page pour voir le rel=canonical. Mais au fil du temps, nous nous concentrerons sur le canonique que vous avez défini. Et nous l'utiliserons principalement pour l'exploration et l'indexation.

Existe-t-il un moyen de forcer l'affichage des liens annexes ?

16:02 "Existe-t-il une stratégie par laquelle les pages souhaitées peuvent apparaître en tant que lien de site dans les résultats de recherche Google ?"

John a précisé que "[…] Il n'y a pas de balise méta ou de données structurées que vous pouvez utiliser pour forcer l'affichage d'un lien de site .

[…] Nos systèmes essaient de comprendre ce qui est […] connexe ou pertinent pour les utilisateurs lorsqu'ils consultent cette seule page Web […] ? […] Notre recommandation est essentiellement d'avoir une bonne structure de site Web, d'avoir des liens internes clairs afin qu'il nous soit facile de reconnaître quelles pages sont liées à ces pages, et d'avoir des titres clairs que nous pouvons utiliser et […] montrer comme un lien de sites.

[…] Ce n'est pas qu'il y ait une garantie que tout cela sera montré comme ça. Mais cela nous aide en quelque sorte à comprendre ce qui est lié. Et si nous pensons qu'il est logique d'afficher un lien de site, il nous sera alors beaucoup plus facile d'en choisir un en fonction de ces informations.

Notre site intègre des PDF avec des iframes, devrions-nous effectuer une OCR du texte ?

17:14 "Notre site Web utilise des iframes et un script pour intégrer des fichiers PDF sur nos pages et notre site Web. Y a-t-il un avantage à prendre le texte OCR du PDF et à le coller quelque part dans le code HTML du document à des fins de référencement, ou Google analysera-t-il simplement le contenu du PDF avec le même poids et la même pertinence pour indexer le contenu ? »

John a répondu : "[…] On dirait que vous voulez prendre le texte du PDF et […] le cacher dans le HTML à des fins de référencement. Et c'est quelque chose que je ne recommanderais certainement pas de faire. Si vous souhaitez que le contenu soit indexable, rendez-le visible sur la page.

[…] Nous essayons de retirer le texte des PDF et de l'indexer pour les PDF eux-mêmes. D'un point de vue pratique, ce qui se passe avec un PDF est comme l'une des premières étapes, nous le convertissons en une page HTML et nous essayons de l'indexer comme une page HTML. […] Ce que vous faites, c'est […] iframer une page HTML indirecte. Et en ce qui concerne les iframes, nous pouvons prendre en compte ce contenu pour l'indexation dans la page principale. Mais il peut aussi arriver que nous indexions le PDF séparément de toute façon. […] Je retournerais la question et la formulerais comme que voulez-vous qu'il se passe ?

Et si vous souhaitez que vos pages Web normales soient indexées avec le contenu du fichier PDF, faites en sorte que ce contenu soit immédiatement visible sur la page HTML. Ainsi, au lieu d'intégrer le PDF en tant qu'élément de contenu principal, faites du contenu HTML l'élément principal et créez un lien vers le fichier PDF.

Et puis il y a une question de savoir si vous voulez que ces PDF soient indexés séparément ou non ? Parfois, vous souhaitez que les PDF soient indexés séparément. Et si vous voulez qu'ils soient indexés séparément, alors créer un lien vers eux est génial.

Si vous ne souhaitez pas les indexer séparément, utilisez robots.txt pour bloquer leur indexation. Vous pouvez également utiliser le noindex [? x-robots ?] En-tête HTTP. C'est un peu plus compliqué car vous devez le servir d'en-tête pour les fichiers PDF si vous voulez que ces fichiers PDF soient disponibles dans l'iframe, mais pas réellement indexés.

Google explore-t-il les URL dans le balisage de données structurées ?

23:24 "Google explore-t-il les URL situées dans le balisage de données structurées ou Google stocke-t-il simplement les données ?"

John a expliqué que « la plupart du temps, lorsque nous examinons des pages HTML, si nous voyons quelque chose qui ressemble à un lien, nous pouvons également essayer cette URL. […] Si nous trouvons une URL en JavaScript, nous pouvons essayer de la récupérer et essayer de l'utiliser. Si nous trouvons un lien dans un fichier texte sur un site, nous pouvons essayer de le parcourir et de l'utiliser. Mais ce n'est pas vraiment un lien normal.

[…] Si vous voulez que Google explore cette URL, assurez-vous qu'il existe un lien HTML naturel vers cette URL , avec un texte d'ancrage clair également, que vous donnez des informations sur la page de destination.

Si vous ne voulez pas que Google explore cette URL spécifique, bloquez-la peut-être avec robots.txt ou sur cette page, utilisez un rel=canonical pointant vers votre version préférée, quelque chose comme ça. […] Je ne supposerais pas aveuglément que simplement parce que c'est dans des données structurées, il ne sera pas trouvé, ni je ne supposerais aveuglément que simplement parce que c'est dans des données structurées, il sera trouvé.

[…] Je me concentrerais plutôt sur ce que vous voulez qu'il se passe là-bas. Si vous voulez qu'il soit vu comme un lien, faites-en un lien. Si vous ne voulez pas qu'il soit exploré ou indexé, bloquez l'exploration ou l'indexation […].