Smazání všech cookies dané stránky není tak lehké jak se může zádat.

Tento článek vznikl hlavně proto, abych se na něj mohl odkazovat, když řešíme testování mazání cookies a dalších uložišť v prohlížeči. Nejde o vzhled cookie lišty, ale o realitu: co přesně se při mazání děje, proč jednoduchý návod často nestačí a kde se při vyhodnocení snadno udělají chybné závěry.

Disclaimer: Tohle není právní rada. Technicky lze popsat, co dělá prohlížeč, skripty a jednotlivé služby. To, jestli je konkrétní implementace v souladu s GDPR nebo ePrivacy, ale vždy závisí i na právním titulu, informační povinnosti, rozsahu zpracování, retenčních dobách, přenosech mimo EU a konkrétním nastavení služeb.

Jinými slovy: z jednoho screenshotu DevTools nebo z jedné nalezené cookie obvykle nejde spolehlivě odvodit, že je web „v pořádku“ nebo že „porušuje GDPR“. Jde jen o dílek celé skládačky.

Co je cílem správného testu

Pokud chcete ověřit chování webu bez souhlasu, potřebujete se dostat do skutečně čistého stavu. To neznamená jen smazat cookies. Moderní weby pracují i s dalšími úložišti a zároveň mohou mít ve stránce už načtené skripty, které po smazání část dat znovu vytvoří.

V praxi proto při testování sledujte minimálně:

• cookies,
• Local Storage,
• Session Storage,
• IndexedDB,
• Cache Storage,
• Service Worker a případně další běžící kontexty stránky.

Jednoduchý návod, který často nestačí

Klasická rada bývá: otevřete web, smažte cookies, obnovte stránku a zkontrolujte, co se vytvoří znovu. Jako rychlá orientace je to použitelné. Jako důkaz správného nebo špatného nastavení to ale často nestačí.

Pro první kontrolu je nejlepší buď čistý profil prohlížeče, nebo anonymní okno. K tomu dává smysl použít DevTools a smazat data cíleně jen pro testovaný web.

Doporučený základní postup

1. Otevřete stránku, kterou chcete testovat.
2. Otevřete DevTools, typicky přes F12 nebo Ctrl+Shift+I.
3. Přejděte do záložky Application / Aplikace.
4. V sekci Storage projděte cookies, Local Storage, Session Storage, IndexedDB, Cache Storage a Service Workers.
5. Vymažte data pro testovaný web. Pokud prohlížeč nabízí i smazání third-party dat pro daný kontext, použijte ho při hlubší kontrole také.
6. Obnovte stránku a sledujte, co se vytvoří znovu a kdy přesně k tomu dojde.

Proč tento návod v reálném světě selhává

V ideálním světě by se vše vytvořilo až po načtení stránky, smazalo jedním klikem a po refreshi byste měli jasno. Jenže reálné weby používají více skriptů, více domén, více typů úložišť a někdy i synchronizaci souhlasu mezi službami. Proto je potřeba počítat s tím, že samotné „smazal jsem cookies“ nic definitivně neprokazuje.

Reálný scénář krok za krokem

1. První načtení stránky

Při prvním načtení se mohou vytvořit technické cookies a další nezbytná data potřebná pro fungování webu, například pro přihlášení, košík nebo bezpečnostní mechanismy. To samo o sobě ještě neříká nic o marketingu nebo analytice.

V této fázi můžete narazit i na situaci, kdy v přehledu uvidíte cookie, která nepatří testované doméně, ale jiné doméně načítané do stránky, například kvůli obrázku, iframe nebo jinému externímu zdroji.

• Důležité upřesnění: přítomnost third-party cookie sama o sobě neznamená, že aktuální web tu cookie vytvořil nebo že právě proběhl analytický hit.
• Typický důvod: prohlížeč při requestu na cizí doménu pošle cookies této cizí domény, pokud to dovolí zásady prohlížeče a atributy cookie, zejména SameSite.
• Praktický závěr: pokud web načítá obsah z cizí domény, může se v testu projevit i stav této cizí domény. To je technická realita webu, ne automatický důkaz chyby na aktuálním webu.

Majitel webu může riziko snížit například tak, že externí statické soubory nebude tahat z domény, která zároveň používá měřicí nebo marketingové cookies, případně že omezí posílání cookies v cross-site kontextech přes správně nastavené atributy SameSite.

2. Načtení souhlasová („cookie“) lišta a měřicích skriptů

Další kritický moment nastává po načtení skriptu pro správu souhlasu a měřicích tagů. Tady je potřeba být velmi přesný a vyhnout se zkratce „skript se načetl, tedy je to špatně“ i opačné zkratce „nenastavila se cookie, tedy je vše v pořádku“.

Například u Google Consent Mode v2 platí, že i v režimu bez souhlasu může dojít k odeslání tzv. cookieless pingů. Google současně uvádí, že v GA4 neukládá IP adresy uživatelů, ale to zdaleka neznamená, že lze každou implementaci automaticky prohlásit za bezproblémovou. Rozhodující je:

• jaké tagy se načítají,
• co přesně odesílají,
• zda nedochází k ukládání dat na zařízení uživatele bez souhlasu,
• zda nejsou přidávána další identifikační data mimo samotný standardní režim Consent Mode,
• jak je vyřešena transparentnost a právní základ.

Jinými slovy: samotné tvrzení „Google Analytics se načetly“ ještě nestačí. Stejně tak nestačí tvrzení „nevznikla cookie, takže je to určitě legální“. Obojí je příliš zjednodušené.

3. Uživatel udělí souhlas

Po udělení souhlasu se typicky uloží informace o volbě uživatele a následně se aktivují tagy, které předtím čekaly. U některých skriptů se po změně souhlasu jen aktualizuje stav. Jiné se do stránky načtou až dodatečně. A další se bohužel spustí až po další pageview, což může zkreslit analytiku nebo reklamní atribuci.

Tohle není jen teoretická poznámka. Je to jeden z nejčastějších důvodů, proč web „vypadá správně“, ale v datech se pak ztrácí zdroj návštěvy nebo první pageview po souhlasu.

4. Uživatel smaže cookies, ale stránka pořád běží

Tady vzniká nejčastější omyl při testování. Uživatel v DevTools smaže cookies a další data, ale stránka je stále otevřená a skripty uvnitř ní dál běží. Některé tedy mohou okamžitě vytvořit nové položky, poslat další request nebo při odchodu ze stránky odeslat událost, která znovu vrátí cookie přes odpověď serveru.

Výsledek je zrádný: tester má pocit, že „smazal všechno“, ale ještě před refreshem už má v prohlížeči část dat znovu.

5. Proč někdy pomůže až dvojité vyčištění

V komplikovanějších implementacích proto dává smysl tento postup:

1. Smazat data v otevřené stránce.
2. Obnovit stránku, aby se znovu načetla bez předchozího běžícího stavu.
3. Znovu zkontrolovat a případně znovu vymazat data, která se mezitím obnovila.
4. Teprve potom udělat finální kontrolu nového čistého načtení.

Není to nutné vždy. U jednoduchého webu to bývá zbytečné. U komplexnějších webů s CMP, GTM, více doménami nebo background procesy je to ale často jediný způsob, jak se dostat k věrohodnému výsledku.

Co by měla dělat dobře i samotná souhlasová lišta

Pokud uživatel sníží úroveň souhlasu nebo souhlas odvolá, nestačí jen přepsat stav v consent cookie. Správná implementace má zároveň odstranit všechna zbytná uložená data, která už pro daný účel nemají oporu. V praxi to znamená hlavně analytické a marketingové cookies a další obdobná úložiště.

Dobrá zásada je jednoduchá: vše, co není technicky nutné pro fungování služby, berte při odvolání souhlasu jako kandidáta na smazání. U nutných technických cookies je naopak rozumné držet jasný allowlist.

Další důvody, proč může test selhat

• Máte otevřených více tabů nebo oken stejného webu. Skript v jiném tabu může znovu vytvářet data nebo posílat requesty na backend.
• Máte více anonymních oken. Dokud nezavřete všechna okna dané privátní relace, úložiště se nemusí resetovat tak, jak čekáte.
• Souhlas se synchronizuje mezi více doménami. Smažete stav na jedné doméně, ale jiná ho vrátí zpět.
• Testujete jen jednu subdoménu. Cookie nastavená pro .example.com může přežít, i když čistíte jen sub.example.com.
• Stejná cookie existuje na různých cestách. Pokud se smaže jen varianta pro /, může zůstat jiná s totožným názvem na /app.
• Jde o HttpOnly cookie. Tu nelze spolehlivě odstranit klientským JavaScriptem; často je nutné mazání přes server.
• Do hry vstupují partitioned cookies a storage partitioning. Third-party data mohou být uložená odděleně podle top-level webu a v testu pak působí matoucím dojmem.
• Běží Service Worker nebo jiný background proces. I po vyčištění může přijít nový request a server vrátí další Set-Cookie.
• Automatický test nemá opravdu čisté prostředí. Typicky když skript recykluje starý profil prohlížeče nebo izolaci řeší jen částečně.

Co z toho plyne pro praxi

Pokud při testu po smazání pořád vidíte nějakou cookie, není správná reakce hned napsat „web je špatně“. Nejdřív si ověřte:

• z jaké domény cookie pochází,
• kdy přesně vznikla,
• jestli ji nevytvořil už běžící skript až po smazání,
• jestli nejde o technickou nebo serverovou cookie,
• jestli ji nevrací jiný otevřený tab, Service Worker nebo backend.

Teprve potom má smysl hodnotit, zda jde o reálný problém implementace, nebo jen o špatně provedený test.

Závěr

Mazání cookies při testování není složité proto, že by byl problém samotný browser. Složité je to proto, že dnešní web je směs více domén, více uložišť, více skriptů a často i více právních režimů najednou. Čím složitější stack, tím opatrnější musí být i interpretace výsledků.

Pokud si z článku chcete odnést jednu věc, tak tuto: „Smazal jsem cookies“ ještě neznamená „jsem v čistém stavu“ a „našel jsem cookie“ ještě neznamená „mám důkaz porušení“.

A právě proto dává smysl testovat pečlivě, opakovaně a bez příliš rychlých závěrů.