Google maraude les trous noirs avec des pages de clustering et d'erreur
Dans le cadre du thème du clustering et de la canonisation avec la recherche Google aujourd'hui, Allan Scott de Google a expliqué ce qu'il a appelé les « trous noirs en maraude » dans la recherche Google. Où le clustering de Google prend certaines pages d'erreur et elles se retrouvent dans cette sorte de trou noir dans la recherche Google.
Cela est ressorti de l'excellente interview Search Off The Record d'Allan Scott de l'équipe de recherche Google, qui travaille spécifiquement sur la duplication dans la recherche Google. Martin Splitt et John Mueller de Google ont interviewé Allan.
Allan a expliqué que ces « trous noirs en maraude » se produisent parce que « les pages d'erreur et le clustering ont une relation malheureuse » dans certains cas. Allan a déclaré : « Les pages d'erreur et le clustering ont une relation malheureuse dans laquelle les pages d'erreur non détectées obtiennent simplement une somme de contrôle comme n'importe quelle autre page, puis se regroupent par somme de contrôle, et donc les pages d'erreur ont tendance à se regrouper les unes avec les autres. Cela a du sens à ce stade, droite? »
Martin Splitt de Google l'a résumé avec un exemple : « Est-ce que ces cas où vous avez un site Web qui a, je ne sais pas, environ 20 produits qui ne sont plus disponibles et qui l'ont remplacé par cet article n'est pas C'est une sorte de page d'erreur, mais elle ne sert pas de page d'erreur car elle sert de HTTP 200. Mais alors le contenu est le même, donc les sommes de contrôle seront toutes les mêmes. Et puis des choses étranges. ça arrive, n'est-ce pas ? »
Je pense que cela signifie que Google pense que ces pages d'erreur sont toutes identiques, car les sommes de contrôle sont toutes identiques.
Qu'est-ce qu'une somme de contrôle ? Une somme de contrôle est un bloc de données de petite taille dérivé d'un autre bloc de données numériques dans le but de détecter les erreurs pouvant avoir été introduites lors de sa transmission ou de son stockage. En elles-mêmes, les sommes de contrôle sont souvent utilisées pour vérifier l'intégrité des données, mais ne sont pas utilisées pour vérifier l'authenticité des données.
De retour à Allan, il a répondu à Martin en disant : « C'est donc un bon exemple. Oui, c'est exactement de cela que je parle. Dans ce cas, le webmaster ne sera peut-être pas trop inquiet car ces produits, s'ils » S'ils sont définitivement partis, alors ils veulent qu'ils disparaissent, donc ce n'est pas grave. Maintenant, s'ils sont temporairement partis, c'est un problème car maintenant ils ont tous été aspirés dans ce cluster, ils ne reviendront probablement pas. dehors parce que le crawl n'aime vraiment pas des dups. Ils disent : « Oh, cette page est un dup. Oublie ça. Je n'ai plus jamais besoin de l'explorer. » C'est pourquoi c'est un trou noir. »
Cela va dans ce trou noir où Google pourrait ne plus jamais consulter cette page. Eh bien, peut-être pas pour toujours.
Allan a déclaré: « Seules les choses qui se situent très vers le haut du cluster sont susceptibles d'en ressortir. »
Alors pourquoi Allan parle-t-il de ça ? Il a dit : « ce qui m'inquiète vraiment, ce sont les sites avec des erreurs passagères, comme ce que vous décrivez, il s'agit en quelque sorte d'une erreur transitoire intentionnelle. » « Eh bien, une fois sur mille, vous allez nous signaler votre erreur. Maintenant, vous avez un trou noir en maraude de pages mortes. La situation est encore pire parce que vous servez également un tas de dépendances JavaScript », a-t-il déclaré. ajouté.
Voici d'autres échanges avec Allan et Martin à ce sujet :
Allan :
Si ceux-ci ne parviennent pas à être récupérés, ils pourraient interrompre votre rendu, auquel cas nous examinerons votre page et penserons qu'elle est cassée. La fiabilité réelle de votre page, une fois ces étapes franchies, n’est pas nécessairement très élevée. Nous devons beaucoup nous inquiéter de voir ce genre d'amas de trous noirs en maraude s'emparer d'un site parce que des choses y sont simplement déversées, comme s'il y avait des sites de médias sociaux sur lesquels je regardais, vous savez, les profils les plus importants, et ils auraient simplement des tonnes de pages en dessous, dont certaines étaient elles-mêmes assez médiatisées et n'appartenaient tout simplement pas à ce groupe.
Martine :
Oh, mon garçon. D'accord. Ouais. J'ai vu quelque chose comme ça lorsque quelqu'un testait A/B une nouvelle version de son site Web, puis certains liens étaient rompus avec des messages d'erreur parce que l'API avait changé et que les appels ne fonctionnaient plus ou quelque chose comme ça. Et puis, dans environ 10 % des cas, vous recevrez un message d’erreur pour la quasi-totalité de leur contenu. Ouais, s'en sortir a été difficile, je suppose.
John Mueller a évoqué les cas où cela peut poser problème avec les CDN :
J'ai également vu quelque chose qui, je suppose, est similaire à celui-ci : si un site a une sorte de CDN devant lui, le CDN effectue une sorte de détection de robot ou de détection DDoS, puis sert quelque chose comme : « Oh, ça on dirait que vous êtes un robot », et Googlebot dit : « Oui, je suis un robot ». Mais ensuite, toutes ces pages, je suppose, finissent par être regroupées et probablement sur plusieurs sites, n'est-ce pas ?
Allan a confirmé et a déclaré que Gary Illyes de Google avait travaillé là-dessus ici et là :
Oui, en gros. Gary a effectivement fait des démarches de sensibilisation pour nous à ce sujet. Vous savez, nous rencontrons des cas comme celui-ci et nous essayons d'amener les fournisseurs de ce type de services à travailler avec nous, ou au moins avec Gary. Je ne sais pas ce qu'il en fait. C'est lui qui s'en charge. Mais tous ne sont pas aussi coopératifs. C'est donc quelque chose dont il faut être conscient.
Alors, comment éviter de rester en dehors de ces trous noirs de Google ? Allan a déclaré : « Le moyen le plus simple est de servir des codes HTTP corrects, donc, vous savez, envoyez-nous un 404, un 403 ou un 503. Si vous faites cela, vous n'allez pas regrouper. Nous ne pouvons regrouper que les pages qui servent un 200. Seulement 200 vont dans les trous noirs.
L’autre option proposée par Allan était :
L'autre option ici est, si vous utilisez JavaScript foo, auquel cas vous ne pourrez peut-être pas nous envoyer de code HTTP. Il est peut-être un peu trop tard pour ça. Ce que vous pouvez faire ici, c'est essayer de traiter un message d'erreur réel, quelque chose qui est très visiblement une erreur comme, vous savez, vous pourriez littéralement dire, vous savez, 503 – nous avons rencontré une erreur de serveur ou 403 – vous n'étiez pas autorisé à visualiser ceci ou 404 – nous n'avons pas pu trouver le bon fichier. N’importe laquelle de ces choses fonctionnerait. Vous savez, vous n'avez même pas besoin d'utiliser du code HTTP. Évidemment, vous pourriez simplement dire quelque chose. Eh bien, nous avons un système censé détecter les pages d'erreur, et nous voulons améliorer son rappel au-delà de ce qu'il fait actuellement pour essayer de résoudre certains de ces mauvais rendus et ces pages servies par des robots. Mais en attendant, il est généralement plus sûr de prendre les choses en main et d’essayer de s’assurer que Google comprend au mieux votre intention.
Ils n'arrêtent pas de parler de cela, et tout commence vers 16:22 minutes – voici la vidéo intégrée :
Discussion sur le forum X.
