ما يفعله Cookie Consent الأصلي في Webflow وأين يتوقف

أضافت Webflow ميزة Cookie Consent الأصلية في 2022 وطورتها منذ ذلك الحين. من الصندوق، تدعم الميزة ثلاث فئات مسبقة الإعداد — Essential وMarketing وPersonalization — وتتيح واجهة بانر قابلة للتهيئة من إعدادات المشروع، وتربط إيقاف Google Analytics باختيار المستخدم. يسجل البانر موافقة المستخدم في ملف تعريف ارتباط من الطرف الأول ويكشف حالة الموافقة لأدوات Webflow المتكاملة. عندما يُمكّن المشغل الميزة ويُهيئ الفئات ويختار نمط الموافقة (opt-in أو opt-out أو implicit)، تتولى المنصة البانر المرئي والإيقاف الأساسي لتكاملاتها الأصلية.

ما لا يفعله البانر الأصلي لـ Webflow — وحيث تفشل معظم عمليات النشر التي بنتها الوكالات — هو إيقاف الكود المخصص الذي يضيفه المشغلون للتحليلات وبكسلات التسويق وأدوات المحادثة والفيديوهات المُضمَّنة. نقاط حقن الكود المخصص تعمل قبل أن يُعرض البانر، مما يعني أن أي سكريبت من طرف ثالث يُضاف عبر هذه النقاط يُنفَّذ قبل أي قرار موافقة. توثيق Webflow يوضح ذلك صراحةً، لكن الواقع العملي هو أن الوكالات كثيراً ما تضيف Hotjar أو Facebook Pixel أو سكريبت CRM من طرف ثالث أو Calendly عبر الكود المخصص وتفترض أن البانر الأصلي يتولى الإيقاف. هذا غير صحيح.

الإعداد الافتراضي: opt-in مقابل الموافقة الضمنية

يتيح البانر الأصلي لـ Webflow ثلاثة أنماط للموافقة. نمط الموافقة الضمنية — حيث تُعامَل زيارة الموقع على أنها موافقة حتى يرفض المستخدم — كان مصدر نتائج متكررة من الجهات التنظيمية ضد المواقع المستضافة على Webflow عبر EEA. نمط opt-in هو الإعداد الافتراضي الصحيح لأي نشر يستهدف EEA أو المملكة المتحدة أو البرازيل أو سويسرا أو أي ولاية قضائية استوردت معيار GDPR. يجب على المشغل اختيار opt-in، وتهيئة الفئات لتكون مُعطَّلة افتراضياً، والتحقق في المعاينة من أن زر الرفض بارز بصرياً على الأقل بقدر زر القبول. هذه هي الإعدادات الثلاثة التي تحول البانر الأصلي إلى نقطة بداية للامتثال.

إيقاف الكود المخصص: العمل الذي لا يقوم به البانر الأصلي

نمط التكامل الذي يعمل على Webflow له ثلاثة أجزاء. أولاً، تهيئة البانر الأصلي بشكل صحيح. ثانياً، تغليف كل سكريبت كود مخصص في فحص موافقة قبل تنفيذه. ثالثاً، تحديد ما إذا كان البانر الأصلي كافياً أو ما إذا كان CMP من طرف ثالث يجب أن يحل محله لمسار التدقيق وإمكانية التهيئة لكل مورد.

أبسط نمط إيقاف هو قراءة ملف تعريف ارتباط موافقة 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 على الحافة — ما يتغير على Webflow هو أن المشغل يجب أن يضيف bootstrap بنفسه.

خيار CMP من طرف ثالث: عندما لا يكون البانر الأصلي كافياً

للمواقع التي تحتاج مسار تدقيق أكثر اكتمالاً، أو تهيئة لكل مورد، أو منطق متعدد الولايات القضائية، أو تكامل مع IAB TCF، فإن البانر الأصلي غير كافٍ ويجب أن يحل محله CMP من طرف ثالث — Cookiebot أو OneTrust أو Usercentrics أو Iubenda أو ما شابه. نمط التكامل واضح لكنه يتطلب إيقاف البانر الأصلي أولاً، وإلا ستتعارض سطحا الموافقة وسيرى المستخدم كليهما.

• تكامل Cookiebot — تثبيت مقتطف Cookiebot عبر Custom Code في قسم Head، وتعليم السكريبتات بسمات data-cookieconsent، وتعطيل البانر الأصلي في إعدادات المشروع.
• تكامل OneTrust — تثبيت مقتطف OneTrust CDN، وتهيئة لوحة OneTrust لقراءة هيكل فئات Webflow، وإيقاف البانر الأصلي.
• تكامل Usercentrics — تثبيت مقتطف Usercentrics، وتهيئة تعريفات الخدمة في لوحة Usercentrics التي تعكس مخزون العلامات الفعلي للمشغل، وتعطيل البانر الأصلي.
• تكامل Iubenda — تثبيت مقتطف Iubenda Consent Solution، وتهيئة السياسة وربط الفئات، وتعطيل البانر الأصلي.

CMS Collections في Webflow والمحتوى المُقدَّم ديناميكياً

تستحق CMS Collections في Webflow اهتماماً خاصاً لأنها تُقدم سطح موافقة لا تملكه الصفحات الثابتة. صفحة المجموعة التي تُضمّن أداة من طرف ثالث — YouTube مُضمَّن في مقال أو TikTok في صفحة محفظة — ترث قرارات الموافقة المتخذة على الصفحة المستضيفة، لكن المحتوى المُضمَّن لا يحترم هذه القرارات تلقائياً ما لم يُهيئ المشغل المجموعة لتُقدم الـ embed عبر عنصر نائب للنقر للتحميل. النمط هو إضافة حقل مجموعة لرابط الـ embed وحقل منفصل يُحدد فئة الموافقة المطلوبة، ثم تقديم الـ embed بشكل مشروط عبر Custom Code على قالب المجموعة.

التحقق وموقف التدقيق لعام 2026

يجب أن يجتاز نشر Webflow القابل للدفاع في 2026 أربعة فحوصات تقنية. أولاً، يجب أن تُنتج جلسة متصفح نظيفة تُقدَّم من عنوان IP ضمن EEA صفراً من ملفات تعريف الارتباط غير الأساسية قبل اتخاذ إجراء على البانر — تغطي ملفات تعريف الارتباط التي تديرها Webflow وسكريبتات الكود المخصص والأدوات المُضمَّنة وأي محتوى من طرف ثالث مُقدَّم عبر المجموعات. ثانياً، يجب أن يُبقي مسار الرفض على هذه الحالة. ثالثاً، يجب أن يُنتج مسار القبول فقط العلامات التي وافق عليها المستخدم، ويجب أن يحتوي سجل الموافقة على السجل المطابق. رابعاً، يجب أن يوقف السحب فورياً أي إطلاق علامات إضافي، وتنتهي صلاحية ملفات تعريف الارتباط المُعيَّنة خلال الجلسة الموافق عليها، وينتشر إلغاء الاشتراك إلى أي جهات خارجية.

سؤال مسار التدقيق هو حيث يُظهر البانر الأصلي لـ Webflow حدوده حالياً. يُسجل البانر الأصلي حالة موافقة المستخدم في ملف تعريف ارتباط من الطرف الأول لكنه لا يحتفظ بسجل تدقيق من جانب الخادم قابل للاستعلام بمعرف المستخدم أو معرف الجلسة. للنشريات التي تحتاج مسار تدقيق أكثر اكتمالاً — التقارير متعددة الولايات القضائية وسجلات الموافقة لكل مورد والتكامل مع معيار التوثيق المتوقع من EDPB — فإن CMP من طرف ثالث هو الإجابة الصحيحة. للنشريات التي تعمل أساساً في ولايات قضائية ذات توقعات أخف لمسار التدقيق، يكفي البانر الأصلي بشرط وجود نمط إيقاف الكود المخصص ومعالجة الـ embed. موقع Webflow الذي اختار بين المسارين بشكل متعمد، وأوقف كل سطح كود مخصص، وعالج نمط embed المجموعات هو موقع حوّل بساطة المُنشئ المرئي إلى جزء قابل للدفاع من موقف الموافقة بدلاً من أن يكون ديناً خفياً للامتثال.