Průchodnost a indexace (crawling)
Jak roboti Googlu, Seznamu a AI asistentů procházejí váš web. Co blokuje indexaci důležitých stránek a kde roboti ztrácejí crawl budget na parametrických URL a filtracích.
Co je technické SEO
Technické SEO je souhrn opatření, která zajišťují, že vyhledávače a AI asistenti mohou web najít, projít, vykreslit, pochopit a zaindexovat. Neřeší, co na webu píšete ani kdo na vás odkazuje, ale zda se k tomu obsahu robot vůbec dostane, jak rychle a v jaké podobě.
Proto rozhoduje dřív než obsah: stránka, kterou Google nezaindexuje, se neumístí ani s nejlepším textem. E-shop, kde roboti tráví 80 % času na kombinacích filtrů, dostane nové produkty do indexu s týdenním zpožděním. Web, který vykresluje obsah až JavaScriptem, se AI asistentům jeví jako prázdný. Technické SEO tyhle bariéry odstraňuje a dělá z webu spolehlivý základ, na kterém teprve dává smysl stavět obsah a odkazy.
Technický audit je jednorázová hloubková kontrola tohoto základu. Výstupem není skóre z nástroje, ale seznam konkrétních zadání pro vývojáře seřazený podle dopadu. Na audit navazuje buď implementace vaším týmem, nebo průběžný monitoring, protože každé nové nasazení může něco rozbít.
Osm oblastí technického SEO
Co přesně kontroluji a jaké nálezy jsou typické. Pořadí odpovídá tomu, jak často bývají příčinou problémů.
1. Crawling a indexace
Základ všeho: může robot stránku najít (interní odkazy, sitemap), smí na ni (robots.txt, meta robots, hlavičky X-Robots-Tag) a chce ji zaindexovat (kvalita, duplicity, canonical)? V Search Console to čtu ze zprávy o indexování, na webu z crawlu a z logů serveru.
Typické nálezy: noindex zapomenutý z testovacího prostředí, sitemap plná přesměrovaných a chybových URL, důležité stránky bez jediného interního odkazu, tisíce stránek „procházeno, ale neindexováno“.
2. Crawl budget
Google projde za den jen určitý počet URL. U webů se stovkami stránek to nehraje roli, u e-shopů s filtrací, řazením, parametry a variantami rozhoduje o tom, jak rychle se změny a nové produkty dostanou do indexu. Řízení crawl budgetu znamená, že roboti tráví čas na stránkách, které mají hledanost, ne na miliónu kombinací filtrů.
Typické nálezy: indexovatelné kombinace filtrů, nekonečné kalendáře a stránkování, session ID v URL, interní vyhledávání otevřené robotům. Podrobně v článku Indexace filtrační navigace.
3. Rychlost a Core Web Vitals
Odezva serveru, velikost stránky, blokující skripty, obrázky, fonty. Google měří Core Web Vitals z reálných uživatelů (CrUX), takže rozhoduje skutečný zážitek, ne laboratorní skóre. Samostatná kapitola níže.
4. Architektura URL, kanonizace a duplicity
Každý obsah má mít jednu adresu. Varianty s lomítkem a bez, http/https, www a bez www, parametry řazení, stránkování, filtrace, produkt ve více kategoriích. Kanonizace říká Googlu, která verze je ta pravá, a přesměrování zajišťují, že se k ní dostane bez okliky.
Typické nálezy: canonical odkazující sám na sebe u každé varianty, řetězce přesměrování po několika migracích, produkt dostupný na čtyřech URL, stránkování s noindex, které odřízne produkty od interních odkazů.
5. Vykreslování a JavaScript
Moderní frontendy (React, Vue, Next.js, headless e-shopy) často pošlou robotovi prázdnou kostru a obsah doplní až skript v prohlížeči. Googlebot JavaScript vykresluje, jiné crawlery to nemusí dělat stejně nebo spolehlivě. Kontroluji proto, co je v prvotním HTML, a navrhuji server-side rendering nebo prerendering klíčových šablon.
Typické nálezy: ceny a dostupnost načítané až JavaScriptem, interní odkazy generované skriptem, obsah v tabech a akordeonech, který se do HTML nedostane. Podrobně v článku AI boti mají HTTP 200, ale nevidí obsah.
6. Strukturovaná data
Schema.org značky pro produkty (cena, dostupnost, hodnocení), organizaci, články, FAQ a drobečkovou navigaci. Pomáhají vyhledávačům pochopit konkrétní údaje a mohou stránku zpřístupnit pro vybrané rozšířené výsledky. Pro AI Overviews ale zvláštní schema není potřeba.
Typické nálezy: chybějící nebo chybové Product schema, hodnocení bez skutečných recenzí (riziko ruční akce), duplicitní Organization na každé stránce s jinými údaji.
7. HTTPS, bezpečnost a hosting
Platný certifikát na všech variantách domény, přesměrování http na https, žádný smíšený obsah, stabilní odezva serveru a správně nastavené CDN, které nezablokuje roboty, jež potřebujete.
Typické nálezy: https verze bez přesměrování z http, bezpečnostní pravidla CDN blokující AI crawlery i Googlebot z některých regionů, testovací doména dostupná a indexovaná.
8. Vícejazyčné weby a hreflang
U webů s mutacemi pro Slovensko, Polsko nebo Německo rozhoduje správné hreflang párování, konzistentní struktura mutací a geografické cílení. Bez toho si mutace konkurují navzájem nebo se zobrazuje špatná verze ve špatné zemi. Rozšířeně řeším v rámci SEO pro expanzi do zahraničí.
Rychlost webu a Core Web Vitals: co měřit a co skutečně pomáhá
Core Web Vitals jsou tři metriky, kterými Google hodnotí zážitek z načítání: LCP (jak rychle se zobrazí hlavní obsah, cíl do 2,5 s), INP (jak rychle stránka reaguje na interakce, cíl do 200 ms) a CLS (jak moc obsah při načítání poskakuje, cíl do 0,1). Google je vyhodnocuje z reálných návštěvníků v Chrome, ne z jednorázového testu, takže rozhoduje průměrný uživatel na průměrném mobilu.
Co v auditech skutečně zrychluje web, seřazeno podle poměru dopadu a pracnosti:
- Odezva serveru (TTFB). Pomalý hosting, chybějící cache nebo těžké databázové dotazy zpomalí všechno ostatní. Často jediná změna hostingu nebo zapnutí cache udělá víc než měsíc ladění frontendu.
- Obrázky. Správné rozměry, moderní formáty (WebP, AVIF), lazy loading mimo první obrazovku a naopak priorita pro hlavní obrázek.
- Skripty třetích stran. Chat, heatmapy, měření, remarketing. Každý tag stojí desítky až stovky milisekund. Audit ukáže, které se vůbec používají.
- Fonty a CSS. Preload klíčových fontů, kritické CSS inline, zbytek odloženě. Jak s tím zacházet v roce 2026, popisuji v článku o prefetch, preload a preconnect.
- Stabilita rozložení. Rezervované místo pro obrázky, bannery a reklamy, aby obsah neposkakoval (CLS).
Co naopak nepomáhá: honba za stovkou v Lighthouse. Skóre je laboratorní odhad, Google používá terénní data. Web se skóre 70 a dobrým LCP u reálných uživatelů je na tom lépe než web se skóre 95, který se na starším mobilu načítá pět sekund.
Technický SEO monitoring: co hlídat každý měsíc
Audit opraví stav k danému dni. Každé další nasazení, nový plugin, změna šablony nebo zásah do CDN může něco vrátit zpět. Proto u klientů v průběžné SEO správě běží technický monitoring, který každý měsíc projde:
- Search Console: pokrytí indexu, nové chyby, propady impresí po stránkách, stav Core Web Vitals.
- Stavové kódy a přesměrování: crawl klíčových URL, nové 404, nové řetězce.
- Rychlost: terénní data CrUX a laboratorní měření po každém větším nasazení.
- Vykreslování a přístupnost: test, co dostane Googlebot a AI crawlery, kontrola robots.txt a pravidel CDN.
- Změny na webu: porovnání crawlu s minulým měsícem, nové šablony, nové parametry v URL, změny v navigaci.
Smyslem není report, ale to, aby se problém zachytil v týdnu, kdy vznikl, ne v měsíci, kdy se projeví na tržbách.
Technické SEO pro Shoptet, PrestaShop, WordPress a weby na míru
Každá platforma má vlastní limity a vlastní typické chyby. Audit tomu přizpůsobuji, protože doporučení, které se na dané platformě nedá nasadit, je k ničemu.
- Shoptet: omezené možnosti přesměrování a úprav šablony, ale dobře řešitelná filtrace, robots.txt a strukturovaná data. Většinu doporučení nastavím v administraci sám.
- PrestaShop: duplicity z kombinací atributů, výkon databáze, moduly třetích stran, které zpomalují a mění URL.
- WordPress: pluginy, které si vzájemně přepisují metadata, těžké šablony, stránkování taxonomií, autorské archivy a přílohy v indexu.
- Weby na míru a headless: vykreslování JavaScriptem, API limity, cache, vlastní logika URL. Nejvíc svobody, nejvíc příležitostí k chybám, a proto nejdůkladnější spolupráce s vývojáři.
