GDPR для сайту у 2026: що бізнесу в ЄС треба за законом, щоб не отримати штраф

Уявіть, що вам на пошту приходить лист від регулятора з темою «скарга користувача». Не через витік даних, не через злам — у вас просто не працює кнопка «Відхилити» в банері cookie. Користувач натиснув її, аналітика все одно завантажилася, він зробив скриншот і надіслав скаргу. Тепер у вас тридцять днів, щоб пояснитися. Це не вигаданий сценарій залякування — саме за такі дрібниці в Європі зараз і прилітають приписи, бо довести їх найпростіше: відкрив сайт, натиснув кнопку, перевірив у інструментах розробника, чи вантажиться трекер.

GDPR для сайту майже всі розуміють хибно — і в обидва боки. Одні вішають банер «Ми використовуємо cookie. ОК» і вважають, що закрили питання, хоча такий банер сам собою є порушенням. Інші в паніці вимикають усю аналітику й працюють наосліп, втрачаючи дані, які їм дозволено збирати. Істина посередині, і вона про інженерію, а не про юридичний переляк: правильно налаштований сайт збирає майже все, що потрібно для зростання, і водночас не дає регулятору жодного приводу.

Ця стаття — практичний розбір того, що бізнес-сайту в ЄС реально потрібно у 2026 році. GDPR для сайту ми розкладемо на конкретний чек-лист: банер cookie, політика конфіденційності, легальна аналітика, форми й справжні порушення, за які штрафують. Без води про «важливість захисту даних» — тільки те, що має стояти на сторінці, щоб ви спали спокійно й при цьому не осліпли в аналітиці.

GDPR і RODO — це один закон. Не лякайтеся двох назв.

Спершу знімемо плутанину, яка коштує людям зайвих грошей на «двох різних» юристів. GDPR (General Data Protection Regulation) і RODO (Rozporządzenie o Ochronie Danych Osobowych) — це буквально той самий загальноєвропейський регламент, просто під англійською і польською назвою. Він діє напряму в усіх країнах Євросоюзу, тому базові вимоги до польського, німецького, іспанського й будь-якого іншого сайту в ЄС однакові. Відрізняються лише дрібні національні надбудови й назва наглядового органу — у Польщі це UODO, у Німеччині регіональні відомства, і так далі.

Що це означає на практиці: якщо ви робите сайт для польського бізнесу, ви виконуєте GDPR, він же RODO. Якщо завтра ви додаєте німецьку чи французьку версію — фундамент той самий, змінюються лише мова текстів і пара локальних деталей. Це, до речі, одна з причин, чому багатомовний сайт під ринки ЄС тримати у відповідності простіше, ніж здається: правовий каркас спільний, дублювати доводиться контент, а не логіку згоди.

Регламент захищає персональні дані — усе, за чим можна прямо або непрямо впізнати людину. І тут перший сюрприз для багатьох власників: персональні дані — це не лише імʼя й телефон із форми. Це й IP-адреса, й ідентифікатор cookie, й дані про поведінку на сайті, які збирає аналітика. Саме тому історія починається з найнуднішого й найбільше порушуваного елемента — з банера cookie.

Банер cookie, який не порушує закон (а не просто «ОК»)

Тут зосереджена більша частина штрафів і майже всі скарги, бо порушення видно неозброєним оком. Розберемо по пунктах, чим легальний банер згоди відрізняється від тієї заглушки, що стоїть на більшості сайтів.

Головний принцип GDPR: згода має бути активною, поінформованою й такою ж легкою для відкликання, як для надання. З цього випливають конкретні вимоги, які легко перевірити:

• Жодного завантаження трекерів до згоди. Google Analytics, Meta Pixel, чат, карти, вбудоване відео не повинні ставити cookie й слати дані, поки людина не натиснула «Прийняти». Це найчастіше й найдоказовіше порушення: трекер видно в інструментах розробника ще до кліку.
• Кнопка «Відхилити» на тому ж рівні, що й «Прийняти». Якщо «Прийняти» — велика зелена, а відмовитися можна лише через три екрани налаштувань, це незаконно по своїй суті. Відмова має бути такою ж простою, як згода.
• Жодних заздалегідь поставлених галочок. Згоду не можна припускати за замовчуванням. Усі категорії, крім суворо необхідних, мають бути вимкнені, поки людина сама їх не ввімкне.
• Гранулярність за категоріями. Користувач має право погодитися на аналітику, але відмовитися від маркетингу. Один спільний перемикач «усе або нічого» регулятори теж вважають проблемним.
• Можливість відкликати згоду потім. Десь має бути посилання чи іконка «Налаштування cookie», щоб людина могла передумати через місяць так само легко, як погоджувалася.

Під усі ці вимоги НЕ підпадає одна важлива категорія — суворо необхідні cookie. Кошик у магазині, сесія входу до особистого кабінету, запамʼятовування вибраної мови, захист форми від ботів — для них згода не потрібна, бо без них сайт фізично не працює. Їх можна й треба вантажити одразу. Проблема майже завжди не в них, а в аналітиці й маркетингових пікселях, які підключають за інерцією й забувають сховати за згоду.

Простий тест для вашого нинішнього сайту: відкрийте його в режимі анонімного перегляду, не натискаючи нічого в банері, і подивіться вкладку Network у інструментах розробника. Якщо до кліку вантажаться google-analytics, facebook, doubleclick чи подібне — ви вже порушуєте, і це видно будь-кому, хто захоче поскаржитися.

Політика конфіденційності: не шаблон зі стелі, а карта ваших даних

Другий обовʼязковий елемент — політика конфіденційності (privacy policy), і тут типова помилка протилежна банеру. З банером бізнес недопрацьовує, а з політикою — навпаки, копіює чужий текст і думає, що закрив питання. Регулятор за скаргою порівнює те, що написано в політиці, з тим, що реально робить сайт, і саме розходження ловить першим.

Робоча політика конфіденційності відповідає на прості питання про ваш сайт, а не про абстрактний:

• Які дані ви збираєте (імʼя, email, телефон із форм; IP і поведінку через аналітику).
• На якій підставі (згода, виконання договору, законний інтерес).
• Навіщо саме — мета кожного збору.
• Кому передаєте — список сторонніх сервісів: яка у вас аналітика, розсилка, CRM, платіжний провайдер, хостинг.
• Скільки зберігаєте і як людина може запросити видалення своїх даних або їх копію.
• Контакт відповідального за дані.

Ключове слово тут — ваші інструменти. Скопійована у сусіда політика майже напевно перелічує не ті сервіси, що стоять у вас, або не згадує ті, що стоять. Підключили Meta Pixel, а в політиці його немає — порушення. Написали про Mailchimp, а шлете через інший сервіс — теж. Згенерований шаблон годиться як каркас, але його обовʼязково треба довести до реальності конкретного сайту. За нашим досвідом, саме це — найчастіша правка, коли до нас приходять із готовим сайтом «привести до ладу за GDPR».

Легальна аналітика: як бачити цифри й не порушувати

Тепер найпрактичніше — як збирати дані про відвідуваність, не перетворюючи сайт на правову міну. Бо сліпий бізнес програє: без аналітики ви не знаєте, які сторінки працюють, звідки приходять клієнти і що лагодити. Добра новина — легальних шляхів кілька.

Шлях перший: Google Analytics за згодою. GA4 у Європі використовувати можна. Умови: вантажте його тільки після кліку «Прийняти», увімкніть режим згоди (Consent Mode) і анонімізацію, чесно опишіть передавання даних у політиці. Це робочий варіант, якщо потрібен глибокий аналіз, ретаргетинг і звʼязка з рекламою. Мінус — складність налаштування, плюс частина користувачів тисне «Відхилити», і ці візити ви в GA не побачите взагалі.

Шлях другий, який ми частіше радимо: аналітика без cookie. Plausible, Umami, Matomo і подібні інструменти рахують відвідуваність, не ставлячи cookie й не збираючи персональних даних у звичному сенсі. Для базових метрик — скільки візитів, звідки, які сторінки популярні — їм у багатьох конфігураціях узагалі не потрібен банер згоди, бо збирати нічого. Це знімає значну частку юридичного ризику разом і заодно прискорює сайт, бо код такої аналітики легший. Ми докладно розбирали цей підхід у матеріалі про аналітику без cookie — для більшості бізнес-сайтів, яким потрібні цифри зростання, а не складний ретаргетинг, це спокійний вибір за замовчуванням.

Порівняймо по-простому, щоб було видно компроміс:

Критерій	Google Analytics (GA4)	Аналітика без cookie
Потрібен банер згоди	Так, обовʼязково	Часто ні
Глибина даних	Висока, до рівня користувача	Базова, за візитами
Ретаргетинг і звʼязка з рекламою	Так	Ні
Частка «втрачених» через відмову	Помітна	Нульова
Юридичний ризик	Вищий, потрібне акуратне налаштування	Нижчий
Вплив на швидкість	Важчий	Легший

Вибір залежить від того, що вам реально потрібно. Запускаєте платну рекламу й рахуєте воронку до кліку — тоді GA зі згодою виправданий. Хочете просто розуміти, чи ростете ви й що лагодити, — аналітика без cookie закриє це з меншим ризиком і меншою морокою зі згодою.

Форми й обробка даних: де витікає довіра

Будь-яка форма на сайті — контакт, заявка, підписка — це збір персональних даних, і до неї GDPR ставиться суворо. Тут кілька правил, які легко виконати й про які часто забувають.

Під кожною формою, що збирає контакт, має стояти явне інформування: коротко, на що людина погоджується, і посилання на політику конфіденційності. Для маркетингової розсилки потрібна окрема активна галочка згоди — не передзаповнена, не «погоджуюся з усім одразу». Заявку на послугу людина лишає на підставі законного інтересу або майбутнього договору, а от додати її до розсилки без окремої згоди не можна.

Далі — техніка, про яку забувають найчастіше. Дані з форми мають іти захищеним зʼєднанням (HTTPS — це давно не опція), зберігатися там, де у вас є до них легальний доступ, і не валятися, наприклад, у відкритій Google-таблиці, до якої має доступ пів офісу. Якщо форма шле заявки в месенджер або CRM, цей сервіс теж має бути згаданий у політиці як отримувач даних. Ми розбирали, як влаштовані форми захоплення заявок, які справді конвертують — і відповідність GDPR там не суперечить конверсії, а допомагає їй: зрозуміла форма з чесним мікротекстом про дані викликає більше довіри, а не менше, особливо в європейської аудиторії, яка до цього звикла.

І ще одна деталь: антиспам. reCAPTCHA від Google теж ставить трекери й формально підпадає під згоду. Альтернатива — honeypot-поле (невидима пастка для ботів), яке не збирає даних і не вимагає банера. На наших проєктах ми за замовчуванням ставимо саме такий варіант: форма захищена від ботів і не додає рядок до списку «що треба узгодити».

Часті порушення і штрафи: за що прилітає насправді

Поговорімо чесно про гроші, бо навколо штрафів GDPR багато страшилок. Верхня планка регламенту справді драматична — до 20 млн євро або 4% річного світового обороту, дивлячись що більше. Але це стеля для великих, умисних, масових порушень на кшталт витоку даних мільйонів користувачів. До сайту-візитки чи невеликого інтернет-магазину це застосовують украй рідко.

Реальність малого бізнесу скромніша й передбачуваніша. Найчастіше сценарій такий: користувач скаржиться, регулятор присилає припис виправити порушення, і якщо ви виправляєте — на цьому все закінчується. Штрафи за «дрібниці» зазвичай вимірюються тисячами, рідше десятками тисяч євро, і тяжкість сильно залежить від того, чи виправили ви проблему після скарги й чи не було злого наміру. За галузевими спостереженнями, типовий «дрібний» кейс — це не розорення, а прикрість плюс термінова переробка під наглядом. Але саме цю прикрість найдешевше не допустити.

Ось за що реально ловлять малий і середній бізнес — за спаданням частоти:

1. Трекери вантажаться до згоди. Найчастіше й найдоказовіше. Відкрив сайт, подивився Network — порушення видно одразу.
2. Немає кнопки «Відхилити» або вона захована. Банер «тільки ОК» або відмова через лабіринт налаштувань.
3. Немає політики конфіденційності або вона не про цей сайт. Скопійований текст, який розходиться з реальністю.
4. Маркетингова згода передзаповнена або вшита в спільну галочку. Підписка без окремої активної згоди.
5. Сервіси-отримувачі не вказані. Pixel, чат, розсилка стоять, а в політиці їх немає.

Зверніть увагу на закономірність: майже все в цьому списку — не про «захист даних» у високому сенсі, а про конкретні елементи інтерфейсу й пару рядків коду. Це і є добра новина. Відповідність GDPR для типового бізнес-сайту — задача інженерна й скінченна, а не бездонна юридична яма.

GDPR для сайту без сліпої аналітики: робоча звʼязка

Головний страх власника звучить так: «Якщо я все закрию згодою, половина людей натисне „Відхилити“, і я осліпну». Це розвʼязне, і розвʼязується без порушень.

По-перше, аналітика без cookie виводить базові метрики з-під згоди — ви бачите відвідуваність за всіма візитами, а не лише за тими, хто погодився. Для більшості сайтів цього достатньо, щоб розуміти зростання й лагодити вузькі місця. По-друге, навіть на GA грамотне налаштування режиму згоди дозволяє збирати знеособлену агреговану статистику по тих, хто відмовився, — без персональних даних, але з розумінням обсягу. По-третє, конверсії, привʼязані до самих дій (надіслав форму, дійшов до сторінки подяки), часто можна рахувати без клієнтських трекерів узагалі.

Звʼязка, яку ми ставимо на проєктах за замовчуванням і яка тримає і закон, і видимість, виглядає так:

1. Суворо необхідні cookie вантажаться одразу — сесія, мова, захист форм. Сайт працює з першої секунди.
2. Банер згоди з чесною кнопкою «Відхилити» на одному рівні з «Прийняти» й гранулярністю за категоріями.
3. Аналітика без cookie як база — відвідуваність видно завжди, банер для неї у багатьох випадках не потрібен.
4. GA або Pixel — лише якщо бізнесу реально потрібен ретаргетинг, і тільки за згодою, з Consent Mode.
5. Антиспам без трекерів на формах, щоб не плодити зайвих узгоджень.
6. Політика конфіденційності, написана під реальний стек сайту, зі списком саме ваших сервісів.

Це не теорія — це те, як ми збираємо сайти, щоб клієнт не вибирав між «за законом» і «бачу цифри». До речі, багато з цих рішень заодно прискорюють сайт: менше важких сторонніх скриптів — кращі Core Web Vitals (LCP, INP, CLS), а отже й позиції в пошуку. Відповідність і швидкість тут тягнуть в один бік, а не в різні.

І ще одне, про що забувають, вважаючи GDPR окремою темою: доступність. Банер згоди має керуватися з клавіатури й читатися скрінрідером — інакше ви ризикуєте водночас порушити і правила про згоду, і вимоги доступності, які в ЄС із 2025 року стали жорсткішими. Той самий інтерфейс, який ви робите чесним для регулятора з даних, розумно одразу зробити чесним і для користувача з обмеженнями.

З чого почати цього тижня

Якщо у вас уже є сайт і ви не впевнені, що він у порядку, не треба переписувати все разом. За спаданням віддачі й простоти:

1. Відкрийте свій сайт в анонімному режимі й перевірте Network до кліку по банеру. Чи вантажаться трекери? Якщо так — це перше, що лагодити.
2. Перевірте кнопку «Відхилити». Чи є вона взагалі, чи на одному рівні з «Прийняти», чи справді вона блокує трекери. Натисніть і знову подивіться Network.
3. Відкрийте свою політику конфіденційності й звірте зі списком того, що реально стоїть на сайті. Усі сервіси згадані? Немає зайвих із чужого шаблону?
4. Подивіться на форми. Чи є посилання на політику, чи окрема згода на розсилку, чи по HTTPS ідуть дані.
5. Вирішіть щодо аналітики. Чи потрібен вам ретаргетинг, чи вистачить чесних цифр відвідуваності без cookie — від цієї відповіді залежить, наскільки складним буде ваш банер.

Зробіть ці пʼять перевірок — і ви закриєте переважну більшість реальних ризиків, за якими штрафують малий бізнес. Решта — це вже тонке налаштування, а не діри, в які провалюються.

Хто зрештою спить спокійно

Повернімося до листа від регулятора з першого абзацу. Бізнес, у якого банер вантажить трекери тільки після згоди, у якого кнопка «Відхилити» працює, політика описує реальний стек, а форми зібрані чесно, — на таку скаргу відповідає одним абзацом і скриншотом, і історія закривається. Бізнес, який повісив «ОК» і забув, відповідає переробкою під наглядом і нервами.

Різниця між ними — не в тому, хто більше боїться закону. Вона в тому, хто поставився до GDPR як до інженерної задачі зі зрозумілим чек-листом, а не як до паперового заклинання чи приводу для паніки. Правильно зібраний сайт збирає майже всі дані, потрібні для зростання, не дає регулятору жодної зачіпки і заодно вантажиться швидше. А неправильний платить двічі: один раз за переробку за скаргою, другий — сліпотою в аналітиці, бо з переляку вимкнув те, що збирати було можна. GDPR для сайту у 2026 році — це не про те, щоб менше знати про своїх клієнтів. Це про те, щоб знати рівно стільки, скільки дозволено, і спати спокійно.