Technické SEO pohledem vývojáře
Technické SEO je péče o to, aby web šel projít, pochopit a rychle zobrazit.
Obsah a odkazy řeší někdo jiný; tahle část leží na lidech, kteří web staví. A právě proto se
na ni často zapomíná: v zadání bývá „udělejte to SEO friendly“, což nikomu nic neříká.
Prakticky jde o čtyři otázky, na které musí web odpovědět dobře:
- Dostane se robot na stránku? Stavový kód, robots.txt, přesměrování,
rychlost odpovědi serveru, žádná blokace na firewallu nebo v CDN.
- Uvidí obsah? Je v HTML, nebo se dolaďuje JavaScriptem až po interakci?
Jsou odkazy skutečné odkazy, nebo kliknutelné divy?
- Pochopí, co to je? Nadpisy, strukturovaná data, kanonické odkazy,
hreflang, stránkování. Jedna adresa, jeden význam.
- Neutopí se ve zbytečnostech? Filtry, parametry, duplicity a stránky,
které nikdo nechtěl. Crawl budget není nekonečný.
Na školení tyhle čtyři otázky procházíme na vašem webu, ne na teoretickém příkladu. Kompletní
rozbor jednotlivých oblastí mám na stránce technické SEO,
kde nabízím i audit na klíč.
Procházení a indexace: co která direktiva dělá
Nejčastější zdroj nedorozumění mezi SEO a vývojem. Tři nástroje, které se pletou, protože
všechny „něco zakazují“, ale každý jinde a s jiným důsledkem:
- robots.txt řídí procházení. Zakázaná adresa se neprojde, ale
může skončit v indexu bez popisku, pokud na ni vedou odkazy. Nikdy proto neslouží
k odstranění stránky z výsledků.
- meta robots / X-Robots-Tag řídí indexaci. Aby robot noindex
viděl, musí stránku projít. Kombinace zákazu v robots.txt a noindexu proto nefunguje,
robot se k direktivě nedostane.
- canonical je doporučení, která z podobných adres je ta hlavní.
Není to příkaz a Google ho může ignorovat, zvlášť když si odporuje s dalšími signály
(odkazy, sitemapa, hreflang).
K tomu patří praktické věci: stavové kódy (proč 302 při stěhování škodí), stránkování, chování
nedostupných produktů, sitemapy a jejich lastmod a řízení filtrací. Rozhodovací matici pro
filtry rozebírám v článku o indexaci filtrační
navigace a postup pro noindex přes GTM v článku o implementaci noindexu pomocí Tag
Manageru.
JavaScript a vykreslování obsahu
Google JavaScript zpracuje, ale ve dvou vlnách: nejdřív si vezme HTML a teprve později
stránku vykreslí. Mezi tím může uplynout podstatná doba a část obsahu se do prvního
hodnocení nedostane. Ostatní roboti jsou na tom hůř: AI crawleři typicky JavaScript
nespouštějí vůbec, takže co není v HTML, pro ně neexistuje.
Co na školení procházíme:
- Kde obsah vzniká. Vykreslování na klientovi, na serveru, statické
generování nebo předrenderování pro roboty. Každá varianta má jiné důsledky a jinou cenu.
- Jak ověřit, co robot vidí. Zobrazení zdrojového kódu vs. DOM, test
živé adresy v Search Console, načtení stránky s vypnutým JavaScriptem, kontrola přes
uživatelský agent robota.
- Typické pasti. Obsah načítaný až po kliknutí nebo scrollu, nekonečné
scrollování bez stránkovaných adres, odkazy jako `onclick` na divu, navigace, která se
neobjeví v HTML.
- Rozpočet na vykreslování. U velkých webů se čeká na vykreslení dlouho.
Čím víc obsahu je rovnou v HTML, tím rychleji se dostane do indexu.
10 SEO chyb, které vznikají v kódu
Nálezy, které vidím v auditech nejčastěji a které vznikly při vývoji, ne v marketingu.
- Noindex nebo blokace přenesená z testuNastaveno na staging, nasazeno na
produkci. Nejdražší chyba za nejméně práce.
- Indexovatelné parametry a filtryKaždá kombinace vlastní adresa. Desítky
tisíc stránek bez hledanosti, které spotřebují crawl budget.
- Odkazy, které nejsou odkazyKliknutelný div nebo `button` s
JavaScriptem místo `a href`. Robot po nich neprojde.
- Obsah až po interakciPopis produktu v záložce, která se načte po
kliknutí. V HTML není, takže pro AI crawlery neexistuje.
- Řetězená a smyčková přesměrováníPo každé migraci přibude vrstva. Po
třech jde robot přes čtyři skoky a část signálu se ztratí.
- Canonical na sebe sama u všech variantNebo naopak canonical na homepage
napříč webem. Obojí je běžné a obojí je špatně.
- Duplicitní strukturovaná dataŠablona, plugin a modul vypisují každý svou
verzi. Google si nevybere a ignoruje je.
- Chybějící stavový kód pro nedostupný obsahVyprodaný produkt vrací 200 s
prázdnou stránkou, chybová stránka vrací 200 místo 404. Index se plní balastem.
- Blokace robotů na infrastruktuřeFirewall nebo CDN odpoví robotům 403
nebo 429 a nikdo o tom neví, protože v prohlížeči web funguje.
- Obrázky bez rozměrů a v původní velikostiNejčastější důvod špatného LCP
a posunů rozvržení. Přitom jde o dva atributy a jeden build krok.
Core Web Vitals z pohledu vývojáře
Tři metriky, které Google hodnotí podle skutečných dat uživatelů Chrome, ne podle
laboratorního skóre. Proto se čísla z nástrojů a ze Search Console liší a proto se změny
projeví až po 28 dnech, kdy se přepočítá klouzavý průměr.
- LCP (načtení největšího prvku): typicky hlavní obrázek nebo nadpis.
Řeší se kritickou cestou vykreslování, prioritou načítání, formáty a rozměry obrázků a
tím, co blokuje vykreslení.
- INP (odezva na interakci): nahradilo FID a měří skutečnou odezvu během
celé návštěvy. Nejčastější viník je dlouho běžící JavaScript hlavního vlákna, často ze
skriptů třetích stran.
- CLS (posuny rozvržení): obrázky a iframe bez rozměrů, dodatečně načtené
bannery, cookie lišty, fonty bez rezervovaného místa.
Na školení si ukážeme, jak měřit správně, jak oddělit laboratorní a terénní data a jak zjistit,
kolik stojí jednotlivé měřicí a marketingové skripty. Podrobněji v článku o rychlosti webu a měřicích tazích. Jestli se pomalý
web projeví i na chování lidí, se dá ověřit v nahrávkách, viz analýza dat z Clarity.
Migrace a redesign bez propadu
Nejrizikovější okamžik v životě webu a zároveň ten, kde se nejvíc vyplatí, když tým ví, co
dělá. Na školení procházíme postup, který používám při dohledu nad
migrací:
- Inventura před spuštěním. Export všech adres, které mají návštěvnost,
odkazy nebo pozice. Bez seznamu se nedá nic ohlídat.
- Mapa přesměrování jedna ku jedné. Každá stará adresa na nejbližší
odpovídající novou, ne všechno na homepage. Včetně obrázků a PDF.
- Inventura funkcí šablony. Co uměla stará šablona a nová ne:
strukturovaná data, canonical, hreflang, meta pole, stránkování.
- Kontrola testovacího prostředí. Zavřené před roboty, ale zkontrolované
tak, jak bude vypadat ostrá verze.
- Den spuštění. Kontrolní seznam: robots.txt, sitemapy, přesměrování,
indexovatelnost, stavové kódy, měření.
- První týdny po spuštění. Denní kontrola chyb procházení, indexace a
návštěvnosti klíčových stránek, aby se případný propad podchytil hned.
AI crawleři: co se změnilo pro IT
Do robots.txt přibyla během posledních let řada nových jmen a rozhodnutí o nich nejsou
technická, ale obchodní. Rozdíl, který je potřeba znát:
- Vyhledávací crawleři (například OAI-SearchBot, PerplexityBot) stahují
obsah pro odpovědi s odkazem na zdroj. Když je zablokujete, přijdete o zmínky a
návštěvy.
- Trénovací crawleři (GPTBot, ClaudeBot, Google-Extended) sbírají data
pro trénink modelů. Tady je legitimní se rozhodnout, že přístup nechcete.
- Stavový kód 200. Hosting, firewall nebo Cloudflare často AI boty odmítají
dřív, než se dostanou k robots.txt. Web pak v AI nástrojích prostě není. Postup v článku o
AI botech a stavovém kódu 200 a v návodu na nastavení Cloudflare.
- Obsah v HTML. AI crawleři typicky nespouštějí JavaScript. Co se
dorenderuje až v prohlížeči, pro ně neexistuje.
- Strukturovaná data a jasná struktura pomáhají modelu pochopit, co
stránka tvrdí, a citovat ji správně.
Souvislosti a byznysovou stránku rozebírám na stránce GEO (SEO pro AI)
a v návodu jak připravit web pro AI
agenty.
Školení, audit, nebo konzultace?
Tři způsoby, jak technické SEO ve firmě posunout. Liší se tím, co vám zůstane.
| Kritérium |
Školení |
Technický audit |
Konzultace |
| Co dostanete |
Schopnost týmu problémy najít a řešit |
Dokument s nálezy a prioritami |
Odpověď na konkrétní otázku |
| Kdy zvolit |
Tým staví weby průběžně |
Potřebujete vědět, co je teď špatně |
Řešíte jedno rozhodnutí nebo nasazení |
| Kdo pracuje |
Tým, já vedu |
Já, tým pak zapracuje |
Společně nad jedním tématem |
| Výstup |
Znalost, materiály, zápis nálezů |
Zadání pro vývojáře |
Doporučení, revize implementace |
| Opakování |
Jednorázově, obnova po velkých změnách |
Podle potřeby nebo pravidelně |
Průběžně podle potřeby |
| Detail |
Tato stránka |
Technické SEO |
Konzultace a mentoring |
Nejčastější kombinace: nejdřív audit, který ukáže stav, a pak školení nad jeho výstupy, aby
tým rozuměl tomu, co opravuje, a příště to postavil rovnou správně.