Un robot d'exploration Google est un logiciel qui demande des pages Web et d'autres ressources afin que Google puisse découvrir et comprendre le contenu. Googlebot est le principal robot associé à Google Search. Une visite du bot Google signifie que Google a récupéré quelque chose ; cela ne signifie pas que la page a été indexée ou qu'elle sera classée pour une requête particulière.
La séquence utile est découvrir → explorer → traiter → indexer → servir. Pour un propriétaire de site, chaque étape nécessite des preuves différentes. Commencez par l'URL exacte, vérifiez si elle peut être récupérée et utilisez votre propre propriété Search Console pour enquêter sur ce que Google rapporte à ce sujet.
Que fait le Googlebot lorsqu'il visite
Un robot envoie une requête HTTP, un peu comme un navigateur demandant une page. Le serveur renvoie un code d'état, des en-têtes et, lorsqu'il est disponible, du contenu. Google peut également récupérer les ressources nécessaires au rendu de la page, telles que JavaScript et les feuilles de style. Un journal du serveur enregistre les requêtes ; il ne révèle pas toutes les décisions ultérieures que Google prend concernant le contenu.
Google décrit Googlebot Smartphone et Googlebot Desktop. Leurs en-têtes d'agent utilisateur identifient le sous-type du robot d'exploration, mais tous deux utilisent le même jeton de bot Google en robots.txt. Ne présumez pas qu'une page fonctionne pour le robot d'exploration mobile de Google simplement parce qu'elle semble complète dans votre navigateur de bureau. Inspectez également le contenu mobile et les conditions d’accès.
Suivre la page de la découverte à un résultat de recherche
GroupesGoogle Recherche dans l'exploration, l'indexation et le service. Séparer la découverte et le traitement dans cette explication vous aide à résoudre les problèmes. Les étapes ci-dessous sont un modèle d'enseignement et non une promesse que chaque URL découverte progresse à travers elles. Le guide de Google sur le fonctionnement de la recherche explique pourquoi l'exploration, l'indexation et l'apparence dans les résultats ne sont pas garanties.
| Ce que cela signifie pour votre page | |
|---|---|
| Découvrir | Google apprend qu'une URL existe, par exemple via un lien ou plan du site. |
| Crawl | Google demande l'URL et reçoit une réponse en cas d'accès réussit. |
| Process | Google analyse le contenu et peut rendre la page pour comprendre it. |
| Index | Google considère le contenu pour son index consultable, y compris les doublons. manipulation. |
| Serve | Google sélectionne les résultats pour une recherche particulière. Être indexé ne garantit pas la visibilité de votre requête cible. |
Supposons que votre navigateur affiche correctement un nouveau guide. Cela établit une visite réussie dans les conditions de votre navigateur. Il n'établit pas de découverte par Google, d'accès depuis le réseau de Google ou d'inclusion dans son index. Gardez ces questions séparées lorsque vous signalez un problème à votre développeur.
Aide Google découvrez l'URL que vous souhaitez réellement indexer
Donnez aux pages importantes des liens internes utiles à partir de pages pertinentes et accessibles. Un guide caché de la navigation et jamais lié à un contenu connexe est plus difficile à découvrir qu'un guide connecté à un sujet établi. Utilisez un texte de lien descriptif pour que les lecteurs comprennent également la destination.
Un plan du site propose un autre chemin de découverte. Googledocumentation du plan du site explique son utilité pour les grands sites, les nouveaux sites et les contenus difficiles à découvrir via des liens. L'inclusion dans un plan de site ne garantit toujours pas l'exploration ou l'indexation.
Lorsque vous publiez un guide, vérifiez que son URL préférée apparaît dans le bon plan du site et que le plan du site peut être récupéré. L'analyseur de plan de site de SearchVector est un point de départ pour réviser un plan de site. Traitez sa sortie comme une preuve de plan de site, puis vérifiez chaque page séparément. Une entrée du plan du site ne peut pas réparer une page bloquée.
Choisissez le bon contrôle : robots.txt, noindex ou canonique
Ces contrôles répondent à différentes questions. Les mélanger est une raison courante pour laquelle un changement de publication délibéré produit un résultat de recherche inattendu.
- robots.txt contrôle l'exploration. Une règle d'interdiction indique à un robot d'exploration conforme de ne pas demander de contenu correspondant. Une URL bloquée peut toujours apparaître dans la recherche si Google en prend connaissance ailleurs.
- noindex contrôle l'indexation. Pour que Google voie une directive noindex dans une page ou un en-tête HTTP, l'exploration doit être autorisée. Bloquer l'URL lors de l'ajout de noindex peut empêcher Google de lire l'instruction.
- Un canonique identifie une version préférée. C'est un signal pour des pages en double ou similaires, pas un contrôle d'accès et non une commande garantie.
Google documente l'exigence d'exploration dans son noindex guidance et la distinction entre les signaux et la sélection dans son guide de canonisation. Le contenu qui doit être privé nécessite une protection d'accès appropriée. Robots.txt est lisible publiquement et ne constitue pas une limite de sécurité.
Avant de modifier une règle de robots, testez l'URL précise et le robot prévu. Le testeur Robots.txt de SearchVector peut prendre en charge cet examen. Enregistrez la règle que vous étudiez plutôt que d’interpréter un résultat global « autorisé » comme une preuve d’indexabilité.
Lisez la réponse avant de réécrire l'article
Une page peut échouer au stade de l'accès même lorsque son écriture est excellente. Vérifiez les redirections et la destination finale, pas seulement la première réponse. Un statut HTTP réussi signifie que la requête a réussi à ce niveau ; il ne certifie pas l'utilité de la page ni son éligibilité à l'indexation.
Le guide d'état HTTP HTTP deGoogle distingue les réponses réussies, les redirections, les erreurs client et les erreurs de serveur. Les pannes persistantes du serveur peuvent affecter l'exploration. Un message d'erreur renvoyé avec un statut de réussite peut également créer un résultat trompeur, souvent décrit comme un soft 404 lorsque Google reconnaît une page de type erreur.
Pour un premier passage ciblé, utilisez le Web Page Crawler de SearchVector pour examiner les signaux d'exploration, puis comparez-les avec votre serveur et les preuves Google. Un robot d'exploration tiers n'est pas un robot Google. Les différences de réseau, d'agent utilisateur et de rendu peuvent expliquer pourquoi deux vérifications ne sont pas d'accord.
Exemple travaillé : un guide toujours bloqué après le lancement
Il s'agit d'un exercice de diagnostic fictif et non d'un journal d'exploration client. Imaginez que vous lancez /guides/packing-list, créez un lien vers celui-ci depuis votre hub de guides et ajoutez-le à un plan de site. Votre navigateur ordinaire reçoit l'article prévu, mais une règle robots interdit toujours le répertoire /guides/. La page contient également une directive noindex restant de la préparation.
- Notez l'état prévu. Ce guide doit être public et éligible à l'indexation. D'autres guides inachevés peuvent encore avoir besoin d'être protégés.
- Vérifiez le chemin exact. Confirmez que la règle des robots concernée correspond à cette URL. Vérifiez indépendamment les en-têtes de réponse et le HTML de la page pour le noindex.
- Effectuez une correction étendue. Ajustez la règle pour le contenu public prévu et supprimez la directive noindex indésirable. N'exposez pas largement chaque page inachevée pour corriger un guide.
- Retestez après le déploiement. Confirmez que l'URL finale renvoie le guide réel, que le robot d'exploration prévu peut y accéder et que les en-têtes et le code HTML reflètent la nouvelle instruction d'indexation.
- Suivi avec Google preuves. Dans votre propriété Search Console, inspectez l'URL et exécutez un test en direct. Si la page est éligible, vous pouvez demander l'indexation. Enregistrez les modifications et vérifiez sans promettre de date limite.
Le diagnostic est constitué de deux obstacles indépendants, et non de « Google a besoin de plus de mots-clés ». Supprimer uniquement le bloc robots ne laisse aucun index en place. La suppression uniquement de noindex laisse Google incapable de récupérer la page. Même après les deux correctifs, un test réussi ne garantit pas que Google l'indexera.
Vérifier qu'une demande provient bien de Google
N'importe qui peut envoyer une requête prétendant être Googlebot dans son en-tête user-agent. Si un trafic suspect surcharge votre site, vérifiez son origine avant de créer des règles de pare-feu spécifiques au robot.
Suivez les instructions demande-vérification de Google. Pour une vérification manuelle, récupérez l'adresse IP source d'un journal digne de confiance, effectuez une recherche DNS inversée, vérifiez le nom d'hôte obtenu par rapport au domaine documenté pour cette catégorie de robot d'exploration, puis résolvez-le en avant. Le résultat du transfert doit correspondre à l'adresse IP d'origine. Un nom contenant simplement « google » est insuffisant.
Pour une vérification automatisée, faites correspondre les adresses avec les plages publiées par Google pour la catégorie de robot d'exploration ou de récupération concernée. Ne traitez pas tout le trafic hébergé par Google comme un robot Google. Si votre site se trouve derrière un proxy, demandez au propriétaire de votre infrastructure quel champ de journal représente l'adresse client vérifiée avant d'agir dessus.
Utilisez la Search Console pour décider de la prochaine action
La documentation d'inspection URL du｟10 distingue les informations indexées du Google d'un test en direct. Le rapport indexé reflète la version connue de Google ; un test en direct vérifie l'accessibilité et l'indexabilité potentielles de la page actuelle. Ni un test en direct réussi ni une demande d'indexation ne garantissent l'inclusion.
Utilisez un compte avec accès à votre propre propriété. Comparez l'URL inspectée, les informations de la dernière exploration, l'état d'indexation et les informations canoniques le cas échéant. Une nouvelle correction du serveur peut coexister avec des informations indexées plus anciennes. Notez les dates avant de conclure que la correction a échoué.
Terminez par une action fondée sur des preuves : améliorez la découverte si l'URL est mal liée, réparez l'accès si les demandes échouent, supprimez une restriction d'indexation involontaire ou enquêtez sur le contenu et la duplication si Google a exploré la page mais l'a exclue. Gardez un bref enregistrement de l'URL, de l'observation, du changement et du suivi. Cela transforme « Google ne nous a pas trouvé » en un problème sur lequel vous pouvez réellement enquêter.
