Co zkontrolovat před spuštěním webu

Nejdřív si společně řekněte, co pro tento web znamená „hotovo“

Před spuštěním se snadno vytvoří dlouhý seznam drobností, na kterém dostane překlep v patičce stejnou váhu jako nefunkční objednávka. Kontrola pak vypadá důkladně, ale nikdo neví, které nálezy opravdu brání publikaci. Začněte proto návratem k účelu webu: kdo na něj přijde, co potřebuje udělat a která chyba by mu v tom úplně zabránila.

Vyberte tři až sedm hlavních situací. U prezentačního webu to může být nalezení služby, ověření důvěryhodnosti firmy a odeslání poptávky. U e-shopu přidejte hledání produktu, košík, platbu a potvrzení objednávky. U klientské zóny bude kritické přihlášení, obnova přístupu a práce s vlastním účtem. Tyto cesty musí projít celé. Nestačí, že každá jejich obrazovka zvlášť vypadá správně.

U každého otevřeného bodu napište, kdo rozhoduje, kdo jej opraví a podle čeho se oprava pozná. Pokud je potřeba přijmout známé riziko, má jej vědomě přijmout člověk odpovědný za web, ne vývojář pod časovým tlakem. Dobré zadání nového webu by už mělo obsahovat cíle a kritéria hotového výsledku. Před spuštěním je jen převádíte do konkrétní kontroly.

Projděte web jako návštěvník, ne jako člověk, který zná jeho zákulisí

Tvůrce webu ví, kde se co skrývá, a podvědomě se vyhne slepým uličkám. Ke kontrole proto přizvěte někoho, kdo projekt nezná tak důvěrně. Dejte mu obyčejné zadání: „Najděte službu pro svou situaci a zeptejte se na cenu.“ Neříkejte mu, na které tlačítko má kliknout. Sledujte, kde váhá, co přehlédne a co chápe jinak, než tým očekával.

Každou hlavní cestu vyzkoušejte alespoň na telefonu a počítači, v běžných podporovaných prohlížečích a jednou v anonymním okně bez přihlášené redakční relace. Zkontrolujte nejen ideální průchod, ale i chybu: neplatný údaj ve formuláři, prázdný výsledek hledání, neexistující stránku nebo odmítnutou platbu v bezpečném testovacím režimu. Člověk musí pochopit, co se stalo a jak může pokračovat.

• Menu, logo, drobečková navigace, vyhledávání a odkazy v obsahu vedou na očekávaná místa.
• Formulář zachová správně vyplněné údaje, srozumitelně označí chybu a po úspěchu potvrdí další postup.
• E-maily a další oznámení skutečně dorazí, mají správného odesílatele a neobsahují zkušební texty ani neplatné odkazy.
• Přihlášení, odhlášení a obnova přístupu fungují v celém průchodu, ne pouze na první obrazovce.
• Stránka 404 člověku poctivě řekne, že obsah chybí, a nabídne užitečnou cestu dál.

Výsledek zapisujte jako situaci, ne jako dojem. „Na telefonu nelze po otevření menu přejít klávesnicí na Kontakt“ se dá zopakovat a ověřit. Poznámka „menu je divné“ se mezi designérem, vývojářem a zadavatelem rychle ztratí.

Přečtěte obsah tam, kde se skutečně zobrazí

Text schválený v dokumentu ještě nemusí fungovat v úzké kartě, na mobilu ani vedle tlačítka. Projděte proto web stránku po stránce, ideálně s člověkem odpovědným za obsah. Hledejte nejen překlepy, ale také staré názvy služeb, neurčité výzvy, nedokončené odstavce, prázdné kategorie a místa, kde návštěvník neví, co udělat dál.

Zvláštní pozornost si zaslouží údaje, podle kterých lidé jednají: telefon, e-mail, adresa, otevírací doba, cena, termín, podmínky a jména odpovědných osob. Každý kontakt opravdu vyzkoušejte. U souborů ke stažení ověřte jejich obsah, datum, čitelný název a velikost. U obrázků zkontrolujte oprávnění k použití, vhodné ořezy a textové alternativy. Zkušební fotografie ani výplňový text nemají v produkci co dělat.

Telefon a klávesnice odhalí potíže, které velký monitor schová

Responzivní náhled v prohlížeči je užitečný, ale alespoň hlavní cesty projděte také na skutečném telefonu. Zkuste pomalejší připojení, otočení obrazovky, otevřenou softwarovou klávesnici a delší skutečný text. Tlačítka nesmějí být schovaná pod lištou, cookie oznámením ani klávesnicí. Tabulky, mapy a galerie potřebují použitelné chování i na úzké obrazovce.

Potom odložte myš a projděte stejnou cestu klávesnicí. Fokus má být vidět, pořadí má dávat smysl a z menu, dialogu nebo vloženého prvku musí jít odejít. Zvětšete stránku na 200 %, odešlete chybně vyplněný formulář a zkontrolujte, zda význam nezávisí jen na barvě. W3C upozorňuje, že podobná rychlá kontrola odhalí pouze část bariér. Ani dobrý automatický výsledek není úplným posouzením přístupnosti.

Podrobný a stále praktický postup nabízí průvodce prvními kroky k přístupnějšímu webu. Pro spuštění je nejdůležitější, aby přístupnost nebyla samostatná položka na konci projektu: projděte s ní stejné nákupní, kontaktní a přihlašovací situace jako při běžném funkčním testu.

Rychlost měřte na několika skutečných typech stránek

Homepage bývá nejvíc opečovávaná, ale návštěvník může přijít rovnou na detail služby, článek nebo produkt. Vyberte reprezentativní vzorek každé hlavní šablony a přidejte stránku s největším obrázkem, nejdelším seznamem a nejvíce interakcemi. Laboratorní test pomůže před spuštěním odhalit regresi. Data skutečných návštěvníků budou k dispozici až postupně po zveřejnění.

Nedívejte se jen na jedno souhrnné skóre. Všímejte si, zda se brzy objeví hlavní obsah, zda stránka pohotově reaguje a zda prvky při načítání neposkakují. Zároveň ji normálně použijte na běžném telefonu. Pokud hero obrázek vypadá krásně v kanceláři, ale na mobilní síti oddálí smysluplný obsah, technický report je pouze stopa k tomu, co už člověk pocítil.

Hranice LCP, INP a CLS, rozdíl mezi laboratoří a terénem i rozumné pořadí oprav popisuje samostatný průvodce rychlostí webu a Core Web Vitals. Před spuštěním si uložte výchozí měření, aby bylo s čím porovnat další nasazení.

Vyhledávačům neposílejte protichůdné zprávy

U nového webu zkontrolujte, zda mají veřejné stránky správný název, popis, jazyk, vlastní preferovanou URL a běžné interní odkazy. Dočasné zákazy indexace použité při vývoji nesmějí zůstat na produkčních stránkách. XML sitemapa má obsahovat kanonické indexovatelné adresy s úspěšnou odpovědí, nikoliv přesměrování, chyby a neveřejné náhledy. Přístup k Search Console musí být připravený pro skutečného vlastníka webu, ne pouze pro osobní účet dodavatele.

Pokud nový web nahrazuje starý a mění URL, samostatnou podmínkou spuštění je schválená mapa starých a nových adres. Otestujte nejnavštěvovanější stránky, důležité externí odkazy, soubory i obsah bez náhrady. Staré adresy mají vést přímo na nejbližší odpovídající cíl. Hromadné posílání všeho na homepage lidem nepomůže.

• Canonical, interní odkazy, sitemapa a případná přesměrování ukazují na stejnou preferovanou podobu URL.
• Indexovatelné stránky nejsou omylem označené noindex ani skryté za přihlášením.
• Sitemapa je dostupná, aktuální a připravená k odeslání v Search Console.
• Staré i nové adresy byly otestované přes celý řetězec až ke konečné odpovědi.

Podrobnosti mají vlastní návody: canonical, noindex a indexace, XML sitemapa a při nahrazování starého webu také migrace a přesměrování. Checklist je má propojit do jednoho rozhodnutí, ne je celé opakovat.

Bezpečnost neověřujte až na veřejném webu

Před spuštěním potvrďte, že produkce neobsahuje zkušební účty, diagnostické obrazovky, zálohy ani jiné soubory, které návštěvník nepotřebuje. Administrace a citlivé akce mají být přístupné jen oprávněným lidem. Otestujte přihlášení, odhlášení, obnovu přístupu, omezení rolí, expiraci relace a chování po opakované chybě. Bezpečnostní testy provádějte jen v dohodnutém rozsahu a na systému, k němuž máte oprávnění.

Prověřte také, jaká data formuláře a měření sbírají, proč je potřebujete, kam se doručují a kdo k nim má přístup. Souhlasy a právní texty musí odpovídat skutečnému chování webu. Univerzální text z jiného projektu tuto kontrolu nenahradí. U plateb, osobních údajů nebo klientské zóny přizvěte podle rizika bezpečnostního a právního odborníka.

Pro konkrétní technická témata navazují průvodce bezpečnostními HTTP hlavičkami a ochranou systémových souborů. Bezpečnostní hlavičky jsou obranná vrstva, ne důkaz bezpečného webu. OWASP stejně tak doporučuje zařazovat bezpečnostní testování průběžně do vývoje a věnovat omezený čas rizikům s největším skutečným dopadem.

Den spuštění potřebuje vlastníka, pořadí a možnost návratu

Sepište krátký plán, kterému rozumí i člověk, jenž jej nevytvářel. Určete čas spuštění, osobu s rozhodovací pravomocí, člověka provádějícího publikaci a kontakty na ty, kteří ověří obsah, objednávky, formuláře a měření. Naplánujte změnu na dobu, kdy jsou tito lidé opravdu dostupní. Tichý pátek večer není výhoda, pokud se při potížích nikomu nedovoláte.

1. 01

   Uložte výchozí stav

   Mějte seznam kritických URL, funkční kontrolní scénáře, schválený obsah a poslední známý dobrý výsledek testů.

2. 02

   Ověřte návrat

   Záloha je užitečná pouze tehdy, když víte, co obsahuje, kdo k ní má oprávněný přístup a jak dlouho bezpečný návrat potrvá.

3. 03

   Spouštějte po ověřitelných krocích

   Po každé zásadní změně zkontrolujte dostupnost a hlavní cestu místo toho, abyste všechny kroky provedli naslepo najednou.

4. 04

   Rozhodujte podle předem daných hranic

   Domluvte, které chyby se opravují za provozu a při kterých je bezpečnější vrátit poslední funkční verzi.

5. 05

   Zapište skutečný výsledek

   Poznamenejte čas, provedené změny, nalezené odchylky a vlastníky další práce. Předání pak nestojí na paměti jednoho člověka.

První načtená homepage ještě neznamená, že je spuštění u konce

Bezprostředně po zveřejnění zopakujte krátkou kontrolu hlavních cest z jiné sítě a bez přihlášení. Sledujte chyby aplikace, nedostupné stránky, nečekané přesměrování, doručování formulářů, objednávky a základní provozní signály. U migrace kontrolujte také požadavky na staré URL a vývoj indexace. Některé problémy se projeví až se skutečnými návštěvníky, různými zařízeními a obsahem, který testovací tým neotevřel.

Monitoring není jen obrazovka s grafy. Každé upozornění musí mít příjemce, srozumitelnou prioritu a domluvenou reakci. První intenzivní kontrolu naplánujte na hodiny po spuštění, další na následující pracovní dny a týdny podle významu webu. Výkon v terénních datech se navíc skládá postupně, takže jej nelze po několika návštěvách definitivně vyhodnotit.

Dobré spuštění přirozeně pokračuje předáním webu

Ještě během závěrečné kontroly vznikají informace, které bude provozovatel potřebovat: kdo vlastní doménu a externí služby, kdo spravuje uživatele, kde se hlásí chyba, jak probíhají aktualizace, co se sleduje a které body zůstaly otevřené. Shromážděte je průběžně. Předání na poslední schůzce nemá být lovem hesel ani pokusem vzpomenout si, proč bylo něco nastavené určitým způsobem.

Web si nechte předvést v rolích, které bude tým skutečně používat. Editor by měl umět publikovat běžný obsah bez obcházení pravidel, odpovědný člověk přidat nebo odebrat uživatele a vlastník projektu poznat, kam se obrátit při výpadku. Osobní účty dodavatele nahraďte vlastnictvím organizace a každému ponechte jen potřebná oprávnění. Přístupové údaje předávejte bezpečným dohodnutým kanálem, ne jako přílohu společného dokumentu.

Na tuto poslední část navazuje průvodce jak správně převzít hotový web. Checklist uzavírá spuštění, předání zase vytváří podmínky pro to, aby web zůstal použitelný, aktualizovaný a pod kontrolou i poté, co realizační tým odejde.