Nové články čekají na načtení a první vysvětlení zní: došel crawl budget. U menšího magazínu to ale nemusí být správná diagnóza. Nejdřív zjistěte, zda robot stránky opravdu nestahuje, nebo je stáhl a nezařadil do indexu. Serverové logy mohou ukázat skutečné požadavky a chyby; samy neprozradí rozhodnutí o indexaci. Provozovatel více webů potřebuje oba pohledy spojit, aniž by z neúplných čísel dělal jistý závěr.
Kdy má smysl crawl budget vůbec řešit
Crawl budget popisuje, které URL Google může a chce procházet. Kapacita souvisí mimo jiné se schopností serveru odpovídat; poptávka po procházení se odvíjí také od obsahu a jeho změn. Vyšší výkon hostingu proto automaticky nezajistí více návštěv robota. Pokud není poptávka nebo problém leží v kvalitě a duplicitách, samotný dražší tarif příčinu neodstraní.
Oficiální průvodce Google je určen hlavně velmi velkým nebo rychle se měnícím webům a případům s významným podílem objevených, dosud neprocházených URL. U běžného menšího magazínu bývá vhodnějším začátkem dostupnost, správný inventář, sitemap a přehled indexace. Součet článků čtyřiceti domén není jeden společný crawl budget. Google v tomto kontextu pracuje se samostatnými hostiteli.
| Situace | První směr kontroly | Co zatím nepředpokládat |
|---|---|---|
| Malý web, několik chybějících článků | Konkrétní URL a její indexační stav | Automaticky vyčerpaný rozpočet |
| Robot nestíhá velký měnící se inventář | Logy, dostupnost a rozsah URL | Že všechny známé adresy mají stejnou hodnotu |
| Články byly procházeny, ale nejsou indexované | Obsah, duplicity a pokyny | Že další stažení samo zajistí indexaci |
| Více webů má současně 5xx | Sdílený hosting a provozní špička | Nezávislou obsahovou chybu každé domény |
| Vznikají tisíce parametrických variant | Generování a smysl inventáře | Nutnost přidat všechny varianty do sitemapy |
Co serverový log ukáže a co v něm chybí
Přístupový log může obsahovat čas, požadovanou cestu, metodu, stav odpovědi, přenesená data, User-Agent a adresu klienta. Některá prostředí přidávají délku zpracování. Rozsah závisí na hostingu a nastavení. Záznam požadavku je důkaz, že daná vrstva požadavek zaznamenala; není důkaz, že čtenář přečetl článek nebo že jej Google zaindexoval.
Rozlišujte log originálního serveru, CDN a ochranné vrstvy. Pokud CDN odpoví ze své cache, požadavek se nemusí objevit na originu. Pokud ochrana klienta odmítne dříve, u WordPressu nemusí být žádný záznam. Absence v jednom logu neprokazuje absenci návštěvy. Nejdřív si nechte od poskytovatele vysvětlit, kterou část cesty soubor pokrývá.
- Ověřte časové pásmo a období, za které máte úplná data.
- Zjistěte, zda se logy vzorkují a jak rychle se přepisují nebo rotují.
- Oddělte HTML články, obrázky, skripty a ostatní soubory.
- Rozlišujte unikátní URL a počet opakovaných požadavků.
- Uchovávejte jen potřebná data a nesdílejte přístupové tokeny či citlivé parametry URL.
Googlebot v názvu klienta není ověření totožnosti
User-Agent lze snadno napodobit. Při důležitém rozhodnutí o přístupu nebo zátěži proto ověřujte původ podle aktuální dokumentace Google. Ta nabízí práci s publikovanými rozsahy IP a také kontrolu reverzního a následného dopředného DNS. Samotný název obsahující „google“ nestačí; výsledek musí odpovídat správné skupině požadavků a vracet se ke stejné adrese.
Odlište běžné automatické procházení od dalších nástrojů a uživatelsky vyvolaných kontrol. Všechny požadavky patřící Googlu nemusí mít shodný účel ani pravidla. Nepovolujte neomezený přístup každému, kdo si nastaví známý řetězec. Pokud nemáte potřebná data, označte skupinu jako neověřenou a nepředstírejte přesný počet skutečných návštěv Googlebota.
Připravte malý a opakovatelný souhrn
Nezačínejte milionem řádků v ručně upravované tabulce. Vyberte přiměřené období, které pokrývá běžný provoz i problémový čas, a stejnou metodu použijte na porovnávaných webech. Délku volte podle objemu a situace; není pevný počet dnů, který vždy stačí. U nízkého počtu požadavků bude krátký vzorek snadno zavádějící.
- Vymezte hostitele, období a vrstvy logování.
- Oddělte ověřené roboty, ostatní automatické klienty a neověřený provoz.
- Seskupte požadavky podle typu URL a stavových kódů.
- Porovnejte důležité nové články s nechtěnými variantami.
- Prověřte chyby a prodlevy v konkrétních časových oknech.
- Pro vybrané URL doplňte indexační informace ze Search Console.
Pokud potřebujete zjistit, proč jeden článek stále chybí, použijte diagnostiku indexace. Logový audit má přidat důkaz o procházení, nikoli nahradit všechny ostatní kontroly.
Model: většinu požadavků tvoří parametry
Modelový magazín zaznamená za vybrané období 1 000 ověřených požadavků na HTML. Z nich 600 míří na různé kombinace parametrů, 250 na články a 150 na archivy či jiné stránky. To znamená 60% podíl parametrických požadavků v tomto konkrétním vzorku. Neznamená to, že po jejich omezení robot automaticky stáhne 600 dalších článků. Jde o model výpočtu, nikoli měření konkrétního webu.
| Skupina | Modelový počet | Co zjistit před zásahem |
|---|---|---|
| Parametrické URL | 600 | Jsou to kopie, filtry nebo potřebné samostatné stránky? |
| Články | 250 | Kolik různých článků a jaké odpovědi robot získal? |
| Archivy a ostatní | 150 | Pomáhají objevit důležitý obsah? |
| Celkem HTML | 1 000 | Je období úplné a robot skutečně ověřený? |
Nejprve dohledáte zdroj vzniku variant. Může jít o nepotřebný generátor odkazů, kalendář nebo alternativní řazení. Teprve podle účelu zvolíte omezení jejich vytváření, sjednocení kopií nebo řízení procházení. Zásady kanonických adres a robots.txt a noindex přitom řeší rozdílné úkoly.
Noindex není rychlá úspora procházení
Robot musí stránku stáhnout, aby její noindex přečetl. Tento pokyn proto nepoužívejte jako přímý nástroj pro snížení počtu požadavků. Současně jej ale neodstraňujte z pomocných stránek jen kvůli údajné úspoře. Nejprve oddělte požadavek „nechci stránku v indexu“ od požadavku „nechci tuto cestu vůbec procházet“.
Také dočasné blokování části webu v robots.txt není spolehlivý způsob, jak přidělit uvolněný rozpočet novým článkům. Pokud robot není omezen kapacitou, nemusí dojít k očekávanému přesunu požadavků. Trvale odstraněné stránky mají vracet odpovídající chybový stav; podrobnosti nabízí přehled HTTP chyb a soft 404.
Více domén, jeden hosting
Každý hostitel posuzujte samostatně, ale infrastrukturu sledujte i společně. Noční zálohy, importy a publikace na desítkách instalací mohou způsobit souběžné vyčerpání prostředků. Z logů sestavte časovou osu: kdy začaly chyby, které weby zasáhly a jaké úlohy právě běžely. Jedna průměrná denní odezva může krátkou kritickou špičku skrýt.
Provozní kontrolu doplňuje monitoring WordPress webů. Vyšší tarif objednávejte s konkrétním podkladem, například doloženým limitem procesů a chybami ve stejném okně. Nezaměňujte jej za nápravu nekvalitního nebo zbytečně duplicitního obsahu.
Jak poznat užitečný výsledek zásahu
Porovnávejte stejné typy URL a podobné provozní období. Sledujte chyby, dostupnost, rozložení požadavků a načtení důležitých článků. Výsledek „méně požadavků na nepotřebné varianty“ je jiný než „více indexovaných článků“. Obojí zaznamenejte odděleně. Když data nepokrývají CDN nebo není ověřený robot, ponechte tuto mezeru v závěru viditelnou.
Co konkrétně předat hostingu nebo správci
Užitečné zadání obsahuje doménu, časové pásmo, začátek a konec problému, několik dotčených URL a příslušné stavové kódy. Připojte, zda problém vidíte také v prohlížeči a zda se opakuje při konkrétní úloze. Požádejte o vysvětlení, která vrstva odpověď vytvořila a jaký limit nebo pravidlo v daném čase zasáhlo. Obecné tvrzení „robot nestíhá“ bez těchto údajů správce obtížně ověří.
Před sdílením odstraňte hesla, tokeny a neveřejné parametry. Pro první posouzení často stačí agregované počty a několik bezpečně vybraných řádků; úplný přístupový log může obsahovat osobní či provozně citlivé údaje. Domluvte i to, kdo má přístup k originu a kdo k CDN, aby každý nezkoumal jinou část stejné cesty.
V odpovědi chtějte ověřitelný závěr: který limit byl dosažen, kdy, na kterých webech a co se změnilo. Pokud tato data nejsou dostupná, ponechte závěr jako hypotézu. Měření po cílené úpravě pak může nejistotu zmenšit; samotné navýšení tarifu není důkaz, že původní příčinou byl crawl budget.
Časté otázky
Musí crawl budget řešit každý WordPress?
Ne. U menších webů bývá důležitější konkrétní dostupnost, obsah, interní odkazy a správná sitemap než samostatná optimalizace rozpočtu procházení.
Dokazuje požadavek v logu indexaci?
Ne. Dokazuje zaznamenané načtení v dané vrstvě; zařazení do indexu se ověřuje samostatně.
Mohu robotovi věřit podle User-Agent?
Ne při rozhodnutí vyžadujícím ověřený původ. Použijte aktuální kontrolu IP či DNS podle dokumentace Google.
Pomůže noindex snížit počet návštěv robota?
Není to přímý nástroj úspory: robot pokyn nejprve musí načíst. O indexaci a procházení rozhodujte jako o souvisejících, ale odlišných cílech.
Vyřeší více výkonu hostingu pomalé objevování článků?
Může pomoci při doloženém kapacitním omezení. Bez něj může být příčina v navigaci, inventáři nebo obsahu a vyšší tarif nemusí mít očekávaný účinek.
