Cloudflare 1102でサイトマップが落ちるとき、最初の30分でやること
Cloudflareで1102が出てサイトマップ配信が不安定なとき、最初の30分で“配れる状態”に戻すチェックリストです。
Cloudflare環境で sitemap.xml を配信していて、Search Consoleが「取得できませんでした」になったり、Cloudflare側で 1102 が出たりするときは、まず「サイトマップ自体が重い/多い/動的すぎる」可能性から潰すのが最短です。
この記事は、Cloudflareで 1102 が出てサイトマップ配信が不安定になったときに、最初の30分で“止血”する手順をチェックリスト化したものです。
関連:
- /media/cloudflare-1102-503-first-response
- /media/search-console-sitemap-fetch-error-first-30-minutes
- /media/sitemap-url-drop-first-30-minutes
0. まず結論（先にやる順番）
最初の30分は、原因の推理より「確実に配れる形に戻す」を優先します。
- サイトマップを “軽い固定物” に寄せる（動的生成・巨大変換・DB全件走査を避ける）
- サイトマップインデックス + 分割 にして、1ファイルあたりの負荷を落とす
- 重要URLだけの暫定サイトマップ に切り替えて、まずGooglebotの再取得を通す
- 収束後に、恒久対応（生成戦略・キャッシュ・観測点）を入れる
1. 影響範囲を3つに分ける（最優先）
まずは「サイト全体の障害」なのか「サイトマップだけ」なのかを切り分けます。
sitemap.xmlだけが落ちる（他は普通に見える）sitemap.xmlを含め、広範囲が落ちる（トップも503/1102）- 特定のUA（Googlebot）だけが落ちる/遅い
サイト全体が落ちているなら、サイトマップ以前にやることがあります: /media/cloudflare-1102-503-first-response
2. 重要URLを直叩き（ブラウザより先）
“見た目”より先に、重要URLを最小セットで確認します。
/（トップ）/robots.txt/sitemap.xml（またはサイトマップインデックス）- Search Consoleに登録しているサイトマップURL（末尾スラッシュ含めて同一か）
ここで「サイトマップだけ落ちている」のが確定すると、対処はかなり機械的になります。
3. “止血”の暫定対応（戻せる形だけ）
最初の30分は、恒久的な最適化ではなく「確実に配れる形」に戻すための暫定対応だけをします。
- インデックス化:
/sitemap.xmlをインデックスにして、子サイトマップへ分割 - 分割: 1ファイルあたりのURL数を減らす（例: 1,000〜5,000単位）
- 静的化: 可能ならビルド時/定期生成に寄せ、リクエスト時の重い処理を避ける
- 暫定の重要URL限定: “重要URLだけ”に絞って一旦復旧し、後で戻す
4. 1102の再発を防ぐヒント（30分の外）
止血できた後にやることです（最初の30分ではやりません）。
- 生成処理の時間/回数を減らす（キャッシュ、事前生成、分割）
- 観測点を増やす（サイトマップ生成時間、レスポンスサイズ、5xx率）
- “量産URL”を減らす（タグ/検索/フィルタの無限増殖を止める）
SiteOpsで“サイトマップ異常”を早期検知する（再発防止）
サイトマップが落ちても、気づくのが遅いほどインデックス回復が遅れます。再発防止としては「落ちた瞬間に気づく」仕組みを先に作るのが効きます。
- Search Consoleのサイトマップ/インデックス異常を、毎朝の優先順位で確認できる状態にする
- “サイトマップだけ落ちる”のか“サイト全体が落ちる”のかをすぐ確定できるようにする
状況が再現できない/原因が複合している場合は、相談だけ先に進めるのも有効です。
この記事を書いた人
川原
SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。
関連記事
次にやること
複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。
料金を見る相談したい / お問い合わせ