Technické SEO: kompletní návod pro rok 2026
· 17 min čtení
Máte skvělý obsah. Články, které dávají smysl, produktové stránky s popisy, na kterých jste si dali záležet. A přesto vás Google nikde nevidí. Pozice se nehýbou, návštěvnost stojí, konkurence s horším textem vás předbíhá.
Ve většině případů za to nemůže obsah. Za to může technika.
Google musí váš web nejdřív najít, projít, načíst a pochopit. Pokud v kterémkoli z těchto kroků narazí na překážku, sebelepší text zůstane neviditelný. Rozbité přesměrování, blokovaný robot, stránka, kterou nezvládne vyrenderovat. Tohle jsou tiché zabijáky pozic, o kterých většina majitelů webů nemá tušení.
Tenhle návod je kompletní. Projdeme crawling, indexaci, sitemapu, stavové kódy, Core Web Vitals, strukturovaná data, JavaScript i migraci. Aktuálně k roku 2026, ne podle článků z roku 2021, které dodnes měří metriky, jež už neexistují.
Pojďme na to.
1. Co je technické SEO a proč rozhoduje
Technické SEO je vše, co umožňuje vyhledávači váš web bez problémů najít, projít a zpracovat. Není to o klíčových slovech ani o textu. Je to o infrastruktuře pod nimi.
Představte si obsah jako zboží ve skladu. Klíčová slova určují, co ve skladu máte. Ale technické SEO jsou dveře, chodby a osvětlení. Pokud Googlebot nedojde k regálu, je jedno, jak dobré zboží na něm leží.
Tři pilíře technického SEO drží celý web pohromadě. Dostupnost - Google se na stránku dostane. Indexovatelnost - Google smí stránku zařadit do indexu. Zpracovatelnost - Google stránku načte a pochopí její obsah i strukturu.
Proč to rozhoduje víc než kdy dřív? Protože web ztěžkl. JavaScriptové frameworky, nekonečné přesměrování, pomalé načítání na mobilech. Každá tahle vrstva je místo, kde se pozice může zlomit. A čím větší web, tím dražší každá technická chyba.
Dobrá zpráva: technické chyby jsou opravitelné. Na rozdíl od budování autority je to práce s jasným začátkem a koncem. Najdete problém, opravíte, pozice se vrátí.
2. Crawling a indexace
Než se stránka dostane do vyhledávání, musí projít dvěma kroky. Crawling: Googlebot stránku navštíví a stáhne. Indexace: Google obsah zpracuje a zařadí do indexu. Bez prvního nenastane druhé.
Robots.txt: co smí robot procházet
Soubor robots.txt leží v kořeni domény a říká robotům, kam smí a kam ne. Řídí crawling, ne indexaci. Tenhle rozdíl je zdrojem nejčastější technické chyby vůbec.
Robots.txt neslouží k deindexaci. Když stránku zablokujete přes Disallow, řeknete Googlu jen "nechoď sem". Ale pokud na tu stránku vedou odkazy, Google ji může zaindexovat i tak, bez znalosti obsahu. Výsledek: URL ve vyhledávání s popiskem "informace nejsou k dispozici".
Chcete stránku dostat pryč z vyhledávání? Použijte meta tag noindex v hlavičce stránky. A pozor: aby Google noindex viděl, stránka NESMÍ být zablokovaná v robots.txt. Zablokovanou stránku robot neprojde, takže noindex nikdy nepřečte.
Crawl budget: kolik Google projde
Crawl budget je počet stránek, které Googlebot na webu projde za dané období. U malých webů do pár tisíc URL řešit nemusíte. U velkých e-shopů s desítkami tisíc stránek je to zásadní.
Rozpočet žerou zbytečné URL. Filtrované varianty s parametry, nekonečné kombinace řazení, duplicitní stránky, řetězy přesměrování. Každá taková URL je návštěva, kterou Googlebot neutratil za stránku, na které vám záleží.
Jak crawl budget šetřit? Blokujte parametrické a filtrační URL, opravte přesměrování, odstraňte odkazy na neexistující stránky a udržujte sitemapu čistou. Více o tom, jak se to projeví u e-shopů, najdete v článku SEO pro e-shop.
Jak zjistit, co Google reálně indexuje
Nehádejte. Změřte. Google Search Console, sekce Indexování stránek, ukáže přesně, které URL jsou v indexu a které ne a proč. "Prošeno, aktuálně neindexováno" nebo "Objeveno, aktuálně neindexováno" jsou signály, které chcete sledovat.
Druhá metoda je operátor site: přímo ve vyhledávání. Zadejte site:vasedomena.cz a Google ukáže přibližný počet zaindexovaných stránek. Když se to číslo výrazně liší od počtu vašich reálných URL, máte problém. Buď se do indexu dostalo něco navíc, nebo naopak chybí to podstatné.
3. Sitemap.xml
Sitemapa je seznam URL, které chcete mít ve vyhledávání. Je to mapa webu, kterou předáte Googlu. Robotovi urychlí objevování stránek, hlavně u nových nebo velkých webů, kde by je jinak hledal dlouho.
Klíčové pravidlo: do sitemapy patří jen indexovatelné URL. Tedy stránky se stavovým kódem 200, bez noindex, bez blokace v robots.txt, s kanonickou verzí ukazující samy na sebe.
Častá chyba je sitemapa plná balastu. Přesměrované URL, stránky s chybou 404, nekanonické varianty. Když Googlu předáte seznam, kde polovina odkazů nikam nevede, snížíte důvěryhodnost celé sitemapy. Robot ji pak bere méně vážně.
Sitemapu udržujte aktuální. U statického webu ji generujete při každé změně. U e-shopu nebo CMS ji generuje systém automaticky. Důležité je, aby odrážela realitu: nová stránka do sitemapy přibude, smazaná zmizí.
Velké weby rozdělte do více sitemap podle typu obsahu. Zvlášť produkty, zvlášť kategorie, zvlášť blog. Nad nimi index sitemapa, která je všechny sdružuje. Snadněji se pak hledá, kde vázne indexace. Hotovou sitemapu vložte do Search Console a odkažte na ni z robots.txt.
4. HTTP stavové kódy a přesměrování
Při každé návštěvě stránky vrátí server stavový kód. Tříciferné číslo, které říká, jak dopadl požadavek. Pro SEO jsou to signály, podle kterých Google rozhoduje, co s URL udělá.
Kódy se dělí do čtyř skupin.
| Kód | Význam | Co s tím z pohledu SEO |
|---|---|---|
| 2xx (200) | Stránka je v pořádku a načtena | Ideální stav, stránka může být indexována |
| 3xx (301) | Trvalé přesměrování | Předá signály na cíl, správný nástroj pro stěhování URL |
| 3xx (302) | Dočasné přesměrování | Signály nepředá plně, pro trvalé změny nepoužívat |
| 4xx (404) | Stránka neexistuje | Odstraňte odkazy, nebo přesměrujte na relevantní obsah |
| 4xx (410) | Stránka trvale odstraněna | Silnější signál než 404, Google URL rychleji vyřadí |
| 5xx (500, 503) | Chyba serveru | Kritické, opakované chyby snižují frekvenci procházení |
Přesměrování 301 a řetězy
Přesměrování 301 je základní nástroj, když měníte adresu stránky. Přenese odkazovou sílu i pozice na novou URL. Použijte ho vždy, když stará adresa má trvale nahradit novou.
Pozor na řetězy přesměrování. Řetěz je situace, kdy URL A přesměruje na B, B na C a C na D. Každý skok stojí čas, zdržuje robota i uživatele a po cestě se ztrácí část odkazové síly.
Pravidlo je jednoduché: řetěz přesměrování by měl mít maximálně jeden skok. Stará URL míří rovnou na finální cíl, ne přes tři mezistanice. Když migrujete web podruhé, aktualizujte stará přesměrování tak, aby ukazovala přímo na aktuální adresu.
Kanonizace
Kanonický tag rel="canonical" říká Googlu, která verze stránky je ta hlavní. Řeší duplicitu, když je stejný nebo velmi podobný obsah dostupný na více URL. Typicky u e-shopů s filtrováním, řazením nebo parametry v adrese.
Každá stránka by měla mít kanonický tag. Nejčastěji ukazuje sama na sebe. U filtrovaných variant ukazuje na základní verzi kategorie. Google canonical bere jako silné doporučení, ne jako příkaz, takže ho podpořte i konzistentním interním prolinkováním.
5. Core Web Vitals konkrétně
Core Web Vitals jsou tři metriky, kterými Google měří reálný zážitek uživatele z načítání stránky. Rychlost, plynulost interakce a vizuální stabilita. Jsou součástí hodnocení a přímo ovlivňují pozice, hlavně u konkurenčních dotazů.
Tady je nejdůležitější aktualizace celého návodu.
INP nahradil FID
- března 2024 Google nahradil metriku FID metrikou INP. FID (First Input Delay) měřil jen zpoždění první interakce. INP (Interaction to Next Paint) měří odezvu na všechny interakce během návštěvy. Je přísnější a lépe vystihuje reálný pocit z používání stránky.
FID už neexistuje. Není to volitelná varianta ani "starší metrika, která pořád platí". Byla nahrazena. Kdo dnes měří a optimalizuje FID, pracuje se zastaralými daty a řeší něco, co Google přestal počítat.
Tohle je přesně místo, kde poznáte zastaralý návod. Pokud článek o Core Web Vitals stále zmiňuje FID jako aktuální metriku, je psaný před březnem 2024 a nebyl aktualizovaný.
Tři prahy, které musíte znát
| Metrika | Co měří | Dobrá hodnota |
|---|---|---|
| LCP (Largest Contentful Paint) | Jak rychle se načte největší prvek stránky | do 2,5 s |
| INP (Interaction to Next Paint) | Jak rychle stránka reaguje na interakce | do 200 ms |
| CLS (Cumulative Layout Shift) | Jak moc obsah poskakuje během načítání | do 0,1 |
Hodnoty se měří na reálných uživatelích, tzv. field data, ne jen v laboratorním testu. Zdrojem jsou data z Chrome, dostupná v Search Console v reportu Core Web Vitals a v nástroji PageSpeed Insights.
Co Core Web Vitals rozbíjí
LCP nejčastěji kazí velké nekomprimované obrázky, pomalý server a blokující skripty v hlavičce. Řešení: komprimujte obrázky do moderních formátů, nasaďte cache, odložte nekritický JavaScript a přednačtěte hlavní obrázek.
INP zhoršuje těžký JavaScript, který blokuje hlavní vlákno prohlížeče. Když uživatel klikne a stránka dlouho nereaguje, protože zpracovává skripty, INP roste. Rozdělte dlouhé úlohy, omezte skripty třetích stran a odložte vše, co není potřeba hned.
CLS způsobují prvky, které se načtou později a odsunou obsah. Obrázky bez rozměrů, reklamy, dynamicky vkládané bannery. Vždy definujte šířku a výšku obrázků a rezervujte místo pro prvky, které dorazí později.
Konkrétní rozbor Core Web Vitals u e-shopů, kde jsou tyhle problémy nejčastější, najdete v článku SEO pro e-shop.
6. Mobile-first a HTTPS
Google indexuje web mobile-first. To znamená, že pro hodnocení a indexaci používá mobilní verzi stránky, ne desktopovou. Mobilní verze je ta hlavní. Desktop je až druhotný.
Důsledek je zásadní. Pokud na mobilu skrýváte obsah, který na desktopu ukazujete, Google ten skrytý obsah nemusí vzít v potaz. Zkrácené popisy, schované sekce, méně odkazů v mobilní verzi. Vše, co na mobilu chybí, jako by pro Google neexistovalo.
Pravidlo je jasné: mobilní a desktopová verze musí obsahovat stejný obsah. Stejné texty, nadpisy, strukturovaná data i interní odkazy. Responzivní design tenhle problém řeší sám, protože obsah je jeden a přizpůsobuje se šířce obrazovky.
Otestujte web na reálném mobilu, ne jen zmenšením okna prohlížeče. Sledujte velikost písma, dostatečně velké klikací plochy, žádné horizontální posouvání a čitelnost bez zoomování.
HTTPS je dnes standard, ne nadstavba. Šifrované připojení je lehký hodnoticí signál a hlavně základní důvěra. Prohlížeče označují weby bez HTTPS jako nezabezpečené, což odrazuje návštěvníky ještě před tím, než něco přečtou.
Při přechodu z HTTP na HTTPS ohlídejte přesměrování. Všechny HTTP URL musí přes 301 mířit na HTTPS verzi, a to bez zbytečných řetězů. Zkontrolujte i takzvaný smíšený obsah, kdy zabezpečená stránka načítá nezabezpečené prvky jako obrázky nebo skripty.
7. Strukturovaná data
Strukturovaná data jsou kód, který Googlu explicitně popíše, o čem stránka je. Ne "tady je text, domysli si to", ale "tohle je produkt, tohle cena, tohle hodnocení". Google díky nim lépe pochopí obsah a může zobrazit bohatší výsledky.
Přínos jsou takzvané rich results. Hvězdičky hodnocení u recenze, cena a dostupnost u produktu, otázky a odpovědi u FAQ, drobečková navigace. Ve výsledcích vyhledávání zaberou víc místa a přitáhnou víc kliknutí.
Formát: JSON-LD
Google doporučuje formát JSON-LD. Je to blok kódu, který vložíte do hlavičky nebo těla stránky, oddělený od obsahu. Nezasahuje do vzhledu stránky a snadno se spravuje. Zapomeňte na starší formáty microdata a RDFa vložené přímo do HTML značek, JSON-LD je čistší a Google ho preferuje.
Které typy použít
Vyberte typ podle obsahu stránky, ne podle toho, co zní zajímavě.
Article pro blogové články. Product pro produktové stránky, ideálně s cenou a dostupností. FAQPage pro stránky s otázkami a odpověďmi. BreadcrumbList pro drobečkovou navigaci. LocalBusiness pro firmy s provozovnou. Organization pro popis firmy na hlavní stránce.
Zásadní pravidlo: strukturovaná data musí odpovídat viditelnému obsahu stránky. Nepřidávejte hodnocení, které na stránce není. Neuvádějte cenu, která se liší od skutečné. Google to považuje za spam a může udělit ruční postih.
Jak validovat
Nikdy nenasazujte strukturovaná data naslepo. Otestujte je v nástroji Rich Results Test od Googlu, který ukáže, zda jsou platná a zda web splňuje podmínky pro rich results. Druhý nástroj je Schema.org validátor pro obecnou kontrolu syntaxe.
Po nasazení sledujte v Search Console report Vylepšení. Ukáže, které typy strukturovaných dat Google na webu našel a zda v nich nejsou chyby.
8. JavaScript a rendering
Tady odpadá většina návodů. JavaScript je nejčastější technická past, kterou běžné audity přehlédnou, protože stránka v prohlížeči vypadá v pořádku. Googlebot ji ale vidí jinak.
Zpracování stránky s JavaScriptem probíhá ve dvou vlnách. Nejdřív Googlebot stáhne HTML. Pokud je obsah přímo v HTML, hotovo. Pokud ho ale dogeneruje JavaScript, musí Google stránku vyrenderovat, tedy spustit skripty v prohlížeči. A to je náročné a odložené.
Renderování stojí zdroje a čas. U velkých webů může trvat dny, než Google stránku vyrenderuje a uvidí obsah, který závisí na JavaScriptu. Do té doby vidí prázdnou nebo neúplnou stránku. To zdržuje indexaci a u kritických stránek to škodí.
SSR vs CSR
Existují dva základní přístupy k vykreslování. Rozdíl mezi nimi rozhoduje o tom, jak rychle a spolehlivě Google váš obsah uvidí.
CSR (Client-Side Rendering) znamená, že server pošle skoro prázdné HTML a obsah dogeneruje JavaScript až v prohlížeči. Pro SEO nejrizikovější varianta. Google musí renderovat, aby vůbec něco viděl.
SSR (Server-Side Rendering) znamená, že server pošle hotové HTML s obsahem uvnitř. Google vidí obsah okamžitě, bez čekání na renderování. Pro SEO nejbezpečnější přístup.
Mezi nimi jsou hybridní řešení. Prerendering, statické generování, dynamický rendering pro roboty. Cíl je vždy stejný: dostat důležitý obsah do HTML, které přijde ze serveru, aby ho Google viděl hned.
Jak zjistit, co Googlebot vidí
Nespoléhejte na to, jak stránka vypadá vám v prohlížeči. Použijte nástroj Kontrola URL v Search Console a zobrazte vykreslené HTML. Uvidíte přesně obsah, který Google po renderování zpracoval.
Druhý rychlý test: vypněte v prohlížeči JavaScript a načtěte stránku. Co zůstane viditelné, to Google spolehlivě vidí. Co zmizí, to je závislé na renderování a je v ohrožení.
9. Migrace webu bez ztráty pozic
Migrace je nejrizikovější operace v SEO. Změna domény, přechod na nové URL, nasazení nového systému nebo redesign. Provedená špatně shodí pozice ze dne na den. Provedená dobře je čtenář ani Google skoro nepozná.
Klíč je příprava a mapování. Nejde tolik o to, co měníte, ale jak pečlivě ohlídáte, aby každá stará adresa našla svůj nový domov.
Před migrací
Udělejte kompletní seznam všech současných URL. Vyexportujte je z crawleru, ze sitemapy a ze Search Console. Zaznamenejte současné pozice, návštěvnost a nejsilnější stránky. Bez tohoto výchozího stavu po migraci nepoznáte, co se zlomilo.
Připravte mapu přesměrování. Ke každé staré URL přiřaďte novou. Jedna stará adresa míří na jednu novou, tematicky odpovídající. Nikdy neházejte vše hromadně na hlavní stránku, tím signály zahodíte.
Během migrace
Nasaďte přesměrování 301 podle mapy. Každá stará URL přes jeden skok na finální novou adresu, žádné řetězy. Zkontrolujte kanonické tagy, aby ukazovaly na nové URL. Aktualizujte interní odkazy tak, aby vedly rovnou na nové adresy, ne přes přesměrování.
Vygenerujte novou sitemapu s novými URL a nahrajte ji do Search Console. Ověřte, že se nikam nedostal noindex ani nechtěná blokace v robots.txt, což je klasická chyba přenesená z testovacího prostředí.
Po migraci
Sledujte Search Console denně. Report indexace, chyby procházení, stavové kódy. Kontrolujte, že přesměrování fungují a nevznikají řetězy nebo smyčky. Hlídejte 404 chyby a doplňte chybějící přesměrování.
Počítejte s dočasným kolísáním pozic. Pár týdnů výkyvů je normální, než Google zpracuje všechny změny. Pokud ale pozice padají a nevrací se, hledejte chybu v mapě přesměrování nebo v indexaci.
10. Mýty v technickém SEO
Technické SEO je plné rad, které byly pravdivé před lety a dnes škodí. Tady jsou tři nejčastější, na které narazíte i v článcích z první stránky Googlu.
Mýtus 1: Měřte FID
Nejrozšířenější zastaralá rada. FID byl nahrazen metrikou INP 12. března 2024. Kdo dnes optimalizuje FID, řeší metriku, kterou Google už nepočítá. Správně: sledujte INP s cílem do 200 ms. FID pusťte z hlavy.
Mýtus 2: FCP a TTI jsou klíčové metriky
FCP (First Contentful Paint) a TTI (Time to Interactive) jsou pomocné, diagnostické metriky. Pomáhají hledat příčinu problému, ale nejsou to metriky, podle kterých Google hodnotí zážitek. Klíčová trojice je LCP, INP a CLS. FCP a TTI berte jako vodítko při ladění, ne jako cíl.
Mýtus 3: Robots.txt slouží k deindexaci
Zablokování v robots.txt stránku z vyhledávání nedostane. Naopak, zablokovaná stránka může zůstat v indexu bez popisu, protože Google k obsahu nemá přístup. K odstranění z vyhledávání slouží meta tag noindex, a stránka přitom nesmí být blokovaná v robots.txt, jinak Google noindex neuvidí.
Společný jmenovatel všech tří mýtů: přežily, protože je nikdo neaktualizoval. Vyhledávač se mění každý rok. Rady, které fungovaly v roce 2021, dnes klidně škodí. Proto u technického SEO vždy ověřujte datum zdroje.
Tip od SEO specialisty
Nejcennější technický nástroj nemá žádné složité rozhraní. Je to vypnutí JavaScriptu.
Když dělám rychlý technický audit, jedna z prvních věcí je: otevřu web, vypnu v prohlížeči JavaScript a načtu stránku znovu. Za deset vteřin vidím to samé, co Googlebot v první vlně. Text, nadpisy, odkazy, menu.
Když po vypnutí JavaScriptu zmizí obsah, zmizí menu nebo se rozpadne prolinkování, mám odpověď na otázku, proč se web neindexuje, ještě než otevřu jakýkoli placený nástroj. Většina lidí tenhle test nikdy neudělá, protože web v běžném prohlížeči vypadá perfektně.
Druhý tip: technické SEO řešte v pořadí podle dopadu, ne podle toho, co je nejvíc vidět. Nejdřív dostupnost a indexace, teprve pak rychlost a strukturovaná data. Nemá smysl ladit INP na stránce, kterou Google kvůli chybnému robots.txt vůbec nevidí. Opravte dveře, pak řešte osvětlení.