Jak na technický audit webu nebo aplikace

Každý web nebo aplikace časem stárne. Ne nutně vzhledem, ale technicky. Přibývají nové funkce, mění se formuláře, pluginy, integrace, hosting, infrastruktura i lidé kolem projektu. Některá původní rozhodnutí postupně přestávají dávat smysl. Část těchto změn je vidět hned. Velká část ale zůstává schovaná.

Proto dává smysl jednou za čas udělat technický audit. Ne až ve chvíli, kdy projekt spadne nebo se nikdo neodváží nasadit další změnu, ale ideálně dřív, dokud projekt funguje a je prostor řešit problémy v klidu.

Kdy technický audit dává smysl

Technický audit se hodí hlavně u projektů, které už nějakou dobu běží a postupně se vyvíjí. Časem přibývají nové funkce, úpravy, pluginy, integrace nebo rychlá rozhodnutí, která mohou z projektu udělat méně přehledný a hůř udržovatelný systém.

Nejčastěji dává audit smysl před větší úpravou, redesignem, migrací na novější infrastrukturu, převzetím projektu po jiném dodavateli nebo před převzetím do dlouhodobé správy. Pomůže i ve chvíli, kdy není úplně jasné, jestli fungují zálohy, jak probíhá nasazování nové verze, kdo má k čemu přístup nebo kde jsou největší technická rizika.

Audit ale nemusí být jen reakcí na konkrétní problém. Často pomáhá majiteli projektu získat přehled o tom, v jakém technickém stavu se jeho web nebo aplikace nachází. Díky tomu lze lépe plánovat další investice, odhadnout budoucí náklady a včas zachytit místa, která by později mohla brzdit rozvoj projektu nebo zbytečně prodražit jeho údržbu.

Co při auditu kontroluji

Technický audit není jen kontrola kódu, pluginů nebo rychlosti webu. Dívám se na projekt jako na celek: jak je postavený, jak se provozuje, kde má slabá místa a co může mít dopad na bezpečnost, výkon, viditelnost ve vyhledávačích, údržbu nebo další vývoj.

Začínám u provozních základů. Kontroluji infrastrukturu, způsob nasazování, staging prostředí, oddělení produkčních a testovacích konfigurací, přístupy, zálohy a obnovu projektu při chybě nebo výpadku. Právě tady se často ukáže, jestli je projekt dobře spravovatelný, nebo jestli je každá větší změna zbytečné riziko.

Častým problémem bývá i nevhodně zvolený hosting. Řada webů a aplikací v Česku stále běží na řešení, které bylo vybrané hlavně podle ceny. To může stačit na začátku, ale u rostoucího projektu začne slabá infrastruktura brzdit výkon, spolehlivost, nasazování, zálohování, logování i další technický rozvoj.

Dívám se také na monitoring a práci s chybami. Nestačí, že aplikace „nějak běží“. Je potřeba vědět, co se stane při chybě platby, rezervace, synchronizace, cron úlohy, odeslání e-mailu nebo napojení na externí službu. Tiché chyby jsou často horší než viditelný výpadek, protože mohou dlouho způsobovat škodu bez toho, aby si jich někdo všiml.

U samotné aplikace sleduji hlavně udržovatelnost. Zajímá mě struktura kódu, rozdělení odpovědností, práce s databází, výkon dotazů, integrace, oprávnění, chybové stavy a místa, která se těžko mění bez rizika vedlejších chyb.

U WordPressu navíc řeším strukturu šablony, vlastní úpravy, pluginy, aktualizace a bezpečnost administrace. U Laravelu se víc zaměřuji na architekturu, databázi, fronty, crony a části systému s přímým dopadem na provoz.

Součástí auditu je i technický stav webu z pohledu výkonu a vyhledávačů. Kontroluji rychlost načítání, přesměrování, stavové kódy, strukturu URL, interní odkazy, indexaci, sitemapu, robots.txt, základní metadata, strukturovaná data a to, jestli se důležité stránky dají správně procházet a najít.

Výsledkem auditu nemá být dlouhý seznam problémů bez kontextu. Důležité je rozlišit, co je kritické riziko, co má dopad na bezpečnost nebo provoz, co brzdí výkon, co komplikuje údržbu a co je jen technická nedokonalost, kterou není nutné řešit hned.

Jaké nástroje a data při auditu využívám

Audit nestavím na jednom automatickém reportu. Nástroje dokážou rychle upozornit na řadu problémů, ale samy neřeknou, co je opravdu důležité, co má dopad na provoz a co je jen upozornění bez větší priority. Proto kombinuji měření, ruční kontrolu a technické posouzení celého projektu.

Podle typu webu nebo aplikace využívám například:

• Google Search Console pro kontrolu indexace, sitemap, chybových URL, kanonických adres a toho, jak web reálně vidí Google.
• Screaming Frog SEO Spider pro procházení webu, kontrolu stavových kódů, přesměrování, titulků, meta popisů, interních odkazů, sitemap a opakujících se problémů napříč šablonami.
• Ahrefs, Semrush nebo podobné SEO nástroje pro širší pohled na organickou viditelnost, odkazy, technický stav webu, konkurenční srovnání a prioritizaci problémů.
• Lighthouse, PageSpeed Insights a Chrome DevTools pro kontrolu výkonu, Core Web Vitals, načítání assetů, síťových requestů, přístupnosti a základních technických problémů.
• Sentry, uptime monitoring a serverové logy pro sledování chyb, výpadků a opakujících se problémů v reálném provozu.
• OWASP ZAP, Trivy, Semgrep, Gitleaks, WPScan, npm audit nebo composer audit pro základní bezpečnostní kontrolu aplikace, závislostí, repozitáře a konfigurace.
• Lynis, Nmap, testssl.sh, OpenVAS / Greenbone nebo OpenSCAP u projektů běžících na vlastním VPS, kde kontroluji otevřené porty, SSH, firewall, TLS, aktualizace systému, běžící služby, oprávnění, logování a základní hardening.
• Ruční kontrolu kódu, závislostí a konfigurace, protože právě ta často odhalí problémy, které automatický nástroj nezachytí.

Nástroje jsou ale jen podklad. Skutečná hodnota auditu není v exportu varování a skóre. Důležité je správně vyhodnotit, co má reálný dopad, co je potřeba řešit hned, co stačí naplánovat později a co je jen technický detail bez zásadního vlivu na provoz.

Kritická místa, která často rozhodují

U technického auditu se často ukáže, že největší riziko není v jedné viditelné chybě, ale v několika provozních detailech, které se dlouho neřešily. Typicky jde o zálohy, aktualizace, přístupy, hosting, nasazování nebo monitoring.

Zálohy jsou časté místo falešné jistoty. Samotná informace, že se projekt zálohuje, nestačí. Důležité je vědět, co přesně záloha obsahuje, kde je uložená, jak dlouho se uchovává a hlavně jestli z ní lze projekt opravdu obnovit. Záloha na stejném serveru jako produkce nebo obnova, která se nikdy nezkusila, nemusí při reálném problému stačit.

Podobné je to s aktualizacemi. U starších projektů se často neodkládají proto, že by na ně nikdo neměl čas, ale proto, že se jich všichni bojí. Není jasné, co se po aktualizaci PHP, Laravelu, WordPressu, pluginů nebo balíčků rozbije. Chybí staging, testy, dokumentace nebo člověk, který původní řešení dobře zná.

Audit proto nesleduje jen to, jestli je něco zastaralé. Důležitější je zjistit, jak velké riziko představuje další změna. Někdy stačí běžná údržba. Jindy je potřeba projekt nejdřív stabilizovat, připravit bezpečné prostředí pro testování, vyřešit nejrizikovější části a teprve potom dělat větší úpravy.

Co je výstupem auditu

Výstupem auditu nemá být dlouhý dokument plný technických poznámek, ve kterém se nikdo nevyzná. Takový výstup sice může působit odborně, ale pro rozhodování často nepomůže.

Důležité je rozlišit, co má skutečný dopad na provoz, bezpečnost, data nebo další vývoj. Některé věci je potřeba řešit hned. Některé stačí naplánovat. Některé jen zvyšují technický dluh, ale nejsou urgentní. A některé se možná nevyplatí řešit vůbec.

Dobrý audit by měl dát jasnou odpověď na několik otázek:

• Co je teď největší riziko?
• Co může brzdit další vývoj?
• Co se musí opravit před větší změnou nebo migrací?
• Co stačí řešit v rámci běžné správy?
• Co by bylo zbytečně drahé vzhledem k přínosu?

Cílem není všechno přepsat ani projekt zbytečně komplikovat. Cílem je získat přehled, priority a rozumný plán dalšího postupu.

Závěr

Technický audit má smysl ve chvíli, kdy chcete nad projektem získat větší kontrolu. Nečekat, až se něco rozbije, ale včas vědět, v jakém stavu web nebo aplikace je, kde se hromadí technický dluh a co může být problém při dalším provozu nebo rozvoji.

Dobře udělaný audit nepřináší jen seznam chyb. Pomáhá rozhodnout, jestli projekt stačí dál udržovat, nejdřív stabilizovat, migrovat na novější technologii, nebo některé části navrhnout jinak.

Největší přínos auditu je v tom, že z technické nejistoty udělá konkrétní plán. Ukáže, na čem projekt opravdu stojí, co má smysl řešit hned a kde by změny stály víc, než kolik by projektu reálně přinesly.