Ce înseamnă crawl budget și cum îl optimizați

Ce înseamnă crawl budget și cum îl optimizați este o întrebare la care răspunsul corect începe cu alta: aveți de fapt o problemă de buget de accesare? Google spune limpede că majoritatea site-urilor, sub câteva mii de pagini, nu au. Site-urile cu zeci de mii de adrese, magazinele cu filtre și platformele care generează pagini automat, da. Ghidul de față explică noțiunea, arată cum verificați dacă vă privește și ce faceți dacă da.

Am adunat aici ce spune documentația Google și ce am văzut în jurnalele serverelor clienților, unde Googlebot este, de obicei, cel mai activ vizitator.

Ce înseamnă crawl budget și cum îl optimizați

Definiția, în termenii Google

Bugetul de accesare este numărul de adrese pe care Googlebot le accesează pe un site într-un interval, rezultat din două componente:

• Limita de accesare (crawl capacity limit): cât de repede poate cere Googlebot pagini fără să încarce serverul. Crește când serverul răspunde rapid și fără erori, scade la răspunsuri lente, la erori 5xx și la expirări.
• Cererea de accesare (crawl demand): cât de mult vrea Google să acceseze site-ul, în funcție de popularitatea adreselor, de cât de des se schimbă și de cât de „învechit” consideră Google indexul lui pentru site.

Bugetul este rezultatul celor două: chiar dacă serverul ar suporta 10.000 de accesări pe zi, Google nu le face dacă nu are motiv; și invers, oricât interes ar avea, nu depășește ce suportă serverul. De aceea, optimizarea are două direcții: să nu irosiți accesările pe pagini fără valoare și să nu le limitați printr-un server lent.

Cine are o problemă de buget

Semnele, conform Google, sunt: site cu peste un milion de pagini care se schimbă des, site cu peste 10.000 de pagini care se schimbă zilnic, sau un număr mare de adrese în raportul Page indexing cu starea Discovered, currently not indexed. Din practică adăugăm: magazine online cu filtre și sortări în adresă, site-uri cu paginare adâncă, site-uri cu calendar sau cu căutare internă indexabilă, și site-uri care au trecut printr-o migrare cu multe redirecționări.

Un site de prezentare cu 200 de pagini nu are ce optimiza aici; dacă paginile lui nu sunt indexate, cauza este valoarea lor sau semnalele tehnice, descrise în ghidul despre erorile de indexare frecvente.

Cum măsurați

Raportul de statistici de accesare din Search Console

Se găsește în Settings, Crawl stats, și arată ultimele 90 de zile: numărul de cereri pe zi, dimensiunea descărcată, timpul mediu de răspuns și starea gazdei. Sub grafice sunt defalcările care contează:

1. By response: procentul de 200, 301, 404, 5xx. Peste 10-15% redirecționări sau 404 înseamnă accesări irosite.
2. By purpose: Discovery (adrese noi) față de Refresh (adrese cunoscute). Un site sănătos are majoritatea în Refresh; mult Discovery pe un site care nu publică mult înseamnă că Google găsește mereu adrese noi, de obicei parametri.
3. By Googlebot type: Smartphone față de Desktop, imagini, video, Ads. Robotul principal este cel Smartphone, din cauza indexării mobile-first, explicată în articolul despre indexarea mobile-first.
4. By file type: HTML față de imagini, CSS, JavaScript. Resursele contează și ele; un site care încarcă 80 de fișiere pe pagină cheltuie buget pe ele.

Host status semnalizează problemele de disponibilitate: erori de robots.txt, DNS sau conectivitate în ultimele 90 de zile. Orice roșu aici reduce limita de accesare.

Jurnalele serverului

Raportul din Search Console este agregat. Jurnalul de acces al serverului arată fiecare cerere a Googlebot, cu adresa și codul de răspuns, și este singura sursă care spune exact ce pagini accesează Google și ce ignoră. Filtrați după user agent și verificați adresele IP prin interogare inversă DNS, fiindcă mulți roboți se dau drept Googlebot; procedura este în ghidul despre jurnalele de acces din cPanel.

grep "Googlebot" access.log | awk '{print $7}' | sed 's/?.*//' | sort | uniq -c | sort -rn | head -30   # cele mai accesate adrese, fără parametri
grep "Googlebot" access.log | grep -c "?"                                                              # câte cereri au parametri
grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c                                        # codurile de răspuns

Pe un magazin analizat anul acesta, 71% dintre cererile Googlebot dintr-o lună mergeau spre adrese cu parametri de sortare și filtrare, iar paginile de produs erau accesate o dată la trei săptămâni. Nicio optimizare de conținut nu ar fi ajutat produsele înainte de rezolvarea acestei risipe.

Ce irosește bugetul

• Parametri în adresă: sortări, filtre, id-uri de sesiune, etichete de campanie. Fiecare combinație este o adresă nouă pentru Google.
• Paginare fără limită și pagini de arhivă pe zile, luni, etichete, autori.
• Conținut duplicat sub mai multe adrese: cu și fără slash final, http și https, www și fără www, majuscule în adresă; consolidarea este descrisă în ghidul despre conținutul duplicat.
• Pagini soft 404: pagini care răspund 200, dar sunt goale („niciun rezultat”, „produs indisponibil”).
• Lanțuri de redirecționări și adrese vechi încă legate din site.
• Căutarea internă indexabilă: fiecare căutare a unui vizitator creează o adresă pe care Google o poate găsi.
• Pagini de calendar, de comparare, de coș, de tipărire.
• Resurse blocate sau lente: CSS și JavaScript pe care Google le cere pentru randare, servite încet sau de pe domenii lente.

Cum îl optimizați, în ordinea efectului

1. Reduceți adresele fără valoare

Pentru fiecare tip de adresă din lista de mai sus, alegeți unealta potrivită. robots.txt oprește accesarea (Disallow: /*?sortare=), potrivit pentru parametri și căutare internă, dar nu scoate din index ce era deja indexat. noindex lasă accesarea, dar scoate din index, potrivit pentru pagini care trebuie să existe pentru vizitatori (filtre utile, paginare). rel=canonical spre versiunea principală consolidează duplicatele. Ștergerea cu 404 sau 410 este corectă pentru ce nu mai are rost să existe. Google spune explicit că noindex nu economisește buget (pagina tot trebuie accesată ca să fie citit), deci pentru volum mare, robots.txt este unealta.

2. Reparați răspunsurile

Fiecare 301 din site costă două accesări în loc de una; fiecare 404 legat intern, una degeaba. Rescrieți legăturile interne direct spre destinația finală și actualizați harta site-ului să conțină doar adrese cu răspuns 200; ce trebuie să fie în ea este în ghidul despre trimiterea hărții XML. Erorile 5xx și expirările reduc direct limita de accesare: dacă Crawl stats arată 5xx, rezolvați întâi serverul, așa cum descriem în articolul despre monitorizarea resurselor.

3. Faceți serverul mai rapid

Timpul mediu de răspuns din Crawl stats este cel pe care îl vede Googlebot, nu cel din browser. Sub 300 ms este bine; peste 1 secundă, Google reduce ritmul. Cache-ul de pagină pentru vizitatori anonimi, un server cu resurse suficiente și imaginile în format modern sunt măsurile cu efect direct; măsurarea și remediile sunt în ghidul despre optimizarea Core Web Vitals.

4. Ajutați descoperirea paginilor importante

Google accesează mai des ce este legat mai des. Paginile de produs sau de serviciu care contează trebuie să fie la cel mult trei clicuri de prima pagină, legate din categorii și din articole; paginile-orfane, aflate doar în hartă, sunt accesate rar. Datele lastmod corecte din hartă spun ce s-a schimbat, ca Google să nu recitească paginile neschimbate.

5. Nu limitați artificial

Search Console nu mai are setarea de limitare a ritmului de accesare din 2024; Google ajustează singur. Dacă serverul suferă din cauza Googlebot, este semn că serverul are o problemă, nu robotul. Blocarea Googlebot din firewall sau dintr-un serviciu de protecție, din greșeală, apare în Host status și oprește indexarea complet; verificați că adresele Google nu sunt în lista de blocare.

Un plan pentru un magazin online

1. Inventarul adreselor din jurnal: pe tipuri (produse, categorii, filtre, sortări, paginare, căutare, altele), cu procentul de accesări al fiecăruia.
2. robots.txt pentru parametrii de sortare și pentru căutarea internă; noindex pentru combinațiile de filtre fără cerere de căutare; canonical de la variante spre produsul principal.
3. Repararea legăturilor interne care trec prin redirecționări (de obicei sute, după o migrare).
4. Harta site-ului regenerată doar cu produse și categorii active, cu lastmod real.
5. Cache pentru paginile de categorie și de produs, măsurat în Crawl stats după două săptămâni.
6. Comparație la 30 de zile: procentul de accesări pe produse trebuie să crească, iar Discovered, currently not indexed să scadă.

Pe magazinul amintit mai sus, după acești pași, accesările pe pagini de produs au crescut de la 12% la 58% din total în șase săptămâni, cu același număr total de cereri pe zi. Bugetul nu a crescut; s-a mutat unde trebuia. Restul verificărilor tehnice de care depinde acest rezultat sunt în ghidul despre auditul SEO tehnic și erorile de accesare, iar pentru magazine, în cel despre optimizarea SEO a unui magazin online. Dacă preferați ca analiza să fie făcută pentru dumneavoastră, auditul SEO include exact această inventariere a accesărilor.

Surse

• Google, gestionarea bugetului de accesare: definițiile, cine este vizat și recomandările oficiale.
• Google, prezentarea roboților Google: tipurile de roboți, user agent-urile și verificarea adreselor IP.