Google広告を出稿していると、突然「機能していないリンク先」と表示されて広告やアセットが不承認になることがあります。
自分のブラウザでは普通に開けるのに落ちるケースも多く、原因がサーバーなのか設定なのか切り分けに迷いがちです。
このページでは、まず何から確認すべきかを順序立てて整理し、原因別に具体的な直し方までつなげます。
最後に、再審査の出し方と再発を防ぐ運用のポイントまでまとめて、同じトラブルで時間を溶かさない状態にします。
Google広告で機能していないリンク先と出たときの直し方
「機能していないリンク先」は、広告のリンク先が正常に表示できない、または正しく設定されていないと判断されたときに出やすい不承認理由です。
直し方のコツは、手当たり次第に触るのではなく、どのURLがどの環境で落ちているかを先に特定してから修正することです。
ここでは、最短で原因に近づくための確認順を、作業手順としてそのまま使える形でまとめます。
不承認の対象URLを先に特定する
最初にやるべきことは、「どの要素」が不承認なのかを分けることです。
広告本体の最終ページURLだけでなく、トラッキングテンプレート、カスタムパラメータ、最終ページURL（モバイル）が原因になることもあります。
管理画面のポリシー表示で対象の広告、アセット、URLを特定し、作業用メモに「不承認になっているURLの完全な文字列」をそのまま控えます。
この段階でURLを省略すると、後で別のURLを直してしまい、再審査でも同じ理由で止まることが増えます。
端末と回線を変えて同じURLを開く
次に、控えたURLを自分で開いて再現する作業に入ります。
PCとスマホ、Wi-Fiとモバイル回線、可能なら別ブラウザでも開き、どの組み合わせで失敗するかを見ます。
特定の端末だけで落ちるなら、モバイル向けリダイレクトや端末判定スクリプトが原因の可能性が高いです。
回線で結果が変わるなら、CDNやWAF、地域制限、ISP別の到達性の問題を疑うと切り分けが速くなります。
HTTPステータスを必ず確認する
「表示できるか」だけでなく、サーバーが何を返しているかを確認するのが重要です。
同じURLでも、タイミングによって一時的に503や500を返していると、クローラー側でエラーとして記録されることがあります。
管理画面の表示やサーバーログで、該当時間帯に4xxや5xxが出ていないか、リクエスト数が急増していないかを見ます。
ステータスが安定しない場合は、広告側の設定よりも先に、サーバーの負荷とエラーを潰すのが近道です。
リダイレクト連鎖と計測URLの順番を整理する
リダイレクトが多いと、途中でタイムアウトしたり、ループ扱いになったりして不承認になりやすくなります。
特に計測URLを挟む構成では、最終的に到達すべきURLまでの「段数」を減らすだけで改善することがあります。
http→https、www有無、末尾スラッシュ統一などの揺れがある場合は、統一ルールを作って常に同じ最終URLへ収束させます。
キャンペーン単位でUTMが異なる運用なら、同じLPでも複数のURLとして審査され得る点も意識します。
WAFやセキュリティでボットを弾いていないか疑う
人間は見られるのに不承認になる代表例が、セキュリティ対策がクローラーをブロックしているケースです。
アクセスが集中したときだけCAPTCHAが出る、特定のUser-Agentで403を返すなどがあると「機能していない」と判定されやすくなります。
WAFのログでGoogle系のクローラーがブロックされていないか、レート制限や国別ブロックが働いていないかを見ます。
もしブロックが原因なら、対象のURL群だけでも例外設定を入れ、審査時に安定して到達できる状態を先に作ります。
地域制限やログイン必須は審査でつまずきやすい
社内IPだけ許可、国内限定、会員ログイン必須などの設計は、審査やクローリングと相性が悪いことがあります。
特に国外からのアクセスを弾く設定があると、クローラーの到達環境によってエラー判定される可能性が上がります。
制約が必要な場合でも、広告のリンク先だけは一般環境で到達できる導線を用意し、アクセス制御は会員ページ側で行う方が安定します。
フォームの先でログインや二段階認証が必須になる場合も、入口ページは問題なく読める状態にしておくと判断が早くなります。
一時的不調を疑うなら監視と再試行の設計にする
「昨日まで配信できていたのに急に不承認」が起きるときは、一時的な障害や負荷が引き金のことがあります。
その場合は、原因を完全に特定する前に、まず安定稼働の条件を満たすことが最優先です。
応答速度、5xxの発生、証明書更新、DNSの切替など、落ちやすいイベントを洗い出して監視対象に入れます。
復旧後に再審査を急ぎすぎると、また不調のタイミングに当たりやすいので、安定している時間帯を選んで申請する方が通りやすくなります。
よくある原因をタイプ別に切り分ける
原因は大きく分けると「サーバー応答」「URLの設定」「到達性の制限」「クローラーとの相性」に集約できます。
ここでは、よく出るパターンを分類し、当てはまるものから優先して潰せるように整理します。
同じ症状でも原因が複数重なっていることがあるため、該当する型が複数ある前提で見ていくのが安全です。
サーバー応答が不安定なパターン
最も多いのは、サーバーが一時的にエラーコードを返してしまうパターンです。
アクセスの山、バッチ処理、DB負荷、メモリ枯渇などで応答が揺れると、審査側のアクセスが失敗した瞬間に不承認へ寄ります。
ログが取れているなら、広告の不承認が出た日時周辺のステータスとレスポンス時間を突き合わせます。
| 起きがちな兆候 | 5xx増加 |
|---|---|
| 主な原因 | 負荷集中 |
| 確認する場所 | サーバーログ |
| 優先対応 | 安定化 |
| 次の一手 | 再審査 |
URLの構造やパラメータが壊れているパターン
URLが長すぎたり、エンコードが崩れたりすると、アクセスできるはずのページでも到達に失敗することがあります。
とくに動的パラメータの受け渡しや、外部計測のリダイレクトを重ねている場合は発生しやすくなります。
一度、パラメータを最小にしたURLで正常に到達できる状態を作り、そこから段階的に戻すのが安全です。
- 不要なパラメータ削減
- エンコード整合
- リダイレクト段数削減
- 末尾スラッシュ統一
- www有無統一
SSLやDNSの揺れで到達できないパターン
証明書更新、CDN切替、DNSの伝播中は、環境によって別の結果になることがあります。
自分の環境で開けても、別環境では古いIPへ向いていたり、TLS交渉に失敗していたりすると不承認が出ます。
切替を行った直後は、広告のリンク先だけ先に固定化できないか、更新作業のタイミングをずらせないかも検討します。
短時間で戻る揺れなら、まず揺れが止まるまで待ってから再審査する方が結果が安定しやすいです。
アクセス制御でクローラーが弾かれるパターン
ボット対策、海外遮断、特定User-Agent遮断などがあると、審査側だけが弾かれて不承認になることがあります。
意図しない遮断の例として、攻撃対策のしきい値が低すぎる、リファラ必須、Cookie必須などがあります。
広告用のLPは、一般的なブラウザ条件で到達できることを優先し、強い制限はフォーム送信後や会員エリア側へ寄せるのが無難です。
どうしても制限が必要なら、例外ルールを作り、審査時に安定して到達できる条件を明示的に担保します。
Googleに到達させるための設定見直し
自分が見られる状態を作っても、クローラーが同じように見られるとは限りません。
ここでは、審査でつまずきやすい設定を中心に、到達性の観点での見直しポイントをまとめます。
修正の優先順位は「弾かれない」「迷子にさせない」「重くしない」の順で考えると整理しやすくなります。
robots.txtやメタ設定で入口を塞いでいないか確認する
クローラーの到達を考えると、意図せず入口を閉じていないかの確認が重要です。
とくにLPがサブディレクトリ配下にあり、全体の制御でDisallowが広くかかっていると、判定が不利になることがあります。
広告流入の入口ページについては、少なくとも表示に必要なリソースがブロックされない状態を目指します。
- 入口パスの許可
- 必要リソース許可
- 過剰な制限撤去
- テスト環境の遮断維持
弾いている条件を可視化して例外化する
WAFやCDNのルールは、設定した本人でも「何が弾かれているか」が見えにくいことがあります。
そのため、まずブロックログを取れる状態にして、どのルールが発火しているかを見える化します。
広告のリンク先に必要な最小限の例外を入れ、過剰な穴を開けずに到達性だけ担保するのが現実的です。
| 確認対象 | ブロックログ |
|---|---|
| よくある遮断 | 403返却 |
| 見直し単位 | URL単位 |
| 推奨対応 | 例外ルール |
| 再発防止 | 監視追加 |
モバイル向けの挙動が別物になっていないか見る
モバイルでだけ別LPに飛ばす、アプリ誘導が強い、表示が極端に遅いといった挙動は不承認の温床になります。
とくにスマホ回線では読み込みが遅くなりやすく、タイムアウトやエラー扱いにつながることがあります。
モバイル用の最終ページURLを設定している場合は、PC用と同じレベルで到達性と速度を確保します。
軽量化は見た目の改善だけでなく、審査や配信の安定化にも直結します。
外部タグやウィジェットが原因で崩れていないか確認する
LP自体は正しくても、外部の計測タグや埋め込みが落ちると表示が崩れることがあります。
タグマネージャー、チャットウィジェット、レビュー表示などが読み込めないと、白画面や無限ローディングになるケースもあります。
一度外部要素を最小化したLPで到達性を確保し、原因の切り分けがついたら必要なものだけ戻す流れが安全です。
「必須ではない装飾」を外せる設計にしておくと、緊急時の復旧が速くなります。
不承認を直した後の再審査と配信再開
修正が終わったら、次は再審査の手順に移ります。
ただし、直したつもりでも「別URLが同じ問題を抱えている」などで落ちることがあるため、再審査前の最終確認が重要です。
ここでは、申請の出し方と、通りやすくするための段取りをセットで整理します。
再審査の出し方を手順として整理する
不承認の対象が広告なのかアセットなのかで、操作する場所が少し変わります。
基本は、管理画面のポリシー関連の画面から対象を選び、修正完了後に再審査をリクエストする流れです。
修正内容が複数ある場合は、先に到達性の根本原因を直してからまとめて申請した方が、やり直しが減ります。
申請後にまたURLを触ると判定が揺れるため、申請前に「当面触らない状態」を作るのがコツです。
再審査前に見直すポイントを早見表にする
再審査で落ちる原因は、直したつもりでも別箇所が残っていることが多いです。
特に複数広告、複数アセットを運用している場合は、対象のURLが増える分だけ見落としが起きやすくなります。
申請前に、最低限ここだけは突き合わせる、という観点を表にしておくと漏れが減ります。
| 確認項目 | 最終URL |
|---|---|
| 確認項目 | モバイルURL |
| 確認項目 | 計測URL |
| 確認項目 | リダイレクト |
| 確認項目 | エラーコード |
反映までの間にやってはいけない動きを知る
再審査の結果が出るまでの間に、LPや計測設定を頻繁に触ると、判定が揺れて不承認が長引くことがあります。
復旧を急ぐほど、修正と申請を短い間隔で繰り返してしまい、結果的に通過が遅れる流れに入りがちです。
申請後は、サーバーの安定稼働と到達性の監視に集中し、余計な変更は控えます。
もし緊急変更が必要なら、変更内容を記録し、いつ何を変えたかを説明できる状態にしておくとトラブル対応が速くなります。
再発時に備えて証跡を残す
「自分は見られるのに不承認」は、再発すると原因追跡が難しくなりやすい問題です。
そのため、直したときの状態を証跡として残しておくと、次に同じ現象が起きたときに切り戻しが速くなります。
URL一覧、リダイレクト経路、WAF設定、エラー発生時刻などを最低限まとめておくと効果的です。
- 対象URL一覧
- 修正内容メモ
- 変更日時
- ログ保存先
- 監視結果
機能していないリンク先を未然に防ぐ運用設計
原因を直しても、同じ構造のままだと、負荷や切替イベントでまた同じ不承認が起きることがあります。
ここでは、広告運用の実務に落とし込める形で、再発しにくい設計の考え方をまとめます。
ポイントは「監視」「変更管理」「冗長化」の3つを、無理なく回せる粒度で入れることです。
死活監視と速度監視を最低限入れる
リンク先が落ちる前兆は、たいてい応答時間の悪化や断続的な5xxに出ます。
広告の出稿量が増えるほど、少しの遅延や不安定さが致命傷になりやすいです。
監視は完璧を目指すより、「落ちたら気づける」「悪化したら止められる」状態を優先します。
- 200応答監視
- 5xx監視
- 応答時間監視
- 証明書期限監視
- DNS変更監視
LPの変更を勝手に増やさないルールを作る
LPの改修、計測の追加、リダイレクト変更が重なると、原因が見えなくなって復旧が遅れます。
広告用LPは「配信中は変更を最小化する」など、運用ルールがあるだけでトラブルが減ります。
変更管理の観点を表で固定しておくと、担当が増えてもブレにくくなります。
| 運用ルール | 変更申請 |
|---|---|
| 運用ルール | 事前テスト |
| 運用ルール | 切替時間固定 |
| 運用ルール | ロールバック |
| 運用ルール | 記録必須 |
計測は複雑化させず復旧しやすくする
計測のためにリダイレクトや外部タグを増やすほど、到達性のリスクは上がります。
計測は「必須」と「任意」を分け、任意要素は障害時に外せる構造にしておくと復旧が速くなります。
タグの追加は段階的に行い、追加した直後に到達性と表示崩れがないかを確認する運用にすると安全です。
広告の成果最大化と、リンク先の安定稼働は両立が必要なので、構造の複雑化を前提にしない方が長期的に強くなります。
要点を整理して次の一手へ
Google広告で「機能していないリンク先」と出たら、最初に不承認の対象URLを特定し、端末と回線を変えて再現性を見ます。
次に、HTTPステータス、リダイレクト、計測URLの連鎖、WAFや地域制限など「クローラー側で落ちる原因」を優先して潰します。
修正後は、再審査前の見直し観点を固定して、対象URLの漏れや揺れを減らしたうえで申請します。
通過後も、死活監視と変更管理を最低限入れて、同じ不承認が繰り返されない運用に寄せることが重要です。
不承認は一度直すと終わりではなく、仕組みを整えるほど発生頻度が下がる問題なので、今回の切り分け手順をテンプレート化して回していきましょう。