Optimalizovali jste obsah. Váš web má odbornost, autoritu a signály důvěry. Ale když AI crawler dorazí na vaši stránku a narazí na časový limit, kdy váš server odpovídá 6 sekund nebo LCP se nevykreslí ani za 5 sekund, crawler pokračuje dál. Váš obsah se nikdy neindexuje. Vaše citace nikdy nevzniknou.
Rychlost zabíjí viditelnost. Ne pomalu. Okamžitě a definitivně.
AI crawlery pracují s omezeními, která tradiční vyhledávače nemají. Mají přísná časová okna, omezené výpočetní rozpočty a malou trpělivost. Stránka, která se na Googlu umisťuje dokonale, může být pro ChatGPT, Perplexity nebo Claude zcela neviditelná, protože se nenačte v termínu crawleru. Tato kapitola popisuje, jak Core Web Vitals fungují pro AI, které metriky záleží nejvíc a jaké změny musíte udělat.
Co měří Core Web Vitals a proč existují
Core Web Vitals jsou tři metriky, které Google vytvořil k měření skutečné uživatelské zkušenosti. Zachycují okamžik, kdy prohlížeč začne zobrazovat obsah, okamžik, kdy mohou uživatelé se stránkou pracovat, a to, jak stabilní zůstává rozvržení během načítání. Google je bere jako faktory řazení. Pro AI crawlery jsou to ale faktory přežití.
Tři metriky jsou:
Largest Contentful Paint (LCP): Jak dlouho trvá, než se načte největší vizuální prvek. Cíl je do 2.5 sekundy. To uživatelé vidí jako první: pokud se hlavní obrázek, nadpis nebo hlavní sekce obsahu zobrazí až za 4 sekundy, musí čekat lidé i crawlery.
Interaction to Next Paint (INP): Jak dlouho trvá, než prohlížeč zareaguje poté, co uživatel na něco klikne. Cíl je do 200 milisekund. Tato metrika testuje, zda váš JavaScript není nafouklý nebo zda se stránka nezasekne, když crawlery simulují interakci.
Cumulative Layout Shift (CLS): Jak moc stránka při načítání poskakuje. Cíl je do 0.1. Když se prvky neočekávaně posunou, crawlery vytáhnou pomíchaný nebo neúplný obsah. Vaše pečlivě napsané odstavce se při zpracování crawlerem zkomolí.
U tradičního vyhledávání jsou to nápovědy. Pro AI crawlery jsou to pevné limity.
Proč mají AI crawlery jiné požadavky na rychlost než Google
Crawler Googlu práci rozděluje. Prochází miliony adres URL na tisících serverů. Může si dovolit čekat 10 sekund, než se stránka načte, protože čekání se rozloží na obrovskou infrastrukturu.
AI crawlery pracují na principu inference při každém dotazu. Když uživatel položí otázku ChatGPT, Perplexity má 3 až 5 sekund, aby váš obsah našlo, získalo a zpracovalo, než musí začít generovat odpověď. Záleží na každé sekundě. Každá milisekunda se počítá do rozpočtu procházení.
Studie chování AI crawlerů ukazují, že weby s First Contentful Paint pod 0.4 sekundy mají v průměru 6.7 citace, zatímco weby, které se načítají déle než 1.13 sekundy, mají v průměru 2.1 citace. Není to korelace. Je to příčinná souvislost. Pomalé stránky se přeskakují.
Retrieval crawler ChatGPT má zdokumentovaný časový limit. Stránky, které v tomto okně neodpoví, se označí jako nedostupné a při dalších pokusech o procházení dostanou nižší prioritu. Bot Perplexity dělá totéž. Web, který odpovídá 6 sekund, druhou šanci nedostane.
Time to First Byte (TTFB): metrika, na které AI crawlerům záleží nejvíc
TTFB měří dobu mezi odesláním požadavku a přijetím prvního bajtu ze serveru. Je to nejčistší míra odezvy serveru.
U AI crawlerů TTFB rozhoduje o tom, zda se vůbec pokusí o vykreslení. Pokud váš server odpovídá 700 milisekund, crawler už ze svého okna 3 až 5 sekund promarnil 700 milisekund. Crawler vykreslování úplně vzdá a spadne zpět na zpracování samotného HTML, což znamená, že obsah vykreslovaný JavaScriptem se stane neviditelným.
Srovnávací hodnoty jsou jasné. TTFB pod 200 milisekund se považuje za výjimečný. 200 až 500 milisekund je přijatelné, ale ne ideální. Nad 600 milisekund máte problém s infrastrukturou serveru.
Většina článků o výkonu bere TTFB jako druhořadý za vizuálními metrikami. Pro AI crawlery je to strážce brány. Pokud TTFB selže, nic dalšího nehraje roli.
Mezi časté příčiny pomalého TTFB patří pomalé dotazy do databáze při každém načtení stránky, přetížený hosting s příliš mnoha weby na jednom serveru, špatné zeměpisné směrování požadavků a chybějící cachování v síti pro doručování obsahu (CDN). Nejsou to problémy designu. Jsou to problémy infrastruktury.
Largest Contentful Paint (LCP): čekání na velký prvek
LCP měří dobu, než se největší vizuální prvek plně načte. Obvykle je to hlavní obrázek, obrázek na pozadí nebo velký textový blok. U stránek s mnoha obsahem je to hlavní oblast obsahu.
LCP pod 2.5 sekundy je "dobrá" hranice. AI crawlery citují stránky v tomto rozsahu 2.8krát častěji než stránky s pomalejším LCP. Rozdíl není nenápadný.
Crawler nečeká, až se načte každý prvek. Počká ale, až se objeví hlavní obsah. Pokud má váš hlavní obrázek 4 megabajty a nemáte ho pro web optimalizovaný, crawler nečinně čeká, než se obrázek stáhne. Než se obrázek načte, jste už za časovým limitem crawleru.
Mezi časté příčiny pomalého LCP patří příliš velké obrázky bez komprese, neoptimalizovaná vložená videa, která blokují vykreslování, webová písma, která nejsou omezená na potřebné znaky a nenačítají se rychle, a skripty třetích stran, které se vykreslují nad ohybem. Každá z těchto věcí přidává sekundy k LCP.
Řešením není čekat déle. Řešením je zařídit, aby LCP nastalo rychleji. To znamená optimalizaci obrázků, líné načítání obsahu pod ohybem, asynchronní načítání skriptů a případně výměnu těžkých vložených prvků třetích stran za statické HTML alternativy.
Interaction to Next Paint (INP): výkon provádění JavaScriptu
INP měří odezvu. Když uživatel (nebo crawler simulující uživatele) se stránkou pracuje, jak dlouho trvá, než se na obrazovce něco změní? Cíl je do 200 milisekund.
U AI crawlerů INP odhaluje, zda je váš JavaScript optimalizovaný, nebo nafouklý. Špatné skóre INP signalizuje, že vaše stránka má příliš mnoho kódu běžícího v hlavním vlákně, nebo že kód není správně rozdělen a odložen.
Crawlery, které simulují interakci, to dělají kvůli získání dynamického obsahu. Pokud vaše stránka načte statické HTML, ale k vykreslení formulářů, podmíněného obsahu nebo interaktivních prvků potřebuje JavaScript, musí crawler tento JavaScript spustit. Pokud je JavaScript pomalý, crawler dostane špatné skóre INP a označí vaši stránku za neefektivní.
Skrytý problém vykreslování na straně klienta je v tom, že většina AI crawlerů JavaScript vůbec nevykresluje. Výzkum ukazuje, že statické HTML se schema markupem dosahuje 94% úspěšnosti zpracování, zatímco obsah vykreslený JavaScriptem skončí na 23%. To znamená, že pokud je váš obsah skrytý za JavaScriptem, AI crawlery ho možná nikdy neuvidí.
Pokud váš web používá vykreslování na straně klienta, problém s INP se mění v problém viditelnosti. Crawler nemůže čekat na provedení JavaScriptu, a proto obsah závislý na JavaScriptu přeskočí.
Cumulative Layout Shift (CLS): stabilita při získávání obsahu
CLS měří vizuální nestabilitu. Když se prvky na stránce při načítání přesouvají, Cumulative Layout Shift roste. Cíl je do 0.1.
U crawlerů nejde u CLS o uživatelskou zkušenost. Jde o přesnost zpracování. Když se DOM posune, zatímco crawler obsah získává, může sebrat špatné prvky. Nadpis se může posunout na místo jiného nadpisu. Postranní panel může vytlačit hlavní obsah z pozice. Crawler získá text, který je na dané pozici, ne text, který tam logicky patří.
Mezi časté příčiny vysokého CLS patří reklamní plochy, které se načtou pozdě a odsunou obsah dolů, obrázky bez zadaných rozměrů, které se načtou a posunou rozvržení, webová písma, která se vymění a změní rozestupy, a karusely, které se samy přehrávají a posouvají obsah. Každá z těchto věcí způsobí pohyb rozvržení.
Řešením je vyhradit místo pro všechno, co se načte. Zadejte rozměry obrázků v HTML. Nastavte font-display na swap, aby písma neblokovala vykreslování. Reklamy a dynamický obsah načítejte do vyhrazených kontejnerů, které neposouvají rozvržení.
Jak optimalizovat rychlost pro AI crawlery
Optimalizace rychlosti pro AI crawlery se liší od optimalizace pro lidi. Uživatelům záleží na tom, kdy stránku uvidí a kdy s ní mohou pracovat. Crawlerům záleží na tom, kdy server odpoví a zda se vykreslí všechen obsah.
Začněte s TTFB. Pokud váš server odpovídá déle než 500 milisekund, nic dalšího nehraje roli. Zkontrolujte dotazy do databáze, přejděte k rychlejšímu poskytovateli hostingu, zaveďte cachování na úrovni aplikace nebo použijte CDN. Investice do TTFB se okamžitě vrátí v pokrytí crawlery.
Optimalizujte obrázky. Každý obrázek na stránce by měl být komprimovaný, zmenšený na rozměr, v jakém se zobrazuje, a poskytovaný v moderních formátech, jako je WebP, s PNG jako záložním. Použijte nástroj pro kompresi obrázků. U hlavních obrázků použijte CDN s automatickou optimalizací.
Odložte nekritický JavaScript. Načítejte jen takový JavaScript, který je naprosto nutný k tomu, aby crawler viděl obsah. Skripty, které sledují analytiku, načítají reklamy nebo pohánějí interaktivní funkce, by se měly odložit nebo načítat asynchronně. Hlavní vlákno tak zůstane volné a provádění rychlé.
Vykreslujte kritický obsah na serveru. Pokud váš web používá framework na straně klienta, vykreslete kritickou cestu na serveru a na klientovi ji doplňte. Zajistíte tak, že crawlery uvidí obsah okamžitě. Ještě lepší je generování statického webu (SSG): stránky se při nasazení sestaví do HTML.
Vyhněte se velkým vloženým prvkům třetích stran. Pokud vkládáte přehrávače YouTube, přehrávače hudby nebo velké externí widgety, blokují vykreslování. Nahraďte je zástupnými prvky, které se načtou až po kliknutí, nebo podstatné informace přesuňte do statického HTML.
Vyhraďte místo pro dynamický obsah. Zadejte výslovné rozměry pro obrázky, reklamy a dynamické sekce. Zabráníte tím posunu rozvržení a zajistíte, že crawler získá správný obsah.
Používejte CDN. Síť pro doručování obsahu směruje požadavky na geograficky nejbližší server, což snižuje latenci a TTFB. Většina CDN nabízí také automatickou optimalizaci a kompresi obrázků.
Co WEMASY nabízí pro rychlost a optimalizaci pro crawlery
Tvůrce webů WEMASY publikuje stránky jako hotové stránky ve formátu HTML, které se negenerují při každém dotazu.
AI crawlery tak vidí váš obsah hned, bez čekání na vykreslení nebo zpracování.
Co všechno zahrnují jednotlivé tarify, zjistíte v ceníku WEMASY.
Často kladené otázky
Ovlivňuje rychlost stránky citace v AI víc než tradiční SEO?
AI crawlery jsou na rychlost citlivější, protože pracují s přísnějšími časovými omezeními. Tradiční crawlery Googlu mohou čekat 10 sekund, než se stránka načte. AI crawlery obvykle vyprší po 3-5 sekundách. V tradičním SEO je rychlost signál řazení. V GEO je rychlost práh. Pokud ho nesplníte, citace nevzniknou vůbec. S Tvůrcem webů od WEMASY to můžete nastavit přímo na svém webu.
Jak poznám, jestli je můj TTFB pro AI crawlery dost rychlý?
Použijte Google PageSpeed Insights (spusťte ho tak, jako by šlo o crawler, tedy ve verzi pro desktop). Hledejte TTFB pod 500ms. Pokud je vyšší, musíte prověřit hosting, databázi nebo kód aplikace. TTFB ukazují i jiné bezplatné nástroje pro testování rychlosti. Pokud je váš TTFB trvale nad 600ms, kontaktujte poskytovatele hostingu nebo zvažte přechod na rychlejší hosting.
Mám optimalizovat Core Web Vitals, i když nesleduji tradiční pozice na Googlu?
Ano. Core Web Vitals přímo ovlivňují viditelnost v AI. Studie ukazují, že 85% webů citovaných platformami AI splňuje všechny tři prahové hodnoty Core Web Vitals. I když pozice na Googlu pro váš byznys nehrají roli, viditelnost v AI ano. Optimalizace je stejná.
Vyplatí se přejít k rychlejšímu poskytovateli hostingu jen kvůli Core Web Vitals?
Pokud je váš současný TTFB nad 600ms, ano. Rozdíl v ceně mezi základním a rychlým hostingem je obvykle $5-15 měsíčně. Návratnost z lepších citací v AI a pokrytí crawlery je výrazně vyšší. Rychlý hosting také zlepšuje uživatelskou zkušenost a míru konverze, nejen procházitelnost.
Zlepšuje cachování Core Web Vitals?
Cachování je nezbytné. Cachování v prohlížeči říká prohlížečům návštěvníků, aby obrázky a statické soubory ukládaly lokálně a nemusely je stahovat znovu. Cachování na serveru ukládá plně vykreslené stránky do paměti, aby se nemusely sestavovat od nuly. Obojí výrazně snižuje TTFB a LCP. Hlavičky cache nastavte důsledně a používejte CDN s automatickým cachováním.
Uškodí optimalizace rychlosti pro AI crawlery uživatelské zkušenosti?
Ne. Optimalizace pro rychlost crawlerů, tedy rychlejší servery, komprese obrázků a odložení JavaScriptu, zlepšují uživatelskou zkušenost celkově. Stránky, které se rychleji načítají crawlerům, se rychleji načítají i lidem. Jedinou výjimkou je pokus optimalizovat čistě pro crawlery odebráním obrázků nebo okleštěním obsahu, což by uživatelům uškodilo. To nedělejte. Optimalizujte rychlost bez odebírání hodnoty.