Webflowフォームスパムを停止：視覚パズルなしで未承諾のピッチをフィルタリング
Webflowフォームには組み込みのハニーポットとreCAPTCHA統合があります。しかし、オフショアSEO提案、暗号通貨詐欺、AIブラウザボットは簡単にそれらをバイパスし、Webflowの月間フォーム制限を消費し、CRM自動化を汚染します。JevShieldはセマンティックなメッセージインテントを検査し、CRMに転送する前にメッセージインテントを評価します。
100
無料チェック / 月
$9
スターター / 月
5,000
スターターチェック / 月
7日間
アカウント検出ログ
ワークフローを比較
| ワークフローステージ | Webflowネイティブ + JevShield | 保護結果 |
|---|---|---|
| ボリューム型ボット防御 | 必要に応じて、WebflowネイティブのハニーポットまたはreCAPTCHAを有効にしたままにしてください。 | ブラウザチェックを追加します。ボリューム攻撃には別途レート制限を使用してください。 |
| クライアント側プリチェック | Webflowページのカスタムコードに軽量ヘルパースクリプト（shield.js）を追加します。 | ヘルパーが実行されると送信前にチェックします。ブロック判定はその送信を防ぐことができます。利用できないチェックは続行されます。クライアントコードはバイパスされる可能性があります。 |
| サーバーサイドWebhook | Webflowフォーム送信Webhookを、Make、Zapier、またはCloudflare Workers経由でJevShield APIにルーティングします。 | リードを HubSpot、Notion、または営業メールに転送する前にプロモーションスパムをフィルタリングします。 |
| 商用リードスコアリング | すべての送信は、スパム判定とともに 0-100 の購入意図スコアを受け取ります。 | 高意向のエンタープライズ問い合わせは即座にフラグが立てられ、営業がすぐにフォローアップします。 |
| 訪問者エクスペリエンス | 100%サイレントで目に見えず、絵のパズルや数学の課題はゼロ。 | 追加のCAPTCHAパズルはありません。チェックは待ち時間を増やし、メッセージを誤分類する可能性があります。 |
なぜ不要な営業提案がまだWebflowのスパム保護をバイパスするのか？
Webflowのネイティブスパム防御（ハニーポットフィールドとGoogle reCAPTCHA）は、HTTPクライアントが自動化されたマシンかどうかを検証するように設計されています。しかし、現代のスパムは主に人間のフリーランサーやAIブラウザエージェントによって送信されています。彼らは本物の訪問者のようにフォームと対話するため、WebflowとreCAPTCHAは彼らにグリーンライトを与えます。どちらのツールも、送信されたテキストが正当なプロジェクト問い合わせか、オフショアリンク構築の未承諾の営業提案かを検査しません。
Webflowフォームスパムの隠れたコスト: クォータとCRMのノイズ
Webflowでのスパム送信は実際の運用上の損害を引き起こします。送信許容量と請求は、現在のWebflowプランによって異なります。WebhookチェックはWebflowが送信を受け入れた後に発生し、クォータ使用量を元に戻すことはできません。さらに、WebflowをZapier、Make、またはHubSpotに接続すると、各スパム送信が有料の自動化タスクをトリガーし、営業パイプラインを汚染します。
方法1: オプションのクライアント側プリチェック
フォームにdata-formshieldを追加し、data-keyを付けてhttps://jevshield.com/shield.jsを読み込みます。ヘルパーはmessage、comment、comments、body、contentという名前のフィールド、およびemailとnameを読み取ります。ブロック判定は送信を防ぎます。レビュー、許可、利用不可のチェック、6秒のタイムアウトは継続します。ブラウザキーは可視であり、クライアントコードはバイパス可能です。公開サイトでネイティブのWebflow送信、検証、配信をテストしてください。これはクォータ保護を保証するものではありません。
方法2: サーバー側Webhookパイプライン（Make、Zapier、CRM向け）
純粋なバックエンド統合を好む場合は、Webflow Form Webhooks を設定してデータを自動化ワークフロー（Zapier、Make、Cloudflare Worker など）に送信します。API キーを使って POST https://jevshield.com/api/v1/check を呼び出します。判定が「allow」ならリードを CRM に渡し、review の結果は手動で処理します。最初は配信を抑制せずに観察を実行してください。受信側で強制と利用不可チェックのポリシーを実装する必要があります。
レシーバーで観察から始める
Webflow の webhook 受信側でログ記録のみのロールアウトを実装します。JevShield を呼び出してその判定を記録しますが、通常の配信フローは続けます。適用したアクションを POST /api/v1/report で報告します。これはサーバーコード内のポリシーであり、API のスイッチではありません。受信側がいつ送信を拒否すべきかを決める前に、検出ログと実際のメッセージ配信を検査してください。