Audit webu v roce 2026: kompletní checklist SEO, Core Web Vitals, přístupnosti a bezpečnosti

V roce 2026 je potřeba audit provádět ve vrstvách. Google stále staví viditelnost na technických základech a obsahu vytvořeném primárně pro lidi, i když výsledky mohou být zobrazovány také ve funkcích využívajících AI. Core Web Vitals je nutné hodnotit podle reálných uživatelských dat, přístupnost nelze potvrdit pouze skenerem a bezpečnost znamená mnohem víc než přítomnost SSL certifikátu.

Tento průvodce pokrývá celý proces: indexaci a SEO, LCP, INP a CLS, WCAG 2.2, bezpečnostní hlavičky, formuláře, analytiku i správné pořadí oprav.

TL;DR: začněte kritickými problémy: nedostupností webu, blokací indexace, chybnými přesměrováními, problémy s HTTPS a zranitelnostmi. Poté zlepšete Core Web Vitals, přístupnost hlavních uživatelských cest, obsah a interní prolinkování. Skóre 100/100 v jednom nástroji nenahrazuje data ze Search Console, testy na skutečných zařízeních ani ruční kontrolu.

Standardy, limity a zdroje byly naposledy ověřeny 23. července 2026.

Hlavní oblasti auditu

Oblast	Co zkontrolovat	Jak vypadá dobrý výsledek	Priorita
Indexace	robots.txt, noindex, sitemap, canonical, HTTP stavy	důležité stránky jsou dostupné a indexovatelné, duplicity sjednocené	kritická
SEO a obsah	záměr, titulky, nadpisy, interní odkazy, strukturovaná data	každá důležitá stránka má jasný účel a jedinečnou hodnotu	vysoká
Výkon	LCP, INP, CLS, TTFB, JavaScript, obrázky, fonty	CWV v pásmu „dobré“ na 75. percentilu	vysoká
Přístupnost	klávesnice, focus, sémantika, kontrast, formuláře, čtečky	hlavní cesty splňují WCAG 2.2 AA	vysoká
Bezpečnost	HTTPS, hlavičky, cookies, závislosti, autorizace, zálohy	žádné kritické zranitelnosti ani zbytečná expozice	kritická
UX a konverze	mobil, formuláře, navigace, chyby, důvěra	uživatel dokončí hlavní úkol bez zbytečných překážek	vysoká
Měření	Search Console, analytika, logy, monitoring	data jsou úplná, v souladu se soukromím a použitelná	střední

Co audit webu skutečně zahrnuje?

Kompletní audit kombinuje nejméně šest perspektiv:

1. Technické SEO - zda crawler dokáže web načíst, vykreslit, následovat odkazy a určit správnou kanonickou URL.
2. Kvalita obsahu - zda stránka odpovídá na skutečnou potřebu uživatele, má logickou strukturu a zbytečně neduplikuje jiné stránky.
3. Výkon - jak rychle se zobrazí hlavní obsah, jak rychle stránka reaguje a zda se během načítání neposouvá rozložení.
4. Přístupnost - zda lze službu používat klávesnicí, čtečkou obrazovky, při zvětšení a bez závislosti pouze na barvě.
5. Bezpečnost a soukromí - zda jsou komunikace, relace, formuláře, závislosti a data uživatelů dostatečně chráněny.
6. UX a obchodní cíle - zda návštěvníci rozumějí nabídce a mohou dokončit nejdůležitější akci bez zbytečných kroků.

Automatické nástroje jsou dobrým začátkem, ale nedokážou posoudit vše. Lighthouse může odhalit část problémů s výkonem a přístupností, nedokáže však určit, zda je nabídka srozumitelná, formulář odpovídá potřebám zákazníka nebo chybová zpráva skutečně pomáhá problém vyřešit. ^[4]

Než začnete: určete rozsah a vzorek URL

Nejčastější chybou je kontrolovat pouze domovskou stránku. V praxi je potřeba otestovat reprezentativní typy stránek:

• domovskou stránku,
• nejdůležitější stránku služby nebo produktu,
• článek či návod,
• kategorii nebo výpis,
• kontaktní formulář, registraci nebo checkout,
• stránku výsledků vyhledávání,
• jazykovou verzi,
• stránku 404 a další chybové stavy,
• stránku vyžadující přihlášení, pokud existuje.

U malého webu může stačit několik nebo desítka URL. U e-shopu, portálu či aplikace je nutné auditovat šablony, ne náhodné URL. Pokud má šablona produktu chybný canonical nebo načítá těžký skript, může problém ovlivnit tisíce stránek.

Před auditem si připravte:

• přístup do Google Search Console a analytiky,
• seznam nejdůležitějších obchodních cílů,
• sitemapu a hlavní šablony,
• informace o změnách, migracích a propadech návštěvnosti,
• data z monitoringu chyb a serverové logy,
• zařízení a prohlížeče nejčastěji používané zákazníky.

Audit technického SEO a indexace

Zkontrolujte HTTP stavy a varianty domény

Každá důležitá URL by měla vracet správný stav:

• 200 pro funkční stránku,
• 301 nebo 308 pro trvalé přesměrování,
• 404 nebo 410 pro odstraněný obsah,
• 5xx pouze při skutečné chybě serveru, ne jako trvalý stav.

Prověřte http/https, www/non-www, koncová lomítka a velikost písmen. Všechny varianty by měly vést na jednu konzistentní verzi. Vyhněte se řetězcům přesměrování a situacím, kdy mnoho starých URL směřuje na nesouvisející domovskou stránku.

Ověřte robots.txt, noindex a přístup k prostředkům

Soubor robots.txt řídí crawling na úrovni stahování, ale není mechanismem pro odstranění stránky z výsledků vyhledávání. Blokovaná URL se může stále objevit v indexu, pokud ji Google zná z jiných zdrojů. ^[5] Pro vyloučení použijte například noindex, ochranu heslem nebo odstranění zdroje.

Zkontrolujte, zda:

• důležité sekce nejsou omylem zablokované,
• testovací prostředí je skutečně zabezpečeno, ne jen skryto v robots.txt,
• Google může načíst CSS, JavaScript a obrázky potřebné pro rendering,
• sitemap je na správné adrese a obsahuje pouze kanonické stránky,
• po nasazení do produkce nezůstal tag noindex.

Posuďte canonicaly a duplicity

Kanonická URL označuje preferovanou verzi duplicitního nebo velmi podobného obsahu. Google považuje canonical za silný signál, může však zvolit jinou URL, pokud jsou ostatní signály nekonzistentní. ^[6]

Kontrolujte soulad mezi:

• rel="canonical",
• přesměrováními,
• interními odkazy,
• XML sitemapami,
• jazykovými verzemi,
• protokolem a hostem.

Canonical by měl zpravidla směřovat na funkční URL se stavem 200, ne na chybu, přesměrování nebo URL s noindex.

Zkontrolujte vykreslování JavaScriptu

Google zpracovává JavaScriptové aplikace ve fázích: crawling, rendering a indexace. ^[7] Obsah vytvářený na klientovi může být zpracován později než okamžitě dostupné HTML, proto by kritické informace a odkazy neměly záviset na křehkém skriptu.

U SPA a hybridních služeb kontrolujte:

• HTML dostupné před spuštěním JavaScriptu,
• odkazy jako skutečné prvky <a href>,
• práci se stavovými kódy,
• metadata generovaná pro každou URL,
• chování při přímém otevření podstránky,
• hydration chyby a neúspěšná API volání,
• indexovatelnost stránkování a infinite scrollu.

Zkontrolujte jazykové verze

Na vícejazyčném webu by každá verze měla mít vlastní stabilní URL. Ověřte:

• platné atributy hreflang,
• vzájemné odkazy mezi verzemi,
• volitelné x-default,
• canonical na stejnou jazykovou verzi,
• žádná automatická přesměrování blokující crawlery,
• přeložené titulky, popisy, obsah a navigaci.

Checklist technického SEO

• Důležité URL vracejí 200.
• Přesměrování jsou jednostupňová a logická.
• Neexistují náhodné blokace v robots.txt.
• Produkce neobsahuje nechtěný noindex.
• XML sitemap obsahuje pouze kanonické URL.
• Canonicaly, odkazy a sitemap jsou konzistentní.
• JavaScript neskrývá kritický obsah před crawlery.
• Stránky 404 vracejí skutečný stav 404.
• Jazykové verze správně používají hreflang.
• Parametry a filtry nevytvářejí masové duplicity.

Audit obsahu a on-page SEO

Každá stránka by měla mít jeden hlavní cíl

Title, H1, úvod, obsah a výzva k akci by měly odpovídat stejnému záměru. Pokud se jedna stránka snaží současně prodávat službu, vysvětlovat základní pojmy a rankovat na řadu nesouvisejících dotazů, obvykle nedělá dobře ani jedno.

Zkontrolujte:

• zda je title jedinečný a popisný,
• zda hlavní H1 odpovídá obsahu,
• zda snippet ve výsledcích láká ke kliknutí bez přehnaných slibů,
• zda H2 a H3 vytvářejí logickou strukturu,
• zda odpověď přichází brzy, ne až po dlouhém úvodu,
• zda článek ukazuje zkušenost, příklady a zdroje,
• zda datum aktualizace odpovídá reálné změně.

Google doporučuje užitečný a důvěryhodný obsah vytvořený primárně pro lidi, nikoli stránky určené pouze k manipulaci s pořadím. ^[1]

Interní odkazy by měly vytvářet strukturu

Dobré interní prolinkování pomáhá uživateli pokračovat a ukazuje vyhledávači vztahy mezi tématy. Používejte popisné anchor texty místo mnoha obecných odkazů „klikněte zde“.

Přirozené návaznosti z tohoto článku:

• Kontrola stavu webu POLPROG,
• Core Web Vitals v praxi,
• Webová strategie,
• Výkon,
• Bezpečnost,
• Jak naplánovat firemní web, který generuje poptávky.

Hledejte také osiřelé stránky, na které nevede žádný interní odkaz.

Obrázky, strukturovaná data a Open Graph

Obrázky by měly mít smysluplné názvy, vhodné rozměry a alternativní text, pokud předávají informaci. Čistě dekorativní obrázek obvykle používá prázdné alt="". Google podporuje běžné formáty včetně JPEG, PNG, WebP, SVG a AVIF. ^[8]

Prověřte:

• width a height pro omezení posunů rozložení,
• srcset a sizes,
• kompresi a formát,
• lazy loading pod prvním viewportem,
• alternativní text,
• strukturovaná data odpovídající viditelnému obsahu,
• og:title, og:description, og:image a og:url.

K praktické kontrole použijte Konvertor a optimalizátor obrázků a Náhled Open Graph.

SEO ve vyhledávání využívajícím AI

Google uvádí, že pro AI funkce ve vyhledávání nadále platí základní SEO postupy. ^[9] Není potřeba přidávat speciální soubory ani nový markup jen kvůli AI Overviews či AI Mode. Stránka musí být indexovatelná a splňovat běžné požadavky Search.

Nejrozumnější strategie:

• publikovat jasné a úplné odpovědi,
• používat zdroje a praktické příklady,
• aktualizovat rychle se měnící informace,
• vyhýbat se masově generovanému opakujícímu se obsahu,
• udržovat sémantickou strukturu a interní odkazy,
• sledovat návštěvnost a dotazy v Search Console.

Core Web Vitals a výkon

Aktuální limity

Core Web Vitals tvoří tři metriky. Hodnocení se provádí na 75. percentilu reálných návštěv, zvlášť pro mobilní zařízení a desktop. ^[2]

Metrika	Co měří	Dobré	Vyžaduje zlepšení	Špatné
LCP	zobrazení největšího prvku obsahu	≤ 2,5 s	2,5-4,0 s	> 4,0 s
INP	zpoždění reakce na interakce	≤ 200 ms	200-500 ms	> 500 ms
CLS	vizuální stabilitu rozložení	≤ 0,1	0,1-0,25	> 0,25

Terénní data ukazují zkušenost skutečných uživatelů, laboratorní data pomáhají problém reprodukovat. ^[2] Nezaměňujte je. Web může mít dobrý lokální Lighthouse, ale špatný INP na starších telefonech nebo pomalý LCP v konkrétní zemi.

Jak zlepšit LCP

Časté příčiny:

• pomalý server nebo chybějící cache,
• příliš velký hero obrázek,
• LCP zdroj objevený až JavaScriptem,
• CSS a fonty blokující rendering,
• dlouhé řetězce požadavků,
• náročná logika před vykreslením.

Opatření:

• zlepšit TTFB a cache,
• dodávat obrázek ve správných rozměrech,
• použít moderní formát a kompresi,
• prioritizovat hlavní zdroj,
• nepoužívat lazy loading pro LCP obrázek,
• omezit kritické CSS a skripty,
• použít CDN, pokud skutečně zkrátí cestu k uživateli.

Jak zlepšit INP

INP zhoršují dlouhé úlohy na hlavním vlákně, nadbytečný JavaScript, drahé renderování komponent a obsluha událostí vykonávající příliš mnoho práce.

Zkontrolujte:

• délku úloh v panelu Performance,
• skripty třetích stran,
• komponenty renderované po každé změně,
• velké seznamy bez virtualizace,
• synchronní operace s pamětí a DOM,
• validaci formulářů a animace během interakce.

Dlouhé úlohy rozdělte, nekritickou práci odložte a posílejte do prohlížeče co nejméně JavaScriptu.

Jak zlepšit CLS

Časté zdroje posunů:

• obrázky a iframe bez rozměrů,
• reklamy bez rezervovaného prostoru,
• cookie lišty vložené nad obsah,
• pozdě načtené fonty,
• komponenty přidané před existující obsah,
• animace vlastností ovlivňujících layout.

Rezervujte prostor, používejte stabilní placeholdery a testujte celý průběh načítání, ne pouze finální snímek.

Neoptimalizujte jen skóre Lighthouse

Lighthouse je laboratorní test v kontrolovaných podmínkách. ^[4] Kvalitní proces kombinuje:

• Search Console a report Core Web Vitals,
• data CrUX nebo RUM,
• Lighthouse a panel Performance,
• testy na pomalejším zařízení,
• monitoring regresí po nasazení.

Audit přístupnosti podle WCAG 2.2

WCAG 2.2 popisuje kritéria testovatelná kombinací automatického a lidského hodnocení. Samotný skener nemůže potvrdit plnou shodu, protože část kritérií vyžaduje posouzení kontextu a interakcí. ^[3]

Klávesnice a focus

Projděte klíčovou cestu bez myši:

• je dostupný každý interaktivní prvek,
• je pořadí focusu logické,
• je indikátor focusu jasně viditelný,
• drží modal focus uvnitř a vrací ho po zavření,
• neexistuje klávesnicová past,
• lze přeskočit opakovanou navigaci.

Sémantika a čtečky obrazovky

Zkontrolujte:

• jedno logické H1 a správnou hierarchii nadpisů,
• landmarky header, nav, main a footer,
• skutečná tlačítka a odkazy místo klikacích div,
• přístupné názvy ikon,
• oznámení dynamických změn,
• správné pořadí čtení,
• jazyk dokumentu v atributu lang.

ARIA má sémantické HTML doplňovat, ne bezdůvodně nahrazovat.

Formuláře a chyby

Každé pole má mít viditelný popisek a programové propojení s popisem. Chyba musí vysvětlit, co opravit, a nesmí být sdělena pouze barvou.

Otestujte:

• popisky a instrukce,
• povinná pole,
• autocomplete atributy,
• pořadí tabulátoru,
• chybové zprávy,
• souhrn chyb po odeslání,
• chování při zvětšení a na úzkém displeji,
• časové limity a možnost prodloužení.

Kontrast, zvětšení a pohyb

Kontrolujte kontrast textu, ikon a stavů focusu. Testujte při zvětšení 200 % a 400 %, s větším textem a v úzkém viewportu. Obsah by neměl vyžadovat horizontální scroll, pokud to není funkčně nutné. ^[3]

Animace mají respektovat prefers-reduced-motion a automaticky se pohybující obsah musí být možné zastavit, pokud ovlivňuje porozumění.

Checklist přístupnosti

• Celá cesta funguje klávesnicí.
• Focus je viditelný a logický.
• Nadpisy a landmarky popisují strukturu.
• Tlačítka a odkazy mají srozumitelné názvy.
• Formuláře mají popisky a užitečné chyby.
• Kontrast splňuje WCAG 2.2 AA.
• Obsah funguje při zvětšení a reflow.
• Informační obrázky mají vhodný alternativní text.
• Pohyb lze omezit.
• Hlavní úkoly byly otestovány čtečkou obrazovky.

Audit bezpečnosti a soukromí

HTTPS je začátek, ne konec

Celý web má fungovat přes HTTPS bez aktivního mixed content. Zkontrolujte platnost certifikátu, řetězec důvěry, podporované protokoly, automatické obnovování a přesměrování z HTTP na HTTPS. Lighthouse označí stránky bez HTTPS, ale neprovádí plný penetrační test. ^[10]

Doménu a certifikát lze prověřit pomocí Inspektoru DNS a SSL.

Bezpečnostní hlavičky

Hlavičky neopraví chybnou autorizaci, ale omezují některé typy útoků a nebezpečné chování prohlížeče. OWASP Secure Headers Project udržuje aktuální doporučení a příklady. ^[11]

Zkontrolujte minimálně:

• Content-Security-Policy,
• Strict-Transport-Security,
• X-Content-Type-Options: nosniff,
• Referrer-Policy,
• Permissions-Policy,
• ochranu proti vložení pomocí frame-ancestors,
• bezpečné atributy cookies: Secure, HttpOnly a vhodné SameSite.

CSP zavádějte postupně: začněte Content-Security-Policy-Report-Only, vyhodnoťte reporty a teprve poté zásady vynucujte. Zkopírovanou konfiguraci přizpůsobte skutečně používaným zdrojům.

Pro rychlou kontrolu použijte Inspektor bezpečnostních hlaviček.

OWASP Top 10:2025 jako mapa rizik

OWASP Top 10:2025 zahrnuje chyby řízení přístupu, bezpečnostní misconfiguraci, selhání softwarového dodavatelského řetězce, kryptografické chyby, injection, nebezpečný návrh, chyby autentizace, problémy integrity, nedostatky logování a alertingu a nesprávnou práci s výjimečnými stavy. ^[12]

Prakticky ověřte:

• zda uživatel může číst nebo měnit data jiného uživatele,
• zda má administrační panel další ochranu,
• zda API kontroluje oprávnění na serveru,
• zda se aktualizují závislosti a kontejnerové obrazy,
• zda tajemství nejsou v repozitáři ani klientském kódu,
• zda jsou vstupy validovány a výstupy kódovány,
• zda relace expirují a lze je zrušit,
• zda logy neobsahují hesla, tokeny nebo citlivá data,
• zda chyby nesdělují stack trace a detaily infrastruktury,
• zda existují zálohy a byl otestován restore.

U aplikací s přihlášením, platbami nebo zákaznickými daty definujte rozsah pomocí OWASP ASVS, ne jen krátkého seznamu hlaviček. ^[13]

Soukromí a analytika

Kontrolujte:

• které skripty se spouštějí před souhlasem,
• zda formuláře sbírají jen nutná data,
• dobu uchování,
• přístup zaměstnanců a dodavatelů,
• možnost souhlas odvolat,
• konfiguraci Consent Mode, pokud se používá,
• logování IP adres a identifikátorů,
• soulad zásad ochrany soukromí se skutečným chováním.

Nepředpokládejte, že cookie banner automaticky zajišťuje soulad. Rozhoduje, co web skutečně načítá a odesílá.

UX, mobil a konverze

Technický audit může dopadnout dobře, přesto web nemusí plnit svůj cíl. Projděte hlavní cestu jako nový uživatel:

• je z první obrazovky jasné, co firma dělá,
• popisuje každé CTA konkrétní akci,
• je navigace srozumitelná bez hádání,
• formulář vyžaduje jen nutné informace,
• lze chyby snadno opravit,
• jsou telefon a e-mail klikatelné na mobilu,
• prvky se nepřekrývají,
• pop-upy nechávají obsah použitelný,
• jsou úspěšné stavy jednoznačné,
• funguje web při pomalém připojení a neúspěšných požadavcích.

Testujte také stránku 404, prázdné výsledky, nedostupný produkt nebo službu, vypršelou relaci a neúspěšnou platbu. Výjimečné stavy často rozhodují, zda se uživatel vrátí.

Pro weby zaměřené na poptávky: Jak naplánovat firemní web, který generuje poptávky.

Měření, monitoring a kvalita dat

Search Console ukazuje výkon webu ve vyhledávání Google, analytika chování po příchodu. Kombinace obou perspektiv pomáhá odlišit problém viditelnosti od problému konverze. ^[14]

Zkontrolujte:

• zda vlastnost Search Console pokrývá správnou variantu domény,
• chyby indexace a ruční zásahy,
• dotazy, stránky, země a zařízení,
• změny kliknutí a zobrazení po nasazení,
• úplnost analytických událostí,
• vyloučení interní návštěvnosti a botů,
• správnost konverzního trychtýře,
• upozornění na JavaScriptové a serverové chyby,
• monitoring dostupnosti a certifikátu.

Neopravujte vše současně bez výchozího stavu. Zaznamenejte baseline a nasazujte změny po skupinách, abyste mohli měřit dopad.

Jak dlouho audit trvá?

Následující hodnoty jsou praktické odhady, nikoli oficiální standard. Rozsah závisí na počtu šablon, přístupu k datům, technologii a riziku.

Rozsah	Orientační čas	Co zahrnuje
Rychlá kontrola jednoho URL	15-30 min	stav, metadata, základní CWV, HTTPS a hlavní chyby
Malý firemní web	2-6 hodin	vzorek, SEO, CWV, přístupnost, bezpečnost a UX
Obsahový nebo vícejazyčný web	1-3 dny	šablony, indexace, hreflang, odkazy, data a priority
E-shop	3-7 dní	kategorie, produkty, filtry, checkout, strukturovaná data a výkon
Webová aplikace	5-10+ dní	role, autorizace, procesy, API, chybové stavy a ruční testy
Bezpečnostní audit vysokého rizika	samostatný rozsah	threat modeling, ASVS, aplikační a infrastrukturní testy

Cena roste méně s počtem URL než s počtem různých chování. Tisíc produktů na jedné šabloně může být jednodušší než aplikace s deseti rolemi a mnoha stavy.

Jak prioritizovat opravy?

Použijte jednoduchý model: dopad × dosah × riziko ÷ náklady implementace.

P0 - opravit okamžitě

• web nebo kritická funkce není dostupná,
• důležité sekce jsou blokovány před indexací,
• únik dat nebo obejití autorizace,
• expirovaný certifikát či aktivní mixed content,
• migrace vytváří masové chyby a ztracené URL,
• formulář nedoručuje poptávky.

P1 - vysoká priorita

• špatné CWV na nejdůležitějších šablonách,
• závažné bariéry klávesnice a formulářů,
• chybné canonicaly nebo hreflang,
• nesrozumitelná nabídka a obtížná konverze,
• kritické neaktualizované závislosti,
• chybějící monitoring důležitých chyb.

P2 - naplánovat do dalšího cyklu

• duplicitní titulky a slabé interní odkazy,
• chybějící alternativní texty,
• těžké obrázky pod prvním viewportem,
• nekonzistentní strukturovaná data,
• slabé 404 a prázdné stavy,
• problémy méně navštěvovaných šablon.

P3 - optimalizace a rozvoj

• další strukturovaná data,
• další snížení hmotnosti,
• experimenty s texty a CTA,
• rozšíření obsahu,
• úklid komponent a dokumentace.

Plán oprav na 30, 60 a 90 dní

Prvních 30 dní

Vyřešte P0, indexaci, přesměrování, HTTPS, formuláře a rizika ztráty dat. Nastavte výchozí měření.

Do 60 dní

Pracujte na nejdůležitějších šablonách: Core Web Vitals, klávesnice, formuláře, obsah, interní odkazy a bezpečnost aplikace. Zaveďte monitoring regresí.

Do 90 dní

Vylepšete méně kritické šablony, standardizujte publikaci, přidejte automatické testy do CI a naplánujte opakované audity po velkých releasech.

Kompletní checklist před uzavřením auditu

SEO a indexace

• Crawlery mohou načíst důležité stránky a zdroje.
• XML sitemap je aktuální.
• Canonicaly, přesměrování a odkazy jsou konzistentní.
• Neexistuje nechtěný noindex.
• Důležité stránky mají unikátní title, H1 a obsah.
• Interní odkazy vedou na obchodně důležité stránky.
• Jazykové verze správně používají hreflang.
• Strukturovaná data odpovídají viditelnému obsahu.
• Open Graph metadata jsou kompletní.

Výkon

• LCP, INP a CLS splňují limity v reálných datech.
• LCP obrázek má správné rozměry a prioritu.
• JavaScript neblokuje interakce.
• Obrázky mají rozměry a vhodný formát.
• Fonty a kritické zdroje nevytvářejí zbytečné zpoždění.
• Výsledky se po nasazení monitorují.

Přístupnost

• Web funguje bez myši.
• Focus je viditelný.
• Sémantika a pořadí nadpisů jsou logické.
• Formuláře mají popisky a užitečné chyby.
• Kontrast a reflow splňují WCAG 2.2 AA.
• Rozhraní bylo otestováno čtečkou obrazovky.

Bezpečnost a soukromí

• HTTPS funguje všude a certifikát je monitorován.
• Session cookies mají bezpečné atributy.
• Hlavičky jsou přizpůsobeny aplikaci.
• Oprávnění se kontrolují na serveru.
• Závislosti a tajemství jsou řízeny.
• Logy a alerty umožňují reakci.
• Zálohy byly otestovány.
• Trackovací skripty respektují souhlas.

UX a obchod

• Nabídka je srozumitelná bez čtení celé stránky.
• CTA vedou ke správné akci.
• Formuláře a checkout fungují na mobilu.
• Chybové stavy pomáhají uživateli.
• Události a konverze se měří správně.
• Každá oprava má vlastníka, prioritu a termín.

Jak používat Kontrolu stavu webu POLPROG

Kontrola stavu webu umožňuje zahájit audit z jedné URL a zkontrolovat SEO, výkon, přístupnost, bezpečnost a best practices. Testy běží na serveru a nevyžadují registraci. ^[15]

Doporučený postup:

1. Proskenujte domovskou stránku a každou důležitou šablonu.
2. Zapište kritické chyby a opakující se vzory.
3. Potvrďte CWV reálnými uživatelskými daty.
4. Ručně otestujte klávesnici, formuláře a hlavní cesty.
5. Samostatně prověřte bezpečnostní hlavičky, DNS a SSL a Open Graph.
6. Prioritizujte backlog podle dopadu a rizika.
7. Po implementaci test zopakujte a sledujte regrese.

Závěr

Nejlepší audit webu v roce 2026 nekončí dokumentem se stovkou upozornění. Končí krátkým, seřazeným seznamem akcí, který odděluje kritické problémy od kosmetických, přiřazuje odpovědnost a umožňuje výsledek po implementaci ověřit.

Nejprve zajistěte, že je web dostupný, indexovatelný a bezpečný. Poté zlepšete hlavní uživatelské cesty, Core Web Vitals a přístupnost. Teprve potom optimalizujte detaily. Toto pořadí obvykle přináší více hodnoty než honba za dokonalým skóre v jednom skeneru.