מה עושה Cookie Consent המובנה של Webflow ואיפה הוא נעצר

Webflow הוסיפה את תכונת Cookie Consent המובנית ב-2022 ושיפרה אותה מאז. התכונה תומכת בשלוש קטגוריות עוגיות מוגדרות מראש — Essential, Marketing ו-Personalization — חושפת ממשק באנר הניתן להגדרה דרך הגדרות הפרויקט ומקשרת את חסימת Google Analytics לבחירת המשתמש. הבאנר רושם את הסכמת המשתמש בעוגיית צד ראשון.

מה שהבאנר המובנה של Webflow לא עושה — ואיפה רוב מימושי הסוכנויות נכשלים — הוא חסימת ה-Custom Code שמפעילים מוסיפים בקביעות לצורך ניתוחים, פיקסלים שיווקיים, ווידג'טים לצ'אט ווידאו מוטמע. נקודות ההזרקה של Custom Code רצות לפני שהבאנר מוצג, כלומר כל סקריפט של צד שלישי שנוסף דרך נקודות אלו מופעל לפני קיומה של החלטת הסכמה כלשהי. סוכנויות מוסיפות לעתים קרובות Hotjar, Facebook Pixel, סקריפט CRM של צד שלישי או Calendly embed דרך Custom Code ומניחות שהבאנר המובנה מטפל בחסימה. הוא לא מטפל.

הגדרת ברירת המחדל opt-in לעומת הסכמה מרומזת

הבאנר המובנה חושף שלושה סגנונות הסכמה. סגנון ההסכמה המרומזת היה מקור לממצאים חוזרים של רגולטורים נגד אתרים המתאחסנים ב-Webflow ב-EEA. סגנון opt-in הוא ברירת המחדל הנכונה לכל מימוש המכוון ל-EEA, UK, ברזיל, שוויץ או כל תחום שיפוט שאימץ את תקן GDPR. על המפעיל לבחור opt-in, להגדיר את הקטגוריות ככבויות כברירת מחדל ולאמת בתצוגה מקדימה שכפתור הדחייה בולט חזותית לפחות כמו כפתור הקבלה.

חסימת Custom Code: העבודה שהבאנר המובנה לא עושה

תבנית השילוב הפועלת ב-Webflow כוללת שלושה חלקים. ראשית, הגדרה נכונה של הבאנר המובנה. שנית, עטיפת כל סקריפט Custom Code בבדיקת הסכמה לפני הפעלתו. שלישית, החלטה אם הבאנר המובנה מספיק או שמא CMP של צד שלישי צריך להחליף אותו.

תבנית החסימה הפשוטה ביותר היא לקרוא את עוגיית ההסכמה של Webflow או את מצב ההסכמה מ-JavaScript hook שהפלטפורמה חושפת ולהפעיל את לוגיקת הצד השלישי באופן מותנה. עבור סקריפטים שנוספו בסעיף Footer Code, התבנית היא לעטוף את ה-snippet ב-event listener המופעל על ידי אירוע שינוי ההסכמה של Webflow. עבור סקריפטים בסעיף Head Code — שם מתגוררים רוב ה-snippets של אנליטיקה ופיקסלים — התבנית היא לטעון את ה-snippet כ-placeholder, כשהבקשה בפועל של הצד השלישי נדחית עד שבדיקת ההסכמה עוברת.

תבנית ה-placeholder לסקריפטים של צד שלישי

התבנית הפועלת ברוב שילובי Webflow הנפוצים היא ה-placeholder <script type="text/plain">. סקריפט הצד השלישי כלול בסמן הדף אך עם המאפיין type מוגדר לערך שהדפדפן לא יריץ. סקריפט bootstrap קטן — נוסף פעם אחת לסעיף Footer Code — מאזין לאירוע שינוי ההסכמה של Webflow, מזהה סקריפטי placeholder התואמים לקטגוריה שניתנה ומכתיב מחדש את המאפיין type שלהם ל-text/javascript כדי שיופעלו. התבנית זהה לזו שמודול EU Cookie Compliance של Drupal משתמש בה ושCloudflare Zaraz מיישם בקצה.

אפשרות ה-CMP של צד שלישי: כשהבאנר המובנה אינו מספיק

לאתרים הזקוקים למסלול ביקורת מלא יותר, הגדרה לפי ספק, לוגיקה רב-תחומית או שילוב עם IAB TCF, הבאנר המובנה אינו מספיק ו-CMP של צד שלישי — Cookiebot, OneTrust, Usercentrics, Iubenda — צריך להחליף אותו. יש לכבות את הבאנר המובנה תחילה.

• שילוב Cookiebot — התקנת snippet של Cookiebot דרך Custom Code בסעיף Head, סימון סקריפטים המנוהלים על ידי Cookiebot עם מאפייני data-cookieconsent וכיבוי הבאנר המובנה של Webflow בהגדרות הפרויקט.
• שילוב OneTrust — התקנת snippet CDN של OneTrust, הגדרת לוח הבקרה של OneTrust לקריאת מבנה הקטגוריות של Webflow וכיבוי הבאנר המובנה.
• שילוב Usercentrics — התקנת snippet של Usercentrics, הגדרת הגדרות שירות בלוח הבקרה של Usercentrics המשקפות את מלאי התגיות הבפועל של המפעיל, וכיבוי הבאנר המובנה.
• שילוב Iubenda — התקנת snippet של Iubenda Consent Solution, הגדרת המדיניות ומיפוי הקטגוריות וכיבוי הבאנר המובנה.

CMS Collections של Webflow ותוכן שמוצג באופן דינמי

CMS Collections של Webflow ראויים לתשומת לב מיוחדת כי הם מציגים משטח הסכמה שלדפים סטטיים אין. דף Collection המטמיע ווידג'ט של צד שלישי — YouTube embed בפוסט בלוג, TikTok feed בדף תיק עבודות — יורש את החלטות ההסכמה שהתקבלו בדף המארח שלו, אך התוכן המוטמע אינו מכבד אוטומטית החלטות אלו אלא אם המפעיל הגדיר את ה-Collection לעבד את ה-embed דרך placeholder של click-to-load.

אימות ועמדת ביקורת ל-2026

מימוש Webflow ניתן להגנה ב-2026 חייב לעבור ארבעה בדיקות טכניות. ראשית, סשן דפדפן נקי המוגש מכתובת IP ב-EEA חייב לייצר אפס עוגיות לא-חיוניות לפני שהבאנר הופעל. שנית, מסלול הדחייה חייב לשמור על אותו מצב. שלישית, מסלול הקבלה חייב לייצר רק תגיות שהמשתמש הסכים להן ויומן ההסכמה חייב להכיל את הרשומה התואמת. רביעית, ביטול חייב לעצור מיד הפעלות תגיות נוספות ולהפיץ את ה-opt-out לנמענים של צד שלישי.

הבאנר המובנה רושם את מצב ההסכמה של המשתמש בעוגיית צד ראשון אך אינו מנהל יומן ביקורת בצד השרת הניתן לשאילתה לפי מזהה משתמש או מזהה סשן. למימושים הזקוקים למסלול ביקורת מלא יותר — דיווח רב-תחומי, רשומות הסכמה לפי ספק, שילוב עם תקן התיעוד הצפוי של EDPB — CMP של צד שלישי הוא התשובה הנכונה. אתר Webflow שבחר ביודעין בין שני הנתיבים, חסם כל משטח Custom Code וטיפל בתבנית ה-embed של Collection, הפך את פשטות בונה הוויזואלי של הפלטפורמה לחלק ניתן להגנה מעמדת ההסכמה של הסוכנות במקום חוב תאימות נסתר.