Web může mít krásný design, zelené kolečko v SEO pluginu a přesto ztrácet lidi ještě před načtením hlavního obsahu. Nebo Google indexuje jinou URL, než čekáte. Případně objednávka funguje, ale měření ji pošle dvakrát.
Proto technickou kontrolu nezačínám honbou za stovkou v jednom testu. Nejdřív hledám chyby, které brání obchodu, indexaci nebo používání webu. Až potom leštím drobnosti.
1. Ověřte, že důležité URL vracejí správný stav
Projděte hlavní stránky služeb, články s návštěvností, kontakt a konverzní cestu. Důležitá stránka má vrátit 200. Trvale přesunutý obsah má mít jeden přímý 301 redirect. Odstraněná stránka nemá potichu končit na homepage.
Kontroluji také HTTP a HTTPS, variantu s www a bez www, lomítka a parametry. Výsledkem má být jedna kanonická URL. Google popisuje redirect jako silný kanonizační signál a doporučuje kombinovat ho s konzistentním canonicalem a sitemapou v dokumentaci ke kanonickým URL.
2. Zkontrolujte indexaci z pohledu skutečné stránky
Robots.txt, meta robots, canonical a sitemap mají spolupracovat. Častá chyba je indexovat stránku, která nemá ve vyhledávání co dělat, a současně blokovat důležitý obsah. U několika reprezentativních URL použijte URL Inspection v Search Console. Ukáže, co Google o stránce ví, a umožní otestovat živou verzi.
- Je kanonická URL ta, kterou chcete?
- Je stránka dostupná bez přihlášení a blokace?
- Obsahuje sitemap pouze indexovatelné 200 URL?
- Nevedou interní odkazy přes redirect?
- Nejsou důležité stránky osiřelé?
Přehled těchto oblastí udržuje Google ve své dokumentaci pro crawling a indexaci.
3. Rychlost měřte na lidech, ne jen v laboratoři
PageSpeed Insights a Lighthouse jsou užitečné diagnostické nástroje. Laboratorní test ale není totéž co zkušenost reálných návštěvníků. Aktuální Core Web Vitals tvoří LCP, INP a CLS; terénní data pracují s reálnými zařízeními a připojením. Přehled a rozdíl mezi field a lab daty vysvětluje oficiální dokumentace Web Vitals.
Já bych priority četl takto:
- LCP: kdy se zobrazí hlavní obsah.
- INP: jak rychle stránka reaguje na používání.
- CLS: zda prvky při načítání neskáčou.
- TTFB a síť: zda se vůbec začne rychle něco dít.
Google zároveň výslovně říká, že dobré skóre nezaručuje první pozice. Celková použitelnost je důležitější než honba za jediným číslem. Viz dokumentace page experience.
4. Najděte skutečného viníka načítání
Ve waterfallu a DevTools hledejte dlouhý čas serveru, blokující CSS a JavaScript, obří obrázky, fonty, opakované požadavky a třetí strany. Staré pravidlo „slučte všechny soubory“ už není univerzální. U moderních protokolů může být důležitější množství nepoužitého kódu a blokování hlavního vlákna.
- Hlavní obrázek načtěte v odpovídající velikosti a moderním formátu.
- Obrázkům určete rozměry, aby neposouvaly obsah.
- Obsah pod prvním zobrazením může používat nativní lazy loading.
- Načítejte jen potřebné řezy fontů a znakové sady.
- Marketingové skripty načítejte asynchronně a jen tam, kde mají účel.
- Komprimujte textové zdroje a nastavte dlouhou cache pro verzované soubory.
Třetí strana bývá drahá nejen v milisekundách. Každý pixel, chat a heatmapa znamená další provozní a datovou odpovědnost. Pokud report nikdo nepoužívá, skript pryč.
5. Projděte web jako zákazník s klávesnicí a mobilem
Technická kontrola nekončí serverem. Na mobilu projděte navigaci, formulář, cookie dialog a objednávku. Zvětšete text, vypněte obrázky, použijte klávesnici. Nadpisy mají tvořit srozumitelnou strukturu, formulář potřebuje popisky a chybová hláška musí říct, co opravit.
Každá stránka má mít hlavní úkol. To neznamená jedno tlačítko za každou cenu, ale jasnou hierarchii. Další praktické body najdete v základním UX checklistu.
6. Opravte chyby zdrojů a JavaScriptu
404 u obrázku, fontu nebo skriptu není kosmetika. Může rozbít vzhled, měření nebo funkci. V konzoli prohlížeče zkontrolujte chyby, v síti neúspěšné požadavky a na serveru opakované 5xx. Kritické cesty testujte po každém nasazení.
7. Strukturovaná data používejte jen pro pravdivý obsah
Schema není způsob, jak si vynutit hvězdičky. Je to strojově čitelný popis toho, co na stránce opravdu je. Použijte podporovaný typ a testujte ho v Rich Results Testu. Google uvádí aktuální podporované formáty i testovací nástroje v dokumentaci strukturovaných dat.
8. Měření nesmí rozbít web, který má měřit
GA4, reklamní platformy a další skripty načítejte neblokujícím způsobem. Události pojmenujte podle rozhodnutí, ne podle každého kliknutí. Ověřte duplicity, souhlas a to, zda někdo data opravdu používá. Praktický základ najdete v článcích o Google Tag Manageru a Google Analytics 4.
9. Pořadí oprav určují peníze a riziko
- Nefunkční objednávka, formulář nebo přihlášení.
- Nedostupná či neindexovatelná důležitá stránka.
- Bezpečnostní problém a zastaralé komponenty.
- Velké problémy mobilního používání a Core Web Vitals.
- Chyby měření, které vedou ke špatným rozhodnutím.
- Až potom drobné skóre a kosmetika.
Technické SEO je startovní čára. Samo nevyhraje závod, ale rozbitý web ho může prohrát ještě před výstřelem. Pokud potřebujete technické nálezy přeložit do priorit pro firmu, můžete popsat web a rozhodnutí, které nad ním řešíte.