Google広告「リンク先が機能していません」の原因と対処｜サイトが正常でも不承認になる切り分けフロー

自分のブラウザでLPを開いても普通に表示される。それなのにGoogle広告の管理画面には「リンク先が機能していません」の表示——この矛盾にぶつかって手が止まる運用担当者は少なくありません。サイトは正常、でも審査は通らない。この状態が起きているとき、多くの人は「サイト側は問題ない」という前提から抜け出せずに時間を失います。

この記事のポイント

• 審査しているのはあなたのブラウザではなくAdsBotというクローラーである
• 不承認の原因は9パターンに分類でき、層ごとに切り分けると当日中に特定できる
• robots.txtを直しても解決しない場合はWAF・CDN層でAdsBotが遮断されている
• リンク先を修正しただけでは再審査は始まらず、管理画面での申請操作が必須
• 日本向け配信でも海外IPからの到達性が必要という前提を理解する

「リンク先が機能していません」とは？サイトが正常でも不承認になるのはなぜか

Google広告における「リンク先が機能していません」とは、Googleの審査クローラーであるAdsBotが広告のリンク先URLに正常にアクセスできなかった場合に表示される不承認理由です。人間の目でサイトが表示されているかどうかとは、判定の主体がまったく別物です。

審査しているのは人間ではなくAdsBotというクローラー

Google AdsBot（AdsBot-Google、モバイル向けはAdsBot-Google-Mobile）は、広告のリンク先ページの品質と到達性を確認するために送り込まれる専用クローラーです。審査担当者が手作業でページを開いているわけではなく、このクローラーがHTTPリクエストを送り、返ってきたレスポンスをもとに機能しているかどうかを機械的に判定しています。ここを理解しないまま「サイトは正常だから原因不明」と結論づけてしまうと、修正の的が定まりません。

自分のブラウザで表示確認しても意味がない理由

ブラウザでの閲覧とAdsBotのアクセスでは、ユーザーエージェント、IPアドレス、Cookieの有無、認証情報の保持状態がすべて異なります。ログイン済みのブラウザでは表示されるが、ログアウト状態やシークレットウィンドウでは403エラーになる、という状態はよくあります。つまり「自分には見えている」は判定材料としてほぼ役に立たず、判断軸を「AdsBotから見えるか」に切り替える必要があります。

「リンク先の問題」系の不承認は4種類ある｜まず不承認理由を正確に特定する

不承認理由の文言を正確に読み取ることが最初のステップです。似た表記でも原因も直し方もまったく異なるためです。

管理画面で不承認理由を確認する場所

Google広告の管理画面では、広告グループまたは広告単位のステータス欄にカーソルを合わせるか、「ポリシーの詳細」を開くことで不承認理由の詳細文言を確認できます。ここに表示される文言をそのまま読み取らずに「なんとなくリンク先がダメらしい」で修正に入ると、見当違いの箇所を触って時間を浪費します。

各理由の意味と直すべき対象の対応表

海外の広告コンプライアンスガイドを扱うAudit Socialsの記事では、Destination requirements配下に11種類の不承認理由が存在し、「機能していない（Not working）」「不一致（Mismatch）」「アクセス・クロール不可（Not accessible/crawlable）」は原因も対処も別物であると整理されています。日本語のヘルプだけを見ていると混同しがちな部分なので、以下のように切り分けて考えるとよいと考えられます。

不承認理由	主な原因	直す対象
リンク先が機能していません	サーバーエラー・遮断・タイムアウト	サーバー・WAF・robots.txt
リンク先の不一致	広告文言とLP内容が対応していない	LPのコンテンツ・広告文
リンク先にアクセス/クロールできません	認証・IP制限・robots.txt	アクセス制御設定

このうち技術的な到達性が原因なのは「機能していません」と「アクセス・クロールできません」で、この記事はこの2つに焦点を当てています。コンテンツの表現自体が原因になっているケースは、コンテンツ内容が原因で不承認になるパターン（医療系の例）で扱う話に近く、技術層の切り分けとは別の対応が必要です。

不承認になる原因9パターン｜英語版ポリシーの分類で網羅する

不承認の技術的原因は、大きく4つの層に分けて9パターンに整理できます。英語版のGoogle Advertising Policies Helpでは、日本語ヘルプよりも一段細かい原因分類が示されています。

設定ミス系：URL誤り・ステージングURL・Basic認証の残置

タイプミスによるURL誤り、公開前に使っていたステージング環境のURLをそのまま設定してしまうケース、開発中にかけたBasic認証を外し忘れているケースです。特にBasic認証の残置は、担当者が「公開済みだから外したはず」と思い込みがちで見落とされやすいポイントです。

サーバー応答系：4xx/5xxエラー・タイムアウト・DNSエラー

404（ページ未検出）、403（アクセス拒否）、500番台のサーバーエラー、応答が遅くタイムアウトする状態、DNS設定の不備によって名前解決ができない状態です。サーバー負荷が高い時間帯だけAdsBotのアクセスがタイムアウトするような間欠的な事象もあり、これは一度の確認では見つけにくい原因です。

ブロック系：robots.txt・海外IP制限・WAFやBot対策によるAdsBot遮断

robots.txtでクローラーを一律拒否する記述、海外からのアクセスを一律遮断する設定、WAF（ファイアウォール）やBot対策サービスがAdsBotを不審なアクセスとして遮断しているケースです。日本語で書かれた記事の多くはrobots.txtと海外IP制限までで止まっていますが、実務ではこのWAF層が最もつまずきやすい部分だと考えられます。

遷移系：リダイレクトループ・リダイレクト過多・工事中/メンテナンス表示

リダイレクトが循環してループしている状態、リダイレクトの段数が多すぎてクローラーが追跡を打ち切る状態、メンテナンスモードで一時的に別ページを表示している状態です。リダイレクトが絡む不具合は、リダイレクトでGCLIDが消える問題の3層切り分けで扱う症状とも重なる部分があり、あわせて点検すると発見が早くなります。

原因の切り分けフロー｜どの層でAdsBotが止まっているかを当日特定する手順

原因を1つに絞り込むには、確認にかかる時間が短い順に手順を進めるのが効率的です。上から順に潰していけば、多くの場合は5ステップ以内で層が特定できます。

手順1：最終ページURLをシークレットウィンドウで直接開く

まずCookieやログイン状態の影響を排除するため、シークレットウィンドウで広告に設定している最終ページURLをそのまま開きます。ここで表示されなければ、URL設定ミスかサーバー側の単純な障害です。

手順2：Chrome DevToolsでユーザーエージェントをAdsBotにして再現確認

シークレットウィンドウで正常に表示される場合は、Chrome DevToolsのNetwork conditionsからユーザーエージェントをAdsBot-Googleに変更し、再度アクセスします。ここで403や404が返る、あるいは応答がないという場合は、ユーザーエージェント単位でAdsBotだけが狙い撃ちされてブロックされている可能性が高いと判断できます。この検証手順は日本語の競合記事ではあまり触れられていない部分です。

手順3：robots.txtにAdsBotを弾く記述がないか確認する

対象ドメインの「/robots.txt」を直接開き、User-agentの指定でAdsBotやすべてのクローラー（*）に対してDisallowが広くかかっていないかを確認します。Disallowが空欄でなくクロール対象パスを制限している記述があれば、そこが原因になっている可能性があります。

手順4：WAF・CDN・サーバーのログでAdsBotのブロック記録を探す

手順2でブロックが再現したのにrobots.txtには問題がない場合、次に疑うのはWAFやCDNの層です。海外の広告運用ブログAdelaide Socialsでは、AdsBotに対するブロックはファイアウォールのイベントログにユーザーエージェントでフィルタをかけることで確認できると解説されています。Cloudflareを利用している場合はSecurity Events、レンタルサーバーであれば管理画面のアクセスログやエラーログを確認します。

手順5：Search ConsoleのURL検査でクロール可否を確認する

Google Search Consoleに登録済みのプロパティであれば、URL検査ツールで対象URLのクロール状況・取得ステータスを確認できます。AdsBot専用の検査ではありませんが、Googlebot全般が到達できているかどうかの参考情報として活用できます。ここまでのステップで再現しない場合は、広告が表示されない「理由は不明です」エラーの対処のような別種の配信停止要因も視野に入れて確認するとよいと考えられます。

原因別の修正方法｜robots.txt・WAF・海外IP制限・リダイレクトの直し方

原因が特定できたら、層に応じて修正内容を変えます。すべてを一律に「robots.txtを直す」で済ませようとすると、WAF層の遮断は解消されません。

robots.txtでAdsBotを許可する書き方

robots.txtでAdsBotを名指しで許可するには、次のように記述します。

User-agent: AdsBot-Google
Disallow:

User-agent: AdsBot-Google-Mobile
Disallow:

すでに「User-agent: *」でDisallowを広くかけている場合でも、個別のUser-agent指定はそちらが優先して評価されるため、上記のように名指しで許可を追加すれば通過できます。修正後は反映まで数時間かかることがある点に注意が必要です。

CloudflareやレンタルサーバーWAFでAdsBotを許可ルールに入れる

海外の実務ブログkeithmenor.devでは、Cloudflareを利用するサイトで広告が一斉に不承認になった事例が紹介されており、robots.txtを修正してもBot Fight ModeなどWAFの機能がファイアウォール層でAdsBotを遮断していれば解決しないと指摘されています。許可ルールはブロックルールより先に評価される仕組みのため、AdsBotのユーザーエージェントを明示的に許可するWAFルールを作成するのが解決策です。日本国内でもCloudflareやレンタルサーバー標準のWAFは広く使われているため、この層の確認は robots.txt の修正とセットで行うべきだと考えられます。

海外IPアクセス制限は日本向け配信でも不承認の原因になる

「日本向けにしか配信していないから海外アクセス制限は関係ない」という思い込みは実務でよく見かける誤解です。海外のナレッジベースN.Rich Knowledge Baseでは、Googleは配信対象国に関わらず世界中のIPプールからリンク先の到達性を確認していると説明されています。国別ブロックやASN単位のブロックを設定している場合、配信ターゲットが日本国内のみであっても不承認の原因になり得るため、海外IP制限は配信対象地域と切り離して確認する必要があります。

リダイレクトチェーンと認証・ステージング残置の解消

リダイレクトが3段階以上重なっている場合は、可能な限り1段のリダイレクトに整理します。Basic認証やIP制限が残っている開発用の設定は、公開後に外し忘れていないか設定画面を直接確認するのが確実です。

修正後の再審査請求のやり方｜リンク先を直しただけでは審査は始まらない

技術的な原因を修正しても、それだけでは審査は自動的に再開されません。管理画面から明示的に再審査請求の操作を行う必要があります。

再審査請求の操作手順と表示されない場合の対処

不承認になった広告の詳細画面を開き、ポリシーの詳細から「審査をリクエスト」または「修正して再審査を依頼」のボタンを選択します。ボタンが表示されない場合は、ポリシーマネージャーの画面から該当の不承認理由を検索し、そこから申請できることがあります。

robots.txtやWAF修正の反映ラグを見込んで申請するタイミング

robots.txtの変更やWAFのルール変更は、キャッシュやCDNの都合で反映までタイムラグが生じることがあります。修正直後に申請すると、AdsBotが古い設定のまま再アクセスして再び不承認になる可能性があるため、手順2で紹介したユーザーエージェント切り替えでの再現確認を行い、ブロックが解除されたことを確かめてから申請する方が手戻りが少なくなります。

審査にかかる時間の目安と繰り返し不承認時のエスカレーション

再審査請求後の審査は、通常1営業日以内で完了するケースが多いとされていますが、目視での確認が必要な内容だと判断された場合はさらに日数がかかることがあります。同じ理由で繰り返し不承認になる場合は、原因の特定自体が誤っている可能性が高いため、切り分けフローの手順1から再度やり直すのが結果的に早いと考えられます。

再発防止チェックリスト｜LP公開・リニューアル時にAdsBot遮断を仕込まない

一度解決しても、サイトのリニューアルやサーバー移行のたびに同じ事故が再発するケースは珍しくありません。公開作業のフローに確認ポイントを組み込んでおくことが有効です。

公開前チェック：Basic認証・noindex・ステージングURLの残置確認

サイト公開前には、Basic認証の解除、noindexタグの削除、ステージング環境のURLが本番設定に紛れ込んでいないかを、公開作業のチェックリストに明文化しておくことが望ましいと考えられます。

サーバー・セキュリティ設定変更時に広告担当へ連携する体制

WAFのルール変更やCDNの切り替えは、多くの場合エンジニアやインフラ担当者の判断だけで実施され、広告運用担当者には共有されません。この情報格差こそが「サイトは正常なのに広告だけ不承認になる」という混乱の根本原因になっていると言えます。制作会社やインフラ担当への発注時点で、AdsBotなどのクローラーアクセスを妨げない旨を仕様に含めておくと事故を防ぎやすくなります。この観点は広告成果を守るLP・サイト発注仕様書の作り方でも扱っている論点です。またCloudflare経由でのSSL証明書更新トラブルも同様にリンク先エラーへつながることがあり、Cloudflare経由で無料SSLの更新が失敗するケースもあわせて点検しておくと安心です。P-MAXキャンペーンでアセットグループ単位の不承認が出ている場合は、通常の広告とは申請経路が異なるため、P-MAXのアセットグループが不承認になった場合の再審査手順を参照すると迷いが少なくなります。

よくある質問

Q：再審査請求をしてから承認されるまで何日かかりますか？ 通常は1営業日以内に結果が出ることが多いとされています。ただし内容によっては手動での確認が必要になり、それ以上の日数がかかる場合もあります。robots.txtやWAFの修正が反映されるまでのタイムラグを見込んだうえで申請するのが無難です。

Q：リンク先を修正すれば自動で再審査されますか？ いいえ、リンク先側の修正だけでは再審査は自動的に始まりません。管理画面のポリシーの詳細から「審査をリクエスト」などの操作を明示的に行う必要があります。

Q：日本向けにしか配信していないのに海外アクセス制限が原因になるのはなぜですか？ AdsBotは配信対象国に関わらず、世界中のIPアドレスからリンク先への到達性を確認する仕組みだからです。国別ブロックやASNブロックをかけている場合、配信ターゲットが日本国内のみであっても不承認の対象になり得ます。

Q：robots.txtでAdsBotだけ許可するにはどう書けばいいですか？ User-agent: AdsBot-GoogleおよびUser-agent: AdsBot-Google-Mobileを個別に指定し、それぞれDisallowを空欄にする記述で許可できます。「User-agent: *」で広くDisallowをかけていても、個別指定が優先されるため通過可能です。修正後は反映までに時間差が生じる点に注意してください。

Q：不承認を放置するとアカウント停止になりますか？ 不承認のまま放置した場合、まずは該当の広告が配信されないだけで済むことが一般的です。ただし同種の違反や不承認が繰り返され改善が見られない場合は、事前の警告を経てアカウント停止に進む可能性があるとされています。早期に原因を特定し修正しておくことが望ましいと言えます。

真策堂では、Google広告の配信が止まった際の原因切り分けや、LP・サーバー側の仕様設計についてもあわせてご相談を受けています。技術的な原因なのかコンテンツ起因なのか判断がつかない場合は、一度状況を整理した上でご相談いただくとスムーズです。