Crawl budget: ce este și cum îl optimizezi pentru site-uri mari

Crawl budget este limita de pagini pe care Googlebot le poate crawla pe site-ul tău într-o fereastră de timp dată. Google alocă fiecărui domeniu un buget bazat pe doi factori: crawl rate limit (cât de rapid poate crawla fără să supraîncarce serverul) și crawl demand (cât de mult vrea Google să crawleze, funcție de popularitatea și frecvența schimbărilor site-ului). Produsul lor determină câte pagini ajung efectiv în coada de crawl.

Termenul a apărut explicit în documentația Google în 2017, când au publicat primul ghid dedicat optimizării pentru crawl budget. Confuzia clasică este că un buget mai mare înseamnă automat mai mult trafic organic. Nu înseamnă. Un buget bine utilizat înseamnă că paginile care contează sunt indexate rapid; cele care nu ar trebui să existe nu consumă din el.

Ce este crawl budget mai exact?

Googlebot nu crawlează un site în întregime la fiecare vizită. Fiecare domeniu primește un număr estimat de cereri pe zi, determinat dinamic de Google în funcție de doi parametri independenți:

• Crawl rate limit: rata maximă cu care Googlebot acceptă să crawleze, ca să nu afecteze răspunsul serverului. Poate fi ajustată manual din Google Search Console, în jos (dacă serverul tău e lent), dar niciodată în sus peste ce decide Google.
• Crawl demand: cererea de crawl pe care Google o consideră justificată pentru domeniu. Site-urile populare, actualizate frecvent, cu backlink-uri de calitate, au o crawl demand mai mare. Site-urile cu conținut stale sau cu prea multe pagini inutile, mai mică.

În practică, bugetul zilnic al unui site mediu este mai mare decât numărul de pagini noi publicate, deci crawl budget-ul nu este o problemă. Devine o problemă când URL-urile cresc mai rapid decât semnalele de calitate, sau când multe URL-uri consumă din buget fără valoare de indexare.

Când contează crawl budget (de la ce dimensiune de site)?

Google a precizat că, pentru site-uri cu câteva sute de pagini actualizate rar, crawl budget-ul nu este un factor de îngrijorare. Devine relevant în trei scenarii:

• Dimensiune mare. Site-uri cu zeci de mii de pagini, unde Googlebot nu poate acoperi tot indexul într-o zi. Magazinele online cu filtre generatoare de URL-uri, site-urile de știri cu arhive adânci, sau platformele cu conținut generat de utilizatori intră în această categorie.
• Publicare frecventă. Site-uri cu câteva mii de pagini care publică zilnic. Dacă Google crawlează mai rar decât publici, articolele noi intră în index cu întârziere.
• URL-uri inutile proliferate. Chiar și un site mic poate epuiza crawl budget-ul dacă are mii de URL-uri din parametri, sesiuni sau filtre. Google cheltuie bugetul pe zgomot și nu mai ajunge la paginile care contează.

Un blog cu câteva zeci de articole nu are de ce să optimizeze crawl budget-ul. Un catalog de e-commerce cu 30.000 de produse și filtre combinate care generează URL-uri unice, da.

Ce factori îl consumă (redirects, parametri URL, duplicate, pagini lente)?

Fiecare cerere HTTP pe care Googlebot o face consumă din buget, indiferent dacă cererea aduce sau nu valoare de indexare. Principalii consumatori neproductivi:

• Lanțuri de redirects. Un redirect 301 consumă o cerere fără să descopere conținut nou. Un lanț A → B → C consumă trei cereri pentru a ajunge la C. Scurtează lanțurile la maximum un redirect și actualizează linkurile interne să pointeze direct la URL-ul final.
• Parametri URL fără valoare semantică. ?utm_source=newsletter, ?session_id=xyz, ?sort=asc&color=red creează variante aparent distincte ale aceleiași pagini. Dacă nu există un tag canonical care să consolideze aceste variante pe URL-ul curat, Googlebot le tratează ca pagini separate și le crawlează pe toate.
• Conținut duplicat. Pagini accesibile pe mai multe URL-uri (cu și fără www, cu și fără slash final, versiuni HTTP și HTTPS) consumă bugetul de mai multe ori. Rezolvarea este o politică de redirect consistentă plus canonical pe toate variantele.
• Pagini cu TTFB mare. Când serverul răspunde lent, Googlebot reduce frecvența crawlului pentru a nu-l supraîncărca. Un time to first byte constant peste 500 ms semnalează un problem de performanță care afectează atât experiența utilizatorilor, cât și ritmul de crawl. Server-side rendering corect implementat reduce TTFB față de o arhitectură pur client-side, pentru că browserul primește HTML complet la prima cerere.
• URL-uri noindex în sitemap. Paginile cu meta robots noindex pe care le listezi totuși în sitemap forțează Googlebot să le crawleze ca să confirme că sunt marcate noindex, consumând buget inutil.

Cum gestionăm sitemap-ul dinamic pe crawlerra.com pentru a optimiza crawl budget-ul?

Sitemap-ul crawlerra.com este randat live de procesul SSR. Handlerul Express face un fetch server-side către endpoint-ul /api/v1/articles/slugs cu timeout de patru secunde, apoi cade pe setul static dacă backend-ul nu răspunde. În felul ăsta sitemap-ul reflectă mereu articolele real publicate, fără URL-uri stale care ar consuma crawl budget-ul Google pe pagini care nu mai există.¹

Consecința practică este că, la fiecare cerere Googlebot către /sitemap.xml, lista de URL-uri este exact ce trăiește în baza de date, cu lastmod-ul corect din coloana updated_at a fiecărui articol. Google nu pierde cereri pe slug-uri șterse sau pe drafturi care nu au ajuns niciodată publice. Detaliile complete despre generarea sitemap-ului și fallback-ul static sunt în intrarea despre sitemap.xml dinamic.

Pe lângă sitemap, robots.txt declară explicit Disallow pentru zonele autentificate (/admin/, /portal/) care nu au valoare de indexare. Asta elimină o clasă întreagă de URL-uri care altfel ar putea ajunge în coada de crawl prin linkuri interne neintenționat lăsate publice.

Care sunt capcanele tipice (orphan pages, infinite spaces, JS-only content)?

• Pagini orfane. URL-uri accesibile tehnic, incluse poate în sitemap, dar la care nicio pagină publică nu linkuiește. Googlebot le poate descoperi prin sitemap, dar semnalul de importanță este slab. Dintr-o perspectivă de crawl budget, o pagină orfană care nu are trafic și nu are backlink-uri consumă din buget fără niciun randament. Soluția este un audit periodic de linkuri interne.
• Infinite spaces (spații infinite). Calendar-uri cu navegare infinită pe date viitoare, filtre de produse combinate fără limită, pagini de căutare cu orice query posibil: orice structură care generează URL-uri nelimitate. Fiecare URL distinctibil consumă din buget. Soluția este noindex pe paginile de navigare fără conținut unic sau Disallow în robots.txt pentru URL pattern-urile generatoare.
• Conținut exclusiv JS. Paginile Angular sau React randate doar client-side ajung la Googlebot ca HTML gol la prima cerere. Google pune renderizarea în coada de procesare și revine ulterior, uneori cu zile de întârziere. Pentru pagini importante (articole, pagini de produs, orice vrei indexat rapid), server-side rendering elimină dependența de coada de renderizare.
• Hreflang greșit configurat. Un sitemap cu declarații hreflang incorecte (URL-uri lipsă, limbi neasociate cu URL-ul corect) poate genera sesiuni de crawl mai lungi, cu mai multe cereri de confirmare a alternativelor lingvistice. Fiecare pereche ruptă costă câteva cereri în plus.
• JSON-LD invalid pe paginile indexate. Un JSON-LD malformat nu blochează indexarea, dar poate face Google să crawleze pagina mai des pentru a valida datele structurate. Validează cu Rich Results Test după fiecare deploy care atinge template-urile.

Diagnoza pornește din Google Search Console, secțiunea Crawl Stats. O scădere bruscă în numărul zilnic de cereri înseamnă că Google și-a redus crawl rate limit-ul, cel mai adesea din cauza TTFB-ului. Dacă numărul de cereri rămâne constant dar paginile indexate stagnează, cereri se duc pe URL-uri inutile. Ambele situații au remedii tehnice clare, parte din orice audit SEO tehnic serios. Despre cum decidem ce proiecte merită un astfel de audit, am scris separat.

1. Handlerul sitemap-ului face fetch către http://127.0.0.1:8084/api/v1/articles/slugs cu AbortController setat la 4 secunde și fallback la URL-urile statice dacă backend-ul nu răspunde. [crawlerra.sitemap_handler]