Webflow クッキー同意統合ガイド:ネイティブバナー、カスタムコード、2026年向けサードパーティCMP

WebflowはWebサイトビルダーのエコシステムにおいて独自の地位を占めています。CMSよりもデザインツールに近く、ホスト型アプリプラットフォームよりもCMSに近い存在です。Next.jsやDrupalスタックを自社で管理する技術的負担なしに完全カスタムのマーケティングサイトを求めるエージェンシーが選ぶプラットフォームとしてますます注目されています。Webflowは合理的なデフォルト設定を備えたネイティブなCookie Consentバナーを提供し、サイトレベルとページレベルでCustom Codeのインジェクションを可能にし、埋め込みHTMLと統合し、運営者にCMS Collectionsモデルを提供します。ネイティブバナーを有効にしただけのWebflowサイトが完全にコンプライアントであることはまれです。ネイティブバナーをサードパーティCMPと連携させ、Custom Codeをゲートし、埋め込みスクリプトを監査したサイトこそ、エージェンシーが2026年に提供できる最もクリーンなビルドの一つです。

WebflowのネイティブCookie Consentができることとその限界

Webflowは2022年にネイティブCookie Consent機能を追加し、以来改良を重ねてきました。この機能はEssential、Marketing、Personalizationの3つのプリセットクッキーカテゴリをサポートし、プロジェクト設定からアクセスできる設定可能なバナーUIを提供し、Google Analyticsのゲーティングをユーザーの選択に紐付けます。バナーはユーザーの同意をファーストパーティクッキーに記録します。

Webflowのネイティブバナーがしないことーーそしてエージェンシーが構築したほとんどのデプロイメントが不十分な点ーーは、運営者が分析、マーケティングピクセル、チャットウィジェット、埋め込み動画のために追加するCustom Codeをゲートすることです。サイトとページレベルのCustom Codeインジェクションポイントはバナーがレンダリングされる前に実行されるため、それらのポイントを通じて追加されたサードパーティスクリプトは同意決定が存在する前に実行されます。エージェンシーはしばしばHotjar、Facebook Pixel、サードパーティCRMスクリプト、またはCalendly埋め込みをCustom Code経由で追加し、ネイティブバナーがゲーティングを処理すると思い込みます。処理しません。

デフォルト設定:opt-in対implicit consent

ネイティブバナーは3つの同意スタイルを提供します。implicit consentスタイル(ユーザーが拒否するまでサイト訪問が同意とみなされる)は、EEA全域のWebflowホストサイトに対する規制当局の繰り返しの指摘の源となってきました。opt-inスタイルはEEA、英国、ブラジル、スイス、またはGDPR基準を取り入れた法域を対象とするあらゆるデプロイメントの正しいデフォルトです。運営者はopt-inを選択し、カテゴリをデフォルトでオフに設定し、プレビューで拒否ボタンが承諾ボタンと同等以上に視覚的に目立つことを確認する必要があります。

Custom Codeのゲート:ネイティブバナーがしない作業

Webflowで機能する統合パターンは3つのパートから構成されます。第一に、ネイティブバナーを正しく設定する。第二に、各Custom Codeスクリプトを実行前に同意チェックでラップする。第三に、ネイティブバナーで十分か、監査証跡とベンダーごとの設定可能性のためにサードパーティCMPに置き換えるべきかを決定する。

最もシンプルなゲーティングパターンは、WebflowのconsentsクッキーまたはプラットフォームのJavaScriptフックから同意状態を読み取り、条件付きでサードパーティロジックを実行することです。Footer Codeセクションに追加されたスクリプトの場合、スニペットをWebflowの同意変更イベントで発火するイベントリスナーでラップするパターンです。Head Codeセクションのスクリプト(ほとんどの分析・ピクセルスニペットが存在する場所)の場合、スニペットをプレースホルダーとして読み込み、同意チェックが通過するまで実際のサードパーティリクエストを延期するパターンです。

サードパーティスクリプトのプレースホルダーパターン

最も一般的なWebflow統合で機能するパターンは<script type="text/plain">プレースホルダーです。サードパーティスクリプトはページのマークアップに含まれますが、type属性をブラウザが実行しない値に設定します。Footer Codeセクションに一度追加する小さなbootstrapスクリプトがWebflowの同意変更イベントを監視し、付与されたカテゴリに一致するプレースホルダースクリプトを特定し、それらのtype属性をtext/javascriptに書き換えて実行します。このパターンはDrupalのEU Cookie ComplianceモジュールとCloudflare Zarazがエッジで適用するものと同じです。

サードパーティCMPという選択肢:ネイティブバナーでは不十分な場合

より完全な監査証跡、ベンダーごとの設定、多法域ロジック、またはIAB TCF統合が必要なサイトにはネイティブバナーでは不十分であり、サードパーティCMP(Cookiebot、OneTrust、Usercentrics、Iubendaなど)に置き換えるべきです。統合パターンは単純ですが、最初にネイティブバナーをオフにする必要があります。

Webflow CMS Collectionsと動的にレンダリングされるコンテンツ

Webflow CMS Collectionsは静的ページにはない同意サーフェスをもたらすため特別な注意が必要です。サードパーティウィジェットを埋め込むCollectionページ(ブログ記事内のYouTube埋め込み、ポートフォリオページのTikTokフィードなど)は、ホストページで行われた同意決定を継承しますが、運営者がCollectionをクリックtoロードのプレースホルダー経由で埋め込みをレンダリングするよう設定しない限り、埋め込みコンテンツはその決定を自動的に尊重しません。

2026年のバリデーションと監査姿勢

2026年に防御可能なWebflowデプロイメントは4つの技術的チェックに合格する必要があります。第一に、EEA IPアドレスから提供されたクリーンなブラウザセッションが、バナーが操作される前にゼロの非必須クッキーを生成すること。第二に、拒否パスがその状態を維持すること。第三に、承諾パスがユーザーが同意したタグのみを生成し、同意ログに対応するレコードが含まれていること。第四に、撤回によりさらなるタグ発火が即座に停止し、同意セッション中に設定されたクッキーが失効し、opt-outがダウンストリームのサードパーティ受信者に伝播すること。

ネイティブバナーはユーザーの同意状態をファーストパーティクッキーに記録しますが、ユーザーまたはセッション識別子でクエリ可能なサーバーサイド監査ログを保持しません。より完全な監査証跡が必要なデプロイメント(多法域レポート、ベンダーごとの同意記録、EDPBの期待する文書化基準との統合)にはサードパーティCMPが正しい答えです。2つのパスの間で意図的に選択し、すべてのCustom Codeサーフェスをゲートし、Collection埋め込みパターンに対処したWebflowサイトは、プラットフォームのビジュアルビルダーのシンプルさを隠れたコンプライアンス負債ではなくエージェンシーの同意姿勢の防御可能な部分に変えています。

← ブログ すべて読む →