Ako prebieha technický SEO audit webu

Technický SEO audit je kontrola tej časti webu, ktorú návštevník nikdy nevidí – dostupnosti stránok pre vyhľadávač, rýchlosti načítania, štruktúry adries, presmerovaní a strojovo čitateľných údajov o obsahu. Je to prvá časť komplexnej kontroly webu, ktorú robíme, pretože kým vyhľadávač stránku nedokáže načítať a spracovať, nemá zmysel riešiť texty ani kľúčové slová. V tomto článku prejdeme celý postup tak, ako ho reálne robíme: v akom poradí, s akými nástrojmi, čo pri každom kroku hľadáme a ako z toho vzniká dokument, s ktorým vie klient aj jeho vývojár ďalej pracovať.

Čo presne patrí do technickej vrstvy

Hranica medzi technickým a obsahovým SEO nie je ostrá a obe oblasti sa v praxi čiastočne prekrývajú – napríklad štruktúra nadpisov je obsahová vec, ale spôsob, akým ju šablóna generuje, je technický. My si to rozdeľujeme jednoducho: do technickej vrstvy patrí všetko, čo rozhoduje o tom, či a ako sa obsah k vyhľadávaču vôbec dostane, zatiaľ čo obsahová vrstva rieši, čo v tom obsahu stojí. Vďaka tomuto rozdeleniu je jasné aj to, kto má nález opravovať: technické veci idú zvyčajne na vývojára alebo správcu servera, obsahové na redaktora.

Praktický dôsledok je poradie prác. Technická vrstva sa rieši ako prvá, lebo tvorí podmienku pre všetko ostatné. Ak polovica produktových stránok vracia chybu alebo je vylúčená z indexu, môžete napísať najlepšie texty na trhu a nepomôže to. Preto keď preberáme nový web, technický prehľad je vždy prvá vec, ktorú spravíme – ešte pred akoukoľvek diskusiou o obsahovej stratégii. Širší kontext toho, ako technická časť zapadá do celku, sme popísali v článku o tom, čo je SEO audit a kedy ho potrebujete.

Prvý krok je crawl webu očami vyhľadávača

Audit začíname tým, že web prejdeme crawlerom – nástrojom, ktorý sa po stránkach pohybuje rovnako ako robot vyhľadávača: načíta úvodnú stránku, nájde na nej odkazy, prejde ich a takto pokračuje ďalej, kým sa nové adresy neminú. Výsledkom je zoznam všetkého, na čo sa dá z webu prekliknúť, spolu so stavovým kódom, titulkom, popisom, nadpismi a kanonickou adresou každej stránky. Tento zoznam je základ celého auditu, pretože ukazuje web tak, ako ho vidí stroj, nie tak, ako ho vidíme my v prehliadači.

Prvé prekvapenie prichádza takmer vždy pri porovnaní troch čísel: koľko stránok si myslí majiteľ, že web má, koľko ich našiel crawler a koľko ich pozná Google. Keď crawler nájde päťtisíc adries pri webe, ktorý má podľa majiteľa dvesto stránok, znamená to, že šablóna alebo filtre generujú adresy navyše – a tie si medzi sebou konkurujú. Opačný prípad, keď crawler nájde menej stránok, než web reálne má, zase odhalí, že sa na časť obsahu nedá prekliknúť a robot ju nemá ako objaviť.

Indexovateľnosť rozhoduje skôr než čokoľvek iné

Keď máme crawl, ide sa na indexovateľnosť. Tu sa v praxi nachádzajú najdrahšie chyby vôbec, pretože jediný nesprávne nastavený riadok dokáže z vyhľadávania odstrániť celú sekciu webu a nikto si to niekoľko mesiacov nemusí všimnúť. Signálov, ktoré o indexovaní rozhodujú, je viac a navzájom si môžu protirečiť – napríklad stránka je uvedená v sitemape, ale súčasne má značku, ktorá indexovanie zakazuje. Nasledujúca tabuľka zhŕňa, čo pri každom signáli kontrolujeme a čo býva zdrojom problémov.

Signál	Čo hovorí vyhľadávaču	Častý problém
robots.txt	Kam robot smie a nesmie vstúpiť	Zákaz prístupu k CSS a skriptom, ktorý znemožní vykreslenie stránky
meta robots / X-Robots-Tag	Či sa stránka smie zaradiť do indexu	Zabudnutý noindex z vývojovej verzie po spustení webu
Kanonická adresa	Ktorá verzia stránky je tá hlavná	Všetky stránky ukazujú kanonicky na úvodnú
XML sitemapa	Zoznam adries, ktoré majú byť indexované	Sitemapa obsahuje presmerované a neexistujúce adresy
Stavové kódy	Či adresa existuje, presunula sa alebo je chybná	Reťazce presmerovaní cez tri a viac krokov

Zdrojom pravdy je pri tejto kontrole dokumentácia Googlu o prehľadávaní a indexovaní a hlavne samotná Google Search Console, ktorá pri každej adrese povie, či je indexovaná, a ak nie, z akého dôvodu. Odporúčame prejsť si zostavu vylúčených stránok riadok po riadku – nie preto, že by mala byť prázdna (to nie je cieľ a ani to nie je reálne), ale preto, že sa v nej pravidelne nájdu stránky, ktoré tam nemajú čo robiť.

Rýchlosť meriame v reálnych podmienkach, nie na výkonnom počítači

Rýchlosť webu sa dnes hodnotí cez tri metriky Core Web Vitals: čas vykreslenia najväčšieho prvku, odozvu na interakciu a stabilitu rozloženia počas načítavania. Podstatné je, odkiaľ tieto čísla berieme. Laboratórny test na kancelárskom počítači s rýchlym pripojením vyzerá skoro vždy dobre; reálne dáta od používateľov, ktoré Google zbiera z prehliadača Chrome, ukazujú niečo iné – hlavne na mobiloch strednej triedy a na pomalších sieťach. My preto vždy porovnávame obidva pohľady a rozhodujeme sa podľa toho horšieho.

Väčšina nálezov v tejto časti sa opakuje z projektu na projekt a väčšina z nich má riešenie, ktoré nevyžaduje prepísanie webu. Neoptimalizované obrázky, chýbajúce moderné formáty, písma načítavané zo vzdialených serverov, reklamné a analytické skripty spúšťané pred vykreslením obsahu a bloky, ktoré počas načítania menia výšku a posúvajú text pod prstom čitateľa – to je zoznam, ktorý pokrýva podstatnú časť problémov s rýchlosťou na bežných firemných weboch. Detailnejšie sa jednotlivým metrikám venujeme v samostatnom článku o Core Web Vitals.

Mobilná verzia sa kontroluje ako hlavná, nie ako doplnok

Google hodnotí weby podľa ich mobilnej verzie, takže pri audite sa na web pozeráme najprv na malej obrazovke a až potom na veľkej. Kontrolujeme, či je na mobile dostupný ten istý obsah ako na počítači – stáva sa totiž, že responzívna šablóna niektoré bloky na mobile skryje, a čo je skryté, to sa nemusí počítať. Ďalej sledujeme veľkosť písma, odstupy medzi klikateľnými prvkami, či sa dá formulár vyplniť jednou rukou a či nejaký prvok nevyžaduje vodorovné posúvanie.

Odporúčame testovať na reálnom telefóne, nie len v simulátore v prehliadači. Simulátor ukáže rozmery, ale nepovie nič o tom, ako sa stránka správa pri slabom signáli, ako reaguje na dotyk alebo či sa neprekrýva s klávesnicou. Toto je jedna z mála častí auditu, kde päť minút s telefónom v ruke prinesie viac než hodina práce s nástrojmi.

Presmerovania, chybové stavy a duplicity

Táto časť auditu je nevďačná, lebo nálezy z nej vyzerajú nudne, ale práve tu sa najčastejšie strácajú výsledky rokov práce. Presmerovania vznikajú pri každej zmene štruktúry webu a majú tendenciu sa vrstviť: stará adresa ukazuje na novšiu, tá na ešte novšiu a na konci reťazca je stránka, ktorá už neexistuje. Duplicity zase vznikajú samy od seba – z parametrov v adrese, z verzie s www aj bez nej, z veľkých a malých písmen alebo z toho, že tá istá stránka je dostupná pod dvomi cestami.

• Reťazce presmerovaní. Každý krok navyše stojí čas načítania. Odporúčame ich skracovať na jeden krok z pôvodnej adresy priamo na cieľovú.
• Presmerovania na úvodnú stránku. Ak zrušená podstránka smeruje na úvodnú, používateľ aj vyhľadávač stratili kontext. Lepšie je smerovať na najbližšiu obsahovo príbuznú stránku.
• Interné odkazy na staré adresy. Fungujú, ale zbytočne. Opravujeme ich priamo v obsahu, aby sa presmerovanie vôbec nespúšťalo.
• Chybové stavy. Chybová stránka musí naozaj vracať kód 404, nie kód 200 s textom o chybe – inak sa neexistujúce stránky hromadia v indexe.
• Verzia s www a bez www, http a https. Vždy má existovať jedna hlavná verzia a ostatné na ňu majú presmerovať.

Štruktúrované dáta a čitateľnosť pre AI systémy

Štruktúrované dáta sú strojovo čitateľný popis toho, čo na stránke je – že ide o článok, produkt, recept, podujatie alebo firmu s adresou a otváracími hodinami. Vyhľadávaču to uľahčí prácu a odmenou býva bohatšie zobrazenie vo výsledkoch. Pri audite kontrolujeme, či sú tieto údaje na stránke prítomné, či sú validné a hlavne či zodpovedajú tomu, čo je v texte. Označenie, ktoré tvrdí niečo iné než viditeľný obsah, je porušenie pravidiel a riziko, nie výhoda.

Odkedy odpovede skladajú aj jazykové modely, pribudla k tomu druhá otázka: dostane sa vôbec robot AI asistenta k obsahu? Odporúčame pozrieť sa do súboru robots.txt, či tam nie sú blokované roboty ako GPTBot, ClaudeBot alebo PerplexityBot. Nie je to univerzálne odporúčanie – niektorí majitelia webov ich blokovať chcú a je to legitímne rozhodnutie. Podstatné je, aby to bolo rozhodnutie, a nie vedľajší efekt skopírovaného nastavenia.

Technický audit nekončí zoznamom chýb. Končí vetou, ktorú vie klient povedať svojmu vývojárovi tak, aby presne vedel, čo má spraviť a prečo.

Ako výstup odovzdávame a čo v ňom klient nájde

Výstupom nie je export z nástroja. Nálezy prepisujeme do jazyka, ktorému rozumie aj netechnický majiteľ webu, a ku každému pridávame konkrétnu adresu alebo šablónu, ktorej sa týka, dôvod, prečo ide o problém, a odhad náročnosti opravy. Zvlášť oddeľujeme veci, ktoré sa dajú vyriešiť v administrácii, od tých, ktoré vyžadujú zásah do kódu alebo nastavení servera – klient tak hneď vidí, čo zvládne sám a na čo potrebuje vývojára.

Nálezy sú zoradené podľa pomeru dopadu a náročnosti. Hore stoja veci, ktoré blokujú indexovanie, potom rýchlosť a mobilná použiteľnosť, ďalej presmerovania a duplicity a nakoniec vylepšenia, ktoré sú užitočné, ale nič nezachraňujú. Pri väčších projektoch k tomu pridávame návrh, čo riešiť v prvom mesiaci a čo môže počkať na ďalší kvartál, aby sa práca dala rozložiť do rozpočtu.

Omyly, na ktoré pri technických auditoch narážame

Najčastejším omylom je viera, že technický audit je jednorazová záležitosť, po ktorej je web navždy v poriadku. Každá aktualizácia šablóny, každý nový doplnok a každá zmena v štruktúre obsahu môže vytvoriť nový problém – preto odporúčame krátku technickú kontrolu po každom väčšom zásahu, nie len raz ročne. Druhým omylom je snaha dosiahnuť stopercentné skóre v nástrojoch na meranie rýchlosti; posledné body sa vykupujú neúmerne veľkou prácou a používateľ ich nepocíti.

Tretí omyl sa týka rozsahu. Pri e-shopoch sa technický audit robí inak než pri firemnej prezentácii, pretože filtre, varianty a vypredané produkty tvoria vlastnú kategóriu problémov, ktorá sa na bežnom webe nevyskytuje. Ak riešite e-shop, prejdite si aj to, na čo sa pri jeho kontrole zamerať – postup z tohto článku pokrýva základ, ale nie špecifiká elektronického obchodu.

---

Často kladené otázky

Čo je technický SEO audit?

Technický SEO audit je kontrola dostupnosti webu pre vyhľadávač: indexovateľnosti, rýchlosti načítania, mobilnej verzie, presmerovaní a štruktúrovaných dát. Rieši predpoklady viditeľnosti, nie samotný obsah stránok.

Čím sa líši od obsahového auditu?

Technická časť zisťuje, či sa obsah k vyhľadávaču vôbec dostane. Obsahová časť hodnotí, čo v tom obsahu stojí a či odpovedá na to, čo ľudia hľadajú. V praxi sa robia spolu, ale opravuje ich zvyčajne niekto iný.

Ako dlho technický audit trvá?

Pri firemnom webe do niekoľkých stoviek stránok zvyčajne dva až päť pracovných dní. Pri rozsiahlom e-shope je to výrazne dlhšie, pretože samotný crawl a jeho vyhodnotenie zaberú niekoľko dní.

Aké nástroje sú na technický audit potrebné?

Google Search Console ako zdroj dát priamo od Googlu, crawler na prejdenie celého webu, nástroj na meranie Core Web Vitals a validátor štruktúrovaných dát. Nástroje však nálezy len nájdu – zoradiť ich podľa dopadu musí človek.

Čo je najčastejšia technická chyba na slovenských weboch?

Z našej praxe je to kombinácia neoptimalizovaných obrázkov a zabudnutých presmerovaní po redizajne. Vážnejšia, aj keď menej častá, je zabudnutá značka noindex prenesená z vývojovej verzie do ostrej prevádzky.

Musí mať web stopercentné skóre v teste rýchlosti?

Nie. Posledné body sa vykupujú neúmerne veľkou prácou a používateľ ich nepocíti. Odporúčame držať sa hodnotenia reálnych dát od používateľov v Search Console a laboratórne skóre brať len ako orientačné.

Ako často opakovať technickú kontrolu?

Po každom väčšom zásahu do webu – redizajne, migrácii, zmene šablóny alebo aktualizácii systému – a inak priebežne sledovaním chybových hlásení v Search Console. Plnohodnotný audit stačí raz ročne.

Zvládne technický audit majiteľ webu sám?

Základnú kontrolu áno – Search Console ukáže chyby indexovania aj problémy s rýchlosťou zrozumiteľne. Ťažšia je interpretácia: rozhodnúť, ktorý nález je kritický a ktorý je kozmetický, vyžaduje skúsenosť z viacerých projektov.

Prečo sa kontroluje najprv mobilná verzia?

Pretože Google hodnotí weby podľa mobilnej verzie. Ak je na mobile skrytá časť obsahu alebo sa stránka správa inak než na počítači, hodnotí sa to, čo vidí mobilný robot, nie desktopová verzia.

Čo nasleduje po technickom audite?

Opravy podľa poradia: najprv veci blokujúce indexovanie, potom rýchlosť a mobilná použiteľnosť, nakoniec presmerovania a duplicity. Až keď je technická vrstva v poriadku, má zmysel investovať do obsahu a odkazov.