Google a précisé que la console de recherche que le rapport de couverture de l’index ne rapporte pas les données de couverture à la minute près. Google recommande d’utiliser l’outil d’inspection d’URL pour ceux qui ont besoin de la confirmation la plus récente pour savoir si une URL est indexée ou non.

Google clarifie les données du rapport de couverture de l’index

Un certain nombre de tweets ont remarqué ce qui semblait être une erreur dans le rapport de couverture de l’index qui l’amenait à signaler qu’une URL avait été explorée mais pas indexée.

Il s’avère qu’il ne s’agit pas d’un bogue mais plutôt d’une limitation du rapport Index Coverage.

Google l’a expliqué dans une série de tweets.

Rapports du bogue de rapport de la console de recherche

« Quelques utilisateurs de Google Search Console ont signalé avoir vu des URL dans le rapport de couverture de l’index marquées comme » explorées – actuellement non indexées « qui, lorsqu’elles ont été inspectées avec l’outil d’inspection d’URL, ont été répertoriées comme » soumises et indexées « ou un autre statut. »

Google explique le rapport de couverture de l’index

Google a ensuite partagé une série de tweets fonctionnement du rapport Couverture de l’index.

« C’est parce que les données du rapport de couverture de l’index sont actualisées à un rythme différent (et plus lent) que l’inspection d’URL.

Les résultats affichés dans l’inspection d’URL sont plus récents et doivent être considérés comme faisant autorité lorsqu’ils entrent en conflit avec le rapport de couverture de l’index. (2/4)

Les données affichées dans la couverture de l’index doivent refléter l’état précis d’une page dans quelques jours, lorsque l’état change. (3/4)

Comme toujours, merci pour vos commentaires 🙏, nous chercherons des moyens de réduire cet écart afin que nos rapports et outils soient toujours alignés et actualisés ! (4/4) »

Lié: Comment signaler des problèmes d’indexation dans Google Search Console

John Mueller répond à une question sur le rapport de couverture de l’index

John Mueller de Google avait répondu à une question à ce sujet le 8 octobre 2021. C’était avant qu’il ne soit compris qu’il n’y avait pas d’erreur dans le rapport de couverture de l’index, mais plutôt une différence dans l’attente de fraîcheur des données du rapport de couverture de l’index. et la réalité que les données sont actualisées à un rythme plus lent.

La personne qui a posé la question a raconté qu’en juillet 2021, elle avait remarqué que les URL soumises via la console de recherche Google signalaient l’erreur de soumission mais non indexée, même si les pages n’avaient pas de balise noindex.

Par la suite, Google reviendrait sur le site Web, explorerait la page et l’indexerait normalement.

« Le problème est que nous obtenons 300 erreurs/aucun index, puis lors des analyses suivantes, seuls cinq sont analysés avant qu’ils n’en explorent à nouveau beaucoup plus.

Donc, étant donné qu’ils ne sont pas indexés et accordés si les choses ne peuvent pas s’afficher ou s’ils ne trouvent pas la page, ils sont dirigés vers notre page introuvable, qui n’a pas d’index.

Et donc je sais que d’une manière ou d’une autre, ils sont dirigés là-bas.

Est-ce juste un problème de mémoire ou puisqu’ils sont ensuite bien explorés, est-ce juste un… »

Jean Mueller a répondu :

« C’est difficile à dire sans regarder les pages.

Donc, j’essaierais vraiment de vérifier si c’était un problème à l’époque et si ce n’est plus un problème ou si c’est toujours quelque chose qui se produit par intermittence.
Parce que si ça n’a pas d’importance, si ça n’a plus lieu maintenant, alors comme quoi que ce soit… »

La personne qui posait la question a répondu en insistant sur le fait que cela se produisait toujours et que cela continuait d’être un problème permanent.

John Mueller a répondu en disant que son intuition est que quelque chose avec le rendu pourrait mal tourner.

« Et si c’est quelque chose qui se produit encore, j’essaierais de comprendre ce qui pourrait en être la cause.

Et il se peut que lorsque vous testez la page dans la Search Console, neuf fois sur dix, cela fonctionne bien. Mais en quelque sorte une fois sur dix, cela ne fonctionne pas bien et redirige vers la page d’erreur ou nous pensons qu’il redirige vers la page d’erreur.

C’est un peu le cas que j’essaierais d’approfondir et d’essayer de comprendre s’il y a trop de demandes pour rendre cette page ou s’il y a quelque chose de compliqué avec le JavaScript qui prend parfois trop de temps et fonctionne parfois bien, puis essayez de réduire les choses de ce point de vue.

Mueller a ensuite expliqué comment la partie d’exploration et de rendu se produit du côté de l’exploration de Google.

Il fait référence à un navigateur « de type Chrome » qui pourrait être une référence au bot Chrome sans tête de Google, qui est essentiellement un navigateur Chrome auquel il manque l’interface utilisateur frontale.

« Ce qui se passe de notre côté, c’est que nous explorons la page HTML, puis nous essayons de traiter la page HTML dans le type de navigateur de type Chromium.

Et pour cela, nous essayons de tirer parti de toutes les ressources qui y sont mentionnées.

Donc, si vous accédez à la Developer Console dans Chrome et que vous regardez la section réseau, elle vous montre un diagramme en cascade de tout ce qu’il charge pour afficher la page.

Et s’il y a beaucoup de choses qui doivent être chargées, il peut arriver que les choses expirent et nous pourrions alors rencontrer cette situation d’erreur.

Mueller a ensuite suggéré de réduire le nombre de demandes de ressources pour les fichiers JavaScript et CSS et d’essayer de les combiner ou de les réduire, et de minimiser les images, ce qui est toujours une bonne chose à faire.

La suggestion de Mueller est liée au rendu SEO qui a été discuté par Martin Splitt de Google, où les aspects techniques de la façon dont une page Web est téléchargée et rendue dans un navigateur sont optimisés pour des performances rapides et efficaces.

Lié: Les 5 problèmes d’indexation Google les plus courants par taille de site Web

Certaines erreurs de crawl sont liées au serveur

La réponse de Mueller n’était pas tout à fait pertinente pour cette situation spécifique car le problème était un problème d’attente de fraîcheur et non d’indexation.

Cependant, ses conseils sont toujours exacts pour les nombreuses fois où il y a un problème lié au serveur qui provoque des délais d’attente de service de ressources qui bloquent le bon rendu d’une page Web.

Cela peut se produire la nuit aux petites heures du matin lorsque des robots malveillants envahissent un site Web et ralentissent le site.

Un site qui n’a pas de ressources optimisées, en particulier un sur un serveur partagé, peut connaître des ralentissements dramatiques où le serveur commence à afficher 500 codes de réponse d’erreur.

Parlant d’expérience dans la maintenance d’un serveur dédié, une mauvaise configuration dans Nginx, Apache ou PHP au niveau du serveur ou un disque dur défaillant peut également contribuer à ce que le site Web ne montre pas les pages demandées à Google ou aux visiteurs du site Web.

Certains de ces problèmes peuvent passer inaperçus lorsque les différents logiciels sont mis à jour avec des paramètres moins qu’optimaux, nécessitant un dépannage pour identifier les erreurs.

Heureusement, les logiciels serveur comme Plesk disposent d’outils de diagnostic et de réparation qui peuvent aider à résoudre ces problèmes lorsqu’ils surviennent.

Cette fois, le problème était que Google n’avait pas correctement défini les attentes correctes pour le rapport de couverture de l’index.

Mais la prochaine fois, cela pourrait être un problème de serveur ou de rendu.

Citations

Google Search Central Tweets Explication du rapport de couverture de l’index

Rapport de couverture de l’index Google et erreurs d’indexation signalées

Regarder à la marque de 6:00 minutes

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici