„Máme přístup do administrace, někde ho najdu”. Takto (bohužel) nezřídka začíná spolupráce s klientem, který má web, “všechno zařízené a nastavené”, ale nikdo vlastně neví, kde je co. A pak zjišťujeme, že přístup do webu není to samé přístup do hostingu a podobně. A začíná detektivka.
Web, co běží, není totéž jako web, co vlastníte.
Web může fungovat roky, aniž by si kdokoliv položil otázku: kdyby dnes správce infrastruktury/webu zmizel, dokázal by to celé převzít někdo jiný? A jak rychle?
Co si klienti myslí, že mají – a co reálně mají
Web se skládá z desítek vrstev – doména, hosting, kód, databáze, e-mail, analytika, reklama, platby, licence… Klient obvykle vidí jen tu poslední, nejviditelnější vrstvu (administraci webu), a předpokládá, že někde tam je zabalené i to ostatní.
- “Mám web.” = přihlašovací údaje do administrace webu.
- “Mám na to přístup.” = jsem přidaný uživatel v účtu, který vlastní někdo jiný.
- “Máme zálohy.” = Ve skutečnosti: existují, ale nikdo neví kde, ani jestli fungují.
Kde potkávám problém nejčastěji
Doména a DNS
Doména je vedená na agenturu, bývalého zaměstnance, nebo cizí e-mail. Takže kdyby chtěl, nemůže s ní manipulovat. Někdy zvládne editovat DNS záznamy, protože přístup do hostingu má, ale pozor – to není to samé! Doména reálně není jeho – pokud by původní vlastník doménu vzal, přesunul ji jinam, odpojil veškerou infrastrukturu… tak má klient po žížalkách.
Co s tím: Zkontrolujte si, že doména je opravdu vaše. Kdyby nejhůř – požádejte si o kód k převodu domény u NIC.cz – pokud vám přijde na e-mail, který je opravdu váš, je vše v pořádku.
Pozn: Ujistěte se, že doména je registrováva na e-mail, který je z jiné domény než ona sama. Pokud ji zapomenete zaplatit, zablokují se všechny služby – včetně e-mailu, který je psaný v registru.
Hosting a server
Klient nemá vlastní účet u hostingu a po zmizení agentury neví, kde web vůbec běží. Časté je i to, že na jednom serveru běží víc klientských webů pod jedním účtem – problém s jedním dodavatelem pak ohrozí všechny najednou.
Toto není nutně špatně, pokud se klient nechce o hosting starat a agenturu si na to najme. Jen musí počítat s tím, že náklady můžou být trochu větší. Nikdo neříká, že musíte mít vlastní hosting a starat se o všechno sami.
Co s tím: Tady platí staré IT přísloví: pokud není problém a jste se správcem spokojeni, není třeba nic řešit. Mějte jistotu, že máte někde po ruce zálohu webu (a dalších dat okolo). Čistě pro klid duše.
Zdrojový kód a repozitáře
Produkční web funguje, ale poslední verze šablony nebo aplikace existuje jen na notebooku vývojáře (často v jakémsi stavu “superpozice”). Git repozitář může být v soukromém účtu dodavatele – klient má web, ale ne historii vývoje, branche ani build proces, natož zdrojové kódy. Není výjimkou, že produkční verze neodpovídá tomu, co je v repozitáři, protože je rychlejší udělat fix přímo na produkci než čekat na deplyoment.
Co s tím: Mějte nastavený deployment proces s automatickými testy a dodržujte ho. Ten pokryje 99,5 % problémů, se kterými se potkáte.
Zálohy
Zálohy často existují, ale leží na tom samém serveru jako web (takže při poškození disku zmizí data i zálohy najednou), nebo se ukládají do cloudového účtu, ke kterému klient nemá přístup. A třešinka na dortu často je, že se je nikdo nikdy nezkusil obnovit.
Co s tím: Mějte připravený plán na recovery proces – mějte jistotu, že máte seznam částí vaší infrastruktury, a zálohy, ze kterých to můžete obnovit.
Firemní e-mail
Často problémy nastanou, když se při přesunu domény a webu zapomene na e-maily. Nebo se neví, jak je zmigrovat. Nebo zapomenete změnit DNS záznamy a e-maily najednou nefungují vůbec. Ještě zákeřnější je situace, kdy obnovovací e-mail nebo dvoufaktorové ověření vede na telefon bývalého vývojáře – přihlašovací údaje jsou správné, ale bez jeho zařízení se účet neotevře.
Co s tím: Buďte si jisti, že e-maily máte na infrastruktuře, kam máte adminový přístup – ať už je to hostingový e-mail nebo nějaký e-mailový provider (Gmail, Seznam, atd…).
Analytics, Search Console, Tag Manager
Tyhle služby bývají založené na účtu agentury, klient je jen “přidaný uživatel”. Po odebrání přístupu může přijít o roky historických dat, nebo nemůže upravit měření a zjistit, co se přes Tag Manager vlastně spouští.
Co s tím: Mějte jistotu, že do těchto účtů máte přístup nejvyšší – Owner nebo Administrátor.
Reklamní účty a platební brány
Kampaně běžící pod agenturním Google Ads nebo Meta účtem se při změně dodavatele obtížně přenášejí – historie a publika často zůstávají tam, kde byla. Platební brána napojená přes účet agentury může navíc vyžadovat po ukončení spolupráce úplně novou smlouvu.
Co s tím: Mějte jistotu, že do těchto účtů máte přístup a jsou psané na vás.
API klíče a automatizace
Některé části a funkce webu nebo infrastruktury mohou záviset na API klíčích, které patří dodavateli – mapy. e-mailové službu, AI API. Po jejich zrušení přestanou fungovat formuláře, platby nebo synchronizace, a nikdo neví proč. Podobně zákeřné jsou externí automatizace (Make, Zapier, n8n) běžící na účtu programátora – synchronizují objednávky nebo sklad, a po jeho vypnutí se proces prostě tiše zastaví, aniž by kdekoli vyběhla chyba. Navíc se může stát, že vám klíče někdo ukradne (např. kvůli napadenému webu) – pak je třeba ihned staré vypnout, vystavit nové a napojit je do infrastruktury.
Co s tím: Mějte jistotu, že klíče těchto služeb jsou opravdu vaše a máte k nim přístup, kdybyste s nimi potřebovali cokoli udělat.
Licence
Pluginy, šablony, fonty, fotky – u ničeho z toho klient často neví, čí je to licence. Zjistí to až ve chvíli, kdy po převzetí webu musí nakupovat několik nových licencí najednou, protože ty staré patřily vývojáři.
Někdy může být v pořádku, že vám licenci dodá vývojář. Ale často bývá v podmínkách takto distribuovaného multi-licenčního software napsáno, že ji smí používat jen sám vývojář/agentura. Pokud se s ním rozloučíte, licence by na vašem webu už neměla zůstat aktivní – web sice dál poběží, ale přijdete o aktualizace i podporu, dokud si nepořídíte vlastní.
Dokumentace (respektive její absence)
Integrace jsou “zdokumentované jen v hlavě vývojáře”. Nikdo neví, proč tam je určitý plugin, co dělá konkrétní webhook, nebo co se bezpečně dá vypnout a co ne – jeden nenápadný plugin může ve skutečnosti zajišťovat export objednávek do účetnictví.
Co s tím: v době AI není problém takovou dokumentaci zpětně vytvořit a automaticky udržovat.
Typické scénáře ze života
- “Máme přístup do administrace, takže máme všechno.” Při migraci se zjistí, že hosting, DNS i zálohy jsou pouze v účtu agentury.
- “Doména je naše.” Firma ji používá deset let, ale v registru je pořád uvedený bývalý programátor.
- “Zálohy máme.” Jsou uložené na stejném serveru, který právě přestal fungovat.
- “Platební brána funguje.” Při změně dodavatele se ukáže, že smlouva i API přístupy jsou vedené přes původního partnera.
- “Přesuneme web a hotovo.” Po migraci se zjistí, že starý server ještě spouštěl noční cron (a desítky dalších automatizací), co aktualizoval sklad.
- “Web běží, takže je vše v pořádku.” Problém se objeví až za tři měsíce, když vyprší licence nebo doména – upozornění chodilo bývalému dodavateli.
Co by mělo být vždy na klienta
Základní princip: dodavatel dostává přístup do klientova účtu, ne klient do účtu dodavatele.
Na klienta by měly být minimálně:
- doména a hlavní účet u registrátora,
- hosting/server (pokud je to rozumně možné),
- DNS / Cloudflare,
- firemní e-mail (Google Workspace / Microsoft 365),
- Google Analytics, Search Console, Tag Manager, Google Ads,
- Meta Business Manager,
- platební brány a bankovní/fakturační služby,
- databáze zákazníků, CRM,
- Git repozitář u custom projektů,
- klíčová externí API.
Na dodavateli může zůstat cokoli, co můžete snadno nahradit:
- některé WordPress pluginy,
- vlastní vývojářské nástroje a buildery,
- monitoring,
- interní deployment nástroje.
Ale klient musí vědět, že jde o dodavatelovu licenci, co se stane po ukončení spolupráce, a kolik bude stát náhrada.
Varovné signály, které stojí za pozornost
- Doména je napsaná na dodavatele, klient nezná registrátora.
- Klient nemá vlastní administrátorský účet, jen “je přidaný”.
- Analytics, Search Console nebo Tag Manager vlastní agentura.
- Zdrojový kód existuje jen u vývojáře, není Git repozitář.
- Nikdo neví, jaké externí služby web vlastně používá, a seznam neexistuje.
- Dodavatel odmítá předat přístupy bez technického důvodu.
- Dodavatel používá jeden společný účet pro všechny své klienty.
Jak si udělat mapu přístupů
U každé služby si vedle sebe zapište:
- k čemu slouží a kde je administrace,
- kdo je vlastníkem účtu a kdo ho platí,
- kdo je hlavní administrátor a kontaktní/obnovovací e-mail,
- jestli má klient plný přístup a jestli má i dodavatel,
- kdy služba expiruje,
- je-li zapnuté 2FA a kdo má druhý faktor,
- co se stane, když se služba vypne.
Hesla do této mapy nepatří – ta ať zůstanou ve firemním správci hesel (1Password, Bitwarden a podobně), s vlastním účtem pro každého člověka, ne sdíleným “admin”.
Jak dohledat služby, o kterých ani nevíte
Pokud dokumentace neexistuje, dá se leccos zrekonstruovat i zpětně:
- z faktur a bankovních výpisů (pravidelné platby prozradí, co všechno firma vlastně platí),
- z e-mailových schránek (fakturační e-maily typu “Your subscription has renewed”),
- z DNS a MX záznamů (a jejich historie),
- ze zdrojového kódu webu a seznamu nainstalovaných pluginů,
- z network requestů v prohlížeči (co všechno se při načtení stránky volá),
- z cookie lišty (často prozradí použité analytické a marketingové nástroje).
Co dělat, když se to už stalo
- Zjistěte, kdo vlastní doménu, a získejte přístup k registrátorovi a DNS.
- Zjistěte, kde web běží, a získejte přístup k hostingu.
- Okamžitě vytvořte kompletní zálohu a uložte ji mimo současný server.
- Získejte export databáze, soubory webu a zdrojové kódy.
- Zmapujte externí služby – e-mail, platební brány, marketingové účty, licence.
- Zkontrolujte fakturaci a expirace u všeho, co jste našli.
- Vytvořte si vlastní administrátorské účty, teprve pak odeberte ty staré.
- Rotujte hesla, API klíče a SSH/deploy klíče.
- Otestujte, že web z toho, co máte, skutečně jde obnovit.
- Zdokumentujte nový stav, ať se tohle příště nemusí opakovat od nuly.
Pamatujte si
Nezačínejte bezhlavě. Dokud nevíte, co je na co napojené, neměňte hned všechna hesla, nevypínejte API klíče a nemazejte účty původního dodavatele – riskujete, že tím vypnete něco, o čem jste ani nevěděli, že to běží. Stejně tak nemigrujte web bez ověřené kompletní zálohy a nerušte starý hosting dřív, než je nová kopie prokazatelně funkční.
Kontrolní otázka na závěr: Kdyby váš vývojář/správce dal výpověď ze dne na den, dokázal by jiný člověk z přístupů a podkladů vaši infrastrukturu převzít a provozovat dál? Pokud si na tuhle otázku nejste jistí odpovědí, je někde závislost, kterou má smysl vyřešit dřív, než se stane problémem.
Potřebujete pomoc se zmapováním nebo převzetím webu?