Google nečte web jako člověk. Sleduje kód, render a signály výkonu
Majitelé webů často řeší hlavně obsah a zpětné odkazy, ale technická stránka rozhoduje o tom, jestli se váš obsah vůbec dostane do indexu ve správné podobě. Google dnes nepracuje jen s HTML, ale i s renderováním stránky v prohlížeči, JavaScriptem, strukturou DOM a signály jako Core Web Vitals. Jinými slovy: pokud je web pomalý, chaotický nebo špatně postavený, může být pro vyhledávač hůř čitelný než pro uživatele.
V praxi to znamená, že dvě stránky se stejným obsahem mohou dopadnout úplně jinak. Jedna se zobrazí v indexu rychle, má správný titulky, strukturovaná data a Google ji snadno pochopí. Druhá spoléhá na těžký JavaScript, blokované zdroje a přetížený template, takže Googlebot uvidí jen neúplný obsah nebo ho vyhodnotí pozdě. Výsledek? Slabší crawling, horší indexace a nižší šance na viditelnost v klasickém i AI vyhledávání.
Jak poznat, že Google váš web nečte správně
Nejčastější problém není „Google nás ignoruje“, ale Google se na stránku nedostane včas nebo ji nepochopí přesně. To se dá poměrně dobře odhalit v Google Search Console a několika dalších nástrojích.
- Search Console → Kontrola URL: porovnejte „Zobrazená stránka“ a „Procházená stránka“. Pokud Google renderuje jiný obsah než vidí uživatel, je problém.
- Indexace: sledujte stav „Prohledáno – momentálně neindexováno“ nebo „Objeveno – momentálně neindexováno“. U větších webů to často signalizuje problém s kvalitou, interním prolinkováním nebo výkonem.
- Logy serveru: Googlebot může část webu navštěvovat opakovaně, ale důležité URL ignorovat. Z logů zjistíte frekvenci crawl budgetu i to, kde robot zbytečně tráví čas.
- Render test v nástrojích jako Rich Results Test, URL Inspection nebo Lighthouse: odhalí, co je skutečně dostupné po vykreslení stránky.
Velmi častý scénář: web v prohlížeči vypadá v pořádku, ale Googlebot dostane prázdný shell a obsah se načítá až po klientském JavaScriptu. Pokud je obsah generovaný až po interakci nebo přes API bez server-side renderingu, vyhledávač může část textu přehlédnout nebo indexovat se zpožděním.
Rychlost není jen UX. Přímo ovlivňuje crawling, render i konverze
Core Web Vitals nejsou kosmetická metrika. Google dlouhodobě používá signály výkonu jako součást hodnocení kvality stránky a z pohledu byznysu jde hlavně o to, že rychlejší weby mají obvykle vyšší míru dokončení konverze. Podle dat Google a dalších benchmarků může i zpoždění v řádu 1 sekundy citelně snížit engagement, zejména na mobilu.
Nejdůležitější metriky dnes:
- LCP (Largest Contentful Paint): ideálně do 2,5 s.
- INP (Interaction to Next Paint): ideálně do 200 ms.
- CLS (Cumulative Layout Shift): ideálně pod 0,1.
Typické příčiny špatných výsledků jsou snadno dohledatelné: příliš velké obrázky bez moderních formátů, blokující CSS, přetížené skripty třetích stran, neoptimalizované fonty nebo špatně nastavený hosting. U WordPressu bývá problém často v kombinaci builderu, desítek pluginů a těžké šablony. U custom řešení zase v tom, že vývojáři spoléhají na client-side rendering bez ohledu na crawl a SEO.
Praktický postup je jednoduchý: změřte web v PageSpeed Insights, Lighthouse a WebPageTest, pak sledujte reálná data v GA4 a Search Console. Pokud máte v CrUX nebo v reálných datech špatné LCP na mobilu, prioritou nejsou nové texty, ale odlehčení hero sekce, obrázků a skriptů.
JavaScript, renderování a indexace: kde weby nejčastěji selhávají
Moderní weby často staví na Next.js, Reactu, Vue nebo headless CMS. To je skvělé pro UX a vývoj, ale jen pokud je správně vyřešené server-side rendering, pre-rendering nebo alespoň důsledná indexovatelnost obsahu. Google sice umí JavaScript vykreslit, ale není to okamžité ani bezchybné. Renderování probíhá ve dvou vlnách: nejdřív se stránka prochází jako HTML, až později se doplní JS obsah.
To vytváří několik rizik:
- obsah není v HTML a Google ho nevidí hned;
- interní odkazy se generují až po renderu a robot je nemusí následovat efektivně;
- meta tagy, canonical nebo strukturovaná data se mění až na klientovi;
- část obsahu je podmíněná cookies, consentem nebo interakcí uživatele.
U headless řešení proto sledujte, zda jsou klíčové stránky serverově renderované, zda odpovídá HTML výstup tomu, co vidí uživatel, a zda jsou ve zdrojovém kódu přítomné všechny důležité prvky. V praxi pomáhá jednoduchý test: otevřete stránku, zobrazte si view-source a porovnejte ho s výsledkem v render testu. Pokud v HTML chybí hlavní text, nadpisy nebo odkazy, je to riziko pro SEO.
U WordPressu bývá problém méně technicky elegantní, ale stejně škodlivý: pluginy na builder, lazy load, cookie lišty a chat widgety mohou zpomalit zobrazení hlavního obsahu. Z pohledu Google je důležité, aby hlavní obsah byl dostupný co nejdříve a bez závislosti na desítkách externích skriptů.
Strukturovaná data, interní architektura a sémantika rozhodují o pochopení obsahu
Google dnes neřeší jen „co na stránce je“, ale i jak je to propojeno a co je hlavní entita. Proto má smysl pracovat s topic clustery, logickou strukturou webu a schema markupem. Správně nasazená strukturovaná data pomáhají vyhledávači pochopit typ stránky, autora, organizaci, produkt, FAQ nebo breadcrumb navigaci.
Nejčastější praktické chyby:
- schema markup neodpovídá skutečnému obsahu stránky;
- na webu je několik verzí stejné entity s rozdílnými názvy;
- chybí interní odkazy mezi hlavním článkem, kategorií a souvisejícími stránkami;
- canonical vede na jinou URL, než je indexovatelný obsah.
Pokud chcete, aby web působil důvěryhodně i pro AI vyhledávání a systémové odpovědi typu Google AI Overviews, je potřeba mít konzistentní sémantiku. To znamená: jasný název firmy, autora, kontakty, datum aktualizace, dobře definované služby a obsah, který pokrývá téma do hloubky. E-E-A-T se neprojevuje jen textem, ale i technickou prezentací důvěryhodnosti.
Pro audit doporučuji kombinaci Schema Validatoru, Rich Results Testu a ruční kontroly HTML. Pokud máte e-shop, hlídejte Product, Offer, AggregateRating a BreadcrumbList. U obsahového webu se víc vyplatí Article, FAQ jen tam, kde dává skutečný smysl, a hlavně konzistentní interní prolinkování, které ukazuje, co je prioritní.
Co zkontrolovat jako první: praktický audit v 60 minutách
Když máte podezření, že Google váš web nečte správně, nezačínejte redesignem. Začněte rychlým technickým auditem, který ukáže největší překážky.
- 1. Search Console: zkontrolujte pokrytí, problémové URL a kontrolu konkrétních stránek.
- 2. Source code vs. render: porovnejte HTML výstup s tím, co vidí uživatel po načtení.
- 3. CWV: vyhodnoťte LCP, INP a CLS na mobilu i desktopu.
- 4. Robots a sitemap: ověřte, že nic důležitého neblokujete a sitemap obsahuje jen indexovatelné URL.
- 5. Interní odkazy: důležité stránky musí být dostupné do 2–3 kliknutí z homepage nebo hlavních hubů.
- 6. Logy: zjistěte, zda Googlebot neplýtvá crawl budgetem na parametrické nebo duplicitní URL.
Pokud zjistíte, že web je pomalý, špatně renderovaný a zároveň má slabou informační architekturu, řešte nejdřív technický základ. Obsah i link building pak mají výrazně vyšší efekt. Google totiž neodměňuje jen dobrý text, ale především web, který umí rychle, přesně a bez překážek přečíst.
