sitemap.xmlのURLが急に減ったとき、最初の30分でやること
sitemap.xmlのURLが急に減ったときに、最初の30分で配信不能・誤配・意図しない除外を除外する手順です。
Search Consoleの「送信されたURL数」や、サイト全体のインデックス数が急に減ったとき、最初に見るべきは“順位”ではなく“sitemap.xmlが本当にいつも通り配れているか”です。sitemapは検索順位を上げる魔法ではありませんが、壊れると「クロールに必要な地図」そのものが崩れ、復旧が遅れます。
この手順の目的は、原因当てゲームではなく「復旧を遅らせる致命傷（配信不能・誤配・意図しない除外）」を30分で除外することです。
0. まずやらないこと
- sitemapを何種類も増やす（切り分け前の増設）
- URLを大量に消す/変える（正規化やリライトを一括で入れる）
- robots.txtを触って祈る（まずは現状把握）
急落時にやるべきは「新しい最適化」ではなく「壊れていないことの確認」です。
1. sitemap.xmlを“ブラウザで”開いて確認（最速）
まずは1つだけで良いので、実際のsitemap URLを開きます。
- 200で返るか（404/5xx/リダイレクト地獄になっていないか）
- 内容が空になっていないか（URLが0件、極端に少ない）
- 直近のデプロイ以降でサイズが激減していないか
複数サイト運営なら、ドメインごとに同じ確認をします。
関連: /media/domain-first-dashboard
2. Search Consoleの「サイトマップ」レポートで“取り込み”を確認
Search Consoleのサイトマップレポートで、次を確認します。
- ステータスがSuccess/Has issuesか（失敗しているなら“まず復旧”）
- 「検出されたURL数」がいつから減ったか（減り始めた時刻の手がかり）
- sitemap URLが意図せず変わっていないか（別URLを送ってしまっていないか）
ここで失敗しているなら、記事改善の前にsitemap復旧を優先します。
3. robots.txt / noindex / canonicalの“意図しない”変更を除外
sitemap自体が200でも、URL側が除外されていれば効果が出ません。
- robots.txtでブロックしていないか
- 重要ページにnoindexが入っていないか
- canonicalが別ドメイン/別ページに飛んでいないか
急落の初動は、1ページずつ深掘りせず「サイト全体で壊れていないか」を先に見ます。
関連: /media/search-console-drop-first-30-minutes
4. “生成側”が壊れていないか（よくある）
sitemapは生成処理に依存するため、次の変更で壊れがちです。
- ルーティング/末尾スラッシュ/正規URLルールの変更
- ビルド・SSR/ISRの構成変更
- データ取得エラーで0件になった（例: API制限、DB接続失敗）
- 環境変数の抜けでベースURLが変わった/空になった
最短復旧は、直近の変更と突き合わせて“壊れた場所”を1つに絞ることです。
5. 直す順番（最初の30分で終わる形）
- sitemap URLを1つに絞って、HTTP 200 + URLが十分あることを確認
- Search Consoleのサイトマップレポートで「失敗していない」ことを確認
- 重要ページ（料金/機能/主要記事）で robots/noindex/canonical を数件だけ確認
- 直近デプロイの差分を見て、sitemap生成/正規URLルールの変更がないか確認
ここまでで“致命傷がない”と分かってから、個別ページの改善やコンテンツ更新に入ります。
参考にした一次情報
- Google Search Central: Sitemaps overview
- Google Search Console Help: Sitemaps report
- Google Search Central: Robots.txt specifications
この記事を書いた人
川原
SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。
関連記事
次にやること
複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。
料金を見る相談したい / お問い合わせ