XMLサイトマップの生成・送信監視｜分割・更新・エラー検知を止めない運用
XMLサイトマップの更新漏れを防ぐには、掲載すべき公開URLの台帳と生成結果を照合し、生成ファイルだけでなく公開先の応答とSearch Consoleの取得結果まで確認します。サイトマップがHTTP 200を返していても、中身が前日のままなら新しいページを伝えられません。反対に、送信が成功しても、記載した全ページのインデックス登録が保証されるわけではありません。
公開ページが増えてきた企業サイトでは、記事、サービス、イベントなどの単位で担当者と更新頻度を分けると、欠落の原因を追いやすくなります。サイト全体の更新基盤から見直す場合は、ウェブサイト構築の基盤選びと合わせ、どの情報を公開URLの正本にするかを先に決めてください。
監視の完了条件は、生成ジョブが終わったことではなく、公開すべきURLとの差分を説明でき、公開先と取得結果まで確認できることです。以下は2026年9月9日時点で確認したGoogle公式資料とSitemap Protocolに基づく運用手順です。監視頻度や警告の閾値は運用例として示し、Googleが定める登録条件とは区別します。
本記事のポイント
- サイトマップは公開すべき正規URLの台帳と照合し、生成成功だけでなく欠落・不要URL・公開配信まで確認します。
- lastmodはページの重要更新を反映し、生成時刻で一律更新せず、分割ファイルも上限と構文を検証します。
- Search Consoleの送信・取得成功とインデックス登録を分け、削除・移転時はページ側の処理も揃えます。
掲載対象と分割単位を先に決める
サイトマップには、検索結果へ掲載したい正規URLを絶対URLで記載します。公開状態、検索への掲載方針、正規URLを管理する台帳から対象を抽出し、下書き、認証が必要なページ、削除済みページ、転送元URLなどを混ぜない設計にします。サイト内でリンクできる全URLを機械的に集めるだけでは、パラメータ違いや重複ページまで含まれる可能性があります。
Googleの公式仕様では、1ファイルは50,000 URL以下かつ非圧縮で50MB以下です。どちらかの上限を超える場合は複数ファイルへ分割します。gzipで配信するときも、圧縮後のサイズだけを検査してはいけません。XMLはUTF-8で作成し、名前空間や必須のloc要素、特殊文字のエスケープも確認します。独自の上限を置く場合は、公式上限より余裕を持たせる運用上の基準として記録します。
分割が必要でなくても、記事と製品情報などを分ければ、どの集合で更新漏れが起きたかを調べやすくなります。ただし、細かく分けるほど検索順位が上がるという意味ではありません。件数だけで毎回分割し直すとURLの所属ファイルが大きく変わり、差分を追いにくくなるため、まずページ種別、次に必要なら年度などの安定した境界を選びます。
| 分割の単位 | 適した状況 | 監視上の注意 |
|---|---|---|
| ページ種別 | 記事、サービス、イベントで更新担当が異なる | 公開台帳と同じ分類を使い、対象漏れを確認する |
| 年度などの固定区分 | 記事数が多く、古い記事の更新もある | 過去ファイルの更新を監視対象から外さない |
| 件数による分割 | 単一種別でも上限へ近づく | 並び順と境界を安定させ、重複・欠落を検査する |
サイトマップインデックスを使う場合は、親ファイルに列挙した子サイトマップをすべて検査します。親が正常でも子が404なら、その集合は取得できません。複数ホストを扱う構成には送信方法や所有権の条件があるため、通常の同一サイト構成から安易に拡張せず、Googleのクロスサイト送信条件を別途確認してください。
生成から取得までを7段階で確認する
確認は「対象URLを確定」「生成を検証」「公開配信を確認」「取得結果を確認」の順に進めます。これを日々の作業へ落とすと、次の7段階になります。後の段階だけを再実行しても、抽出条件の誤りは直りません。
1. 公開台帳から期待するURL集合を作る
CMSや公開管理データから、対象URL、ページ種別、公開状態、正規URL、実質的な更新日時を取り出します。サイトマップとまったく同じ抽出コードだけで期待値を作ると、同じ不具合を見逃すため、公開件数や直近の公開記録とも照合します。ページを公開・更新・廃止する責任の分け方は、Webサイトのコンテンツガバナンスを参考に整理できます。
2. 一時出力へ生成し、失敗を公開先へ流さない
生成ジョブでは実行ID、開始・終了時刻、対象データの版、終了結果、ファイル数、URL数を記録します。まず一時領域へ出力し、検証合格後に公開用ファイルへ切り替える構成にします。生成の途中で空ファイルを本番へ上書きすると、ジョブ失敗がそのまま配信障害になるためです。既存ファイルを保持する場合も、古い状態を正常と扱わず警告を残します。
3. XML、件数、差分、lastmodを検証する
XMLとして解析できるか、必須要素と名前空間が正しいか、絶対URLか、重複がないか、上限を超えていないかを機械検査します。期待集合にあるのに出力されないURLと、対象外なのに残っているURLを分けて出してください。増減率だけでは、新規10件と誤削除10件が相殺されるため、URL単位の差分も必要です。
lastmodにはページの最終的な重要更新日時を使います。Googleは継続的に正確で検証可能なlastmodを利用すると説明しており、本文や構造化データ、リンクの重要な変更が例として挙げられています。サイトマップを生成しただけで全URLを当日へ更新しません。正確な更新日を管理できない場合は、任意項目のlastmodを無理に作らず省略する判断もできます。Googleはpriorityとchangefreqを無視するため、これらの値の調整を監視の主目的にしません。
4. 公開URLから実際の配信ファイルを取得する
公開後、サイトマップインデックスと全子ファイルへ外部からGETを送り、HTTP応答、XMLとしての内容、URL数、対象URLの差分を確認します。ローカルのファイルが正しくても、配信先のパス違い、古いキャッシュ、認証画面の返却があり得ます。HTTP 200でもHTMLのエラーページなら不合格です。生成時の内容と公開配信の内容を、解凍や正規化の条件を揃えて比較します。
5. 記載URLを重点的に点検する
新規・更新・削除・移転に関係するURLは優先して確認し、大規模サイトの変化がない部分は定期的な抽出検査と全件検査を組み合わせます。正規URLの向き先、HTTP応答、noindexの有無、アクセス制限などを点検します。全件を高頻度に取得してサイトへ負荷をかけず、重要ページや変更分から確認する順序と上限を決めます。
6. Search Consoleで送信と取得の結果を読む
適切なプロパティで対象のサイトマップを送信し、サイトマップレポートの最終読み込み日時とステータスを確認します。「成功しました」は取得・処理できたことを示し、全URLの登録完了ではありません。URL検査やページのインデックス登録レポートで、必要なページの状態を別途確認します。サイトマップ送信はヒントであり、Googleによるダウンロードやクロールを保証するものではないと公式資料にも明記されています。
7. 復旧の証拠を揃えて警告を閉じる
修正後は、失敗したジョブの再実行だけでなく、期待URLとの差分、公開先の正常応答、必要に応じた取得結果の変化まで確認します。監視通知には対象ファイル、検知時刻、期待値と実測値、担当者、次に確認する時刻を残します。検索エンジン側の反映に時間がかかる状態と、自社側で修正が必要な障害を分ければ、同じ送信を繰り返すだけの対応を避けられます。
警告は生成・配信・内容・取得に分ける
すべてを「サイトマップエラー」と通知すると、制作担当と基盤担当の間で調査が往復します。生成処理、公開配信、掲載内容、検索エンジンの取得という4種類に分け、最初に見る証拠を決めておきます。
| 症状 | 最初に確認すること | 対応の方向 |
|---|---|---|
| 予定時刻を過ぎても生成記録がない | ジョブの起動、入力データ、終了ログ | 原因を修正し、検証付きで再生成する |
| 公開先が404、5xx、認証画面 | 配信パス、サーバー、アクセス制限 | 公開先の取得可能性を復旧する |
| 件数が同じなのに新規URLがない | 期待集合との差分、抽出条件、キャッシュ | 欠落と不要URLを別々に修正する |
| Search Consoleで取得できない | 送信先、最終読み込み、表示されたエラー詳細 | 自社の配信状態とGoogle側の結果を照合する |
| 送信成功でもページが未登録 | URL検査、正規化、内容、登録除外の理由 | サイトマップの再送だけで解決しようとしない |
更新のないサイトでは、ファイルの更新日時が古いこと自体は障害ではありません。公開台帳に変更があったのに反映されない場合を検知します。たとえば毎日公開があるサイトなら、公開処理の直後に変更分を確認し、日次で全ファイルの構文と差分を確認する設計が考えられます。これは運用例であり、全サイト共通の必要頻度ではありません。
件数の急減を警告する閾値も、自社の通常の増減に合わせます。イベントの一括終了やサイト整理など、正当な減少は変更記録と突き合わせて判断します。警告を黙らせるために期待件数を下げず、減ったURLと理由を記録してください。配信キャッシュが疑われる場合は、CDNキャッシュの除外・更新設計のように、実際の配信基盤の設定と照合します。
削除・移転時はページ側の処理と揃える
削除したページをサイトマップから外しても、それだけで検索結果から削除されるわけではありません。ページの廃止方針に応じてHTTP応答や検索への掲載制御を設定し、サイトマップには現在掲載したい正規URLを残します。移転では、転送先が正常に公開され、正規URLの指定と内部リンクが揃っているかを確認したうえで、転送元を除外し転送先を掲載します。
大量の移転では、転送対応表とサイトマップ差分を同じ単位で照合すると、転送先の欠落を見つけやすくなります。公開ファイルだけを過去版へ戻す場合も、既に廃止したURLを復活させていないかを確認してください。正常だった過去ファイルが、現在も正しいとは限りません。
運用台帳には、親・子サイトマップのURL、掲載対象の抽出条件、担当者、期待する更新契機、検証方法、通知先をまとめます。担当交代時は、管理画面の権限だけでなく、生成ジョブと公開配信の責任範囲を引き継ぎます。新規ページを1件公開したときに、どのファイルへ載り、誰がどの証拠で確認するかを説明できる状態が目標です。
よくある質問
サイトマップは毎日更新する必要がありますか？
実際の公開・重要更新・削除があったときに内容を追随させます。更新のない日にlastmodだけを当日へ変える必要はありません。監視頻度は更新頻度と障害時の影響から決めます。
HTTP 200なら正常と判断できますか？
できません。XMLの構文、掲載URL、件数、配信内容の新しさも確認します。HTMLの認証画面や古いXMLが200で返る場合もあるためです。
送信が成功すれば全ページが検索結果へ出ますか？
保証されません。取得・処理の成功とインデックス登録は別です。必要なURLの登録状態や除外理由はURL検査などで確認します。
lastmodが分からないページはどうしますか？
実質的な更新日時を正確に管理できないなら、任意項目のlastmodを省略できます。ファイル生成時刻をページの更新日として機械的に入れないでください。
分割したサイトマップもすべて確認しますか？
親のインデックスだけでなく全子ファイルの取得と構文を確認します。記載ページの検査は変更分を優先し、規模に応じて定期的な全件検査を組み合わせます。
削除URLを外すだけで検索結果から消えますか？
サイトマップからの除外だけでは削除を保証しません。ページ側の応答や検索への掲載制御を廃止方針と揃え、その後の状態を確認します。
関連ページと関連記事
URLの公開方針を整理したら、BtoB LPの公開前チェックリストでページ自体の品質も確認してください。サイトマップ監視とページの公開確認を接続すると、公開作業の終了条件が明確になります。
ページ公開と更新監視を担当者任せにせず、生成・検証・通知の仕組みを業務に合わせて実装したい場合は、ファネルAiの超速AIパートナーで支援内容をご確認ください。
