Article publié sur le blog anglophone le 7 mai 2019


Googlebot est le robot d'exploration qui visite les pages Web pour les inclure dans l'index de la recherche Google. Dernièrement, l'une des questions posées les plus régulièrement par les membres de la communauté lors d'événements et sur les réseaux sociaux portait sur la possibilité d'assurer la compatibilité de Googlebot avec la dernière version de Chromium.

Aujourd'hui, nous sommes heureux d'annoncer que Googlebot fonctionne désormais avec le dernier moteur de rendu Chromium (version 74 au moment de la rédaction de ce post) pour le rendu des pages dans la recherche. À partir de maintenant, Googlebot mettra régulièrement à jour son moteur de rendu afin de rester compatible avec les dernières fonctionnalités de la plate-forme Web.




Ce que cela implique pour vous

Par rapport à la version précédente, Googlebot est désormais compatible avec plus de 1 000 nouvelles fonctionnalités. Par exemple :

• ES6 et les nouvelles fonctionnalités JavaScript
• IntersectionObserver pour le "lazy loading"
• API pour les Web Components (version 1)

Vérifiez si vous utilisez le transpilage ou des polyfills spécifiquement pour Googlebot. Si c'est le cas, voyez si c'est toujours nécessaire. Certaines limitations persistent : consultez notre outil de dépannage pour les problèmes liés à JavaScript et notre série vidéo sur le SEO avec JavaScript.

Vous avez des commentaires ? N'hésitez pas à nous contacter sur Twitter ou sur les forums pour les webmasters, ou à participer à l'un de nos événements en ligne.

Publié par Martin Splitt, votre spécialiste du Web

Pour obtenir une vue complète de votre site Web dans la Google Search Console, Google recommande d'en valider toutes les versions (http, https, www et non www). Malheureusement, cela peut entrainer une fragmentation des données et empêcher les webmasters de déterminer clairement comment Google "voit" l'ensemble d'un unique domaine. Pour pallier ce problème, nous sommes heureux d'annoncer la création des "propriétés de domaine" dans la Search Console. Ces propriétés offrent un moyen de vérifier et de voir les données issues de la recherche Google pour l'ensemble des URLs d'un domaine, quelque soit le protocole ou le sous-domaine.



Les propriétés de domaine affichent les données de toutes les URL régies par le nom de domaine, y compris les protocoles, les sous-domaines et les chemins. Elles vous donnent une vue globale de votre site Web dans la Search Console et vous évitent ainsi de devoir combiner les données manuellement. Par conséquent, que vous utilisiez des URL "m point" pour les pages mobiles ou que vous vous soyez (enfin) décidé à mettre en œuvre le HTTPS, la Search Console vous permet maintenant d'accéder à une vue complète des données de votre site concernant la recherche Google.

Si vous avez déjà mis en place une validation DNS, la Search Console créera automatiquement vos propriétés de domaine dans les semaines qui viennent, avec des données sur tous les rapports. Dans le cas contraire, pour créer une propriété de domaine, accédez à l'outil de sélection des propriétés, ajoutez une propriété de domaine et faites un enregistrement DNS.

À partir de maintenant, nous vous recommandons d'utiliser les propriétés de domaine quand cela est possible.

Nous avons créé les propriétés de domaine suite à vos commentaires et tenons à vous remercier une nouvelle fois pour vos retours depuis toutes ces années. Nous espérons que cette nouveauté vous aidera à gérer votre site plus facilement et à bénéficier d'une vue globale sans avoir à combiner manuellement les données. Si vous avez des questions, n'hésitez pas à les poser sur nos forums d'aide ou à laisser un commentaire sur Twitter. Comme toujours, vous pouvez aussi utiliser l'outil de commentaires intégré dans la Search Console.

Publié par Erez Bixon, équipe Search Console

De nombreux frameworks frontend utilisent JavaScript pour afficher des contenus. Cela implique que Google peut mettre un certain temps à indexer vos contenus ou à mettre à jour les contenus déjà indexés présentés sous cette forme.
L'une des solutions dont nous avons parlé lors de la conférence Google I/O de cette année est l'affichage dynamique. Il existe plusieurs façons de le mettre en œuvre. Nous allons voir dans cet article de blog un exemple d'affichage dynamique avec Rendertron, une solution Open Source basée sur headless Chromium.

Quels sont les sites qui devraient utiliser l'affichage dynamique ? Tous les moteurs de recherche et les robots de réseaux sociaux qui explorent votre page ne sont pas capables d'exécuter JavaScript. Ainsi, Googlebot peut mettre un certain temps à exécuter vos fichiers JavaScript et présente certaines limites.
L'affichage dynamique est utile pour les contenus fréquemment modifiés et dont l'affichage requiert JavaScript.
Vous pouvez améliorer l'expérience des utilisateurs sur votre site (en particulier le délai d'affichage du first meaningful paint) avec un rendu hybride (Angular Universal, par exemple).

Comment l'affichage dynamique fonctionne-t-il ?

L'affichage dynamique consiste à alterner le contenu affiché côté client et le contenu pré-affiché en fonction des user-agents spécifiques qui tentent d'accéder au contenu.
Vous aurez besoin d'un moteur de rendu pour exécuter le code JavaScript et générer un code HTML statique. Nous utiliserons ici Rendertron. C'est un projet Open Source qui utilise Chromium sans interface graphique (headless Chromium) pour afficher les contenus. Les Single page Apps (applications à page unique) chargent souvent des données en arrière-plan ou reportent les tâches d'affichage du contenu. Rendertron est doté de mécanismes qui déterminent quand l'affichage du contenu d'un site Web est terminé. Il attend que l'ensemble des demandes réseau et des tâches soient terminées.

Dans cet article, nous allons :

• Observer un exemple d'application Web 
• Configurer un petit serveur express.js qui diffusera l'application Web
• Installer et configurer Rendertron en tant que middleware pour l'affichage dynamique

* * *

Exemple d'application Web

L'application Web "kitten corner" utilise JavaScript pour charger des images de chats à partir d'une API et les afficher dans une grille.

Des images de chats mignons et un bouton pour en afficher d'autres, que demander de plus à cette application Web !

Voici son code JavaScript :

  const apiUrl = 'https://api.thecatapi.com/v1/images/search?limit=50';

  const tpl = document.querySelector('template').content;

  const container = document.querySelector('ul');

  function init () {

    fetch(apiUrl)

    .then(response => response.json())

    .then(cats => {

      container.innerHTML = '';

      cats

        .map(cat => {

          const li = document.importNode(tpl, true);

          li.querySelector('img').src = cat.url;

          return li;

        }).forEach(li => container.appendChild(li));

    })

  }

  init();

  document.querySelector('button').addEventListener('click', init);

L'application Web utilise du JavaScript moderne (ES6), qui n'est pas encore interprété par Googlebot. Nous pouvons utiliser le test d'optimisation mobile pour vérifier que Googlebot ne peut pas afficher les contenus :

Si l'on en croit le test d'optimisation mobile, la page est mobile-friendly, mais on ne voit pas les images de chats sur la capture d'écran. L'en-tête et le bouton s'affichent, mais pas les photos de chats.

Même si ce problème se résout facilement, c'est un bon exercice pour s'entraîner à configurer l'affichage dynamique. Grâce à celui-ci, Googlebot pourra voir les photos de chats sans que vous ayez à modifier le code de l'application Web.

Configurer le serveur

Pour diffuser l'application Web, vous devez utiliser la bibliothèque node.js express afin de créer des serveurs Web.

Voici le code du serveur (vous trouverez le code source du projet complet ici) :

const express = require('express');

const app = express();

 

const DIST_FOLDER = process.cwd() + '/docs';

const PORT = process.env.PORT || 8080;

 

// Diffuser les éléments statiques (images, CSS, etc.)

app.get('*.*', express.static(DIST_FOLDER));

 

// Rediriger toutes les autres URL vers index.html pour notre application ayant une seule page

app.get('*', (req, res) => {

res.sendFile(DIST_FOLDER + '/index.html');

});

 

// Démarrer le serveur Express

app.listen(PORT, () => {

console.log(`Node Express server listening on http://localhost:${PORT} from ${DIST_FOLDER}`);

});

L'exemple en ligne se trouve ici : si vous utilisez un navigateur récent, vous devriez y voir des images de chats. Pour exécuter le projet depuis votre ordinateur, vous aurez besoin de node.js afin d'exécuter les commandes suivantes :

npm install express rendertron-middleware
node server.js

Saisissez ensuite http://localhost:8080 dans votre navigateur. Vous êtes maintenant prêt à configurer l'affichage dynamique.

Déployer une instance Rendertron

Rendertron exécute un serveur qui renvoie du code HTML statique pour une URL donnée en utilisant headless Chromium. Nous allons suivre les recommandations du projet Rendertron et utiliser Google Cloud Platform.

Le formulaire pour créer un projet Google Cloud Platform.

(Notez que vous pouvez commencer par utiliser le niveau gratuit. Utiliser cette configuration en production peut entraîner des frais, conformément à la tarification Google Cloud Platform.)

1. Créez un projet dans la Google Cloud Console. Notez l'ID de projet situé sous le champ de saisie.
   
2. Installez le SDK Google Cloud comme décrit dans la documentation et connectez-vous.
   
3. Clonez le dépôt Rendertron depuis GitHub avec :
   
        git clone https://github.com/GoogleChrome/rendertron.git
     cd rendertron
   
4. Exécutez les commandes suivantes pour installer des dépendances et compiler Rendertron sur votre ordinateur :
   
        npm install && npm run build
   
5. Activez le cache de Rendertron en créant un fichier intitulé config.json dans le répertoire de Rendertron. Ajoutez-y le contenu suivant :
   
        { "datastoreCache": true }
6. Exécutez la commande suivante depuis le répertoire de Rendertron. Remplacez VOTRE_ID_DE_PROJET par l'ID de projet obtenu à l'étape 1.
   
        gcloud app deploy app.yaml --project VOTRE_ID_DE_PROJET
   
7. Sélectionnez la région de votre choix et confirmez le déploiement. Attendez la fin du déploiement.
   
8. Dans votre navigateur, saisissez l'URL VOTRE_ID_DE_PROJET.appspot.com (remplacez VOTRE_ID_DE_PROJET par l'ID de projet obtenu à l'étape 1). L'interface de Rendertron devrait s'afficher avec un champ de saisie et quelques boutons.

Interface utilisateur de Rendertron après le déploiement sur Google Cloud Platform

Lorsque l'interface Web de Rendertron s'affiche, cela signifie que vous avez déployé votre propre instance Rendertron. Notez l'URL de votre projet (VOTRE_ID_DE_PROJET.appspot.com), car vous en aurez besoin pour la suite du processus.

Ajouter Rendertron au serveur

Le serveur Web utilise express.js et Rendertron dispose d'un middleware express.js. Exécutez la commande suivante dans le répertoire du fichier server.js :

npm install --save rendertron-middleware

Cette commande installe le middleware rendertron-middleware depuis npm pour que nous puissions l'ajouter au serveur :

const express = require('express');

const app = express();

const rendertron = require('rendertron-middleware');

Configurer la liste de robots

Rendertron utilise l'en-tête HTTP "user-agent" pour déterminer si la requête provient d'un robot ou du navigateur d'un utilisateur. Il compare ces requêtes à une liste complète d'user-agents de robots. Par défaut, cette liste n'inclut pas Googlebot, car il peut exécuter JavaScript. Pour que Rendertron affiche également les requêtes Googlebot, ajoutez Googlebot à liste des user-agents :

const BOTS = rendertron.botUserAgents.concat('googlebot');

const BOT_UA_PATTERN = new RegExp(BOTS.join('|'), 'i');

Rendertron comparera l'en-tête "user-agent" à cette expression régulière.

Ajouter le middleware

Pour diriger les requêtes des robots vers l'instance Rendertron, vous devez ajouter le middleware au serveur express.js. Le middleware vérifie l'user-agent à l'origine de la requête et envoie les requêtes des robots reconnus à l'instance Rendertron. Ajoutez le code suivant à server.js. N'oubliez pas de remplacer "VOTRE_ID_DE_PROJET" par votre ID de projet Google Cloud Platform :

app.use(rendertron.makeMiddleware({

 proxyUrl: 'https://YOUR_PROJECT_ID.appspot.com/render',

 userAgentPattern: BOT_UA_PATTERN

}));

Les robots qui demandent l'exemple de site Web reçoivent le code HTML de Rendertron et n'ont donc pas besoin d'exécuter le JavaScript pour afficher le contenu.

Tester la configuration

Pour vérifier la bonne configuration de Rendertron, exécutez à nouveau le test d'optimisation mobile.

Cette fois-ci, les photos de chats sont visibles. Dans l'onglet "HTML", nous pouvons voir tout le HTML généré par le code JavaScript. On voit également que grâce à Rendertron, le contenu n'a plus besoin de JavaScript pour s'afficher.

Conclusion

Vous venez de configurer un affichage dynamique sans modifier l'application Web. Grâce à cela, vous pouvez proposer une version HTML statique de l'application Web aux robots d'exploration. Félicitations !

Publié par Martin Splitt, Licorne de l'Open Web

Il y a quelques mois, nous avons lancé la nouvelle Search Console pour tous les webmasters. Aujourd'hui, nous annonçons quelques nouveautés dans cette nouvelle expérience.


L'outil d'inspection d'URL

L'une des demandes les plus souvent entendues de la part des webmasters est la capacité d'avoir plus de détails dans la Search Console sur la façon dont Google Search comprend une URL en particulier. Nous avons écouté ce feedback, et aujourd'hui, nous lançons un nouvel outil, l'outil d'inspection d'UR, qui devrait permettre de rendre le moteur un peu plus transparent pour certaines URLs. L'outil fournit des informations sur le crawl, l'indexation, et la diffusion de vos pages directement depuis l'index Google.

Entrez une URL dans cet outil pour connaître la date du dernier crawl (exploration) et le statut de ce crawl, pour vérifier s'il existe des erreurs d'exploration ou d'indexation pour cette URL, ou pour connaître la version canonique de l'URL. Si la page est correctement explorée et indexée, vous pourrez voir d'éventuelles informations que nous avons trouvées sur la page en question (une version AMP associée, des résultats enrichis comme des recettes, etc...)

Si une page n'est en revanche pas indexée, vous pouvez comprendre pourquoi. Le nouvel outil inclut des informations sur les balises noindex et sur le choix d'URL cnaonique par Google pour un document.

Un seul clic peut alors vous mener au rapport montrant plus d'informations sur l'erreur en particulier et listant toute autre page du site qui subirait la même erreur, et vous pouvez alors régler le problème pour toutes les URLs concernées.

Nous espérons que cet outil vous aidera à améliorer le référencement de votre site. Nous rendons cet outil disponible aux premiers utilisateurs à partir d'aujourd'hui, et il deviendra accessible à tous les utilisateurs dans les jours ou les semaines qui viennent.

Encore plus outils !

En plus du lancement de l'outil d'inspection d'URL, nous avons récemment lancé plusieurs outils et fonctionnalités pour la nouvelle Search Console :

• 16 mois de données de traffic : La Search Analytics API contient désormais 16 mois de data, tout comme le rapport sur les performances.

• Informations sur les recettes de cuisine : Le rapport sur l'état des résultats enrichis vous aide désormais à régler les problèmes d'implémentation de données structurées pour les recettes sur votre site. Testez et validez les problémes remontés, et tenez-vous au courant de l'état de correction des problèmes grâce à nos messages envoyés dans la Search Console.

• Nouveaux filtres dans le rapport Performance : Le rapport sur la performance inclut désormais des filtres qui permettent de montrer les données pour les résultats Web Light et Google Play Instant.

Merci pour vos feedbacks et commentaires 

Nous lisons vos commentaires en permanence et avec attention. Nous envoyons des questionnaires de satisfaction, et nous analysons en continu l'utilisation des différents rapports mis à disposition dans la Search Console. Par exemple, nous sommes heureux de voir que le rapport AMP a beaucoup de succès, ainsi que la validation de problèmes d'indexation dans l'outil "couverture de l'index." Nous observons que le temps nécessaire pour la correction de problèmes sur vos sites est plus court lorsque ces outils sont utilisés. 

Nous remercions toutes les personnes qui prenennt du temps pour nous donner du feedback et nous envoyer des commentaires. Cela nous aide pour améliorer le flow utilisateur et pour résoudre les bugs quand nous en trouvons (et quand vous les trouvez pour nous). 

La suite ?

La nouvelle Search Console est toujours en mode Beta, mais de nouvelles fonctionnalités et outils sont régulièrement ajoutés. Continuez à nous faire part de vos questions et suggestions !

Ecrit par Roman Kecher et Sion Schori - ingénieurs Search Console

Lorsque nous avons annoncé, il y a plus d'un an, que nous testions l'indexation Mobile-First, nous avions indiqué que nous informerions les éditeurs de notre progression. Nous l'avons fait ces derniers mois au cours de discussions publiques lors de sessions YouTube Live en direct et lors de conférences comme la Pubcon. Nous l'avons également fait en langue française, comme par exemple lors l'événement "Le SEO en 2018" qui s'est déroulé à Paris dans nos locaux le 1ier décembre (compte-rendu disponible ici).

Pour résumer ces communications, à l'heure actuelle, nos systèmes d'exploration, d'indexation et de classement s'appuient généralement sur la version classique du contenu d'une page, ce qui peut entraîner des problèmes pour les mobinautes lorsque celle-ci est très différente de la version pour mobile. Cependant, l'indexation Mobile-First signifie que nous utiliserons la version pour mobile du contenu pour l'indexation et le classement, afin de mieux aider nos utilisateurs, qui sont principalement des mobinautes, à trouver ce qu'ils cherchent. Les webmasters constateront une augmentation importante de l'exploration par Googlebot pour smartphone, et les extraits dans les résultats ainsi que le contenu des pages en cache de Google proviendront de la version mobile des pages.

Comme nous l'avons indiqué, les sites qui utilisent le Responsive Web Design et mettent en œuvre la diffusion dynamique correctement n'ont en général rien à faire. Voici cependant quelques conseils supplémentaires pour vous assurer qu'un site est prêt pour l'indexation Mobile-First :

• Vérifiez que la version mobile du site comporte elle aussi le contenu important et de grande qualité, notamment le texte, les images (avec les attributs alt) et les vidéos, aux formats pouvant être explorés et indexés habituels.
  
• Les données structurées sont importantes pour l'indexation et les fonctionnalités de recherche que les internautes apprécient : elles doivent figurer à la fois sur la version mobile et la version classique du site.
  
• Les métadonnées doivent être présentes sur les deux versions du site. Elles fournissent des indications sur le contenu d'une page pour son indexation et sa diffusion. Assurez-vous par exemple que les titres, les balises META description et les annotations "hreflang" sont les mêmes sur les deux versions des pages du site.
  
• Aucune modification n'est nécessaire pour lier les URL pour mobile distinctes (sites mobiles m point). Pour les sites qui utilisent des URL pour mobile distinctes, conservez les éléments link rel="canonical" et link rel="alternate" communs à ces versions.
  
• Vérifiez les liens "hreflang" des URL pour mobile distinctes. Lorsque vous utilisez des éléments link "rel=hreflang" pour l'internationalisation, associez les URL pour mobile et pour ordinateur séparément. Le "hreflang" de votre URL pour mobile doit renvoyer vers les versions des URL pour mobile dans d'autres langues ou pour d'autres régions, et associer de la même manière les URL pour ordinateur entre elles à l'aide des éléments link "hreflang".
  
• Assurez-vous que les serveurs qui hébergent le site ont assez de capacité pour gérer l'augmentation potentielle de la fréquence d'exploration. Cela n'affecte pas les sites qui utilisent le Responsive Web Design et la diffusion dynamique, uniquement ceux pour lesquels la version pour mobile est hébergée sur un hôte distinct, tel que m.example.com. 

Nous évaluerons les sites indépendamment pour voir s'ils sont prêts pour l'indexation Mobile-First, en utilisant les critères indiqués ci-dessus. Nous effectuerons leur transition vers le mobile first indexing le moment venu, lorsque les sites sont prêts. Ce processus a déjà commencé pour quelques sites et il est étroitement surveillé par notre équipe de recherche.

Nous restons vigilants dans le déploiement de l'indexation orientée mobiles. Nous pensons que les webmasters doivent préparer leurs sites pour les mobinautes de manière progressive, et pour cette raison, nous n'avons actuellement pas d'échéance pour cette mise en œuvre. Si vous avez des questions, n'hésitez pas à consulter nos forums d'aide pour les webmasters ou à assister à nos événements publics.

Publié par Gary

Le processus d'exploration AJAX avait été mis en place à l'origine pour rendre les pages Web en JavaScript accessibles à Googlebot. Nous avions par le passé annoncé notre intention de le désactiver. Au fil du temps, les ingénieurs Google ont considérablement amélioré l'affichage de JavaScript pour Googlebot. Compte tenu de ces progrès, dès le deuxième trimestre de l'année 2018, nous assurerons l'affichage de ces pages et il ne sera plus demandé aux sites de s'en charger eux-mêmes. En bref, nous n'utiliserons bientôt plus le processus d'exploration AJAX.

Pour rappel, le processus d'exploration AJAX accepte les pages dont l'URL contient "#!" ou une balise Meta fragment, et les explore ensuite avec "?_escaped_fragment_=" dans l'URL. Cette version avec _escaped_fragment_ doit être une version intégrale ou équivalente de la page, créée par le site Web lui-même.

Avec cette modification, Googlebot affichera l'URL #! directement. Il sera donc inutile pour le propriétaire du site de fournir une version interprétée de la page. Nous continuerons de prendre en charge ces URL dans les résultats de recherche.

Nous nous attendons à ce que cette mise à jour n'entraîne pas de changements importants pour la plupart des sites Web explorés par AJAX. Les webmasters peuvent vérifier leurs pages en suivant les recommandations ci-dessous. Nous enverrons des notifications à tous les sites présentant des problèmes potentiels.


Si votre site utilise actuellement des URL contenant #! ou la balise Meta fragment, suivez ces conseils :

• Vérifiez que vous êtes bien le propriétaire du site dans la Google Search Console, afin d'avoir accès aux outils qui s'y trouvent et d'autoriser Google à vous signaler tout problème susceptible d'être détecté.
  
• Effectuez un test à l'aide de l'outil Explorer et afficher de la Search Console. Comparez les résultats de l'URL #! et ceux de l'URL d'échappement pour voir les différences. Procédez ainsi pour toutes parties du site Web qui soient sensiblement différentes. Consultez notre documentation pour les développeurs pour en savoir plus sur les API prises en charge, et reportez-vous à notre guide de debugging, si nécessaire.
  
• Utilisez l'outil Inspecter l'élément de Chrome pour confirmer que les liens utilisent des éléments HTML "a" et contiennent un attribut rel=nofollow, le cas échéant (par exemple, dans le contenu généré par les utilisateurs).
  
• Utilisez l'outil Inspecter l'élément de Chrome pour vérifier le titre et la balise meta description de la page, les balises Meta pour les robots et les autres métadonnées. Vérifiez aussi que les données structurées sont disponibles sur la page affichée.
  
• Convertissez le contenu Flash, Silverlight ou provenant d'autres technologies basées sur des plug-ins en contenu JavaScript ou en HTML "normal", si leur contenu doit être indexé dans la recherche. 

Nous espérons que ce changement facilitera la gestion de votre site Web et vous évitera d'avoir à afficher les pages vous-même. Si vous avez des questions ou des commentaires, n'hésitez pas à consulter nos forums d'aide pour les webmasters ou à rejoindre notre groupe de travail sur les sites JavaScript.


Publié par John Mueller, Google Switzerland

Ces derniers temps, nous avons vu fleurir un certain nombre de définitions du "budget d'exploration" ou "crawl budget". Toutefois, nous ne disposons pas d'un terme unique pour décrire tout ce que ce terme semble signifier en externe. Avec cet article, nous entendons clarifier ce dont il s'agit réellement et ce que cela signifie pour Googlebot.

Tout d'abord, nous voulons souligner le fait que le budget d'exploration, tel qu'il est décrit ci-dessous, ne concerne pas la plupart des éditeurs. Si vous observez que les nouvelles pages sont généralement explorées le jour même de leur publication, alors vous n'avez pas vraiment à vous préoccuper du budget d'exploration. De même, si un site dispose de moins de quelques milliers d'URL, il sera exploré correctement la plupart du temps.

Hiérarchiser le contenu à explorer, la date d'exploration et la quantité de ressources que le serveur hôte peut consacrer à l'exploration est plus important pour les sites plus volumineux ou ceux qui génèrent automatiquement des pages à partir de paramètres d'URL, par exemple.

Limite de la vitesse d'exploration
Googlebot est conçu pour être un bon "citoyen" du Web. Il fait de l'exploration sa priorité, mais il s'assure aussi de ne pas nuire à l'expérience des internautes qui consultent le site. C'est ce que nous appelons la "limite de la vitesse d'exploration". Elle définit une valeur maximale pour un site donné.

Pour faire simple, cela représente le nombre de connexions simultanées parallèles que Googlebot peut utiliser pour explorer le site, ainsi que le temps qu'il doit attendre entre deux explorations. La vitesse d'exploration peut augmenter ou diminuer en fonction de deux facteurs :

• L'état de l'exploration : si le site répond très rapidement pendant un certain temps, la limite augmente, ce qui signifie que davantage de connexions peuvent être utilisées pour l'exploration. Si le site ralentit ou répond par des erreurs de serveur, la limite diminue et Googlebot réduit son exploration.
• La limite définie dans la Search Console : les propriétaires de sites Web peuvent réduire l'exploration de leur site par Googlebot. Sachez que définir une limite plus élevée n'entraîne pas nécessairement une augmentation de l'exploration.

Besoin d'exploration
Même si la vitesse d'exploration n'atteint pas sa limite, en l'absence de besoin d'indexation, l'activité de Googlebot sera faible. Les deux facteurs qui jouent un rôle important dans la détermination du besoin d'exploration sont les suivants :

• La popularité : les URL les plus populaires sur Internet ont tendance à être explorées plus souvent pour être le plus à jour possible dans notre index.
• L'obsolescence : nos systèmes s'efforcent d'empêcher que les URL ne soient pas actualisées dans l'index. 

En outre, les événements sur l'ensemble du site comme les déplacements de site peuvent déclencher une augmentation du besoin d'exploration afin de réindexer le contenu sur les nouvelles URL.

En associant la vitesse d'exploration et le besoin d'exploration, nous définissons le budget d'exploration comme le nombre d'URL que Googlebot peut et veut explorer.

Facteurs affectant le budget d'exploration
D'après nos analyses, la multiplication d'URL à faible valeur ajoutée peut nuire à l'exploration et à l'indexation d'un site. D'après ce que nous avons pu constater, les URL à faible valeur ajoutée entrent dans ces catégories, par ordre d'importance :

• Navigation à facettes et identifiants de session
• Contenu en double sur le site
• Pages d'erreurs "soft 404"
• Pages piratées
• Espaces infinis et proxys
• Contenu de mauvaise qualité et spam

Gaspiller inutilement des ressources du serveur pour des pages de ce type détournera l'activité d'exploration de pages qui ont réellement de la valeur, ce qui peut considérablement retarder la découverte de contenu intéressant sur un site.


Foire Aux Questions !
L'exploration est le point d'entrée pour un site dans les résultats de recherche Google. L'exploration efficace d'un site Web aide donc indirectement à son indexation dans la recherche Google.

Q : La vitesse du site a-t-elle une influence sur mon budget d'exploration ? Qu'en est-il des erreurs ?
R : En rendant un site plus rapide, vous améliorez l'expérience des utilisateurs tout en augmentant la vitesse d'exploration. Pour Googlebot, un site rapide est le signe de serveurs en bon état : il peut accéder à un contenu plus important avec le même nombre de connexions. En revanche, un nombre important d'erreurs 5xx ou de problèmes de délai avant expiration de la connexion indiquent le contraire, et l'exploration ralentit.
Nous recommandons de prêter attention au rapport Erreurs d'exploration de la Search Console et de limiter le nombre d'erreurs serveur.

Q : L'exploration joue-t-elle un rôle dans le classement ? 
R : Une vitesse d'exploration supérieure n'aboutit pas nécessairement à un meilleur classement dans les résultats de recherche. Google utilise des centaines d’indicateurs pour classer les résultats : même si l'exploration est nécessaire pour figurer dans les résultats, elle n'est pas un indicateur de classement.

Q : Les autres versions des URL et le contenu intégré comptent-ils dans le budget d'exploration ?
R : En général, toutes les URL que Googlebot explore comptent dans le budget d'exploration d'un site. Les autres versions d'une URL, comme les versions AMP ou "hreflang", ainsi que le contenu intégré, comme le contenu CSS et JavaScript, peuvent nécessiter une exploration également et utiliser ainsi le budget d'exploration d'un site. De même, les chaînes de redirection longues peuvent avoir des conséquences négatives sur l'exploration.

Q : Puis-je contrôler Googlebot à l'aide de l'instruction "crawl-delay" ?
R : L'instruction non standard "crawl-delay" d'un fichier robots.txt n'est pas traitée par Googlebot.
Pour en savoir plus sur la façon d'optimiser l'exploration de votre site, consultez notre article sur l'optimisation de l'exploration de 2009, qui est toujours valable.

Q: La directive "nofollow" affecte-t-elle mon budget d'exploration ?
A: Tout dépend. Toute URL explorée impacte le budget d'exploration, donc même si un lien vers une page est marqué en nofollow, cette page peut être au bout d'autres liens sur votre site ou sur d'autres sites.

Si vous avez des questions, posez-les sur le forum !

Publié par Gary, équipes Crawl et Indexation