広告リンク先の公開状態監視｜404・リダイレクト・フォーム停止を早期検知する方法
広告のクリック数は増えているのに問い合わせが届かない。調べると、ページ移転でリンク先が変わっていた、フォームの送信だけが失敗していた、ということがあります。配信状況と予算だけを見ていると、クリック後の不具合は見逃しやすくなります。
広告リンク先は、HTTP応答、最終到達URL、ページの表示、フォームの完了、計測の順に確認します。異常を見つけたら影響する広告を特定し、停止・代替URLへの変更・継続の判断者へ通知します。復旧はページが開くだけで終えず、利用者が目的の操作を完了できることを確かめてから配信を再開します。
コンバージョンファネルで見ると、広告クリックから問い合わせ完了までの途中にある障害は、その先の成果を止めます。ここでは広告文の改善や入札調整ではなく、配信中のリンク先を継続して点検する運用に絞ります。
本記事のポイント
- 広告リンク先はHTTP応答だけで判断せず、最終URL・表示・フォーム完了・計測を分けて確認します。
- 異常時は影響する広告を逆引きし、送信不能・計測不備・監視元の遮断を区別して停止と継続を判断します。
- 修復後は同じ訪問条件で受付まで再検証し、広告の再開判断と監視結果を一つの記録へ結び付けます。
広告リンク先の正常性は5つの層で判定する
Google広告のリンク先要件では、機能しないリンク先やクロールできないリンク先などが不承認の対象になります。公式案内は、4xx・5xx応答、DNSエラー、リダイレクトの不備、タイムアウト、認証要求などを例示しています。担当者のブラウザで一度開けたことだけでは、広告のリンク先として正常だと判断できません。
一方、広告ポリシーを満たすことと、自社の問い合わせ導線が正常であることは別の確認です。以下の5層を運用上の点検基準にすると、通信、表示、操作、計測のどこで止まっているかを分けられます。これは特定媒体が指定した監視方式ではなく、公式要件とブラウザの挙動を踏まえた実務上の設計です。参照した公式情報は2026年9月8日時点の内容です。
| 確認する層 | 正常の判断例 | 異常時に残す情報 |
|---|---|---|
| 通信 | DNS・TLS接続が成立し、想定するHTTP応答を得る | 時刻、監視地点、応答コード、接続エラー、所要時間 |
| 到達先 | 許可したドメイン・パスへ到達し、転送が循環しない | 開始URL、経由先、最終URL、クエリの保持状況 |
| 表示 | 広告で案内したサービス名、主要見出し、申込導線が見える | 画面、欠落した要素、端末・ブラウザ条件 |
| 操作 | 入力・確認・送信を進め、受付結果と保存先を照合できる | 失敗した段階、テスト識別子、受信・保存の確認結果 |
| 計測 | 同意条件に沿って期待するイベントが適切な回数で発生する | 同意状態、イベント名、発生回数、確認した範囲 |
HTTP 200は通信上の成功を示しますが、画面の正しさを保証しません。GoogleのHTTPステータスコードの公式解説でも、2xxを返していても空白やエラーメッセージなどの内容によってsoft 404と判断される場合があります。検索の扱いと広告審査を同一視せず、「成功コードだけで本文の品質は分からない」という点を点検へ取り入れます。
リダイレクトも回数だけで不良と決めません。正式な移転による転送と、意図しないトップページへの転送、ログインページへの転送、循環を区別します。許可する到達先と転送の目的を台帳へ記録し、変更時に見直します。Google検索向けの転送上限を、すべての広告媒体の共通仕様として流用しないことも必要です。
7段階で監視対象と確認シナリオを作る
図の流れを実装する際は、最初から全ページへ高頻度の送信テストをかけず、配信中のURLを整理し、低負荷の確認と操作を伴う確認を分けます。
- 広告とURLの対応を集める。媒体、アカウント、キャンペーン、広告の識別子、最終ページURL、モバイル用URL、トラッキング設定、配信期間、担当者を一覧にします。同じURLへ複数広告が向かう場合は、URL側から影響する広告を逆引きできるようにします。
- 到達先の期待値を決める。広告の設定から確認できるリンク先を起点に、想定するドメイン、パス、主要見出し、フォーム、完了状態を定義します。管理者としてログイン済みの画面ではなく、一般の新規訪問者に近い条件を用意します。
- HTTPと転送を確認する。GET応答と転送の経路を記録し、4xx・5xx、DNS・TLSエラー、タイムアウト、意図しない到達先を検知します。HEADとGETで挙動が異なるサイトもあるため、HEADが通っただけで本文取得を省略しません。
- 主要な表示と入力を確認する。スマートフォンとパソコンの優先する環境を選び、見出し、入力欄、同意欄、送信ボタンの表示・操作を確認します。Cookie同意前後、初回訪問、埋め込みフォームの読み込みを必要に応じて分けます。
- テスト送信の終点を決める。許可された専用のテスト情報で送信し、完了画面だけでなく、受付システムへの保存や通知の確認範囲を決めます。実際の営業配信や自動架電へ流れないよう、識別と除外を先に設定します。
- 計測を別判定にする。URLのパラメータ、同意条件、イベントの発火と重複を確認します。問い合わせは届くが計測だけ欠けるケースを、送信不能とは分けて通知します。広告管理画面への反映遅延まで即時障害と決めないようにします。
- 頻度と担当者を設定する。配信額、時間帯、変更頻度、復旧に必要な時間を基に、確認間隔、再確認回数、通知先、応答期限を決めます。ページ更新、フォーム変更、DNS変更、広告開始の直後には追加確認を行います。
たとえば重要な配信先では軽いURL確認を15分ごと、送信を伴う確認を配信開始前と変更後に行う、といった設計が考えられます。これは頻度の例であり、媒体要件や万能な推奨値ではありません。監視によるアクセスや登録数、サービス側の制限、通知を受けて対応できる時間帯を踏まえて調整します。監視が止まった場合に備え、最後の正常実行時刻が古くなったことも別に検知します。
URLパラメータの期待値はUTM命名規則と揃えます。ただし実際の有料広告を繰り返しクリックして試す運用は避け、媒体が用意するリンク先テストなどと、許可されたURLの直接確認を組み合わせます。直接アクセスは広告配信の全経路を再現するものではないため、トラッキング設定の確認範囲を記録します。
フォームの操作条件はBtoBフォームの機能要件と対応付けると、必須項目、入力エラー、同意、完了後の処理を点検しやすくなります。本番へのテスト送信ができない場合は、送信前までの監視と検証環境の送信試験を分け、「本番の保存先まで確認済み」とは記録しません。
誤検知を減らし、停止と再開の判断を揃える
ブラウザによる自動確認では、ページの読み込み終了を待つだけでなく、利用者が必要とする要素を明示的に確認します。Playwrightのナビゲーション解説は、loadイベントの後にもページが動的な処理を行うことを説明しています。画面が描かれた時点と、入力やクリックが実際に機能する時点がずれることもあります。
Playwrightのアサーションでは、要素の表示、入力可能状態、URL、テキストなどを期待値と比較できます。固定秒数の待機を長くするだけで対応せず、主要見出しが見える、フォームが入力できる、受付結果が現れるという業務上の条件を設定します。確認対象の文言が正当に変わった場合は、監視の期待値も承認して更新します。
403やCAPTCHAが出た場合は、監視環境だけが防御機構で止められた可能性と、一般訪問者もアクセスできない可能性を分けます。まず画面、レスポンス、端末条件を記録して通常の利用条件と比較し、短い間隔の再試行で遮断を悪化させないようにします。監視のために保護を全面解除したり、広告審査のクローラーだけ別の内容へ誘導したりする対処は行いません。
| 検知した事象 | 初動 | 再開・継続の確認 |
|---|---|---|
| 対象URLが404、継続する5xx、転送ループ | 別条件で再確認し、影響する広告を特定して停止判断へ送る | 正しいURL・本文・フォームの到達を確認する |
| ページは表示されるが送信不能 | 送信段階と保存先を切り分け、代替導線の有無を確認する | 専用テスト情報で受付と保存を照合する |
| 送信成功だが計測が欠落・重複 | 同意状態とイベントを確認し、計測担当と広告担当へ共有する | 実成果との照合と、入札への影響を判断する |
| 監視元だけ403・タイムアウト | 監視不能として扱い、通常環境とサービスの状態を確認する | 障害と監視の誤検知を区別して記録する |
停止単位は障害の範囲へ合わせます。一つのフォームだけの問題なら、そのフォームに誘導する広告を抽出します。全サイト障害なら共通ドメインを使う広告も確認します。誰が、何を根拠に、どの広告をいつ止めたかを残し、停止操作が媒体側で反映されたかも確認します。広告停止は既に開かれたページや既存の問い合わせを取り消すものではありません。
代替URLを使う場合は、広告文の約束、提供内容、対象者、必要な同意、計測との整合を確認します。単に開くからとトップページへ差し替えず、媒体の再審査や反映時間も見込みます。Google広告で不承認になっている場合は、サイト修復後も広告側の状態を確認し、必要な再審査手続きを行います。
配信の継続判断には広告予算のペーシング管理も関係します。停止による未消化を取り戻そうとして即座に予算を増やすと、修復確認が不十分なまま流入を戻すことになります。まず少量で状態を見られる再開条件を合意し、予算調整は正常性の確認と分けて判断します。
広告リンク先の復旧が完了するのは、ページが再び開いた時ではなく、同じ訪問条件で申込の受付まで確認し、影響した広告の再開判断と監視結果を結び付けて記録できた時です。
記録は、発見時刻、最後の正常確認、対象URL、広告の識別子、症状、利用条件、対応者、停止時刻、修復内容、再検証、再開時刻を一つの事象へまとめます。個人情報やトークンを含むURL、フォーム入力、画面は必要に応じて伏せ、調査に必要な範囲だけを残します。最後の正常確認と発見時刻の間は発生時刻の候補範囲であり、正確な障害開始時刻と断定しません。
よくある質問
HTTP 200なら広告リンク先は正常ですか？
正常とは限りません。誤った本文や空白ページ、動かないフォームも200を返すことがあります。主要表示と目的の操作まで確認します。
監視は何分ごとに行えばよいですか？
一律には決められません。配信額、変更頻度、対応時間、監視の負荷を基に設定し、軽いURL確認と送信を伴う確認で頻度を分けます。
監視ツールだけ403になる場合は広告を止めますか？
直ちに全広告を止めると決めず、監視不能として記録し、一般訪問者と広告側の到達状況を確認します。影響が確認された範囲に応じて停止を判断します。
本番フォームへテスト送信できない場合はどうしますか？
送信前までの本番監視と検証環境の送信試験を分けます。本番の受付・保存まで検証したとは扱わず、確認できていない範囲を運用記録に残します。
計測タグが読み込まれれば計測確認は完了ですか？
完了ではありません。同意条件に沿ったイベントの発生と重複、実際の受付との対応を確認します。媒体の集計遅延とイベント欠落を区別します。
ページを直したら広告は自動で再開しますか？
媒体と停止・不承認の状態によります。ページ、フォーム、計測を確認した後、広告側の状態や必要な再審査、配信反映を確認します。
広告から問い合わせまでの流れを見直し、計測と日々の改善を揃えたい場合は、ファネルAiのマーケティング支援をご確認ください。
