El pressupost de temps que Google t’assigna
Imagina que Google és un auditor amb un nombre limitat d’hores disponibles cada dia. Si el teu edifici té 50 habitacions ben etiquetades i senyalitzades clarament, l’auditor les pot revisar totes amb eficiència. Però si n’hi ha 500, moltes sense etiquetar, algunes plenes de còpies idèntiques dels mateixos documents i d’altres amb passadissos que acaben en parets, l’auditor se n’anirà sense haver vist el que importa.
El crawl budget funciona exactament així. És el conjunt de recursos —temps, peticions HTTP, ample de banda— que Googlebot té disponibles per rastrejar el teu lloc en un període de temps determinat. Quan aquest pressupost s’esgota, Google se’n va. Les pàgines que no ha pogut visitar resten sense indexar, almenys fins a la propera visita, que pot trigar dies o setmanes.
Abans que qualsevol pàgina aparegui als resultats de cerca, Google ha de completar tres passos: rastrejar, indexar i posicionar. El crawl budget afecta la primera baula d’aquesta cadena. Si Google no rastreja una pàgina, no pot indexar-la. Si no l’indexa, no pot posicionar-la.
Aquesta guia explica com funciona aquest pressupost, quan has de preocupar-te’n i, sobretot, com assegurar-te que Googlebot destina els seus recursos a les teves pàgines més valuoses.
Què determina el crawl budget: dos factors que treballen junts
Google va publicar formalment el concepte de crawl budget el gener de 2017. Segons aquella documentació —vigent encara avui—, el pressupost efectiu de rastreig resulta de la combinació de dos factors independents.
El crawl rate limit (límit de taxa de rastreig) és la velocitat màxima a la qual Googlebot pot rastrejar el teu lloc sense degradar l’experiència dels usuaris reals. Google ajusta aquest límit automàticament en funció del temps de resposta del teu servidor. Si el teu servidor respon en 200 ms, Googlebot pot fer més peticions per segon que si respon en 1.500 ms. Pots ajustar aquest límit manualment a Google Search Console, tot i que rarament és recomanable fer-ho a la baixa.
La crawl demand (demanda de rastreig) indica quant vol Google rastrejar el teu lloc, determinat per dos subfactors: la popularitat de les URLs (mesurada aproximadament pel PageRank) i la freqüència de canvis. Una pàgina amb molts enllaços entrants de qualitat té demanda alta. Una pàgina de producte que actualitza el seu preu i disponibilitat cada hora també en té. Les pàgines sense popularitat i sense canvis recents tenen demanda baixa i Googlebot les visita amb menys freqüència.
El crawl budget efectiu és el resultat d’equilibrar tots dos factors. Un lloc amb servidors molt ràpids però amb URLs poc populars no rebrà necessàriament més rastreigs. Un lloc amb contingut fresc i popular però amb servidor lent veurà com Googlebot redueix les seves visites per no sobrecarregar la infraestructura.
Quan importa realment?
John Mueller, de Google, ha estat directe al respecte: “IMO crawl-budget is over-rated. Most sites never need to worry about this.”
Segons la documentació oficial de Google, el crawl budget és rellevant principalment en dos escenaris:
- Llocs amb més d’1 milió de pàgines úniques actualitzades amb freqüència setmanal o superior.
- Llocs amb més de 10.000 pàgines que canvien diàriament.
El llindar d’1 milió de pàgines no ha canviat des del 2020, tal com va confirmar Gary Illyes el 2025. Això significa que per al 99% dels llocs web empresarials, els problemes que semblen de crawl budget són en realitat problemes de qualitat del contingut, estructura d’enllaços interns o velocitat del servidor.
L’insight clau: la base de dades importa més que el volum
Durant dècades, la conversa sobre el crawl budget ha girat al voltant del nombre de pàgines. La intuïció era lògica: més pàgines implica més URLs a rastrejar, cosa que pot esgotar el pressupost. No obstant, al maig de 2025, Gary Illyes va compartir un insight que inverteix aquesta prioritat de manera significativa.
Al podcast Search Off the Record, Illyes va explicar: “If you are making expensive database calls, that’s going to cost the server a lot.” I va afegir un exemple concret: un lloc amb 500.000 pàgines que fa consultes SQL costoses pot tenir més problemes de rastreig que un lloc amb 2 milions de pàgines que serveix contingut estàtic en caché.
Aquest descobriment té implicacions pràctiques immediates. Si tens un e-commerce amb un catàleg mitjà (50.000-200.000 productes) i experimentes problemes d’indexació, la primera pregunta no hauria de ser “quantes URLs tinc?” sinó “quant triguen les meves pàgines a respondre i quines consultes de base de dades executen?”.
La documentació de Google confirma la referència: “Aim for server response times below 300-400 milliseconds on average.” Aquest llindar es refereix al Time to First Byte (TTFB) que Googlebot experimenta, no al temps de càrrega percebut per l’usuari.
Els factors principals que malbaraten el crawl budget
El contingut duplicat tècnic és responsable, segons Ahrefs, del 60% de les URLs duplicades a la web. Les variants més comunes en un mateix lloc: http:// vs. https://, www.domini.com vs. domini.com, URLs amb trailing slash vs. sense, paràmetres de seguiment (?utm_source=email, ?fbclid=...), session IDs a URLs. Cada variant és una petició HTTP diferent per a Googlebot. La solució és consolidar mitjançant canòniques i redirigir variants a l’URL principal.
La navegació per facetes és el multiplicador d’URLs més gran en e-commerce. Una categoria amb filtres de talla (12 opcions), color (8 opcions) i marca (20 opcions) pot generar matemàticament fins a 1.920 combinacions d’URLs úniques. La majoria no té valor SEO independent. Les estratègies de mitigació inclouen etiquetes noindex a les URLs de facetes o filtres JavaScript que no canvien la URL.
Les cadenes de redirecció sumen una petició HTTP addicional per a Googlebot a cada salt. La regla general: cap redirecció hauria de tenir més d’un salt. Les cadenes s’han de col·lapsar apuntant directament al destí final.
Els errors de rastreig (404, soft 404 i 5xx) consumeixen pressupost sense aportar valor. Els errors 5xx són els més perjudicials: indiquen sobrecàrrega o fallades d’infraestructura i Googlebot pot reduir agressivament la seva taxa de rastreig si els troba amb freqüència.
La velocitat de base de dades afecta el crawl budget d’una manera que sovint es passa per alt. Com va assenyalar Gary Illyes al maig de 2025, les consultes costoses poden alentir el servidor fins al punt que Googlebot redueixi la seva taxa de rastreig. Implementar caché de pàgina completa pot millorar dràsticament el TTFB.
Els crawlers d’IA (GPTBot d’OpenAI, CCBot de Common Crawl i similars) poden consumir fins al 40% de l’ample de banda disponible durant cicles de rastreig profund, reduint la disponibilitat del servidor per a Googlebot. Bloquejar GPTBot té, però, un cost documentat: els llocs que ho han fet han registrat una reducció significativa en les citacions a les respostes de ChatGPT.
Com mesurar el teu crawl budget actual
Abans d’optimitzar, necessites dades. Aquestes són les fonts d’informació més fiables.
El Google Search Console — informe de Cobertura mostra l’estat d’indexació de totes les URLs conegudes. Presta atenció especial a “Descobertes: actualment no indexades” i “Rastreades: actualment no indexades”. La primera indica URLs que Google coneix però a les quals no ha pogut arribar encara.
Les Estadístiques de rastreig de GSC (Configuració → Estadístiques de rastreig) mostren el nombre de peticions diàries de Googlebot, el temps de descàrrega mitjà i el propòsit de cada petició. Calcula el ràtio entre el nombre de pàgines rastreades diàriament i el total de pàgines del teu lloc:
- Ràtio pàgines/rastreigs diaris > 10:1 → problema urgent
- Ràtio entre 3:1 i 10:1 → monitorar activament
- Ràtio ≤ 3:1 → no prioritari en aquest moment
L’anàlisi de logs del servidor és la font de la veritat. Eines com Screaming Frog Log Analyzer o SEOlyzer permeten filtrar peticions de Googlebot, calcular taxes de rastreig per secció i identificar URLs amb errors.
Pla d’acció: priorització per impacte
Prioritat 1 — Impacte immediat
- Corregir errors 5xx al servidor
- Eliminar variants d’URL no canòniques (redirigeix HTTP→HTTPS, www→non-www, trailing slash inconsistent)
- Col·lapsar cadenes de redirecció en salts únics
- Corregir el sitemap XML: només URLs 200 canòniques
Prioritat 2 — Impacte mitjà
- Implementar caché de pàgina completa per reduir el TTFB
- Gestionar URLs de facetes (noindex o bloqueig a robots.txt)
- Eliminar o noindex pàgines primes sense valor independent
- Depurar consultes de base de dades lentes
Prioritat 3 — Optimització estructural
- Revisar l’enllaçament intern perquè les pàgines prioritàries estiguin a menys de 3 clics
- Definir una política per als crawlers d’IA (GPTBot, Google Extended, etc.)
- Implementar monitoratge continu de logs per detectar regressions
Conclusió: quan actuar i quan no
John Mueller té raó quan diu que el crawl budget està sobrevalorat per a la majoria de llocs. Si el teu lloc té menys de 100.000 pàgines, un servidor que respon en menys de 400 ms i contingut sense duplicats massius, el crawl budget no és el teu problema.
Però si tens un e-commerce gran, un portal amb navegació per facetes, un lloc amb historial de migracions o una arquitectura amb moltes URLs paramètriques, el crawl budget pot ser l’estrangulador que expliqui per què les teves pàgines no apareixen a Google tot i tenir bon contingut.
La jerarquia correcta de prioritats per optimitzar el crawl budget, a la llum de l’insight de Gary Illyes de 2025, és: velocitat del servidor primer, qualitat del contingut rastreable segon, i volum d’URLs tercer.
Per aprofundir en la intersecció entre SEO tècnic i visibilitat als motors d’IA, revisa la nostra guia sobre problemes d’indexació a Google.