JavaScript a AI crawlery: proč musí být obsah v HTML

Web postavený jako single-page aplikace, kde obsah do stránky doplňuje až JavaScript po načtení, vypadá v prohlížeči dokonale. Otázka, kterou si vlastníci webů kladou málokdy, zní: vidí to samé i AI crawler? U většiny z nich je odpověď ne.

Co ukázala analýza edge logů

Nejlepší dostupný zdroj k téhle otázce je analýza edge logů Vercelu, konkrétně nextjs.org a dva job boardy s odlišnými frameworky, prosinec 2024. Vercel má výhodu, kterou nemá skoro nikdo jiný: vidí přímo, jaký obsah crawler stáhl a jestli spustil JavaScript, nebo ne. Je to jediný nezávislý zdroj s popsanou metodikou, jaký se nám podařilo dohledat, a druhý nezávislý zdroj jsme nenašli, což je poctivé přiznat rovnou.

CrawlerProvozovatelRenderuje JavaScript?
GPTBotOpenAINe
ChatGPT-UserOpenAINe
OAI-SearchBotOpenAINe
ClaudeBotAnthropicNe
PerplexityBotPerplexityNe
BytespiderByteDanceNe
Meta-ExternalAgentMetaNe
Gemini (Google)GoogleAno
ApplebotAppleAno

Sedm z devíti sledovaných crawlerů si stránku stáhne jako syrový HTML dokument a JavaScript vůbec nespustí, takže soubory (skripty, data) sice stáhnou, ale nevyhodnotí je. Obsah, který se do DOM dostává až po hydrataci na klientovi, pro ně jednoduše neexistuje. Výjimkou jsou Gemini a Applebot, které renderují stejně jako běžný prohlížeč.

Proč na tom záleží

Indexovatelnost je podle vlastní dokumentace Google nutnou podmínkou pro to, aby se stránka mohla objevit jako podpůrný odkaz v AI Overviews nebo AI Mode (podrobně v Co doložitelně zvyšuje šanci, že vás AI ocituje). Pozor ale na to, co z toho NEplyne: Googlebot JavaScript renderuje, takže SPA v Googlu indexovaná být může a tuhle podmínku splnit umí. Problém je jinde. Stránka, jejíž hlavní obsah je prázdný <div id="root"></div> čekající na JavaScript, je prázdná z pohledu AI crawlerů, které nerenderují (GPTBot, ClaudeBot, PerplexityBot a další z tabulky níž), i když v prohlížeči vypadá kompletní.

Netýká se to jen textu. Struktura nadpisů, tabulky a seznamy, tedy všechno, co crawler používá k pochopení hierarchie obsahu, musí být v HTML, které dorazí ze serveru, ne dosazené až po načtení stránky.

Jak přesně otestovat, co crawler vidí

Nemusíte hádat ani věřit frameworku na slovo, protože se to dá ověřit přímo. Postup je jednoduchý a funguje na jakémkoli webu:

  • Stáhněte stránku bez spuštění JavaScriptu příkazem curl -A "GPTBot" https://vas-web.cz/stranka (nebo jakýkoli nástroj, který nerenderuje) a podívejte se do vráceného HTML, jestli tam hlavní text stránky vůbec je.
  • Otevřete stejnou stránku v prohlížeči a porovnejte, kolik textu vidíte tam oproti tomu, co přišlo z curl. Chybějící nadpisy, odstavce nebo celé sekce jsou přesně to, co crawlery bez renderu nikdy neuvidí.
  • Pokud rozdíl existuje, zkontrolujte, jestli jde o obsah, na kterém záleží (hlavní text, nadpisy, klíčová fakta) nebo jen o interaktivní prvky (formuláře, filtry, widgety), protože u těch druhých rozdíl nevadí.
  • Otestujte víc typů stránek, ne jen homepage, protože u SPA frameworků se často liší, kolik obsahu je v počátečním HTML na landing page a kolik na vnitřních stránkách (detail produktu, článek).

Které frameworky mají problém ve výchozím nastavení

Riziko není stejné napříč frameworky. Čistě klientské aplikace (typicky vytvořené jako single-page app bez dodatečné konfigurace serveru) posílají prohlížeči skoro prázdné HTML a celý obsah dosadí až JavaScript, a přesně tenhle vzorec crawlery bez renderu nevidí. Naproti tomu frameworky, které mají server-side rendering nebo static generation jako výchozí nebo snadno zapnutelnou volbu (Next.js, Nuxt, SvelteKit, Astro), posílají hotové HTML hned v první odpovědi, a to platí bez ohledu na to, jestli stránku pak na klientovi "oživí" JavaScript (hydratace) kvůli interaktivitě.

Existují i prerendering/dynamic-rendering služby, které pro roboty vrátí předrenderovanou verzi stránky, zatímco lidem servírují běžnou SPA. Je to funkční záplata pro web, kde přepsat celou architekturu není reálné, ale přidává další systém, který se musí udržovat a testovat, takže když se rozjede nový projekt, jednodušší a spolehlivější je zvolit SSR/static generaci od začátku.

Co s tím prakticky

Server-side rendering (SSR) nebo static generation je nejspolehlivější cesta, protože obsah je v HTML odpovědi hned, bez ohledu na to, jestli crawler spustí JavaScript. Next.js, Nuxt a podobné frameworky to umí nativně a nevyžaduje to žádnou zvláštní konfiguraci navíc.

Hybridní přístup je rozumný kompromis tam, kde přepsat celou aplikaci není reálné: statický nebo serverem vyrenderovaný základní obsah (text, nadpisy, hlavní data) a JavaScript jen pro interaktivní vrstvu navrch, tedy formuláře, filtry, animace. Funguje to pro oba typy crawlerů zároveň a nevyžaduje to kompromis v uživatelském zážitku.

Ověření, co crawler doopravdy dostane, patří do běžné údržby webu, ne jen do jednorázového auditu při spuštění, a postup z předchozí sekce stojí za zopakování po každé větší úpravě frontendu, protože migrace na novou verzi frameworku nebo přidání nové knihovny dovede tenhle poměr nenápadně zhoršit.

Co nevíme

Metodika Vercelu je omezená na tři konkrétní weby v jednom měsíci, takže je to nejlepší dostupný zdroj, ne definitivní studie napříč celým webem. Chování crawlerů se navíc může měnit rychleji, než stíhá dokumentace; datum poslední kontroly u každého zdroje je uvedené v sekci Zdroje níž.

Nevíme ani, jestli Gemini a Applebot renderují stránku úplně stejně jako běžný prohlížeč, nebo jen z části (například s omezeným časem na vykonání skriptů), protože Vercelova analýza tenhle detail nerozebírá, jen konstatuje, že rozdíl mezi stáhnutým a viditelným obsahem u nich byl minimální.

Otevřená otázka je i to, jak rychle se situace může změnit. Chování AI crawlerů dnes kopíruje ekonomiku: rendering JavaScriptu je výpočetně dražší než stažení syrového HTML, a při crawlování miliard stránek se ten rozdíl v nákladech násobí. Není důvod čekat, že se to změní jen proto, že by to bylo pro vlastníky webů pohodlnější, a spíš je rozumné počítat s tím, že rozdíl mezi renderujícími a nerenderujícími crawlery vydrží.

Pokud spravujete web s frontendovým týmem, stojí tahle otázka za to, aby se dostala rovnou do definice hotovo pro každou novou stránku, protože je levnější zkontrolovat to při vývoji než dohledávat o dva měsíce později, proč se stránka nikde neobjevuje.

Kontrola ACC-03 v Torumatě přesně tohle měří: porovná text, který dostane běžný HTTP požadavek, s textem po plném renderu v prohlížeči, a rozdíl větší než 40 % slov nahlásí jako nález. Spusťte bezplatný audit a zjistěte, kolik z vašeho obsahu AI crawlery skutečně vidí.

Zdroje