Посібник з інтеграції згоди на файли cookie Webflow: Нативний банер, користувацький код та CMP третіх сторін для 2026
Webflow займає унікальну позицію в екосистемі конструкторів веб-сайтів. Ближче до інструменту дизайну, ніж до CMS, ближче до CMS, ніж до хостингової платформи для програм, і дедалі більше стає платформою вибору для агентств, коли вони хочуть повністю налаштованих маркетингових сайтів без інженерного тягаря управління стеком Next.js або Drupal. Webflow надає нативний банер Cookie Consent з розумними налаштуваннями за замовчуванням, відкриває ін'єкцію Custom Code на рівні сайту та сторінки, інтегрується з вбудованим HTML і надає операторам модель CMS Collections. Сайт Webflow, який активував лише нативний банер, рідко є повністю відповідним; сайт, який пов'язав нативний банер із CMP третьої сторони, заблокував свій Custom Code і перевірив вбудовані скрипти, є одним із найчистіших проектів, які агентство може надати у 2026 році.
Що робить нативний Cookie Consent Webflow і де він зупиняється
Webflow додав нативну функцію Cookie Consent у 2022 році і з тих пір розвиває її. Функція підтримує три попередньо встановлені категорії файлів cookie — Essential, Marketing і Personalization — відкриває налаштовуваний інтерфейс банера через налаштування проекту і пов'язує блокування Google Analytics із вибором користувача. Банер фіксує згоду користувача у файлі cookie першої сторони.
Чого нативний банер Webflow не робить — і де більшість реалізацій, побудованих агентствами, зазнають невдачі — це блокування Custom Code, який оператори регулярно додають для аналітики, маркетингових пікселів, чат-віджетів і вбудованих відео. Точки ін'єкції Custom Code запускаються до відображення банера, тобто скрипти третіх сторін, додані через ці точки, виконуються до того, як з'явиться рішення про згоду. Агентства часто додають Hotjar, Facebook Pixel, скрипти CRM третіх сторін або Calendly embed через Custom Code і вважають, що нативний банер обробляє їх блокування. Не обробляє.
Налаштування opt-in за замовчуванням vs. мовчазна згода
Нативний банер відкриває три стилі згоди. Стиль мовчазної згоди був джерелом повторюваних регуляторних висновків проти сайтів, розміщених Webflow у EEA. Стиль opt-in є правильним налаштуванням за замовчуванням для будь-якої реалізації, що орієнтується на EEA, Велику Британію, Бразилію, Швейцарію або будь-яку іншу юрисдикцію, яка прийняла стандарти GDPR. Оператори повинні вибрати opt-in, налаштувати категорії так, щоб вони були вимкнені за замовчуванням, і перевірити в попередньому перегляді, що кнопка відхилення є принаймні настільки ж візуально помітною, як кнопка прийняття.
Блокування Custom Code: робота, яку нативний банер не виконує
Робочий шаблон інтеграції у Webflow складається з трьох частин. По-перше, правильне налаштування нативного банера. По-друге, загортання кожного скрипту Custom Code у перевірку згоди перед виконанням. По-третє, вирішення, чи достатньо нативного банера або чи повинен CMP третьої сторони замінити його для відстеження аудиту та можливості налаштування за постачальником.
Найпростіший шаблон блокування — зчитування файлу cookie згоди Webflow або стану згоди з JavaScript hook, що відкривається платформою, і умовне виконання логіки третьої сторони. Для скриптів, доданих у розділ Footer Code, шаблон полягає у загортанні фрагмента коду в обробник подій, що активується при події зміни згоди Webflow. Для скриптів у розділі Head Code — де розміщено більшість фрагментів аналітики та пікселів — шаблон полягає у завантаженні фрагмента як заповнювача, з відкладанням фактичного запиту третьої сторони до проходження перевірки згоди.
Шаблон заповнювача для скриптів третіх сторін
Шаблон, що працює в більшості поширених інтеграцій Webflow, є заповнювач <script type="text/plain">. Скрипт третьої сторони включено до розмітки сторінки але з атрибутом type, встановленим на значення, яке браузер не виконуватиме. Невеликий bootstrap скрипт — доданий один раз у розділ Footer Code — прослуховує подію зміни згоди Webflow, ідентифікує скрипти-заповнювачі, що відповідають заданій категорії, і перезаписує їхній атрибут type на text/javascript для виконання. Шаблон ідентичний тому, що використовує модуль EU Cookie Compliance Drupal і який Cloudflare Zaraz застосовує на межі.
Варіанти CMP третіх сторін: коли нативного банера недостатньо
Для сайтів, яким потрібне більш повне відстеження аудиту, конфігурація за постачальником, логіка для кількох юрисдикцій або інтеграція з IAB TCF, нативного банера недостатньо і CMP третьої сторони — Cookiebot, OneTrust, Usercentrics, Iubenda — повинен замінити його. Нативний банер необхідно спочатку вимкнути.
- Інтеграція Cookiebot — встановіть фрагмент Cookiebot через Custom Code у розділі Head, позначте скрипти, керовані Cookiebot, атрибутами data-cookieconsent і вимкніть нативний банер Webflow у налаштуваннях проекту.
- Інтеграція OneTrust — встановіть фрагмент CDN OneTrust, налаштуйте панель управління OneTrust для зчитування структури категорій Webflow і вимкніть нативний банер.
- Інтеграція Usercentrics — встановіть фрагмент Usercentrics, налаштуйте визначення сервісів у панелі управління Usercentrics, що відображають фактичний інвентар тегів оператора, і вимкніть нативний банер.
- Інтеграція Iubenda — встановіть фрагмент Iubenda Consent Solution, налаштуйте політику та відображення категорій і вимкніть нативний банер.
Webflow CMS Collections і динамічно відтворений вміст
CMS Collections Webflow заслуговує особливої уваги, оскільки вводить поверхню згоди, якої у статичних сторінок немає. Сторінка Collection, що вбудовує віджет третьої сторони — YouTube embed у публікації блогу, TikTok-стрічка на сторінці портфоліо — успадковує рішення про згоду, прийняті на хостинговій сторінці, але вбудований вміст автоматично не поважає ці рішення, якщо оператор не налаштував Collection для відтворення embed через заповнювачі click-to-load.
Валідація та стан аудиту для 2026 року
Захищувана реалізація Webflow у 2026 році повинна пройти чотири технічні перевірки. По-перше, чисті сеанси браузера, що обслуговуються з IP-адреси EEA, повинні виробляти нуль несуттєвих файлів cookie до активації банера. По-друге, шлях відхилення повинен підтримувати цей стан. По-третє, шлях прийняття повинен виробляти лише теги, на які користувач погодився, а журнал згоди повинен містити відповідний запис. По-четверте, відкликання повинно негайно зупинити подальшу активацію тегів і поширити opt-out на одержувачів третіх сторін нижнього рівня.
Нативний банер фіксує стан згоди користувача у файлі cookie першої сторони але не веде журнал аудиту на стороні сервера, який можна запитувати за ідентифікатором користувача або сеансу. Для реалізацій, яким потрібне більш повне відстеження аудиту — звітність для кількох юрисдикцій, записи згоди за постачальником, інтеграція з очікуваними стандартами документації EDPB — CMP третьої сторони є правильною відповіддю. Сайт Webflow, який свідомо вибрав між двома шляхами, заблокував кожну поверхню Custom Code і вирішив шаблон embed для Collection, перетворив простоту візуального конструктора платформи на захищувану частину позиції згоди агентства замість прихованого боргу відповідності.