crawl budget crawl budget

Optimizarea bugetului de crawl

Managementul crawl-ului este parte integrantă a optimizării pentru motoarele de căutare. Și totuși, gestionarea crawl-ului este atât de prost explicată de comunitatea SEO, încât multe site-uri gestionează greșit crawl-ul. Ceea ce ar trebui să fie unul dintre domeniile fundamentale ale optimizării pentru motoarele de căutare a fost întunecat de absurdități și așteptări false.

Nu există un astfel de lucru ca „crawl budget”, cel puțin nu în ceea ce privește motoarele de căutare. Puteți grupa mai multe concepte diferite sub eticheta colectivă de „buget de accesare”, dar acestea rămân concepte separate. „Crawl budget” este una dintre acele expresii care a ajuns în sălbăticie și a devenit preferata comunității SEO și a prezentatorilor de conferințe care nu au absolut nicio idee despre ce vorbesc. Este o expresie pe care inginerii de căutare o înțeleg mai bine decât cei care au făcut-o o marcă înregistrată pentru marketingul digital. Nu puteți gestiona bugetul de crawl. Dacă ar exista un buget de accesare, acesta ar fi gestionat de motorul de căutare. Aveți mai multe șanse să dovediți că Bigfoot există decât să dovediți că puteți gestiona bugetul crawl.

Ceea ce puteți face, în calitate de SEO sau de operator al unui site, este să gestionați crawl-ul. Gestionarea crawl-ului de pe site-ul este foarte diferită de gestionarea crawl-ului de pe motorul de căutare. Nu puteți forța un motor de căutare să extragă un anumit URL, cu atât mai puțin să îl programeze. Puteți face doar o sugestie. Pe de altă parte, puteți solicita ca motorul de căutare să nu cerceteze un URL. Destul de ciudat, chiar și Google ignoră uneori „robots.txt”. De asemenea, puteți împiedica un motor de căutare să vă cerceteze site-ul sau anumite URL-uri. Aceasta este gestionarea căutărilor, dar nu gestionați „bugetul căutărilor”.

Ce ne spun motoarele de căutare despre crawl

În postarea de pe blog din ianuarie 2017, Gary Illyes a prezentat cititorilor câteva expresii pe care Google le utilizează intern:

Crawl rate limit este „rata maximă de căutare pentru un anumit site”.

Cererea de accesare este determinată de „indexare” (pe care Gary o utilizează pentru a descrie în mod indirect sistemele sau procesele responsabile de crearea indexurilor utilizate de algoritmii de căutare Google).

Nu stabiliți limita ratei pentru site-ul vostru. Google calculează acest lucru pentru a estima momentul în care crawlingul său poate crea o experiență negativă pentru alți vizitatori ai site-ului respectiv. Cum ar putea face acest lucru? Cel mai simplu mod ar fi să urmărească timpii de răspuns la solicitările Googlebot. Dacă păstrează un istoric al activității de urmărire a site-ului, ar putea, ipotetic, să calculeze un timp mediu de răspuns, o abatere standard și alți parametri care ar putea fi utilizați pentru a-și ajusta rata de urmărire. Sau ar putea face alte lucruri. Tot ce putem face este să speculăm (ei bine, am putea să-i întrebăm ce măsurători calculează și folosesc, dar uneori nu vor să ne spună aceste lucruri).

Nici tu nu stabilești cererea pentru site-ul tău. Puteți solicita unele căutări prin intermediul Google Search Console, dar cerințele privind cererea din partea sistemelor de indexare sunt în afara controlului sau influenței tale directe.

Prin urmare, dacă nu puteți gestiona sau stabili limita ratei de crawl sau cererea de crawl pentru un site, nu puteți gestiona ceea ce credeți că este „bugetul de crawl” pentru un inginer de căutare.

„PageRank drives crawl”, potrivit lui Matt Cutts, fost angajat la Google, la o conferință desfășurată cu mult timp în urmă într-o galaxie foarte îndepărtată. Deoarece Google încă utilizează PageRank, este probabil un pariu sigur că sistemele lor de crawling îl iau în considerare într-unul sau mai multe moduri.

„Conform analizei noastre, existența multor URL-uri cu valoare adăugată scăzută poate afecta negativ crawling-ul și indexarea unui site”, a scris Gary în postarea de blog menționată mai sus. Cred că acesta este un mod interesant de a spune lucrurile. El pare să sugereze că Google nu degradează în mod arbitrar indexarea unui site. Mai degrabă, site-urile își degradează neintenționat propriul crawl. El a oferit câteva exemple de „URL-uri cu valoare adăugată scăzută”:

  • Navigare cu fațete
  • Identificatori de sesiune
  • Conținut duplicat pe site
  • Pagini cu erori ușoare
  • Pagini piratate
  • Spații infinite (cum ar fi calendarele)
  • Proxies
  • Conținut de calitate scăzută sau spam

Sunt o mulțime de lucruri de care trebuie să ții cont. Fiecare specialist SEO învață rapid să caute aceste tipuri de probleme. Dar „remedierea” acestor probleme nu garantează că relația de crawl a motorului de căutare cu site-ul se va îmbunătăți. Dacă acest lucru se întâmplă depinde de diverse lucruri. De exemplu, doar pentru că-i spuneți lui Google să filtreze anumiți parametri URL în Search Console nu înseamnă că nu va găsi mai multe URL-uri cu acei parametri. Ce se întâmplă în interiorul algoritmilor de urmărire și indexare cu toate aceste „linkuri găsite”? Singurul răspuns corect din partea oricărei persoane din afara Google este că nu știți. Nu este nevoie să ghiciți sau să argumentați că presupunerea voastră este probabil corectă. Nu știți ce se întâmplă cu URL-urile nou găsite care conțin componente de navigare cu fațete.

Site-urile rapide vor fi vizitate mai frecvent deoarece pot tolera o cercetare mai frecventă fără a afecta experiența utilizatorului. Gary a spus acest lucru și, prin urmare, doar cei mai paranoici dintre SEO-iști vor respinge această afirmație de fapt.

Nu există niciun factor de clasificare sau semnal bazat pe crawl. Viteza și frecvența cu care un motor de căutare accesează site-ul tău pot avea un efect indirect asupra performanței tale în SERP atunci când îți schimbi paginile.

În general, orice URL pe care Googlebot îl parcurge va conta în bugetul de parcurgere al unui site. Consolidarea conținutului duplicat prin canonical nu va reduce cantitatea de crawl pe care un motor de căutare o direcționează către site-ul tău. De fapt, am găsit odată Google raportând erori de căutare pentru URL-uri inexistente pe care le-ar fi putut obține doar din declarații „rel=’canonical'” configurate greșit. În orice caz, canonical-ul poate determina motorul de căutare să aloce o parte din „bugetul tău de urmărire” pentru a obține URL-uri despre care nu știa anterior.

Google nu onorează solicitările „crawl-delay” din „robots.txt” și nu garantează că nu va cerceta un URL pe care l-ați etichetat ca „nofollow” într-unul dintre linkurile dvs.

Noțiuni de bază pentru oricine este nou în SEO

Pentru un motor de căutare, site-ul nu are o ușă „din față” sau „din spate”. Nu există „primul” sau „ultimul” URL al unui site.

  • Un motor de căutare poate începe explorarea site-ului tău de la orice URL aleatoriu.
  • Un motor de căutare va prelua o adresă URL de câte ori poate și de câte ori dorește.
  • Un motor de căutare poate alege să nu extragă un URL, indiferent cât de mult doriți să extragă acel URL.
  • Un motor de căutare poate prelua un URL de la mai mult de o adresă IP.
  • Doar pentru că vedeți un user-agent al unui motor de căutare în jurnalul serverului, nu înseamnă că preluarea a venit de la un motor de căutare.
  • Nu puteți garanta că veți găsi toate URL-urile de pe un site prin explorarea acestuia.
  • Nu puteți reproduce cunoștințele unui motor de căutare despre site-ul vostru.
  • Motoarele de căutare cercetează URL-urile de ani de zile, indiferent dacă URL-urile mai există sau au existat vreodată.
  • Motoarele de căutare pot ignora și ignoră „robots.txt” chiar și atunci când spun că îl respectă.

De două ori până acum în acest articol am spus că motoarele de căutare pot și ignoră „robots.txt”. Ce înseamnă asta? Înseamnă că am văzut cum Bing și Google solicită pagini pe care nu ar trebui să le vadă. Fișierele „robots.txt” nu sunt eronate. Cred că este corect să spunem că aceste căutări au loc în circumstanțe speciale, dar nu am văzut niciodată o listă completă a acestor circumstanțe speciale.

Ceea ce mi se pare deosebit de amuzant este faptul că Google reușește cumva să extragă conținut de pe o pagină care servește un cod de stare 403 pe care browserul meu nu poate sau nu vrea să o facă. Există un defect în software-ul serverului Apache sau Google știe ceva ce noi nu știm? Bing se strecoară prin crăpături chiar mai mult decât Google. Urmărirea lor neîngrădită duce la probleme în analiza performanțelor site-urilor, deoarece acestea apar ca „ghost hits” la pagini și scripturi. Acest lucru este foarte enervant.

  • Motoarele de căutare care caută și onorează „robots.txt” au întotdeauna un „robots.txt” la care să se refere.
  • Este mai bine să blocați un crawler prin intermediul unui firewall al serverului (de exemplu, „iptables”) decât prin orice altă metodă.
  • Nu puteți sculpta PageRank-ul, dar îl puteți irosi.
  • Modul corect de a gestiona fluxul de valoare de tip PageRank prin intermediul unui site este plasarea pozitivă a legăturilor.
  • Navigarea ierarhică a site-ului funcționează mai bine decât navigarea plată a site-ului.
  • Fiecare pagină de pe un site cu mai mult de 3 pagini ar trebui să aibă linkuri de la cel puțin alte 3 pagini de pe site.
  • Linkurile sunt mai întâi pentru oameni, apoi pentru motoarele de căutare.
  • Motorul de căutare decide care linkuri contează, nu experimentele tale SEO.
  • Motorul de căutare decide dacă textul de ancorare al unui link ajută la clasare.

Dacă aveți de gând să gestionați crawl-ul, trebuie să stabiliți așteptări adecvate. Dacă încercați să faceți munca motorului de căutare mai ușoară, atunci aveți așteptările corecte. Dacă încercați să vă îmbunătățiți clasamentul, atunci aveți așteptări greșite. Implementarea celui mai bun management al crawl-ului posibil pentru un site nu vă garantează nimic în ceea ce privește indexarea și clasarea oricărei părți a site-ului în orice motor de căutare. Crawl-ul nu este bagheta magică pe care o căutați.

Cum poate un motor de căutare să aibă întotdeauna un „robots.txt” la care să facă referire? Dacă un motor de căutare nu găsește un fișier „robots.txt”, acesta presupune că un astfel de fișier, dacă ar exista, ar permite motorului de căutare să cerceteze fiecare URL de pe site. Prin urmare, motorul de căutare are întotdeauna un fișier „robots.txt” la care să se refere.

De ce este firewall-ul iptables mai bun pentru blocarea unui crawler? Există două motive. În primul rând, dacă nu doriți crawlerul pe site-ul dvs. atunci nu trebuie să irosiți resurse pentru el. În al doilea rând, unele crawlere ignoră „robots.txt” (intenționat sau involuntar). Crawlerele vă pot ataca site-ul înainte să expire imaginile din cache ale fișierului dvs. „robots.txt”. În caz de urgență, atunci când crawlerul vă lovește prea tare serverul, ar trebui să-l blocați prin iptables. Așteptați 1-2 zile și apoi lăsați crawlerul să intre din nou. Acesta va prelua fișierul „robots.txt” și va începe să evalueze din nou prioritățile de crawl ale site-ului vostru.

Acesta este un răspuns radical la un crawler excesiv de agresiv. Nu este un răspuns de primă alegere, dar dacă nu puteți face un crawler să se comporte bine în 30 de minute, blocați-l. Rezultatele căutării nu vor avea de suferit doar pentru că motorul de căutare primește erori de timeout timp de câteva ore.

Cum se irosește valoarea asemănătoare PageRank? Orice strategie SEO menită să manipuleze fluxul de valoare PageRank-like prin intermediul unui site funcționează orbește, fără să cunoască absolut deloc modul în care motoarele de căutare calculează aceste valori. Nu contează dacă adăugați mai multe linkuri de navigare pe o pagină sau dacă le eliminați. Nu veți găsi niciodată zona de aur în fluxul PageRank. Nu ar trebui să o căutați.

Valoarea PageRank curge către URL-ul unui document din legăturile care indică către acesta. Dacă ați câștigat sau ați construit linkuri pentru postările individuale de pe blog sau pentru paginile de produse, atunci toate aceste pagini pot canaliza o valoare asemănătoare PageRank către restul site-ului vostru.

Așa că acum uitați-vă la toate modelele pe care experții SEO vi le-au arătat despre valoarea PageRank care curge din URL-ul rădăcină al unui site … și râdeți. Nu știți de unde provine valoarea de tip PageRank sau încotro se îndreaptă.

Ce trebuie să faceți pentru a gestiona crawl-ul pe un site

Nu rulați niciodată un crawler SEO pe un sitecu speranța că vă va spune ceva util despre ceea ce găsesc motoarele de căutare. Trebuie să înțelegeți cu adevărat faptul că motoarele de căutare nu cercetează site-ul dvs. de sus în jos (pentru că nu există „de sus în jos”) și că pot pune în așteptare orice adresă URL a site-ului dvs. pentru a fi cercetată din cauza legăturilor externe care direcționează către aceasta. Căutările SEO irosesc resursele serverului, ceea ce creează o experiență proastă pentru utilizator. Mai rău, acestea ratează o mulțime de lucruri pe care ar trebui să le căutați. Prin urmare, crawlerele SEO vă irosesc timpul.

Iată cum ar trebui să colectați date despre crawl-ul unui site:

  • Obțineți erorile 404 din jurnalele serverului.
  • Obțineți celelalte 40x erori din jurnalele serverului.
  • Obțineți cele 30x redirecționări din jurnalele serverului.
  • Consultați baza de date pentru redirecționări.
  • Consultați fișierele .htaccess sau fișierele echivalente pentru redirecționări.
  • Obțineți lista URL-urilor publicate din baza de date (dacă există una).
  • Parcurgeți arborele de directoare din partea serverului pentru a obține lista de URL-uri publicate.
  • Comparați listele de URL-uri publicate cu fișierele sitemap.
  • Obțineți o listă de fișiere sitemap din fișierul „robots.txt”.
  • Obțineți o listă a fișierelor sitemap trimise către motoarele de căutare.

Secțiuni întregi ale unui site ar putea fi orfane de la URL-ul rădăcină al unui site și totuși explorate frecvent și complet indexate de motoarele de căutare deoarece acestea au găsit link-uri pe alte site-uri sau URL-urile sunt listate în fișiere sitemap.

Dacă folosiți crawlere SEO pe site-uri, o faceți greșit. La fel de bine ați putea cere cuiva să vă spună toate lucrurile pe care nu le știe. Site-ul în sine este singura sursă autorizată de informații despre ceea ce este publicat, blocat și/sau redirecționat. Orice altceva vă oferă doar o imagine parțială, cu excepția cazului în care cercetați un site perfect. Și dacă ai găsit un site perfect, să-mi dai de veste.

Navigarea pe site ar trebui să fie doar utilă

„Util” este foarte, foarte greu de definit. Trebuie să vă uitați la ceea ce utilizatorii folosesc de fapt pe un site pentru a determina cât de util este un lucru. Dar ar trebui să vă uitați la datele de o zi, de o săptămână, de o lună sau de un trimestru? Unele URL-uri sunt necesare doar pentru perioade scurte, o dată pe an. Unele URL-uri sunt necesare o singură dată. Prin urmare, cât de utilă este o legătură de navigare depinde de cine ar putea să o folosească, când și de ce.

Chiar și așa, trebuie să descoperiți cele mai utile linkuri de navigare și să vă asigurați că acestea sunt vizibile și ușor de găsit. Accesibilitatea este, de asemenea, un mare avantaj, dar este posibil să vă confruntați cu un designul unui site care are o navigare foarte vizibilă, dar inaccesibilă. Aceasta nu este chiar o problemă de SEO, dar este ceva cu care ar trebui să fiți pregătit să vă confruntați.

Navigarea inutilă ar trebui eliminată. Nimeni nu poate raționaliza vreodată navigarea inutilă decât spunând: „Este acolo pentru a îmbunătăți crawl-ul”. De fapt, aceasta degradează crawl-ul. Mai rău, alți algoritmi POT acorda un scor slab unei pagini pentru că are prea multă dezordine inutilă. Toate elementele de pe pagină contribuie la evaluarea algoritmică a modului în care funcționează pagina, a relevanței acesteia și a modului în care își îndeplinește sarcinile (calitatea paginii).

Navigarea pe site ar trebui să fie întotdeauna consecventă

Unii experți în UX urăsc meniul hamburger de pe site-urile mobile. Eu, personal, îl ador. Indiferent ce părere aveți despre forma, amplasarea și formatul oricărui widget de navigare a site-ului, ar trebui să utilizați întotdeauna aceeași formă, amplasare și format pentru widgeturile de navigare principale. Folosiți exact același aspect și funcționalitate pe fiecare pagină.

Faceți acest lucru pentru utilizatori și pentru optimizarea motoarelor de căutare. Dacă nu puteți găsi cu ușurință navigarea primară pe o pagină, cum veți evalua capacitatea motorului de căutare de a face acest lucru? Trebuie să puteți să vă uitați la o pagină și să înțelegeți intuitiv cum se deplasează utilizatorii în jurul ei și de la o pagină la alta pe site-ul respectiv. Asta doar pentru propria sănătate mintală.

Este în regulă să existe navigare redundantă pe o pagină

Mi-aș dori ca mai multe site-uri să își reproducă meniurile din partea de sus a paginii în partea de jos a articolelor lor. Este pur și simplu mai ușor pentru un utilizator să navigheze către o altă pagină atunci când are opțiunea de a face acest lucru la sfârșitul articolului pe care l-a citit.

Motoarelor de căutare nu le pasă dacă replicați un meniu în partea de sus și de jos a paginii. Și nu-mi spuneți prostii despre „primul link contează (cel mai mult)”. Astea sunt prostii pseudoștiințifice și nu au nimic de-a face cu crearea unei experiențe bune pentru utilizator. Amintiți-vă legea: „Link-urile sunt mai întâi pentru oameni, apoi pentru motoarele de căutare”.

Lăsați motoarele de căutare să decidă dacă acele linkuri din meniul de jos sunt importante pentru algoritmii lor. Acestea nu vă vor penaliza pentru că faceți ceva ușor de utilizat.

Oamenii vor scrie un articol de 2 000 de cuvinte plin de text de umplutură pentru că o vedetă SEO spune că articolele de 2 000 de cuvinte se clasează mai bine, dar nu vor adăuga un meniu în partea de jos a paginilor pentru vizitatorii lor. De ce? Pentru că nimeni nu promite clasări mai bune.

Ca o paranteză: Site-urile WordPress rareori au opțiunea de a-și afișa meniul principal de navigare atât în partea de sus, cât și în partea de jos a paginii. Deși există soluții stângace care vă permit să faceți acest lucru, este o deficiență de bază în designul de bază al WordPress.

Acolo unde este posibil, utilizați navigarea secundară specifică secțiunii.

Pe un site mare, aceasta este o modalitate foarte eficientă de a gestiona nevoile de navigare. Meniul de nivel superior rămâne mic, dar fiecare secțiune din cadrul site-ului are propriul său sub-meniu. Este mai ușor să realizați acest lucru în WordPress decât să afișați meniul principal de navigare în partea de jos a paginii. Instalați un plugin care vă permite să afișați un meniu secundar în bara laterală, filtrând în funcție de categorie. Pluginul Advanced Sidebar Menu este un exemplu pe care îl puteți lua în considerare, dar există și altele. Nu vreau să recomand unul în mod special.

Există mai multe motive pentru a NU utiliza meniuri expansive uriașe ca navigație principală. În primul rând, nimeni nu va face clic pe toate acele linkuri. În al doilea rând, este aproape imposibil să obțineți un stil care să rămână nemișcat în timp ce deplasați cursorul mouse-ului către opțiunea corectă. Aceste meniuri uriașe NU sunt ușor de utilizat. NICIODATĂ. În al treilea rând, cu cât navigarea principală devine mai mare, cu atât structura site-ului devine mai plată, iar arhitectura plată a site-ului degradează capacitatea unui motor de căutare de a identifica cele mai importante pagini ale unui site.

Utilizați cu moderație widgeturile de navigare ascunse

Nu vreau să spun să nu faceți acest lucru. Uneori are sens să ascundeți conținutul în spatele unei file CSS. Și în timp ce Google a avertizat designerii să nu facă acest lucru pe desktop, ei spun că va fi în regulă pentru „Mobile First Index”. Ascunderea conținutului pe pagină prin intermediul stilului controlat de utilizator chiar are sens și pe unele site-uri chiar îmi place acest lucru. Dacă motorul de căutare urmărește legăturile, atunci faceți-o. Dar încercați să găsiți modalități alternative de a adăuga opțiuni de navigare la conținutul dvs. profund.

Includeți pe pagini cuvintele pentru care doriți să vă poziționați

Prea mulți oameni încă mai cred că trebuie să folosească textul de ancorare al linkurilor pentru ca o pagină să se claseze pentru o expresie de căutare dorită. Acest lucru nu a fost niciodată adevărat. Nu trebuie să folosiți textul de ancorare pentru nimic. Textul de ancorare a linkurilor este o opțiune, nu o cerință. Este mai bine dacă includeți expresiile dorite pe pagină. Textul de ancorare a legăturii de intrare poate completa conținutul de pe pagină. Motoarele de căutare doresc cu adevărat să vadă acordul dintre ancorele de link și textul de pe pagină.

Dacă considerați că expresia de căutare nu are ce căuta pe pagină, atunci aceasta nu este pagina potrivită pentru a fi clasată în rezultatele căutării.

Crawl Management începe cu elementele de bază, dar …

O bună gestionare a căutărilor este mult mai complexă decât pot include aici. Prea puțini oameni stăpânesc elementele de bază. În comunitatea de marketing se discută mult prea mult despre optimizarea „avansată” inutilă. Până când oamenii nu înțeleg bine chestiunile de bază, concentrarea asupra tehnicilor mai avansate va duce la rezultate confuze și inconsecvente.

Specialiștii în marketing digital trebuie să înceteze să mai vorbească despre „crawl budget”. Este un subiect care induce în eroare și este un semn roșu împotriva întregii industrii de marketing. Gestionarea crawl-ului este prea importantă pentru a fi lăsată deoparte de prostii precum „cum să gestionăm bugetul crawl-ului”. Mai rău, chestiunile cu adevărat de bază se referă mai mult la acordarea accesului crawlerelor (sau la refuzarea accesului acestora) decât la rezolvarea unor probleme specifice, cum ar fi URL-urile moarte, conținutul duplicat și altele asemenea.

Crawl este parte integrantă a rezolvării unor probleme SEO, dar aceste probleme se află cu adevărat în afara crawl-ului. Oamenii trebuie să înceteze să mai complice discuțiile despre gestionarea crawl-ului cu toate aceste alte probleme. Crawl este un instrument, nu un scop. Este timpul ca toată lumea să renunțe la retorica despre crawl, deoarece conversația îi derutează pe toți, atât pe experții în marketing, cât și pe clienți.

Lasă un răspuns