Google nečte stránku jako člověk. Vidí kód, signály a kontext

Člověk otevře web, přečte si nadpis, podívá se na obrázek a během pár sekund chápe, o čem stránka je. Google postupuje jinak. Nejprve si stáhne HTML, vyhodnotí strukturu, interní odkazy, metadata, schema markup, rychlost načítání a teprve potom se snaží pochopit obsah v širším kontextu. Pokud je stránka technicky slabá, může mít skvělý text, ale přesto se neprojeví ve výsledcích hledání.

To je důvod, proč technické SEO není „jen pro vývojáře“. Ovlivňuje, zda se obsah vůbec dostane do indexu, jak se bude zobrazovat ve výsledcích a jestli si Google spojí stránku s konkrétním vyhledávacím záměrem. V praxi se často ukazuje, že web ztrácí výkon ne kvůli obsahu, ale kvůli chybám v renderingu, kanonizaci, duplicitách nebo pomalé odezvě serveru.

Indexace začíná u HTML, ne u designu

První kontrola by měla být jednoduchá: co Google skutečně dostane při načtení stránky. U webů postavených na JavaScriptu se často stává, že uživatel vidí obsah okamžitě, ale robot dostane prázdnější verzi stránky nebo opožděně vykreslený obsah. To je problém zejména u Next.js, SPA řešení nebo složitých widgetů.

Praktický postup je následující:

  • v Google Search Console zkontrolujte Inspekci URL a porovnejte „Prohlížená stránka“ s tím, co vidí uživatel,
  • otestujte stránku v Rich Results Test a Schema Markup Validator,
  • použijte nástroj jako View Source a ověřte, zda je důležitý obsah v HTML už při prvním načtení,
  • u JavaScript webů ověřte, zda je použité SSR nebo prerendering pro klíčové landing pages.

Jeden typický příklad z praxe: e-shop měl produktové detailní stránky postavené v Reactu, ale popisy se načítaly až po interakci. Uživatel je viděl, Google ne. Výsledek byl jednoduchý: stránka se indexovala bez hlavního textu a organická návštěvnost z long-tail dotazů byla nízká. Po přechodu na server-side rendering a doplnění staticky dostupných popisů se počet indexovaných produktů zvýšil během několika týdnů.

Rychlost a Core Web Vitals už nejsou jen technický detail

Google dlouhodobě pracuje s metrikami Core Web Vitals, které sledují uživatelský zážitek při načítání stránky. V praxi jde hlavně o LCP (Largest Contentful Paint), INP (Interaction to Next Paint) a CLS (Cumulative Layout Shift). Pokud jsou hodnoty špatné, stránka může působit pomalu i tehdy, když se „nějak“ načte.

Co je dobré držet jako orientační cíl:

  • LCP pod 2,5 sekundy,
  • INP pod 200 ms,
  • CLS pod 0,1.

Nejčastější příčiny problémů bývají překvapivě konkrétní: velké hero obrázky bez komprese, příliš mnoho JS skriptů, blokující fonty, neoptimalizované bannery nebo reklamy a špatně nastavené lazy loading. U WordPressu bývá slabinou kombinace těžké šablony, desítek pluginů a nekontrolovaných obrázků nahraných v plné velikosti.

Pro audit doporučuji kombinaci PageSpeed Insights, Lighthouse, WebPageTest a dat z Search Console. Pokud je LCP vysoké na mobilu, ale na desktopu v pořádku, problém bývá často v serverové odezvě, obrázcích nebo v render-blocking zdrojích. U mobilního provozu je to kritické: většina uživatelů dnes přichází právě z telefonu a Google tomu přizpůsobuje i hodnocení.

Struktura stránky rozhoduje o tom, jestli Google pochopí téma

Google dnes nehodnotí jen jednotlivá klíčová slova, ale i celkový význam stránky a její vztah k dalším obsahům na webu. Proto je důležité pracovat s logickou strukturou nadpisů, interním prolinkováním a tematickými clustery. Stránka bez jasné hierarchie je pro vyhledávač i pro AI systémy hůře čitelná.

V praxi to znamená:

  • jeden jasný H1 na stránce,
  • nadpisy H2 a H3 rozdělené podle témat, ne podle designu,
  • interní odkazy mezi souvisejícími články a službami,
  • obsahové clustery kolem jednoho hlavního tématu,
  • kanonické URL pro varianty a duplicitní stránky.

Typická chyba vzniká u webů, které mají podobné stránky pro různé regiony, služby nebo produktové varianty, ale bez jasné kanonizace. Google pak indexuje více verzí téhož obsahu, rozptyluje signály a výsledkem je slabší výkon všech verzí. Stejný problém se objevuje i u filtrů v e-commerce, kde vznikají tisíce kombinací URL s minimální přidanou hodnotou.

Dobrá praxe je vytvořit si mapu témat: hlavní stránka, podpůrné články, FAQ, srovnání, lokální landing pages a konverzní stránky. Každá z nich má jiný účel, ale dohromady tvoří srozumitelný signál. Pro Google to znamená lepší pochopení relevance, pro uživatele jasnější navigaci.

Schema markup pomáhá Googlu i AI systémům pochopit obsah rychleji

Strukturovaná data nejsou doplněk „navíc“. Jsou způsob, jak stránce dát přesnější význam. U technického SEO mají velký dopad zejména typy Organization, LocalBusiness, Product, Article, FAQPage a BreadcrumbList. Správně nasazené schema pomáhá s bohatšími výsledky, ale také s lepší interpretací obsahu v AI vyhledávání, kde systémy čerpají z jasně strukturovaných dat.

Nejčastější chyby jsou tři: nevalidní JSON-LD, nesoulad mezi viditelným obsahem a daty ve schématu a přehnané označování všeho možného bez reálného obsahu na stránce. Google tyto nesrovnalosti umí rozpoznat a výsledek bývá nulový nebo problematický.

Praktický checklist:

  • ověřte schema přes Rich Results Test,
  • kontrolujte, zda údaje odpovídají skutečnému obsahu stránky,
  • u článků doplňte autora, datum publikace a aktualizace,
  • u lokálních firem používejte konzistentní NAP data,
  • u e-commerce doplňte cenu, dostupnost a recenze jen tam, kde jsou skutečně vidět.

V době AI Overviews a dalších generativních vyhledávacích rozhraní roste význam přesného značení obsahu. Systémy totiž častěji vybírají části textu, které jsou jasně definované, důvěryhodné a snadno strojově čitelné. Kdo má v datech chaos, ten ztrácí i v nových typech vyhledávání.

Kontrola v Search Console a pravidelný audit šetří týdny ztraceného výkonu

Technické SEO není jednorázová oprava. Web se mění, přibývají stránky, pluginy, kampaně, skripty i nové obsahové sekce. Proto je nutné sledovat stav indexace, pokrytí webu a výkon pravidelně. Google Search Console je v tomto směru základní nástroj, ale jen pokud se používá systematicky.

Co kontrolovat minimálně jednou týdně:

  • Stránky – počet indexovaných URL a důvody vyloučení,
  • Mapy webu – zda se odesílají správné URL a bez chyb,
  • Ruční zásahy a bezpečnostní problémy,
  • Výkon – dotazy, stránky, CTR a pozice,
  • Mobilní použitelnost a případné chyby v renderingu.

Pokud web ztrácí návštěvnost, je důležité nehádat, ale porovnat data před a po změně. Často se ukáže, že problém vznikl po redesignu, změně URL, nasazení nového pluginu nebo úpravě robots.txt. U větších webů se vyplatí mít i log file analýzu, která ukáže, jak Googlebot skutečně prochází webem, které URL navštěvuje a kde ztrácí čas.

Pro majitele webu je nejpraktičtější držet jednoduchý proces: technický audit každé čtvrtletí, měsíční kontrola Search Console a okamžitá reakce na chyby indexace, 5xx odpovědi, přesměrovací řetězce nebo náhlý pokles výkonu. Google totiž nereaguje na problémy „později“. U slabého webu je umí promítnout do výsledků rychle, a stejně rychle umí sebrat viditelnost i stránkám, které byly dlouho stabilní.