Jak dlouho trvá indexace? A co procházení? Mám čísla přímo z Google

Časová osa s typickými časy Googlu: indexace nové URL asi 1,5 hodiny, robots.txt asi 24 hodin, canonical 1–3 týdny, re-crawl známé stránky asi 30 dní, návrat po core updatu 3–6 měsíců

Gary Illyes z Googlu ukázal, kolik času zaberou jednotlivé procesy v Google Search. Přeložil jsem jeho čísla do otázky, kterou řešíte nejčastěji: kdy ještě čekat a kdy začít hledat chybu.

Čísla zazněla 2. října 2026 na Search Central Live Deep Dive v Barceloně. Google je nikde nepublikoval, známe je z recapu Johna Campbella (ROAST) a z přepisu na Search Engine Roundtable z 5. října 2026. Chybí metodika i definice slova „typicky“, beru je proto jako orientační body pro odhad.

Nová stránka za den, úprava za měsíc

Novou URL Google typicky objeví zhruba za 20 hodin a samotná indexace pak trvá asi 1,5 hodiny. Stránku, kterou už zná, ale znovu projde typicky jednou za zhruba 30 dní. Proto úprava obsahu „nefunguje hned“. Nový titulek nebo snippet se sice propíše za 1–2 dny, počítáno ale až od dalšího průchodu Googlebota.

Na velkém webu se tahle prodleva natahuje. B2B e-shop, se kterým spolupracujeme, má v sitemapách asi 10 100 URL ve třech jazykových mutacích. Googlebot k němu podle statistik procházení v GSC chodí tempem kolem 188 požadavků denně. I kdyby šel jen po URL ze sitemap, prošel by je všechny až za víc než 50 dní. Navíc lastmod u 3 344 z 3 367 URL uváděl čas, kdy se soubor vygeneroval. Googlu tak nedával signál, které stránky se změnily a má je projít přednostně.

Co dalšího jak trvá?

  • robots.txt a sitemapa: kolem 24 hodin.
  • Canonical a odebrání z indexu: 1–3 týdny.
  • Stěhování webu: 1–3 měsíce.
  • Návrat po core updatu: 3–6 měsíců. Jeho rozjetí za 2–4 týdny o návratu nic neříká. Jak takový návrat vypadá v praxi, popisuji v případové studii.
  • Kapacita procházení: sníží se během sekund, třeba při přetíženém serveru. Zotavuje se 1–3 týdny, i když web už dávno běží zdravě.

Zpoždění se sčítají. Stránka se nezaindexuje, dokud ji Googlebot neprojde, a pomalý crawl posune všechno za ním. Když Google stránku nepovažuje za hodnou indexace, technická oprava ji tam nedostane.

Kdy čekat a kdy prověřit

Prahy jsem odvodil z nejpomalejších časů. Berte je jako hrubé vodítko.

SituaceNormálníPrověřit
Nová stránka není v indexudo 2–3 dnůpo 2 týdnech
Nový titulek se nepropsaldo pár dnůpo 2–3 týdnech
Canonical, sloučení duplicitdo 3 týdnůpo 1–2 měsících
Odebrání URL (404, 410, noindex)do 3 týdnůpo 2 měsících
Stěhování webudo 3 měsícůpo 3 měsících
Návrat po core updatu3–6 měsícůpo 6 měsících

U titulku pozor: Google si ho může přepsat sám, takže nemusí jít o zpoždění. U canonicalu hledejte konfliktní signály v interních odkazech, sitemapě, hreflangu a redirectech. A když se web nevrátí ani po 6 měsících od core updatu, obvykle už nezbývá než počkat na další.

Sitemapu hlídejte sami

Na stejném e-shopu vracely 30. září 2026 od dopoledne dvě jazykové sitemapy kód 500 a Googlebot se na ně mezitím čtyřikrát zeptal. Příčina byla v datech e-shopu: smazaná a znovu založená kategorie se stejnou adresou shodila generování sitemap. Oprava od vývojářů přišla druhý den, což při typickém zpracování sitemapy kolem 24 hodin není katastrofa. Bez hlídání by ale výpadek mohl trvat dlouho.

Čísla od Googlu tak pomáhají hlavně s odhadem, jestli je zpoždění ještě v normálu. Dostupnost sitemap má smysl hlídat vlastním monitoringem. Spoléhat na to, že si výpadku všimne Google, se nevyplácí.

Napište komentář

Vaše e-mailová adresa nebude zveřejněna. Povinná pole jsou označená.