AWS WAFで海外IPをブロックしているサイトのGoogle広告が審査落ち（403）したときの対処方法をまとめてみた

AWS WAF で海外IPをブロックしていると、Google広告の審査落ちや検索クローラーのブロックが起きてしまうことがあります。今回はその原因と解決方法を、実際の対応手順ベースでご紹介します。

2026.07.31

こんにちは！クラウド事業統括本部のおつまみです。
 はじめにALB + AWS WAF の構成で「海外IPをブロックする（日本以外は拒否）*」設定を入れている環境において、「Google広告の審査が「機能していないリンク先」ポリシーで不承認になる」「Googleの検索クローラーがサイトを巡回できない」という事象に遭遇することがあります。
原因は、Googleの広告審査クローラー（AdsBot-Google／AdsBot-Google-Mobile）や検索クローラー（Googlebot）が 海外IPからアクセスしてくるため、WAFの海外IPブロックに引っかかっていることが多いです。
今回は、この事象の切り分けと、GoogleクローラーのIPレンジをWAFで許可する設定方法を、実際にやった手順ベースでご紹介します。
 3行まとめWAFで海外IPブロック（GeoMatchStatement）をしていると、海外IPから来る Google広告審査クローラー（AdsBot）や検索クローラー（Googlebot）が403でブロックされ、広告審査落ち（403）やSEO巡回不可の原因になることがある
User-Agent の許可だけでは足りず、awselb/2.0（ALB/WAF層）で弾かれているのがポイント。対処は Googleが公開するIPレンジ（special-crawlers.json／googlebot.json 等）を許可用IP Setに登録し、海外IPブロックより高い優先度のAllowルールで通すこと
GoogleのIPレンジは月1〜2回更新されるため、静的に登録しただけだと再発リスクが残る。Lambda + EventBridge での自動更新まで含めて設計するのがおすすめ
 事象Google広告の出稿時に、審査が 「機能していないリンク先」ポリシーにより不承認（403）になりました。
一方で、同じランディングページを日本国内のブラウザからアクセスすると正常に表示されるという状況です。「ページは生きているのに、なぜ審査だけ落ちるのか？」と悩ましいところですよね。
まず疑いたくなるのは、
ページ自体が 404（存在しない）
サーバー（Apache/Nginx）側で拒否している
あたりですが、今回のケースはいずれも違いました。
 原因の切り分け 403 を返しているのは誰かcurl で AdsBot-Google の User-Agent を騙って（＝クローラーのふりをして）アクセスし、レスポンスヘッダーを確認します。
curl -I -A "AdsBot-Google (+http://www.google.com/adsbot.html)" https://example.com/lp/
このとき、レスポンスヘッダーの Server に注目します。
HTTP/1.1 403 Forbidden
Server: awselb/2.0
Server: awselb/2.0 から 403 が返っているということは、オリジンサーバー（Apache 等）ではなく、ALB／WAF層でブロックされているということです。もしオリジンで拒否しているなら Server: Apache のような値になります。ここが最初の重要な切り分けポイントです。
 なぜ WAF で弾かれるのかWAFのログ（CloudWatch Logs）を確認すると、優先度１のルールが海外IPブロック用のルール（GeoMatchStatement を使ったルール）になっていました。
WAFのログ確認方法や、国ベースのマッチ（GeoMatchStatement）の仕様は以下のドキュメントも参考になります。
AWS WAF 地理的一致ルールステートメント（GeoMatch）
AWS WAF のログ記録
Googleの広告審査クローラーや検索クローラーは、主にアメリカなど海外のIPアドレスからアクセスしてきます。そのため、「日本以外のIPをブロックする」設定を入れていると、クローラーのアクセスがことごとく403になってしまうわけです。
ここで陥りがちなのが、「User-Agent（AdsBot-Google 等）を許可すればいいのでは？」という対処です。しかし User-Agent の許可だけでは解消しません。海外IPブロックはあくまで**IPアドレス（送信元の国）**で判定しているため、User-Agent をいくら許可しても、そのアクセス元IPが海外である限りブロックされ続けます。
 構成の前提今回の構成はざっくり次の通りです。
WAF（Web ACL）のルールは、優先度順に評価され、Allow / Block はその時点で評価が終了します。今回の対応前のルール構成は次のようなイメージです。


優先度
ルール名
アクション
内容


1
GeoBlockNonJapan
Block
日本以外のIPをブロック

2
RateLimit
Count
レートリミット

11〜
AWSマネージドルール群
Count
Common / KnownBadInputs / SQLi など

この構成だと、Googleクローラー（海外IP）は優先度1の海外IPブロックに該当し、403 になります。
 対応：GoogleクローラーのIPレンジを許可する方針はシンプルで、Googleが公開しているクローラーのIPレンジを許可し、それを海外IPブロックより高い優先度の Allow ルールで評価させます。これにより、Googleクローラーは海外IPブロックに到達する前に許可されます。
 GoogleのIPレンジ JSONGoogleはクローラーの送信元IPレンジをJSON形式で公開しています。用途ごとに複数のファイルがあります。どのクローラーがどのファイルに対応するかは、以下の公式ドキュメントにまとまっています。
Googlebot などの Google クローラーの検証


ファイル
対象
用途


googlebot.json
Googlebot
自然検索（SEO）のクローラー

special-crawlers.json
AdsBot 等
Google広告の審査クローラーを含む特殊クローラー

user-triggered-fetchers.json / user-triggered-fetchers-google.json
ユーザー起因のフェッチャー
サイト所有者の操作等で発生する取得

Google**広告の審査落ち（403）**を解消したいだけなら、special-crawlers.json（AdsBot が含まれる）を許可すれば十分です。
あわせてSEO（自然検索）への影響を避けたい場合は、googlebot.json も許可しておくのがおすすめです。
user-triggered-fetchers 系は緊急性が低いことが多く、要件に応じて判断すればよいでしょう。
JSONの中身は次のような構造で、ipv4Prefix と ipv6Prefix が並んでいます。
{
  "creationTime": "2026-07-30T14:47:02.000000",
  "prefixes": [
    { "ipv4Prefix": "66.249.64.0/27" },
    { "ipv6Prefix": "2001:4860:4801:10::/64" }
  ]
}
IPv4だけでよいか？IPv6も要るか？は環境次第です。

**ALB の IP アドレスタイプが ipv4（IPv4のみ）**であれば、そもそもクライアントは IPv6 で接続できないため、IPv4レンジだけ登録すれば十分です。ALB を dualstack（IPv6対応）にしている場合は、IPv6レンジも登録する必要があります（WAFのIP SetはIPv4用とIPv6用が別々なので、その場合は2つ用意します）。
 IPレンジを抽出するcurl + jq で、JSONからIPv4レンジだけを抜き出せます。googlebot.json はリダイレクトされることがあるので -L を付けています。
# special-crawlers（AdsBot等）と googlebot のIPv4レンジを結合・重複排除
curl -sL https://developers.google.com/static/crawling/ipranges/special-crawlers.json -o special-crawlers.json
curl -sL https://developers.google.com/static/search/apis/ipranges/googlebot.json     -o googlebot.json

jq -n '[inputs.prefixes[].ipv4Prefix | select(. != null)] | unique | sort' \
  special-crawlers.json googlebot.json > google-ipv4.json

echo "件数: $(jq 'length' google-ipv4.json)"
 IP Set を作成するGoogleクローラー専用のIP Setを新規作成します（REGIONAL はALB向け。CloudFront向けなら CLOUDFRONT を us-east-1 で作成）。
aws wafv2 create-ip-set \
  --name example-ipset-google-allow \
  --scope REGIONAL \
  --region ap-northeast-1 \
  --ip-address-version IPV4 \
  --description "Google crawler IP ranges special-crawlers and googlebot IPv4" \
  --addresses $(jq -r '. | join(" ")' google-ipv4.json)
ちなみに、create-ip-set の --description は使える文字に制限があり、丸括弧 () などは弾かれます。筆者はここでエラーになりました。説明文は英数字・+=:#@/-,. とスペース程度に留めておくと安全です。
作成後、マネジメントコンソールの WAF > IP sets からも、GoogleのIPレンジが登録されていることを確認できます。
IP Set の作成・管理の詳細は以下を参照してください。
AWS WAF IP set の作成と管理
 Web ACL に許可ルールを追加する作成したIP Setを参照する Allow ルールを、海外IPブロックより小さい優先度番号（＝先に評価される）で追加します。

優先度は一意である必要があるため、既存ルールの優先度を1つずつ繰り下げて隙間を作ります。
対応後のルール構成はこうなります。


優先度
ルール名
アクション
内容


1
AllowGoogleCrawlers
Allow
GoogleクローラーのIPレンジ（新設）

2
GeoBlockNonJapan
Block
日本以外のIPをブロック（1→2に繰り下げ）

3
RateLimit
Count
レートリミット（2→3に繰り下げ）

11〜
AWSマネージドルール群
Count
変更なし

コンソールの Web ACL のルール一覧で、AllowGoogleCrawlers が海外IPブロックより上（優先度が小さい）に並んでいることを確認します。
追加するルールのJSONは次の通りです。
{
  "Name": "AllowGoogleCrawlers",
  "Priority": 1,
  "Action": { "Allow": {} },
  "Statement": {
    "IPSetReferenceStatement": {
      "ARN": "arn:aws:wafv2:ap-northeast-1:111122223333:regional/ipset/example-ipset-google-allow/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "AllowGoogleCrawlers"
  }
}
update-web-acl は Web ACL 全体のルール配列を丸ごと置き換えるAPI です。既存ルールを取得し、優先度を調整しつつ新ルールを足した配列を作って更新します。更新には LockToken（get-web-acl で取得）が必要です。
# 1. 現状取得（LockToken もここで取れる）
aws wafv2 get-web-acl --scope REGIONAL --region ap-northeast-1 \
  --name example-waf-webacl --id <WEBACL_ID> > wacl.json

# 2. jq で優先度を繰り下げつつ AllowGoogleCrawlers を追加
GARN="arn:aws:wafv2:ap-northeast-1:111122223333:regional/ipset/example-ipset-google-allow/xxxxxxxx"
jq --arg garn "$GARN" '
  [ .WebACL.Rules[]
    | if .Name=="GeoBlockNonJapan"        then .Priority=2
      elif .Name=="RateLimit"             then .Priority=3
      else . end ]
  + [ { "Name":"AllowGoogleCrawlers","Priority":1,"Action":{"Allow":{}},
        "Statement":{"IPSetReferenceStatement":{"ARN":$garn}},
        "VisibilityConfig":{"SampledRequestsEnabled":true,"CloudWatchMetricsEnabled":true,"MetricName":"AllowGoogleCrawlers"} } ]
  | sort_by(.Priority)
' wacl.json > rules.json

# 3. ルール配列を丸ごと差し替えて更新
LT=$(jq -r '.LockToken' wacl.json)
aws wafv2 update-web-acl --scope REGIONAL --region ap-northeast-1 \
  --name example-waf-webacl --id <WEBACL_ID> \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=example-waf-webacl \
  --rules file://rules.json --lock-token "$LT"
適用後、AdsBot-Google の User-Agent + 海外相当のアクセスで 403 が解消されているか、WAFログの terminatingRuleId が AllowGoogleCrawlers になっているかを確認すれば完了です。
 恒久運用：IPレンジの更新にどう追従するかGoogleのIPレンジは月1〜2回更新されます。 今回のように静的に登録しただけだと、更新で追加された新しいIPからのアクセスで 403 が再発するリスクが残ります。
運用方針としては、主に次の選択肢があります。
 案A（おすすめ）：Lambda + EventBridge で自動更新EventBridge Scheduler で定期（例：日次）に Lambda を起動し、GoogleのJSONを取得してGoogle用IP Setだけを update-ip-set で更新する構成です。
IPレンジ更新による403再発リスクを恒久的に解消できます
自動更新はGoogle用IP Setの中身（アドレス）だけを差し替える形なので、Web ACLのルール構成自体は触りません
update-ip-set も LockToken が必要なので、Lambda内で get-ip-set → update-ip-set の順で呼びます。差分がないときはスキップすると無駄な更新を避けられます
定期実行の基盤には EventBridge Scheduler が便利です。IP Set 更新API（update-ip-set）の仕様とあわせて、以下を参考にしてください。
Amazon EventBridge Scheduler
AWS CLI: wafv2 update-ip-set
 案B：月1回の手動更新をルール化初期構築の工数は小さいですが、更新のタイムラグによる再発リスクと、毎月の運用負荷が残ります。頻度やSLA次第では選択肢になりますが、恒久対策としては案Aに軍配が上がります。
 利用時の注意点User-Agent の許可だけでは解決しない
繰り返しになりますが、海外IPブロックはIPで判定しているため、User-Agentの許可では回避できません。

「AdsBotのUAを許可したのに直らない」ときは、まず Server: awselb/2.0 から403が返っていないか（＝IP/WAF層で弾かれていないか）を確認しましょう。
Allow ルールは評価を終了させる
AllowGoogleCrawlers に該当したリクエストは、その時点で評価が終わり、以降のマネージドルール等は評価されません。これは意図通りですが、「Googleクローラーを名乗るIPには他の防御も効かせたい」といった要件がある場合は設計を見直してください（とはいえ、Googleの公開IPレンジからのアクセスに限定されるため、実運用上のリスクは限定的です）。
優先度番号は一意にする
WAFのルール優先度は一意の整数である必要があります。海外IPブロックより「小さい番号」で許可ルールを入れる必要があるため、既存ルールの優先度を繰り下げて隙間を作ります。相対的な評価順が変わらないように注意しましょう。
IaC（CloudFormation等）を使っている場合はドリフトに注意
CLI/コンソールで直接IP SetやWeb ACLを変更すると、IaCテンプレートとの間にドリフトが発生します。次回のデプロイで設定が巻き戻らないよう、テンプレート側にも同じ構成を反映しておきましょう。案A（自動更新）を導入する場合は、Google用IP Setの中身はLambda管理に寄せ、IaC側では「IP Setの箱」だけを管理する（中身の差分は無視する）設計にするとスッキリします。
 さいごに今回は、AWS WAF で海外IPブロックをしている環境で、Google広告の審査落ち（403）やGoogleクローラーのブロックを解消するための、IPレンジ許可設定をご紹介しました。
ポイントを改めて整理すると、
403 の出どころは Server: awselb/2.0（WAF/ALB層）。User-Agent許可では不十分で、IPレンジの許可が必要
Googleが公開する special-crawlers.json（広告審査）／googlebot.json（SEO） を許可用IP Setに登録し、海外IPブロックより高い優先度のAllowルールで通す
IPレンジは月1〜2回更新されるため、Lambda + EventBridge の自動更新まで含めて設計するのがおすすめ
「日本以外はブロック」というシンプルな要件でも、Google広告やSEOと両立させようとすると意外と考慮点が多い領域です。同じような事象で悩んでいる方の参考になれば幸いです。
最後までお読みいただきありがとうございました！

どなたかのお役に立てれば幸いです。
以上、おつまみ（＠AWS11077）でした！
 参考Googlebot などの Google クローラーの検証
Google クローラーとフェッチャー（ユーザーエージェント）
special-crawlers.json（AdsBot等のIPレンジ）
googlebot.json（GooglebotのIPレンジ）
AWS WAF IP set の作成と管理
AWS WAF 地理的一致ルールステートメント（GeoMatch）
AWS WAF のログ記録
AWS CLI: wafv2 update-ip-set
Amazon EventBridge Scheduler
AWS WAF Bot Control ルールグループ

AWS WAFで海外IPをブロックしているサイトのGoogle広告が審査落ち（403）したときの対処方法をまとめてみた

はじめに

3行まとめ

事象

原因の切り分け

403 を返しているのは誰か

なぜ WAF で弾かれるのか

構成の前提

対応：GoogleクローラーのIPレンジを許可する

GoogleのIPレンジ JSON

IPレンジを抽出する

IP Set を作成する

Web ACL に許可ルールを追加する

恒久運用：IPレンジの更新にどう追従するか

案A（おすすめ）：Lambda + EventBridge で自動更新

案B：月1回の手動更新をルール化

利用時の注意点

さいごに

参考

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS

優先度	ルール名	アクション	内容
1	GeoBlockNonJapan	Block	日本以外のIPをブロック
2	RateLimit	Count	レートリミット
11〜	AWSマネージドルール群	Count	Common / KnownBadInputs / SQLi など

ファイル	対象	用途
`googlebot.json`	Googlebot	自然検索（SEO）のクローラー
`special-crawlers.json`	AdsBot 等	Google広告の審査クローラーを含む特殊クローラー
`user-triggered-fetchers.json` / `user-triggered-fetchers-google.json`	ユーザー起因のフェッチャー	サイト所有者の操作等で発生する取得

優先度	ルール名	アクション	内容
1	AllowGoogleCrawlers	Allow	GoogleクローラーのIPレンジ（新設）
2	GeoBlockNonJapan	Block	日本以外のIPをブロック（1→2に繰り下げ）
3	RateLimit	Count	レートリミット（2→3に繰り下げ）
11〜	AWSマネージドルール群	Count	変更なし