- autor Redakce
- 18. 09. 2026
Máte obsah, který by měl vydělávat, ale ve výsledcích chybí — a stejně tak v odpovědích ChatGPT nebo AI Overviews. Vycházíme z průvodce Semrush o technickém SEO: nebudeme opisovat celý manuál, jen vytáhneme místa, kde infrastruktura webu rozhoduje o dohledatelnosti, indexaci i tom, jestli vás systémy vůbec správně přečtou.
Když mluvíme o technickém SEO, nejde už jen o to, aby web „prolezl“ Google. Jde o to, aby obsah vůbec dokázaly najít a správně přečíst i systémy, které z vyhledávání dělají odpovědi. V praxi tedy řešíme infrastrukturu webu: jak se stránky procházejí, jak se vykreslují, co se dostane do indexu a co z něj pak může být citováno.
To je důležitý posun. Většina týmů stále řeší techniku hlavně jako údržbu pro klasické výsledky vyhledávání. Jenže viditelnost se přesouvá i do prostředí typu ChatGPT, Google AI Overviews nebo Copilot. A tam už nestačí, že je text kvalitní a dobře napsaný. Pokud se k němu systém nedostane, nebo si ho neumí správně vyložit, zůstane mimo hru.
V tom je technické SEO překvapivě prosté a zároveň nekompromisní. Neřeší jen, jestli web „nějak funguje“. Řeší, jestli z něj vyhledávače a AI systémy umí vytěžit správné verze stránek, pochopit vztahy mezi nimi a pracovat s obsahem bez zmatku. Když je web technicky slabý, i silný obsah ztrácí dosah, návštěvnost i šanci stát se zdrojem, ze kterého AI čerpá odpovědi.
Semrush v téhle souvislosti staví technické SEO jako průvodce tím, jak fungují procházení a indexování a jaké postupy ovlivňují viditelnost v tradičním i AI vyhledávání. A právě to je dnes podstata celé disciplíny: neudržovat web jen „bez chyb“, ale průběžně hlídat, aby byl čitelný pro stroje, které rozhodují o tom, co uživatel vůbec uvidí.
Procházení webu je chvíle, kdy roboti poprvé narazí na naše stránky. Bez něj nevznikne viditelnost ani ve výsledcích vyhledávání, ani v AI odpovědích.
V praxi nejde o náhodné „prohlížení internetu“. Robot postupuje po odkazech ze stránek, které už zná, a hledá další URL. Právě proto rozhoduje architektura webu. Když jsou důležité stránky snadno dosažitelné, robot je najde rychleji a častěji.
Nejlépe to vidíme na interním prolinkování. Nový blogový článek se často objeví až ve chvíli, kdy na něj vede odkaz z hlavní stránky blogu, z kategorie nebo z jiného obsahu. Když odkaz chybí, stránka se snadno promění v sirotka. Taková stránka nemá žádnou interní cestu z ostatních částí webu, a tím se ztrácí pro roboty i pro uživatele.
V auditních nástrojích, včetně Semrush Site Audit, se osamělé stránky dají dohledat po dokončení procházení. Praktický přínos je prostý: doplníme odkazy z relevantních, existujících stránek a vrátíme obsah do mapy webu. Nestačí stránku jen vytvořit. Musí na ni vést funkční cesta.
Vedle interních odkazů pomáhá i XML sitemap. Je to seznam důležitých URL, který robotům napoví, jaký obsah web vůbec má a kde ho najdou. Sitemap typicky leží na adrese yoursite.com/sitemap.xml nebo yoursite.com/sitemap_index.xml a do Googlu ji posíláme přes Google Search Console v části Indexování > Sitemapy. V praxi ji bereme jako pojistku pro objevování obsahu, ne jako náhradu za špatnou strukturu webu.
Stejně důležitý je soubor robots.txt. Tím říkáme robotům, včetně AI crawlerů jako OAI-SearchBot, kam smí a kam ne. Soubor bývá na adrese yoursite.com/robots.txt. Tady se často chybuje: někdo omylem zablokuje blog, produktové stránky nebo jiný důležitý obsah a pak se diví, že zmizel z vyhledávání. Pokud chceme viditelnost i ve vyhledávacích zkušenostech ChatGPT, nesmíme blokovat ani roboty, kteří tento obsah používají.
Jenže robots.txt není náhrada za noindex. Blokace procházení sama o sobě nezaručí, že URL zmizí z výsledků. Když na stránku vedou odkazy z jiných míst webu, může se ve vyhledávání objevit dál. Pokud chceme stránku z výsledků skutečně vyloučit, patří na ni noindex. To je záměrné rozhodnutí o indexaci, ne jen zákaz vstupu pro robota.
Rozdíl je praktický. robots.txt řeší přístup, noindex řeší zařazení do indexu. Směšovat oba nástroje znamená vytvářet zbytečné slepé uličky.
Do stejné kategorie patří i JavaScript. Moderní weby na něm často stojí, ale řada AI crawlerů, například GPTBot, OAI-SearchBot a ClaudeBot, JavaScript vůbec nespouští. Spoléhají na počáteční HTML odpověď. Google sice běžně pracuje ve fázích procházení, vykreslování a indexování, jenže to neznamená, že si můžeme dovolit odkládat klíčový obsah až „po načtení“.
Právě tady se praxe láme s realitou. Co je pro návštěvníka na obrazovce okamžité, nemusí být pro robota vůbec viditelné. Pokud se důležité odkazy nebo obsah objeví až po vykreslení, musejí být dostupné spolehlivě a bez závislosti na kliknutí, scrollu nebo jiných interakcích. A hlavně nesmíme v robots.txt blokovat JavaScriptové soubory a další zdroje potřebné pro vykreslení.
Semrush Site Audit umí na podobné problémy upozornit. Prakticky tím hlídáme, zda robot dostane stejný nebo alespoň použitelný obraz webu, jaký vidí uživatel. Když procházení, struktura webu, sitemap, robots.txt a renderování fungují dohromady, web se neprosazuje silou obsahu, ale také tím, že ho vůbec někdo dokáže najít.
Po procházení přichází chvíle, kdy se rozhoduje o viditelnosti v praxi. Indexování není jen technický zápis stránky do databáze vyhledávače. Je to filtr, který odděluje stránky, jež mají šanci objevit se ve výsledcích, od těch, které zůstanou stranou.
V běžné praxi se často sleduje jen to, jestli stránka „žije“. Jenže aktivní URL ještě neznamená, že ji Google skutečně používá ve vyhledávání. Proto kontrolujeme stav přes operátor site:. U domény nám dá hrubý obraz o rozsahu indexace, u konkrétní adresy zase rychle ukáže, zda se URL do indexu dostala vůbec.
Tenhle kontrolní krok má smysl hlavně ve chvíli, kdy web generuje více verzí jedné stránky. Filtry, řazení, testovací prostředí nebo interní výsledky vyhledávání často vytvářejí množství adres, které nemají vlastní vyhledávací hodnotu. Pro tyhle případy slouží noindex. Používáme ho tehdy, když chceme stránku záměrně vyloučit z indexace. Není to univerzální oprava, ale řízené rozhodnutí, co do výsledků nepatří.
Současně platí důležitý rozdíl, který se v praxi pořád plete: zablokování crawlování není totéž co vyloučení z výsledků. Když vyhledávač nebo jiný robot nesmí stránku načíst, neznamená to automaticky, že URL zmizí z hledání. Pokud na ni vedou odkazy z jiných míst, může se stále objevit jako známá adresa, i když bez obsahu.
Jiný problém řeší canonical. Ten patří na duplicitní nebo velmi podobné verze obsahu, kde nechceme soupeření více adres o stejné signály. Canonical říká, která URL představuje hlavní verzi, a pomáhá Googlu soustředit hodnocení správným směrem. Dává smysl i na hlavní stránce, ne jen u kopií. Tím držíme web čitelnější pro vyhledávač i pro vlastní interní práci s URL.
Ve výsledku nejde o tři izolované nástroje, ale o tři různé typy řízení indexace. site: slouží ke kontrole, noindex k vědomému vyloučení a canonical k určení preferované verze. Kdo je zaměňuje, obvykle řeší špatný problém správným nástrojem.
Praktický přehled k noindex a canonical uvádí Semrush a Semrush.
HTTPS dnes neřeší jen technickou čistotu webu. V praxi rozhoduje o tom, zda si návštěvník stránku vůbec otevře bez varování, a zda ji vyhledávače i AI systémy vyhodnotí jako důvěryhodný zdroj.
HTTPS je zabezpečená verze HTTP. Přidává vrstvu ochrany při přenosu dat, takže se hůř zachytávají citlivé údaje, jako jsou hesla nebo platební informace. Pro e-commerce i leadové weby jde o základ, ne o doplněk.
Vyhledávače navíc berou HTTPS jako jeden z hodnoticích signálů už od roku 2014. Neznamená to, že samotný certifikát zvedne pozice, ale web bez něj ztrácí důležitý bod důvěry. Stejný problém vidíme i v prohlížečích, které nešifrované stránky označují jako „Není zabezpečeno“. To je drobnost, která umí odradit dřív, než začne jakákoli práce s obsahem.
V prostředí AI vyhledávání má HTTPS stejnou logiku. Systémy, které obsah sbírají a citují, pracují raději s jasně zabezpečenými zdroji. Když web stále běží na HTTP, působí jako méně spolehlivý vstup pro citování i pro další zpracování obsahu.
Pokud web HTTPS nepoužívá, potřebuje SSL/TLS certifikát. Ten ověřuje identitu webu a nastaví bezpečné spojení. V praxi ho dnes lze získat i zdarma, třeba přes Let’s Encrypt.
Po přechodu ale nestačí jen certifikát nahrát. Musíme také nastavit přesměrování z HTTP na HTTPS, jinak si vyhledávače i uživatelé mohou dál otevírat starou verzi adresy a web si sám rozdělí důvěru i signály mezi dvě varianty.
Semrush na to upozorňuje v návaznosti na práci s přesměrováním, protože právě tady se často láme úspěch celé migrace. Bez správného přesměrování zůstane HTTPS jen vedlejší verzí webu, ne jeho jedinou bezpečnou podobou.
Duplicitní obsah si často spojujeme s trestem od Googlu. V praxi je obraz střízlivější. Google za samotnou duplicitu stránky nestrhává body. Jenže klid na místě to neznamená.
Jakmile stejný nebo velmi podobný obsah žije na více URL, vyhledávač začne řešit, kterou verzi má ukazovat. Vedlejší efekt je dobře známý: do výsledků se dostanou nežádoucí adresy, signály z odkazů se rozmělní a robot zbytečně utrácí čas na stránky, které nepřinášejí nic nového.
Právě tady často naráží běžná praxe. Týmy řeší obsah po jednotlivých kampaních, produktech nebo filtrech, ale nehlídají, že stejná informace vznikne v několika podobách. Ve výsledku pak web neprohrává kvůli kvalitě obsahu, ale kvůli vlastnímu nepořádku v URL struktuře.
Smysl auditu je jednoduchý: najít, kde web opakuje stejné pasáže, a rozhodnout, co má zůstat jako hlavní verze. Zbytek je potřeba sloučit, přesměrovat nebo jasně označit jako kopii. Cíl není vymazat všechno podobné, ale odstranit zmatek, který brzdí viditelnost i využití odkazové síly.
Semrush Site Audit dokáže duplicity vytáhnout jako samostatný problém. Po kompletním procházení webu stačí v záložce Problémy vyhledat výraz „duplicitní obsah“. Nástroj ukáže chybu a přes volbu Jak to opravit nabídne konkrétnější postupy.
Dobře nastavená oprava má dopad i na crawl budget, jak upozorňuje Google ve svém vysvětlení tohoto tématu. Když robot nemusí znovu a znovu navštěvovat téměř stejné stránky, zůstane mu víc prostoru pro důležité URL. U větších webů už nejde o detail, ale o rozdíl mezi pořádkem a provozní hlučností.
Na papíře působí rozdíl mezi www a non-www jako drobnost. V praxi z něj ale často vznikne zbytečný technický chaos. Pokud se web otevře na obou adresách, vyhledávače i uživatelé pracují se dvěma verzemi stejného obsahu. A to je přesně situace, která rozbíjí jasný signál o tom, jaká adresa je ta hlavní.
Marketingové týmy někdy nechají obě varianty běžet „pro jistotu“. Jenže jistota to není. Ve skutečnosti tím vznikají dvě cesty k jednomu obsahu, dvě adresy v očích systému a dvě místa, kam se mohou rozptýlit odkazy. Výsledek bývá prostý: obsah vypadá stejně, ale autorita webu se dělí mezi dvě verze.
My proto pracujeme s jedním pravidlem: zvolit jednu preferovanou verzi domény a druhou trvale přesměrovat. Není důležité, jestli zůstane web na https://yourwebsite.com nebo na https://www.yourwebsite.com. Důležité je, aby existovala jen jedna verze, kterou systém považuje za hlavní.
Smysl není jen v čistotě adres. Pokud obě varianty zůstanou dostupné, rozpadá se i profil zpětných odkazů. Jeden web pak sbírá odkazy na dvě různé URL, místo aby veškerá hodnota mířila na jedno místo. V technickém SEO je to zbytečný únik výkonu, který se často přehlíží právě proto, že na první pohled web funguje bez chyby.
V praxi proto kontrolujeme, jestli se na web vstupuje vždy stejnou cestou, a druhou variantu opravdu přesměrujeme. Když tohle necháme být, řešíme později zbytečné duplicity, nejasnosti v indexaci i rozmělněné signály z odkazů. U tak základní věci se vyplatí být nekompromisní. Jedna doména, jedna verze, jeden jasný směr.
Rychlost webu často působí jako technický detail, ve skutečnosti ale zasahuje přímo do hodnocení i do chování lidí na stránce. Kdo čeká, ten nečte, neproklikává se dál a často ani nedá šanci dalšímu obsahu. Z pohledu vyhledávání proto nejde jen o komfort, ale o signál, který vstupuje do posuzování webu na mobilu i na desktopu.
První krok není odhad, ale měření. PageSpeed Insights od Googlu ukáže výkon v rozmezí 0 až 100 a vyšší číslo znamená lepší výsledek. Není to jediné měřítko kvality webu, ale dává rychlý obraz o tom, kde stránka ztrácí čas a co se podepisuje na jejím zpomalení.
V praxi bývají největší zdržení tam, kde je web nejobjemnější. Obrázky často tvoří největší soubory na stránce, takže jejich komprese mívá okamžitý dopad na velikost přenášených dat. U řady webů jde o nejrychlejší zásah s nejviditelnějším efektem, protože se netýká jen jedné šablony, ale opakuje se napříč celým obsahem.
Další páka je CDN. Ta rozkládá kopie obsahu na servery po světě a posílá návštěvníka na blízký server místo na vzdálenou centrálu. V praxi tím zkracuje cestu dat a snižuje prodlevu hlavně u návštěv z jiných regionů. Pro web s širším zásahem to není bonus navíc, ale způsob, jak doručovat obsah rovnoměrněji.
Nejpodceňovanější bývá i prosté zmenšení HTML, CSS a JavaScriptu. Kód často nese spoustu mezer, komentářů a znaků, které uživateli nic nepřinesou. Minifikace je odstraní a zkrátí dobu načítání bez zásahu do obsahu samotného. Často přitom nejde o velkou technologickou změnu, ale o disciplínu, která vrací výkon tam, kde web zbytečně bobtná.
Když rychlost srovnáme s dalšími technickými kroky, vidíme, že nejde o samostatný ostrov. Navazuje na širší výkon webu a dál se promítá do Core Web Vitals, kde se už ale sledují konkrétní uživatelské metriky. Základní pointa zůstává stejná: web může mít silný obsah, ale bez svižného načítání z něj část hodnoty zůstane na cestě.
Rychlost načítání je jen část příběhu. Core Web Vitals jdou dál a měří, jak web skutečně působí na člověka při používání.
Google používá LCP, INP a CLS jako praktické ukazatele uživatelské zkušenosti. Neřeší jen, že stránka „nějak“ otevřela. Zajímá je, jak rychle se zobrazí hlavní obsah, jak svižně web reaguje na kliknutí a zda se rozložení stránky během načítání nerozsype pod rukama.
LCP sleduje čas potřebný k načtení největšího viditelného prvku. V praxi jde obvykle o hlavní obrázek, blok textu nebo hero část. INP měří odezvu na interakce uživatele. CLS ukazuje neočekávané posuny prvků, které posouvají obsah a zhoršují čitelnost i ovládání.
Google v materiálu uvedeném Semrush pracuje s jasnými limity: LCP do 2,5 sekundy, INP do 200 milisekund a CLS do 0,1. Pod tuto hranici se web dostává do kategorie, kterou má Google za dobrou.
Pro nás je podstatné ještě něco jiného: Core Web Vitals se nevyplatí řešit pocitově. V Google Search Console najdeme report Základní webové metriky, který ukáže stav napříč webem. V Semrush Site Audit zase stačí otevřít zprávu Core Web Vitals přes tlačítko Zobrazit podrobnosti. To už je konkrétní kontrola, ne dojem z jednoho rychlejšího nebo pomalejšího testu.
Smysl celé disciplíny je prostý: web může působit dobře na screenshotu a přesto trápit návštěvníka při prvním kliknutí. Core Web Vitals tenhle rozdíl odhalují a dávají nám tvrdší podklady pro opravy, které mají dopad na použitelnost i viditelnost.
U mobilu už nejde o pohodlí navíc. Google pracuje s mobile-first indexací, takže pro indexaci a hodnocení vychází z mobilní verze webu.
V praxi to mění pohled na „dobrý web“. Nestačí, aby desktop vypadal přesvědčivě. Na mobilu musí být dostupný stejný základní obsah, stejné odkazy i stejná strukturovaná data. Co na menší obrazovce chybí, vyhledávač bere jako chybějící signál.
To je častá slabina webů, které staví na odlišném mobilním řešení. Tým pak hlídá vzhled, ale přehlédne obsahovou paritu. Jenže Google nehodnotí „hezkou desktopovou verzi“. Vychází z mobilní zkušenosti a právě podle ní posuzuje obsah stránky.
Mobilní použitelnost přitom nestojí na složitých úpravách. Základ tvoří meta viewport tag, čitelné velikosti písma a dostatek prostoru kolem tlačítek i dalších klikacích prvků. Když web na mobilu nutí uživatele přibližovat, trefovat se na malou plochu nebo scrollovat do stran, působí to proti čitelnosti i důvěryhodnosti.
Kontrolu má smysl dělat přímo v nástrojích, které ukážou, kde mobilní verze selhává. PageSpeed Insights pracuje se SEO zprávou a v Semrush se mobilní použitelnost promítá do části Úspěšné audity. Nejde o formální odškrtnutí položky, ale o rychlý způsob, jak odhalit, jestli mobilní verze skutečně drží krok s desktopem.
Drobečková navigace patří mezi drobnosti, které webu vracejí řád. V praxi jde o sadu textových odkazů, jež ukazují, kde se uživatel na webu nachází a odkud na stránku přišel.
Nejde jen o pohodlnější orientaci. Drobečky zkracují cestu zpět do vyšší úrovně webu bez zbytečného klikaní přes zpět nebo hledání v menu. U obsahu s více kategoriemi, produktových webů nebo rozsáhlých magazínů to bývá rozdíl mezi plynulým pohybem a zbytečným blouděním.
V marketingové praxi se drobečky často berou jako kosmetika. Ve skutečnosti pomáhají i struktuře webu. SEO z nich těží proto, že propojují stránky napříč úrovněmi a rozdělují odkazovou hodnotu napříč webem. Semrush to ve svém článku o breadcrumbs popisuje právě tímto směrem: drobečky nejsou jen orientační prvek, ale i další signál vnitřního propojení.
Pro weby na WordPressu nebo Shopify jde navíc o relativně levný zásah. Některé šablony je mají připravené hned po instalaci, jinde je doplní SEO plugin. Když není hotové nic z toho, dá se drobečková navigace doplnit ručně přes schema markup pro breadcrumbs. I tady ale platí stejná podmínka jako u jiných technických prvků: musí odpovídat skutečné struktuře webu, ne jen hezky vypadat v šabloně.
V redakční praxi se vyplatí sledovat hlavně jedno: drobečky mají dávat smysl uživateli i robotům současně. Když ukazují reálnou cestu webem, pomáhají orientaci, posilují interní prolinkování a zlepšují čitelnost hierarchie. A to je přesně typ technického prvku, který dělá práci tiše, ale dlouhodobě.
U dlouhých seznamů obsahu funguje stránkování jako obyčejně praktické řešení. Rozřízne katalog, výpis článků nebo produktů do přehledných částí, které se dají snadněji načíst, projít i pochopit.
V praxi to bývá pořád lepší volba než nekonečné rolování. To sice působí moderně, ale často spoléhá na dynamické načítání, které vyhledávače ne vždy spolehlivě uvidí celé.
Právě v tom je rozdíl mezi hezkým uživatelským dojmem a reálnou dohledatelností. Když se obsah načítá až při posunu, může část položek zůstat mimo procházení i mimo výsledky vyhledávání.
Dobře udělané stránkování naopak drží jednotlivé části obsahu v samostatných URL a propojuje je mezi sebou. Google pak může následné odkazy sledovat a dojít i k položkám, které by se jinak v dlouhém proudu obsahu ztratily.
Semrush doporučuje hlídat hlavně to, aby stránkování nebylo jen vizuální efekt, ale skutečná navigace. My bychom to shrnuli jednoduše: když má seznam víc stránek, musí mít vyhledávač i člověk jasnou cestu k dalším položkám.
Zdroj: Semrush, Pagination: You Are Doing It Wrong? Part 1
Strukturovaná data nejsou kouzelný trik na vyšší pozice, ale přesný popis obsahu pro roboty. V praxi jde o kód, který vyhledávačům napoví, co je na stránce skutečně důležité: produkt, organizace, recept, událost nebo recenze.
Právě tahle přesnost rozhoduje, jestli web získá bohaté úryvky. Ty z výsledků vyhledávání dělají přehlednější a výraznější záznamy, protože pod názvem a popisem ukazují další informace. V Semrush to popisují jednoduše: správně nasazené strukturované údaje mohou stránku ve výsledcích posunout dopředu a pomoci i míře prokliku.
Jenže tady se často dělá chyba. Mnoho webů značkuje obsah spíš přáními než realitou. Pokud schema slibuje cenu, která na stránce není, nebo hodnocení, které uživatel vůbec nevidí, vyhledávač to nemusí vzít v potaz. V horším případě to vyhodnotí jako klamavé značení. Strukturovaná data musí sedět s viditelným obsahem, ne s marketingovou představou o tom, co by na stránce mělo být.
To je důležité i pro AI odpovědi. Jasně popsaný obsah se lépe čte, interpretuje a znovu používá v dalších vyhledávacích funkcích. Když má stránka srozumitelný signál o tom, co nabízí, roste šance, že z ní systémy vytěží správnou informaci místo neurčitého odhadu.
Nejde přitom o univerzální šablonu pro všechny weby. Google podporuje desítky typů značkování, ale smysl má jen to, které odpovídá povaze stránky. U e-shopu dává největší logiku produktové značení na produktové stránky, ne experiment s typem schema, který s obsahem souvisí jen volně. Tady se nejvíc ukazuje rozdíl mezi rychlou implementací a funkčním řešením: technicky přidat kód je snadné, ale správně popsat skutečný obsah už vyžaduje disciplínu.
Prakticky stačí začít tam, kde značení přinese nejvíc. Google nabízí galerii podporovaných typů strukturovaných dat, pro rychlé vytvoření kódu lze použít i bezplatné generátory, například TechnicalSEO Schema Markup Generator. Ve WordPressu se podobná práce dá zvládnout i přes Yoast SEO. Nástroj ale pořád zůstává jen pomůckou. Rozhodující je, jestli značení odpovídá tomu, co uživatel opravdu vidí.
Více informací najdeme v galerii strukturovaných dat od Googlu, v nástroji TechnicalSEO Schema Markup Generator a v návodu Yoast SEO k implementaci schema.
Nefunkční URL nejsou jen technická vada v reportu. V praxi rozbíjejí cestu uživatele a kazí důvěru ve web. Když někdo klikne na odkaz a dostane 4xx, nepomůže ani dobrý obsah na další stránce. Zkušenost se přeruší dřív, než začne fungovat.
Navíc platí jednoduchá věc: pokud na takovou adresu vedou externí odkazy, nepracuje pro web vůbec. Hodnota z odkazů míří do prázdna a web ztrácí signály, které už mohl využít. Právě proto má smysl řešit nefunkční stránky jako provozní problém, ne jako kosmetickou chybu.
Semrush v Site Audit umí rozbité stránky najít po procházení webu v záložce Problémy. Stačí vyhledat „4xx“ a otevřít seznam stránek přes odkaz s počtem pages. Tím dostaneme rychlý přehled, kde web naráží na slepé uličky.
Samotné zjištění ale nic neřeší. Po opravě může jít o obnovení omylem smazané stránky nebo o přesměrování na nejbližší relevantní obsah. Podstatné je, aby stará URL neskončila jen jako mrtvý konec bez náhrady.
Stejně důležité je pak projít interní odkazy. Pokud jsme stránku opravili nebo přesměrovali, musíme upravit i odkazy, které na ni stále míří. Jinak web dál posílá návštěvníky i roboty na špatné místo.
Site Audit navíc umí dohledat i nefunkční interní odkazy a ukázat stránky, které na problémovou URL odkazují. To je praktický detail, který rozhoduje o výsledku. Bez opravy odkazové sítě totiž často jen přesuneme chybu o jeden krok dál.
Jinými slovy, opravou práce nekončí. Teprve když zkontrolujeme cílovou URL a přepíšeme interní odkazy, web přestane ztrácet návštěvnost i důvěru na místech, kde je to zbytečné.
Jakmile web nabízí víc jazykových verzí, nestačí jen přeložit text a nechat vyhledávač, ať se zorientuje sám. V praxi pak často vidíme zbytečný chaos: české stránky v německých výsledcích, slovenské verze naopak v českém prostředí, nebo střídání správné a nesprávné varianty podle toho, která URL získala silnější signál.
Hreflang řeší právě tuhle vrstvu. Jde o HTML atribut, který vyhledávačům říká, pro jaký jazyk a případně i geografické cílení je konkrétní verze stránky určená. Nejde o kosmetický detail, ale o signál, který pomáhá Googlu zobrazit lidem správnou variantu obsahu podle jejich prostředí.
V multijazyčném webu má smysl přidat hreflang do všech jazykových verzí stejné stránky. Nestačí ho dát jen do jedné mutace a doufat, že si ostatní doplní samy. Vyhledávač potřebuje vidět vztahy mezi verzemi jasně a z obou stran. Když to chybí, hrozí záměna verzí nebo slabší práce s lokálním cílením.
Nejčastější chyba bývá prostá: tým přeloží obsah, ale technické propojení verzí zůstane nedotažené. Obsah pak funguje pro čtenáře, jenže vyhledávač nepozná, která verze patří kterému publiku. Výsledek? Zbytečně rozptýlená viditelnost a horší kontrola nad tím, co se komu ukazuje.
Semrush na to ukazuje i jednoduchý princip na domovské stránce s více jazykovými verzemi: každá varianta musí odkazovat na své jazykové ekvivalenty, aby Google rozuměl celé sadě. V redakční praxi to znamená hlídat nejen překlad textu, ale i technickou vzájemnost mezi verzemi. Bez ní se z vícejazyčného webu rychle stane jen sada oddělených stránek bez jasného vztahu.
Smysl hreflangu je tedy praktický: pomáhá nasměrovat správnou verzi správnému uživateli a brání tomu, aby se jazykové mutace mezi sebou přetlačovaly ve výsledcích vyhledávání.
Na stránce nevyhrává jen dobře napsaný text. Vyhledávače i AI systémy skládají obraz z více vrstev najednou: z nadpisů, popisků, obrázků, videí, URL i strukturovaných dat. Když každá vrstva říká něco jiného, interpretace se zadrhne.
V praxi vídáme častý problém: stránka míří na jedno téma, ale vizuály naznačují něco jiného, metadata pracují s jiným názvem a URL používá další variantu. Pro člověka jde o drobnosti. Pro stroj je to zbytečný šum.
Semrush upozorňuje, že systémy analyzují různé typy obsahu, ne jen samotný text. Sledují i okolní kontext, popisky, strukturovaná data nebo vizuální prvky. Čím víc signálů se shodne, tím snadněji pochopí, o čem stránka skutečně je, a tím snáz ji dokážou znovu použít ve výsledcích i v AI odpovědích.
Dobře to ukazuje příklad stránky Applu s obnovenými iPhony. Stejný subjekt se tam opakuje v H1, podpůrném textu, názvu stránky, meta popisu, Open Graph značkách i v URL cestě. Nejde o stylistickou posedlost. Jde o to, aby každá důležitá část stránky ukazovala na stejnou entitu.
Právě v tom se láme rozdíl mezi chaotickou a čitelnou stránkou. Když viditelný obsah, metadata a struktura URL mluví stejným jazykem, dostává vyhledávač jasnější signál. Pokud se od sebe rozcházejí, roste riziko, že stránku vyhodnotí váhavě nebo ji přeskočí ve prospěch jasnější konkurence.
Pomáhá proto držet konzistentní naming napříč textem, obrázky i metadaty. Stejný princip platí pro popisný alternativní text, názvy souborů i titulky u obrázků a videí. Když se soubor jmenuje jinak, než co zobrazuje, vzniká další zbytečná pochybnost.
Stejně důležitý je soulad strukturovaných dat s viditelným obsahem. Značení má potvrzovat, co uživatel skutečně vidí na stránce, ne vytvářet paralelní realitu pro robota. Jakmile se značení začne rozcházet s obsahem, ztrácí důvěryhodnost.
Nejde tedy o kosmetiku. Konzistence napříč formáty zmenšuje prostor pro omyl a zvyšuje šanci, že si systém stránku správně zařadí. A to je v technickém SEO často rozdíl mezi obsahem, který se dá snadno přečíst a citovat, a obsahem, který se musí domýšlet.
Technické SEO nekončí jedním auditem a jednou opravou. Web roste, přibývají šablony, kampaně, filtry, landing page i nové typy obsahu. S každou změnou přichází další možnost, že se něco rozbije nebo začne fungovat jinak, než jsme čekali.
V praxi se proto vyplácí sledovat technický stav průběžně, ne až ve chvíli, kdy začne padat návštěvnost. Krátký problém v přesměrování, zablokovaný crawler nebo nově vzniklá chyba v indexaci často zůstane skrytá déle, než by měla. U složitějších webů se navíc drobné vady skládají do většího výkonového dluhu.
Semrush Site Audit v tomhle směru pomáhá hlavně šíří záběru. Sleduje více než 140 technických SEO problémů, takže zachytí i věci, které by při ruční kontrole snadno prošly. Důležité ale je, že nástroj sám o sobě nic neřeší. Ukáže, kde web ztrácí jistotu, a my z toho musíme udělat prioritu.
Dobře to ilustruje příklad webu Petco, který Semrush uvádí jako ukázku tří problémů spojených s přesměrovacími řetězci a smyčkami. Jde o typ chyby, která na první pohled není vidět v obsahu, ale zbytečně komplikuje cestu robota i uživatele. Přesměrování se natahují, zvyšuje se riziko omylu a web ztrácí čistotu, kterou technické SEO potřebuje.
Bez auditu založeného na procházení by podobný problém klidně zůstal dlouho bez povšimnutí. To je přesně rozdíl mezi pocitem, že „web funguje“, a reálným technickým zdravím. Pravidelné audity nám dávají konkrétní úkoly, ne abstraktní doporučení. Díky nim víme, co opravit hned, co sledovat a co může počkat.
Do monitoringu dnes patří i viditelnost v novějších vyhledávacích zkušenostech. Bing Webmaster Tools ve zprávě AI Performance ukazují, jak často se obsah objevuje v Microsoft Copilot, v AI generovaných shrnutích Bingu a v některých integrovaných partnerstvích. I tady platí stejná logika: co nesledujeme pravidelně, to nám snadno uteče.
Technické SEO tedy neřešíme jako jednorázový zásah. Bereme ho jako průběžnou údržbu, která drží web čitelný pro vyhledávače i nové AI rozhraní. A právě pravidelnost rozhoduje, jestli problémy zachytíme včas, nebo je budeme hasit až ve chvíli, kdy už stály výkon i viditelnost.
Technické SEO nefunguje jako jednorázová akce, po které máme hotovo. Web se mění, přibývají nové šablony, obsah i chyby, a spolu s nimi se posouvá i to, co má skutečně smysl řešit jako první.
V praxi proto nehoníme všechno najednou. Největší smysl dává začít u základů, které drží viditelnost webu pohromadě: procházení, indexování, HTTPS a mobilní zkušenost. Bez nich se drobnější úpravy snadno minou účinkem.
Teprve potom přicházejí na řadu zásahy podle dopadu. Někde stačí opravit jednu chybějící vazbu v navigaci, jinde rozhodne jediný špatně nastavený redirect nebo duplicitní verze stránky. Priorita se má odvíjet od toho, co brzdí celý web, ne od toho, co je jen nejviditelnější v reportu.
Právě v tom bývá rozdíl mezi běžnou praxí a funkční správou technického SEO. V běžných týmech se často řeší všechno podle hluku. V realitě ale vyhrává pořadí podle dopadu na provoz, indexaci a interpretaci obsahu.
Silné technické základy mají ještě jeden praktický efekt. Stránky se pak snáz dostanou do tradičních výsledků vyhledávání i do odpovědí generovaných umělou inteligencí. Nejde o bonus navíc, ale o důsledek toho, že web je pro systémy čitelný a použitelný.
Nejspolehlivější start dává kompletní audit. Semrush Site Audit sem zapadá jako praktický příklad, protože umí ukázat, kde web skutečně ztrácí výkon. Bez takového průchodu se snadno opravují drobnosti a přehlížejí problémy, které brzdit celý systém.
Stejně důležitá jako jednorázový audit je pravidelnost. Jak web roste a mění se chování uživatelů ve vyhledávání, mění se i priority oprav. Proto má smysl vracet se k auditu průběžně, nejčastěji po čtvrtletích, a znovu si potvrdit, co má v dané chvíli největší váhu.
Technické SEO tak neřídíme pocitově. Řídíme ho jako živý systém, který potřebuje kontrolu, pořadí kroků a opakované přehodnocení. Jen tak zůstane web připravený na viditelnost i na to, jak se vyhledávání dál proměňuje.
Technické SEO se v praxi pořád podceňuje jako sada samostatných oprav. Jenže jeho skutečný význam je jinde: rozhoduje o tom, jestli se obsah vůbec dostane do procházení, indexace a následně i do výsledků Googlu nebo AI odpovědí. Když web nemá zvládnuté základy, neprohraje kvůli slabému copy, ale proto, že ho systémy neumí správně přečíst.
Proto dává smysl postupovat prioritně. Nejdřív dát do pořádku procházení, indexaci, HTTPS a mobilní zkušenost. Teprve pak má cenu ladit duplicitní URL, canonicaly, rychlost, strukturovaná data nebo jazykové mutace. Kdo začíná u detailů, často jen maskuje problém, který leží o dvě vrstvy níž.
Nejspolehlivější přístup je jednoduchý: držet web čitelný pro roboty, průběžně kontrolovat změny a pravidelně přehodnocovat, co skutečně brzdí výkon. Technické SEO není jednorázová oprava. Je to provozní podmínka viditelnosti. A právě to je rozdíl mezi webem, který jen existuje, a webem, který má šanci být citován, zobrazován a využíván.
Ano. Kvalitní obsah bez správného procházení a indexace zůstane mimo hru. Technická vrstva neurčuje jen výkon, ale i to, jestli se obsah vůbec dostane k vyhledávači nebo AI systému.
Každý nástroj řeší něco jiného. robots.txt omezuje procházení, noindex vylučuje z indexu a canonical určuje preferovanou verzi. Problém vzniká hlavně tehdy, když je používáme zaměněně.
Když trávíme čas drobnostmi a přitom zůstávají otevřené chyby v indexaci, přesměrování nebo mobilní použitelnosti. Opravovat se má podle dopadu na celý web, ne podle toho, co nejvíc svítí v reportu.
Má. Menší web sice nemá tolik vrstev, ale o to víc ho může brzdit jedna chyba v doméně, přesměrování nebo duplicitě. U menších projektů bývá dopad technické chyby často rychlejší a viditelnější.
Jednorázový audit nestačí. Web se mění, přibývají nové stránky, šablony i chyby. Bez průběžné kontroly se technické problémy vracejí a priority se rychle posunou.