Cookie Consent gốc của Webflow làm gì và dừng lại ở đâu

Webflow đã thêm tính năng Cookie Consent gốc vào năm 2022 và phát triển nó kể từ đó. Tính năng hỗ trợ ba danh mục cookie được thiết lập sẵn — Essential, Marketing và Personalization — hiển thị giao diện banner có thể cấu hình qua cài đặt dự án và liên kết việc chặn Google Analytics với lựa chọn của người dùng. Banner ghi lại sự đồng ý của người dùng trong cookie bên thứ nhất.

Điều banner gốc Webflow không làm — và nơi hầu hết các triển khai do agency xây dựng thất bại — là chặn Custom Code mà người vận hành thường xuyên thêm cho phân tích, pixel marketing, widget chat và video nhúng. Các điểm tiêm Custom Code chạy trước khi banner được hiển thị, nghĩa là các script bên thứ ba được thêm qua các điểm đó được thực thi trước khi quyết định đồng ý tồn tại. Các agency thường thêm Hotjar, Facebook Pixel, script CRM bên thứ ba hoặc Calendly embed qua Custom Code và giả định rằng banner gốc xử lý việc chặn chúng. Không xử lý.

Cài đặt opt-in mặc định so với đồng ý ngầm định

Banner gốc hiển thị ba kiểu đồng ý. Kiểu đồng ý ngầm định đã là nguồn gốc của các phát hiện quy định lặp đi lặp lại đối với các site được lưu trữ bởi Webflow ở EEA. Kiểu opt-in là mặc định đúng cho mọi triển khai nhắm mục tiêu EEA, UK, Brazil, Thụy Sĩ hoặc bất kỳ khu vực pháp lý nào khác đã áp dụng tiêu chuẩn GDPR. Người vận hành phải chọn opt-in, cấu hình các danh mục tắt theo mặc định và xác minh trong bản xem trước rằng nút từ chối ít nhất nổi bật về mặt hình ảnh như nút chấp nhận.

Chặn Custom Code: công việc mà banner gốc không làm

Mô hình tích hợp hoạt động trong Webflow có ba phần. Thứ nhất, cấu hình banner gốc đúng cách. Thứ hai, bọc mỗi script Custom Code trong kiểm tra đồng ý trước khi thực thi. Thứ ba, quyết định liệu banner gốc có đủ không hay CMP bên thứ ba có nên thay thế nó để theo dõi kiểm tra và khả năng cấu hình theo từng nhà cung cấp.

Mô hình chặn đơn giản nhất là đọc cookie đồng ý của Webflow hoặc trạng thái đồng ý từ JavaScript hook mà nền tảng hiển thị và thực thi logic bên thứ ba có điều kiện. Đối với các script được thêm trong phần Footer Code, mô hình là bọc đoạn code trong trình nghe sự kiện được kích hoạt trên sự kiện thay đổi đồng ý của Webflow. Đối với các script trong phần Head Code — nơi hầu hết các đoạn phân tích và pixel tồn tại — mô hình là tải đoạn code như một trình giữ chỗ, với yêu cầu thực tế của bên thứ ba bị trì hoãn cho đến khi kiểm tra đồng ý vượt qua.

Mô hình trình giữ chỗ cho script bên thứ ba

Mô hình hoạt động trên hầu hết các tích hợp Webflow phổ biến là trình giữ chỗ <script type="text/plain">. Script bên thứ ba được đưa vào đánh dấu trang nhưng với thuộc tính type được đặt thành giá trị mà trình duyệt sẽ không thực thi. Script bootstrap nhỏ — được thêm một lần trong phần Footer Code — lắng nghe sự kiện thay đổi đồng ý của Webflow, xác định các script trình giữ chỗ khớp với danh mục đã cho và ghi lại thuộc tính type của chúng thành text/javascript để thực thi. Mô hình giống với mô hình được sử dụng bởi module EU Cookie Compliance của Drupal và mà Cloudflare Zaraz áp dụng ở edge.

Tùy chọn CMP bên thứ ba: khi banner gốc không đủ

Đối với các site cần theo dõi kiểm tra đầy đủ hơn, cấu hình theo nhà cung cấp, logic đa khu vực pháp lý hoặc tích hợp với IAB TCF, banner gốc không đủ và CMP bên thứ ba — Cookiebot, OneTrust, Usercentrics, Iubenda — nên thay thế nó. Banner gốc phải được tắt trước.

• Tích hợp Cookiebot — cài đặt đoạn Cookiebot qua Custom Code trong phần Head, đánh dấu các script do Cookiebot quản lý bằng thuộc tính data-cookieconsent, và tắt banner gốc Webflow trong cài đặt dự án.
• Tích hợp OneTrust — cài đặt đoạn CDN OneTrust, cấu hình bảng điều khiển OneTrust để đọc cấu trúc danh mục Webflow và tắt banner gốc.
• Tích hợp Usercentrics — cài đặt đoạn Usercentrics, cấu hình định nghĩa dịch vụ trong bảng điều khiển Usercentrics phản ánh kho tag thực tế của người vận hành và tắt banner gốc.
• Tích hợp Iubenda — cài đặt đoạn Iubenda Consent Solution, cấu hình chính sách và ánh xạ danh mục và tắt banner gốc.

Webflow CMS Collections và nội dung được hiển thị động

CMS Collections của Webflow xứng đáng được chú ý đặc biệt vì chúng giới thiệu bề mặt đồng ý mà các trang tĩnh không có. Trang Collection nhúng widget bên thứ ba — YouTube embed trong bài đăng blog, feed TikTok trên trang portfolio — kế thừa các quyết định đồng ý được thực hiện trên trang đang lưu trữ nó, nhưng nội dung nhúng không tự động tôn trọng các quyết định đó trừ khi người vận hành đã cấu hình Collection để hiển thị embed thông qua trình giữ chỗ click-to-load.

Xác thực và vị trí kiểm tra cho năm 2026

Triển khai Webflow có thể bảo vệ vào năm 2026 phải vượt qua bốn kiểm tra kỹ thuật. Thứ nhất, các phiên trình duyệt sạch được phục vụ từ địa chỉ IP EEA phải tạo ra không cookie không thiết yếu nào trước khi banner được kích hoạt. Thứ hai, đường dẫn từ chối phải duy trì trạng thái đó. Thứ ba, đường dẫn chấp nhận phải chỉ tạo ra các tag mà người dùng đã đồng ý và nhật ký đồng ý phải chứa bản ghi tương ứng. Thứ tư, việc thu hồi phải ngay lập tức dừng các kích hoạt tag tiếp theo và truyền opt-out đến các bên nhận bên thứ ba ở downstream.

Banner gốc ghi lại trạng thái đồng ý của người dùng trong cookie bên thứ nhất nhưng không duy trì nhật ký kiểm tra phía server có thể được truy vấn theo định danh người dùng hoặc phiên. Đối với các triển khai cần theo dõi kiểm tra đầy đủ hơn — báo cáo đa khu vực pháp lý, hồ sơ đồng ý theo nhà cung cấp, tích hợp với các tiêu chuẩn tài liệu được EDPB kỳ vọng — CMP bên thứ ba là câu trả lời đúng. Website Webflow đã cố ý lựa chọn giữa hai con đường, chặn mọi bề mặt Custom Code và xử lý mô hình embed Collection, đã biến sự đơn giản của trình tạo trực quan của nền tảng thành một phần có thể bảo vệ trong vị trí đồng ý của agency thay vì khoản nợ tuân thủ ẩn.