Když web funguje, ale nefunguje pro SEO
Největší past technického SEO je pocit, že „všechno běží“. Stránka se zobrazí, formulář odesílá, žádná kritická chyba v administraci nesvítí. Jenže vyhledávače nehodnotí web jen podle toho, zda je online, ale podle toho, jak snadno ho dokážou procházet, pochopit a důvěřovat mu. A uživatelé zase podle toho, jak rychle se dostanou k obsahu a zda jim web šetří čas.
V praxi to znamená, že i bez jediné „tvrdé“ chyby může web ztrácet na několika frontách: Google indexuje jen část stránek, důležité URL se kanibalizují, Core Web Vitals jsou na hraně, obsah se načítá až po JavaScriptu nebo se signály důvěry rozpadnou mezi duplicity. Výsledek? Nižší viditelnost, slabší CTR a horší konverze, i když web navenek působí bezproblémově.
1. Neviditelné technické problémy, které brzdí indexaci
První skupina problémů se týká procházení a indexace. Typicky nejde o 404 chyby nebo výpadky serveru, ale o jemnější bariéry, které Googlebotu zbytečně komplikují práci. Častý příklad: web má stovky nových URL, ale v Search Console je indexovaná jen menší část. Nebo se stránky sice objeví v indexu, ale velmi pomalu a v neúplné podobě.
Co kontrolovat:
- Robots.txt a meta robots – neblokujete omylem důležité sekce, parametry nebo staging pravidla?
- Canonical tagy – ukazují na správnou preferovanou verzi, nebo se navzájem ruší?
- XML sitemap – obsahuje jen indexovatelné URL, nebo i nechtěné duplicity a přesměrování?
- Interní prolinkování – jsou klíčové stránky dostupné do 3 kliknutí, nebo jsou pohřbené hluboko v architektuře?
Praktický signál problému najdete v Google Search Console v sekcích „Stránky“ a „Sitemaps“. Pokud je rozdíl mezi odeslanými a indexovanými URL dlouhodobě výrazný, není to jen „normální zpoždění“. Zvlášť podezřelé je, když Google opakovaně hlásí „Prozkoumáno – momentálně neindexováno“ nebo „Objeveno – momentálně neindexováno“. To často znamená, že stránka není pro vyhledávač dostatečně důležitá, nebo je technicky hůř dostupná, než si myslíte.
U větších webů se vyplatí použít crawl nástroje jako Screaming Frog, Sitebulb nebo JetOctopus. Sledujte například hloubku kliknutí, počet interních odkazů na URL, stavové kódy, canonical řetězce a nechtěné noindexy. Pokud má důležitá produktová nebo obsahová stránka o desítky procent méně interních odkazů než konkurenční URL, je to SEO problém, i když se stránka normálně otevře.
2. Obsah, který je vidět lidem, ale ne vždy vyhledávačům
Druhá častá skupina problémů vzniká u moderních webů postavených na JavaScriptu, headless CMS nebo složitějších šablonách. Pro uživatele je vše v pořádku, ale Google nemusí okamžitě vidět kompletní obsah, interní odkazy, recenze, FAQ nebo produktové parametry. To je typické zejména pro weby, kde se obsah renderuje až po načtení skriptů.
Jak to poznáte? Zkuste si stránku porovnat ve třech pohledech: běžný prohlížeč, Google URL Inspection a „view-source“/rendered HTML. Pokud se důležitý text, odkazy nebo strukturovaná data objevují až v DOM po vykreslení, ale ne v serverově dodaném HTML, zvyšujete riziko, že Google část obsahu vyhodnotí pozdě nebo neúplně.
U webů v Next.js, Nuxtu nebo jiných frameworkách je zásadní sledovat, zda se používá SSR nebo prerendering pro SEO důležité stránky. U e-shopů bývá problém hlavně na kategoriích, filtrech a produktových detailech. Pokud je například cena, dostupnost nebo hlavní popis zobrazen jen klientsky po načtení skriptu, můžete mít slabší indexaci i horší rich results.
Praktické pravidlo: cokoli je pro SEO důležité, mělo by být dostupné bez nutnosti „čekat na JavaScript“. Pokud to nejde, ověřte aspoň, že Google vidí stejný obsah jako uživatel. K tomu pomůže Chrome DevTools, Search Console a v případě potřeby i testy přes Rich Results Test nebo Schema Markup Validator.
3. Core Web Vitals: web může být rychlý „na pocit“, ale ne v datech
Rychlost je další oblast, kde se web často tváří lépe, než ve skutečnosti je. Na výkonném notebooku a rychlé síti se stránka načte „hned“, ale reálná data z Chrome User Experience Report nebo GA4 ukážou jiný obraz. Pro SEO i UX jsou dnes klíčové hlavně LCP, INP a CLS.
- LCP by měl být ideálně do 2,5 s.
- INP by měl být pod 200 ms.
- CLS by měl být pod 0,1.
Co je zrádné: web může mít „dobrý PageSpeed score“, ale v reálném provozu selhává. To se stává například kvůli těžkým hero obrázkům, blokujícím skriptům, špatnému lazy-loadu nebo reklamním a marketingovým prvkům, které posouvají obsah po načtení. Pokud se uživatelům posouvá tlačítko pod prstem nebo hlavní nadpis naskakuje až po sekundě, je to problém i bez technické chyby.
Pro diagnostiku použijte kombinaci PageSpeed Insights, Lighthouse, WebPageTest a CrUX. Sledujte zvlášť:
- velikost a formát hlavního obrázku,
- počet a pořadí skriptů,
- font loading a layout shift,
- zda se kritický obsah renderuje hned, nebo až po interakci.
Jeden z nejčastějších „tichých“ problémů je přetížení analytikou, chat widgety, heatmapami a tag managerem. Každý nástroj sám o sobě může být v pořádku, ale dohromady zvednou INP a zpomalí hlavní thread. U větších webů má smysl pravidelně auditovat třetí strany a nechat jen ty, které skutečně přinášejí hodnotu.
4. Duplicitní signály a slabá informační architektura
Další typ škodlivého webu je ten, který neporušuje žádné pravidlo, ale posílá vyhledávačům zmatené signály. Typicky jde o duplicity v URL variantách, stránkování, filtrování, parametrech, podobných kategoriích nebo vícejazyčných verzích. Google pak neví, kterou stránku má upřednostnit, a síla se rozmělní mezi více adres.
Tohle je velmi časté u e-shopů a obsahových webů. Například dvě kategorie mají téměř stejný text, stejné produkty a rozdíl je jen v názvu. Nebo se produkt dá otevřít přes několik URL cest. Na první pohled je vše funkční, ale z pohledu SEO vzniká kanibalizace a zbytečné rozptýlení interní autority.
Co sledovat:
- duplicitní title a meta description,
- více URL s téměř identickým obsahem,
- nejasné canonical nastavení,
- stránky bez interních odkazů, ale s indexovatelným stavem,
- parametry v URL bez SEO logiky.
V praxi pomůže jednoduchý audit v Screaming Frogu: seřaďte stránky podle title, H1, canonical a počtu slov. Pokud najdete desítky URL se stejným title nebo téměř identickým textem, máte problém, i když je web „bez chyb“. U velkých webů je vhodné vytvořit jasný model: které URL mají rankovat, které mají být noindex, které canonicalizovat a které vůbec nevytvářet.
Dobře navržená informační architektura je často účinnější než další obsahový sprint. Když vyhledávačům jasně ukážete hlavní témata, podtémata a vazby mezi stránkami, zlepší se nejen indexace, ale i šance na získání širšího tematického pokrytí včetně AI Overviews a dalších systémů založených na porozumění obsahu.
5. Jak poznat, že web škodí byznysu, ne jen SEO
Technický problém nemusí být vidět v organice hned. Někdy se projeví až poklesem konverzí, horším engagementem nebo vyšším podílem bounces z mobilu. Proto je důležité propojit data ze Search Console, GA4, heatmap a případně i serverových logů. Teprve kombinace těchto zdrojů ukáže, kde se web láme.
Varovné signály v datech:
- pokles impresí bez zásadní změny obsahu,
- nižší CTR u stránek, které ztratily rich results nebo mají horší title,
- rostoucí podíl stránek „Prozkoumáno – momentálně neindexováno“,
- vyšší odchodovost na mobilu u pomalých landing pages,
- pokles konverzí po nasazení nového designu nebo skriptů.
Praktický postup pro audit je jednoduchý: jednou za měsíc si vytáhněte top landing pages z organiku, porovnejte jejich výkon za 28 dní proti předchozím 28 dnům a sledujte změny v impresích, kliknutích, průměrné pozici, engagement rate a konverzích. Pokud klesá výkon jen u určité šablony, sekce nebo typu URL, je velká šance, že problém je technický, nikoli obsahový.
U větších webů doporučuji mít i základní monitoring v Log File Analyzeru nebo přes vlastní logy. Zjistíte tak, které URL Googlebot skutečně navštěvuje, jak často a kam se zbytečně vrací. Když bot tráví crawl budget na duplicity, parametry a slabé stránky, je to tichá brzda růstu. A právě takové weby „škodí“ i bez jediné chyby v administraci.
