Technické SEO

10 min čtení

Týká se crawl budget vůbec vašeho webu?

Crawl budget není o tom, kolik URL na webu máte. Je o tom, kam Google při crawlování investuje svůj čas. Googlebot má pro každý web určitou kapacitu procházení a zároveň vyhodnocuje, které URL má smysl navštěvovat a jak často. Problém tedy nezačíná toho, že máte velký web, ale ve chvíli, kdy podstatnou část crawlu spotřebují duplicity, filtry, parametry nebo jiné URL bez reálné hodnoty. Důležité stránky se pak mohou dostat na řadu později, než potřebujete.

Cover ilustrace k článku o crawl budgetu a analýze serverových logů.

Než budete číst dál, udělejte si jeden test. Pokud se vaše stránky obvykle procházejí tentýž den, kdy je publikujete, můžete tady skončit. Je to test, který doporučuje sám Google, a většinu debat o crawl budgetu ukončí dřív, než začnou.

Je crawl budget vůbec váš problém?

Dokumentace Googlu ke crawl budgetu je nezvykle přímočará v tom, pro koho je určená. Jmenuje tři profily webů. Velké weby s více než milionem unikátních stránek, jejichž obsah se mění zhruba týdně. Střední weby s deseti tisíci a více stránkami, které se mění denně. Třetí skupinou jsou weby, u kterých velká část URL zůstává ve stavu „Objeveno, momentálně neindexováno“.

Firemní web s dvěma sty stránkami, jehož nové články se zaindexují během hodin, problém s crawl budgetem nemá, ať už health score v auditním nástroji říká cokoli. Pokud se tam obsah neindexuje, příčinou je téměř vždy kvalita, interní prolinkování nebo duplicita, a „optimalizace crawl budgetu“ je způsob, jak strávit čtvrtletí opravou něčeho, co vás nebolí.

Komplikace je v tom, co se počítá jako počet stránek. Prahové hodnoty se týkají unikátních URL, na které se Google dostane, ne produktů ve vaší databázi. E-shop s 30 000 produkty a neošetřenou filtrovanou navigací může vystavit miliony procházitelných URL. O tom, jestli se vás crawl budget týká, rozhoduje, kolik URL web reálně vystaví, ne kolik má produktů.

V téhle fázi se dělají dvě chyby. Neoptimalizujte crawl budget na webu, kde se nové stránky indexují tentýž den. Vynaložíte úsilí a firma z toho nic nepozná. A stav „Objeveno, momentálně neindexováno“ nevykládejte výhradně jako problém s procházením. Na menších webech je to daleko častěji verdikt o kvalitě nebo interním prolinkování než o kapacitě, přestože Google velký podíl URL v tomto stavu uvádí jako jeden ze tří profilů, pro které je tahle práce určená.

Proč vám samotná Search Console plýtvání neukáže

Nejdřív se dívám do přehledu Statistiky procházení v Search Console. Ukáže celkový počet požadavků, trend doby odezvy a rozdělení podle stavových kódů, typů souborů a typů Googlebota. Řekne vám, že něco není v pořádku, tedy skok v počtu požadavků, rostoucí podíl 404 nebo rostoucí průměrnou dobu odezvy.

Co vám spolehlivě neřekne, je kam procházení odchází na úrovni, na které děláte rozhodnutí, tedy vzor URL po vzoru URL. Report ukazuje příklady, ne celý tok požadavků. U webu dost velkého na to, aby na crawl budgetu záleželo, je jediným úplným záznamem chování Googlebota váš serverový access log. Všechno ostatní je vzorek nebo odhad

Tady se dělá chyba, kterou vidím pořád dokola. Analýza se často dělá nad výstupem vlastního crawleru místo nad logy. Crawl ukazuje, co Googlebot mohl načíst, když prochází vaše odkazy. Logy ukazují, co skutečně načetl, jak často a s jakou odpovědí. Právě v rozdílu mezi oběma seznamy obvykle leží nálezy, na kterých mi záleží, tedy URL, která si Google pořád vyžaduje a která váš vlastní crawl vůbec neobjeví. Typicky jde o zbytky po starých strukturách, feedech a dávno zrušených kampaních.

Jak analýza logů vypadá

Postup, který používám u projektů technického SEO, je stejný, ať už ho děláte v BigQuery, v Pythonu nebo v nástroji na analýzu logů, a má čtyři kroky.

  1. Izolujte ověřený provoz Googlebota. Filtrujte podle user agenta a pak ověřte podle zveřejněných rozsahů IP adres crawlerů Google. Falešného user agent Googlebota může poslat kdokoli a na některých webech tvoří scrapery vydávající se za Googlebota významnou část „botího“ provozu.
  2. Zařaďte každý požadavek do příslušné skupiny URL. Produkty, kategorie, filtrační parametry, interní vyhledávání, stránkování, statické soubory, feedy, všechno ostatní. V téhle klasifikaci je jádro celé analýzy, protože log se sloupcem vzoru odpoví na otázky, na které surový log odpovědět nedokáže.
  3. Agregujte podle vzoru. Počet požadavků, podíl na celku, skladba stavových kódů a vývoj v čase. Z věty „Googlebot minulý měsíc udělal 400 000 požadavků“ se stane věta typu „38 % stažení šlo na parametry řazení, které jsou stejně kanonizované“.
  4. Spojte to s daty o hodnotě. Spárujte vzory se zobrazeními ze Search Console a tam, kde je máte, s tržbami na vstupní stránku. Výsledkem jsou dva sloupce vedle sebe, tedy na co Google utrácí procházení proti tomu, co něco vydělává.

Z mé vlastní praxe. Tohle spojení dělám v BigQuery, logy na jedné straně, hromadný export Search Console do BigQuery na druhé, obojí spojené přes vzor URL. Důvodem není sofistikovanost, ale opakovatelnost. Jednorázová analýza logů vám řekne, kde bylo plýtvání minulý měsíc. Stejný dotaz spouštěný každý měsíc vám řekne, jestli opravy skutečně změnily chování Googlebota při procházení, a to je otázka, za kterou klient platí.

Serverové logy Googlebotu rozdělené podle vzorů URL a jejich hodnoty pro crawl budget.

Kde se plýtvá nejčastěji

Data ze serverových logů na úrovni vzorů obvykle vynesou na povrch stejné kategorie plýtvání. Řadím je zhruba podle toho, jak často se objevují.

  • Filtrační a parametrické URL. Řazení, přepínače zobrazení, session a trackovací parametry a kombinace filtrů, které nikdo nehledá. Na e-shopech to bývá největší položka.
  • Výsledky interního vyhledávání. Procházitelné ?q= URL, které někdy vznikají ze spamových dotazů odkazovaných zvenčí webu.
  • Řetězce a smyčky přesměrování. Každý skok je samostatný požadavek, takže řetězec, který projde třemi URL, než dorazí na finální, stojí čtyři stažení místo jednoho. Googlebot zvládne řetězec až deseti skoků, takže dlouhé řetězce se obvykle dojdou až na konec. Jen vás to pokaždé něco stojí. Google sám doporučuje přesměrovávat rovnou na finální cíl, a pokud to nejde, držet řetězec ideálně do tří skoků a rozhodně pod pěti. Nejvíc řetězců vzniká po migracích, kdy se nová mapa přesměrování naskládá na tu předchozí, a nejlevněji se najdou při kontrole přesměrování hned po spuštění.
  • Soft 404. Stránky, které vracejí 200 a přitom uživateli sdělují, že nic nebylo nalezeno. Google výslovně říká, že se dál procházejí a crawl budgetem skutečně plýtvají. Všimněte si rozdílu oproti skutečným 404, protože ve svém přehledu mýtů a faktů o procházení Google uvádí, že stránky vracející kódy 4xx (kromě 429) neplýtvají crawl budgetem, protože crawler dostal stavový kód a žádný obsah. Pokud vaše analýza logů počítá běžné 404 jako plýtvání, počítá špatnou věc.
  • Duplicity hostitele a protokolu. HTTP vedle HTTPS, www vedle verze bez www, varianty s lomítkem a bez lomítka na konci, staging subdomény, které nikdo nikdy nezavřel.
  • Pasti kalendářů a stránkování. Šablony, které donekonečna generují odkaz „další“ a posílají crawler do nekonečna.
Googlebot má procházet stránky, které přinášejí hodnotu, ne parametry bez užitku.

Jak to opravit, každý vzor má své řešení

Řešení nejsou nic převratného. Disciplína spočívá v tom, že na každý vzor nasadíte jedno řešení a víte, co který nástroj skutečně dělá. Robots.txt zabrání stažení, což z něj dělá správný nástroj na čisté plýtvání, jako je interní vyhledávání nebo nekonečné kalendáře, ale neodstraní už zaindexovaná URL a na stránce zablokované v robots.txt Googlebot pravidlo noindex neuvidí.

Noindex stránky z indexu odstraní, ale spotřebuje na to procházení. Kanonické značky sloučí téměř duplicity. A to, co na webech, na kterých jsem pracoval, zabralo nejvíc, je přestat generovat interní odkazy na URL, která jste nikdy nechtěli mít procházená. Vzor, na který nic neodkazuje, přestane být problémem sám od sebe.

V této fázi hrozí dvě pasti. Neblokujte vzory v robots.txt jako první krok u URL, která už jsou zaindexovaná. Googlebot na nich noindex neuvidí a URL mohou v indexu zůstat. A od komprese sitemap nečekejte výraznou úsporu procházení, protože zabalené sitemapy se stejně musí ze serveru stáhnout.

Jedno omezení stojí za to znát. Limit kapacity procházení se u Google počítá na hostitele a je sdílený mezi všemi jeho crawlery. Pokud web na sdílený limit kapacity naráží, může vysoká poptávka jednoho z nich, třeba AdsBota na dynamických cílech reklam nebo Google Shopping na merchant feedech, kapacitu pro Googlebota snížit. Každý web navíc začíná na stejné konzervativní výchozí hodnotě a větší kapacitu dostane jen tehdy, když zátěž zvládá bez chyb a zpomalení.

Kdo chce jít hlouběji, Google k procházení vydal celou sérii Crawling December. Je to nejucelenější oficiální materiál k tématu a stojí za přečtení celý, ne jen po částech.

Čeho se vyvarovat

  • Neřešte crawl budget na malém webu. Web s pár stovkami stránek dostane od nástroje „crawl budget issue“ a tým tři měsíce ladí robots.txt. Nové články se přitom indexují do hodin. Nejdřív test „indexuje se to tentýž den?“.
  • Neanalyzujte logy bez ověření Googlebota. Analýza logů běží nad všemi požadavky s user agentem Googlebot a půlka je scraper. Bez ověření IP rozsahů se řeší cizí provoz.
  • Nepřesměrovávejte 404 na kategorii. Report počítá běžné 404 jako plýtvání a tým „opravuje“ tisíce 404 přesměrováním na kategorii. Vznikne soft 404 a plýtvá se víc. 404 nechat být, řešit soft 404.
  • Neblokujte v robots.txt to, co má nejdřív vypadnout z indexu. Zaindexované filtry se zablokují v robots.txt, „aby se ušetřil crawl“, a mohou v indexu zůstat, protože Google noindex neuvidí. Pořadí je noindex, počkat, blokovat.

Otázky, které dostávám před auditem

Bude Google procházet mé dobré stránky víc, když omezím plýtvání?

Samo o sobě ne. Google to říká přímo. Google nově uvolněný crawl budget nepřesune na jiné stránky, pokud už nenaráží na limit kapacity procházení vašeho webu. Poptávka po procházení je stejně důležitá jako kapacita. I když limit kapacity vyčerpaný není, nízká poptávka znamená, že Google váš web prochází méně.

Zlepší lepší procházení pozice?

Ne a Google to uvádí mezi mýty o procházení. Procházení je nutné k tomu, aby stránka byla ve výsledcích vyhledávání, ale není to signál pro řazení. Tahle práce mění to, jak rychle se objeví nové a aktualizované stránky, a právě v tom leží byznysová hodnota u velkých, rychle se měnících katalogů. Pokud vám někdo prodává optimalizaci crawl budgetu jako páku na pozice, je to varovný signál.

Sdílejí mé subdomény jeden crawl budget?

Ne. Google zde chápe web jako unikátní název hostitele, takže příklad: www.example.com a shop.example.com mají samostatný crawl budget. Proto musí odpověď vycházet z dat, ne z celkového skóre, které nástroj přiřadí celému webu.

Tři čísla, která ukážou, že to fungovalo

  1. Podíl procházení podle jednotlivých vzorů URL, měsíc po měsíci. Skupiny, kde se plýtvá, by se měly zmenšovat, produkty a kategorie by měly růst jako podíl na celkovém počtu stažení.
  2. Čas od publikace k prvnímu průchodu Googlebota u nových produktů a článků, tedy metrika, kterou pochopí i vedení bez vysvětlování.
  3. Skladba stavových kódů u provozu Googlebota. Podíl kódů 200 na indexovatelných URL by měl růst, měl by klesat počet zbytečných 404 a počet přesměrování v řetězcích s tím, jak se zkracují řetězce přesměrování.

Pokud se tyhle tři metriky hýbou správným směrem, práce s procházením je hotová a debata se může vrátit tam, kam patří, tedy k obsahu a odkazům.

A pokud jste po prvním testu zjistili, že se vás crawl budget netýká, je to nejlevnější zjištění v celém tomhle článku. Ušetřilo vám to mnoho práce na problému, který nemáte.