En bref : Si votre site compte moins de 10 000 pages, le crawl budget n'est presque certainement pas votre probleme. Arretez de l'optimiser. En revanche, si vous gerez une boutique e-commerce avec 500 000 fiches produits, un site de petites annonces avec des parametres d'URL infinis, ou quoi que ce soit avec de la navigation a facettes — le crawl budget sabote silencieusement votre indexation. Ce guide explique comment diagnostiquer un vrai probleme de crawl budget, et comment le resoudre. La reponse est generalement peu spectaculaire : des serveurs plus rapides, des URL plus propres, un meilleur robots.txt.
Votre crawl budget reel correspond au plus petit de ces deux facteurs. Si Google souhaite explorer 50 000 de vos pages aujourd'hui (forte demande), mais que votre serveur ne peut gerer que 5 000 requetes sans degradation (limite de debit faible), vous obtenez 5 000. Si votre serveur peut encaisser 100 000 requetes mais que Google ne s'interesse qu'a 2 000 de vos pages (faible demande), vous obtenez 2 000.
C'est la ou la plupart des guides se trompent. Ils traitent le crawl budget comme un reservoir fixe qu'il faudrait « economiser » en bloquant les pages sans importance. En realite, c'est dynamique, ca change chaque jour, et pour la majorite des sites, ce n'est absolument pas le goulot d'etranglement.
Je dois le dire clairement, parce que j'ai vu des agences vendre de l'optimisation de crawl budget a des sites de 200 pages.
Si votre site compte moins de 10 000 URL uniques environ, l'optimisation du crawl budget est presque certainement une perte de temps.
Gary Illyes l'a dit lui-meme, a plusieurs reprises, notamment lors de Google I/O et sur Twitter. Sa formulation exacte : « Si votre site a quelques milliers d'URL, la plupart du temps il sera explore efficacement. » Martin Splitt, Developer Advocate chez Google, a fait echo a ce constat lors d'un episode de ses office hours JavaScript SEO en disant que le crawl budget ne devient un vrai sujet « qu'a partir de dizaines de milliers de pages ou plus ».
Google explore des milliards de pages par jour. Votre blog WordPress de 500 pages est une erreur d'arrondi. Google explorera l'integralite du site en quelques jours apres n'importe quel changement, sans que vous fassiez quoi que ce soit de special.
Les cas ou le crawl budget compte vraiment :
Si aucune de ces situations ne vous correspond, allez directement a la section FAQ en bas de page et passez a autre chose. Je suis serieux. Consacrez votre temps a la qualite du contenu et au maillage interne. Je reste convaincu que 90 % des personnes qui font de « l'optimisation de crawl budget » devraient entendre ceci : votre probleme est probablement ailleurs.
2. Verifiez votre ecart d'indexation. Comparez le nombre de pages dans votre sitemap avec le nombre de pages indexees dans le rapport « Pages » de la GSC. Si vous avez 100 000 URL dans votre sitemap mais seulement 40 000 indexees, quelque chose consomme votre crawl budget avant qu'il n'atteigne les pages importantes.
3. Analysez les logs serveur. C'est le vrai diagnostic. La GSC vous donne des donnees agregees. Les logs serveur vous donnent la verite — chaque requete de Googlebot, a quel moment, vers quelle URL, et quelle reponse il a recue. Si vous constatez que Googlebot passe 60 % de son exploration sur des pages d'archives paginées ou des URL filtrees, c'est votre probleme, noir sur blanc.
Je vais etre honnete sur une limite ici : je ne suis pas certain que le rapport de statistiques d'exploration de la GSC soit toujours fiable. Nous avons constate des ecarts entre ce que la GSC rapporte et ce que les logs serveur de nos clients montrent. Parfois des ecarts significatifs — de 30 a 40 %. Je ne sais pas si c'est un probleme d'echantillonnage cote Google, un artefact de mise en cache, ou autre chose. C'est pourquoi je recommande toujours de verifier avec les logs serveur quand les enjeux sont importants.
| Signal diagnostique | Sain | Alerte | Critique |
|---|---|---|---|
| Nouvelle page indexee en | 1 a 3 jours | 1 a 2 semaines | 4+ semaines ou jamais |
| Requetes d'exploration/jour vs total de pages | > 50 % des pages explorees par semaine | 10 a 50 % par semaine | < 10 % par semaine |
| Temps de reponse moyen du serveur | < 200 ms | 200 a 500 ms | > 500 ms |
| % d'exploration sur des URL non indexables | < 10 % | 10 a 30 % | > 30 % |
| Chaines de redirections lors de l'exploration | Aucune | < 5 % des requetes | > 5 % concernees |
| Taux d'erreurs 5xx durant l'exploration | 0 % | < 1 % | > 1 % |
Note : ces seuils sont des reperes bases sur l'experience, tires de tendances observees dans les donnees clients de SEOJuice, pas des chiffres officiels publies par Google. Vos resultats peuvent varier selon la taille du site, le secteur et l'architecture serveur.
Si la plupart de vos signaux sont dans la colonne « Sain », vous n'avez pas de probleme de crawl budget. Allez optimiser autre chose.
C'est le facteur de crawl budget qui a le plus d'impact et qui recoit le moins d'attention. Tout le monde veut parler de robots.txt et de sitemaps. Personne ne veut parler de la raison pour laquelle son serveur met 1,2 seconde a repondre a une simple requete HTML.
Googlebot est poli. Il surveille le temps de reponse de votre serveur en temps reel. Si votre serveur commence a ralentir, Googlebot reduit sa frequence d'exploration pour eviter de le surcharger. C'est la limite de debit d'exploration en action. Un serveur qui repond en 100 ms sera explore de facon radicalement plus intensive qu'un serveur qui repond en 800 ms.
« Si le site est vraiment rapide, Googlebot pourra utiliser davantage de connexions et explorer le site plus rapidement. Si le site ralentit ou renvoie des erreurs serveur, il ralentira et explorera moins. »
— Gary Illyes, Senior Search Analyst, Google (Google Developers Blog)
C'est une citation directe du billet de blog officiel sur le crawl budget. « Vraiment rapide » pour Google signifie un temps de premier octet (TTFB) inferieur a 200 ms. Pas le temps de chargement de la page — le TTFB. Le temps que met votre serveur a commencer a envoyer la reponse HTML.
Gains rapides pour le temps de reponse serveur :
Sur le site d'un client SEOJuice — une boutique e-commerce de meubles avec environ 80 000 fiches produits — nous avons observe la chute de leur taux d'exploration dans la GSC de 15 000 requetes/jour a 3 000 en deux semaines. Aucun changement de contenu ni de structure. La cause ? Leur hebergeur les avait migres vers un nouveau cluster de serveurs et le TTFB etait passe de 180 ms a 900 ms. Une fois l'hebergement corrige, le taux d'exploration s'est retabli en quatre jours. Pas de modification du robots.txt. Pas de mise a jour du sitemap. Juste des serveurs plus rapides.
Les parametres d'URL sont la source la plus courante de gaspillage de crawl. Et le probleme est insidieux, car souvent vous ne savez meme pas que ca se produit.
Prenons un site e-commerce avec du filtrage. Un utilisateur parcourt les chaussures et selectionne : taille 42, couleur noire, marque Nike, tri par prix, page 2. Ca donne une URL du type :
/shoes?size=10&color=black&brand=nike&sort=price&page=2Maintenant, multipliez par chaque combinaison possible. 8 tailles, 12 couleurs, 40 marques, 4 options de tri, 50 pages de resultats. Ca fait 8 × 12 × 40 × 4 × 50 = 768 000 URL. A partir d'une seule page categorie. Et le contenu de la plupart de ces pages se recoupe significativement — les chaussures Nike noires taille 42 triees par prix, ce sont globalement les memes produits que les chaussures Nike noires taille 42 triees par nouveaute.
Googlebot ne le sait pas. Il voit 768 000 URL uniques et commence a les explorer. Vos veritables pages produits — celles qui devraient se positionner — patientent dans une file d'attente derriere des centaines de milliers de variations filtrees que personne ne recherchera jamais.
C'est ce qu'on entend par « la navigation a facettes cree des pieges de crawl ». Il ne s'agit pas de Google pris dans une boucle infinie (bien que ca puisse arriver avec certains systemes de pagination). C'est que Google alloue son crawl budget limite a des URL qui n'apportent aucune valeur unique.
Je tiens a preciser un point : l'outil de parametres d'URL dans Google Search Console a ete deprecie et supprime en 2022. Google vous permettait auparavant de lui indiquer quels parametres ignorer. Cette option n'existe plus. Vous disposez desormais de trois outils pour gerer ca :
Chacun a ses compromis. Je couvre le robots.txt et les canonicals dans leurs sections dediees ci-dessous.
Votre robots.txt est le premier fichier que Googlebot consulte avant d'explorer votre site. C'est aussi le fichier le plus mal compris en SEO. Les gens le laissent vide (occasion manquee) ou en font trop (en bloquant ce qu'ils ne devraient pas).
Voici le principe cle : bloquez ce qui gaspille du crawl budget, pas ce qui est « sans importance ». Il y a une difference. Une page « sans importance » peut quand meme avoir besoin d'etre indexee. Une page qui gaspille du crawl budget est une page qui n'apporte aucune valeur unique a la recherche et qui existe en milliers de variations parametrees.
# Bloquer les parametres de navigation a facettes
User-agent: *
Disallow: /*?sort=
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*&sort=
Disallow: /*&color=
Disallow: /*&size=
# Bloquer les resultats de recherche interne
Disallow: /search?
Disallow: /search/
# Bloquer les URL basees sur les sessions
Disallow: /*?sessionid=
Disallow: /*?ref=
# Bloquer les pages admin, panier et compte
Disallow: /admin/
Disallow: /cart/
Disallow: /my-account/
Disallow: /checkout/
# Bloquer les versions impression et PDF
Disallow: /*?print=
Disallow: /*?format=pdf
# NE PAS bloquer CSS, JS ou images
# Googlebot en a besoin pour afficher vos pages
Allow: /*.css
Allow: /*.js
Allow: /*.jpg
Allow: /*.png
Allow: /*.webp
Sitemap: https://example.com/sitemap.xmlErreurs critiques que j'ai vues :
/products/ parce qu'il veut bloquer /products?filter= et desindexe accidentellement l'integralite de son catalogue.Ce dernier point merite d'etre repete, car il piege aussi les SEO experimentes. Robots.txt bloque l'exploration. Il ne bloque pas l'indexation. Si vous voulez empecher l'indexation, utilisez <meta name="robots" content="noindex"> ou un en-tete HTTP X-Robots-Tag. Mais attention : pour que Google voie une balise noindex, il doit d'abord explorer la page. Donc si vous bloquez l'exploration avec robots.txt ET ajoutez noindex, Google ne verra jamais la balise noindex. Ce paradoxe seme la confusion depuis des annees.
Un sitemap ne garantit pas l'indexation. Il ne garantit meme pas l'exploration. Ce qu'il fait, c'est donner a Google une indication des URL existantes, de leur derniere modification, et (discutablement) de leur importance relative les unes par rapport aux autres.
Les erreurs que les gens font avec les sitemaps concernent presque toujours un exces d'inclusion, pas un manque.
Ce qu'il faut inclure dans votre sitemap :
<lastmod> exactes — pas la date du jour, pas la meme date sur chaque page, mais la vraie date de derniere modificationCe qu'il faut exclure de votre sitemap :
J'ai vu des sitemaps avec 500 000 URL dont seulement 80 000 etaient reellement indexables. Les 420 000 restantes etaient des redirections, des pages noindexees, des variations parametrees et des URL cassees. Ce sitemap n'aide pas Google — il l'envoie en chasse au tresor dont 84 % de la carte est fausse.
Martin Splitt a qualifie <lastmod> de « l'une des balises les plus detournees dans les sitemaps » parce que tellement de CMS la reglent sur la date du jour pour chaque page. Quand chaque page dit « je viens d'etre modifiee », Google apprend a ignorer completement le signal. Si votre CMS ne suit pas les vraies dates de modification, corrigez ca avant de vous preoccuper de quoi que ce soit d'autre lie au sitemap.
Je consacre une section entiere a la navigation a facettes parce que c'est a l'intersection du crawl budget, du contenu duplique et de l'architecture technique — et qu'une mauvaise gestion peut couler silencieusement le SEO d'un site sur plusieurs mois.
Le probleme : la navigation a facettes (filtres sur les sites e-commerce, les petites annonces, les sites d'emploi) genere des combinaisons d'URL exponentielles. Nous avons couvert les calculs plus haut. Mais la solution n'est pas aussi simple que « tout bloquer avec robots.txt » parce que certaines pages facettees ont une reelle valeur en recherche.
Reflechissez : « chaussures de running Nike taille 42 » est une vraie requete de recherche qu'une vraie personne tape dans Google. Une page facettee correspondant a cette requete pourrait se positionner dessus. Bloquer toutes les URL facettees signifie perdre cette opportunite.
Le cadre que je recommande — et que nous implementons pour les clients SEOJuice confrontes a ce probleme :
| Type de facette | Exemple | Valeur en recherche | Approche recommandee |
|---|---|---|---|
| Categorie + Marque | /shoes/nike/ | Elevee — les internautes recherchent marque + categorie | Indexer, inclure dans le sitemap, utiliser une URL propre |
| Categorie + 1 filtre | /shoes?color=black | Moyenne — depend du volume de recherche | Verifier le volume de recherche. Indexer si > 100 recherches mensuelles, canonical vers le parent sinon |
| Categorie + 2 filtres ou plus | /shoes?color=black&size=10 | Faible — trop specifique pour la plupart des recherches | Canonical vers le filtre le plus pertinent ou la categorie parente |
| Variations de tri | /shoes?sort=price-asc | Nulle — personne ne cherche « chaussures triees par prix » | Bloquer avec robots.txt ou noindex |
| Pages de pagination profondes | /shoes?page=47 | Nulle au-dela des pages 2-3 | Noindex apres la page 3-5, garder explorable |
| Parametres de session/tracking | /shoes?utm_source=email | Nulle | Bloquer avec robots.txt, supprimer au niveau serveur |
L'implementation des balises canonical pour les pages multi-filtres ressemble a ceci :
<!-- Sur /shoes?color=black&size=10&sort=price -->
<link rel="canonical" href="https://example.com/shoes?color=black" />
<!-- Sur /shoes?sort=price -->
<link rel="canonical" href="https://example.com/shoes" />
<!-- Sur /shoes (la page categorie propre) -->
<link rel="canonical" href="https://example.com/shoes" />Une erreur que j'ai commise et que je n'ai pas completement resolue : que faire des pages facettees qui ont accumule des backlinks. Un client avait des milliers de liens externes pointant vers des URL filtrees. Les canonicaliser vers la page parente devrait faire remonter l'autorite — ca semble logique en theorie.
En pratique, nous avons observe une baisse de 15 % des positions de la page parente apres avoir implemente les canonicals. Je ne sais toujours pas pourquoi. Mon hypothese : la consolidation soudaine de milliers de signaux a perturbe l'evaluation de Google, mais c'est de la speculation. Nous avons fait marche arriere sur les canonicals des pages filtrees les plus linkees et les avons laissees indexables. C'est un compromis qui ne me satisfait pas.
En resume : rel="next" et rel="prev" sont deprecies. Google a confirme en 2019 qu'il n'utilisait plus ce signal depuis des annees. Alors que faire a la place ?
Trois options, classees par ordre de preference :
Option 1 : chargement progressif ou defilement infini avec pushState. C'est l'approche la plus propre pour les nouveaux sites. Les utilisateurs voient une seule URL. Google explore le contenu complet. Pas d'URL de pagination gaspillant du crawl budget. Mais ca necessite du JavaScript, ce qui introduit ses propres couts en crawl budget (plus de details ci-dessous).
Option 2 : pagination classique avec noindex sur les pages 2+. Gardez les URL paginées explorables (pour que Google puisse decouvrir les produits/articles lies depuis celles-ci) mais noindexez-les pour que Google ne tente pas d'indexer des pages de gabarit identiques. Le canonical sur chaque page paginee doit etre auto-referent — ne canonicalisez pas toutes les pages vers la page 1, car le contenu est different.
Option 3 : page vue complete. Si votre contenu pagine totalise moins de ~200 elements, envisagez une page unique qui affiche tout et canonicalise la serie paginee. Google a historiquement prefere les pages vue complete. L'inconvenient : le temps de chargement. Si votre page vue complete met 8 secondes a charger, le remede est pire que le mal.
<!-- Page 2 des archives du blog -->
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https://example.com/blog/page/2" />
<!-- Important : utilisez "noindex, follow" — pas "noindex, nofollow"
Vous voulez que Google suive les liens des pages paginées
pour decouvrir les pages de contenu reelles -->Notez la directive follow. C'est crucial. Vous ne voulez pas que la page paginee apparaisse dans l'index, mais vous voulez absolument que Google suive les liens qu'elle contient pour trouver votre vrai contenu. Utiliser nofollow ici orphelinerait chaque article ou produit uniquement lie depuis la page 2+ de vos archives.
Cette section concerne tous ceux qui gerent un site lourd en JavaScript (React, Vue, Angular, Next.js sans SSR correctement configure). Si votre site utilise un rendu HTML classique cote serveur, passez a la suite.
Google explore en deux vagues. Premiere vague : il telecharge et traite le HTML brut. Deuxieme vague : il rend la page avec un navigateur Chromium headless pour executer le JavaScript et voir le contenu final. La deuxieme vague intervient plus tard — parfois des heures plus tard, parfois des jours.
Martin Splitt a explique tout cela en detail lors de ses office hours JavaScript SEO. L'idee cle : le rendu coute cher a Google. Ca consomme plus de ressources qu'un simple telechargement HTML. Google doit lancer une instance Chromium, executer votre JavaScript, attendre que les appels API se resolvent, puis traiter le DOM rendu. Les pages dependantes de JavaScript sont donc explorees de maniere moins efficace que les pages rendues cote serveur.
L'impact sur le crawl budget :
La solution : le rendu cote serveur (SSR) ou la generation statique (SSG). Next.js, Nuxt, SvelteKit proposent tous cette fonctionnalite. Si vous ne pouvez pas faire du SSR complet, utilisez le rendu dynamique : servez du HTML pre-rendu a Googlebot et l'experience JS complete aux utilisateurs. Google le deconseille techniquement, mais debut 2026 ca fonctionne en pratique. Nous avons couvert les defis specifiques aux SPA dans notre guide des bonnes pratiques SEO pour les SPA.
Ce qu'il faut chercher dans vos logs :
Outils : Screaming Frog Log Analyzer est l'outil dedie le plus populaire. Vous pouvez aussi parser les logs en ligne de commande (grep sur le user agent Googlebot, pipe dans awk). Pour un suivi continu, la fonctionnalite d'analytique d'exploration de SEOJuice traite automatiquement les logs serveur et signale les problemes de crawl budget.
Un exemple reel tire de nos donnees : un client avait un site WordPress avec environ 25 000 articles publies. Du bon contenu, un trafic correct. Mais leurs logs serveur montraient que Googlebot consacrait 40 % de son crawl budget aux endpoints /wp-json/ et aux URL /feed/. Ce ne sont pas des pages que quiconque recherche. Deux lignes ajoutees au robots.txt ont libere ces 40 % pour les pages de contenu reel. En trois semaines, leur taux d'exploration sur les pages d'articles avait augmente de 60 %, et 12 nouvelles pages avaient ete indexees alors qu'elles stagnaient dans le purgatoire « Decouverte — actuellement non indexee » depuis des mois.
# Economies de crawl budget specifiques a WordPress
User-agent: *
Disallow: /wp-json/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /author/*/feed/
Disallow: /category/*/feed/
Disallow: /tag/*/feed/
Disallow: /?replytocom=
Disallow: /trackback/Les liens internes sont le signal le plus puissant que vous controlez pour indiquer a Google quelles pages comptent. Pas les balises meta. Pas les valeurs de priorite du sitemap (que Google ignore de toute facon). Les liens internes.
Chaque lien est un vote. Une page liee depuis votre page d'accueil, votre navigation et 50 autres pages sera exploree plus frequemment qu'une page liee depuis une seule page d'archive, trois clics plus profond. C'est la distribution basique du PageRank, et c'est ainsi que Googlebot decide ou depenser son crawl budget.
L'implication pratique : si des pages ne sont pas indexees et qu'elles se trouvent a 3 clics ou plus de votre page d'accueil, ajouter des liens internes depuis des pages bien connectees augmente leur frequence d'exploration. Nous l'avons constate de facon systematique — les pages passant de 0-1 liens internes a 5+ recoivent leur premiere visite de Googlebot en 48 heures, meme sur les grands sites ou les nouvelles pages attendent normalement des semaines.
C'est pourquoi nous avons integre le maillage interne automatique dans SEOJuice. Gerer manuellement les liens internes sur plus de 10 000 pages est impossible. Mais le benefice en termes de priorite d'exploration en fait l'une des activites de SEO technique au meilleur retour sur investissement.
Une architecture plate (chaque page accessible en 3 clics ou moins) est meilleure pour le crawl budget qu'une hierarchie profonde. Mais « plat » ne signifie pas « tout lier a tout ». Cela signifie un maillage strategique — clusters thematiques, pages piliers, liens contextuels — qui cree des chemins d'exploration clairs vers vos pages les plus importantes.
Je vais etre precis sur ce que nous faisons concretement, plutot que du discours marketing vague.
SEOJuice suit le comportement d'exploration via trois sources : les statistiques d'exploration de la GSC (via l'API Search Console), nos propres donnees d'exploration (nous crawlons les sites clients pour construire le graphe de maillage interne), et optionnellement, l'integration des logs serveur.
Ce que nous mettons en evidence :
Nous ne faisons pas encore d'analyse complete des logs serveur dans le produit (parser des formats de logs serveur heterogenes a grande echelle est un defi d'ingenierie que je n'ai pas resolu a ma satisfaction). Mais les donnees GSC combinees a notre propre robot d'exploration donnent a la plupart des sites suffisamment d'elements pour identifier et corriger les problemes de crawl budget sans toucher a un fichier de log.
Si vous avez lu jusqu'ici et determine que vous avez effectivement un probleme de crawl budget, voici ce qu'il faut corriger, par ordre d'impact :
Les etapes 1 a 3 resolvent le probleme pour la majorite des sites qui ont reellement besoin d'optimiser leur crawl budget. Les etapes 4 a 9 s'adressent aux autres — les sites a architectures complexes ou les bases ne suffisent pas.
Non. Le crawl budget affecte la capacite de vos pages a etre explorees et indexees, pas la facon dont elles se positionnent une fois indexees. Mais une page qui n'est jamais exploree n'est jamais indexee, et une page qui n'est jamais indexee ne peut pas se positionner. Le crawl budget est donc un prerequis, pas un facteur de classement. L'optimiser n'ameliorera pas le positionnement des pages deja indexees — ca aide les pages qui ne sont pas du tout indexees.
Presque jamais. Les parametres de taux d'exploration dans la GSC vous permettent de reduire la frequence d'exploration de Googlebot, pas de l'augmenter. La seule raison d'utiliser ca est si Googlebot submerge litteralement votre serveur. Si votre serveur supporte le trafic, n'y touchez pas. J'ai vu des gens la reduire en pensant que ca « concentrerait » Google sur les pages importantes. Ca ne fonctionne pas comme ca — Google explore simplement moins de tout.
Les pages populaires et frequemment mises a jour : plusieurs fois par jour. Les pages statiques inchangees depuis des mois : toutes les quelques semaines. La moyenne est d'environ 1 a 2 semaines par page, mais varie enormement. Les sites d'actualites sont explores en quelques minutes. Une page « A propos » rarement mise a jour peut passer un mois entre deux visites. La balise <lastmod> peut signaler qu'une page a change, mais seulement si vous l'utilisez correctement — Google l'ignore si elle est toujours reglee sur la date du jour.
Vous pouvez augmenter votre limite de taux d'exploration (serveur plus rapide) et reduire le gaspillage de crawl (pour que davantage de budget aille aux pages importantes). Mais vous ne pouvez pas demander directement a Google de vous explorer davantage. La demande d'exploration est une decision de Google basee sur la valeur percue du contenu. La meilleure approche indirecte : publiez regulierement, construisez des backlinks, rendez votre contenu genuinement utile. Les sites a forte valeur sont explores plus agressivement, automatiquement.
Oui. Google explore quand meme la page pour voir la balise noindex. 100 000 pages noindexees signifient 100 000 requetes de crawl budget (bien que moins frequentes que pour les pages indexees). Si ces pages n'ont vraiment jamais besoin d'etre indexees, robots.txt est plus economique en crawl — mais robots.txt empeche Google de voir quoi que ce soit sur la page, y compris les liens. Utilisez noindex+follow quand vous voulez la decouverte de liens mais pas l'indexation. Utilisez robots.txt quand vous ne voulez pas que la page soit exploree du tout.
Cet article fait partie de notre serie sur le SEO technique. Si vous travaillez sur des problemes de crawl budget, ces guides complementaires vous aideront :
Si vous gerez un site volumineux et souhaitez un suivi automatise du crawl budget, SEOJuice surveille le gaspillage de crawl, la velocite d'indexation et le temps de reponse serveur sur l'ensemble de vos pages. Ca ne remplacera pas l'analyse des logs serveur pour les architectures complexes, mais ca met en lumiere la majorite des problemes de crawl budget qui comptent — en continu, pas uniquement quand quelqu'un pense a lancer un audit. Demarrez un essai gratuit et decouvrez ou va votre crawl budget en quelques minutes.
no credit card required
No related articles found.