Search Consoleのサイトマップレポートに「成功」と表示されていても、サイトマップが整っているとは限りません。404ページ、リダイレクトURL、noindexページ、非正規URLが混ざっていても「成功」と表示されることがあり、その状態ではサイトマップの品質は十分とはいえません。
XMLサイトマップの監査では、「ファイルが存在するか」だけでなく、「検索結果に出したいURLだけが正しく掲載され、Googleが取得・解析できる状態か」まで確認することが欠かせません。
この記事では、SEO担当者・開発担当者がXMLサイトマップを確認するときの項目を、実務の順番に沿って整理します。サイトマップを取得できるか、XMLとして正しいかを確かめたうえで、送信しているURLの中身、canonical、更新日（lastmod）、ファイルの分割、Search Consoleのエラーへと進みます。後半では、毎回すべてを見直さずに済む差分の見方と、確認用のチェックリストも載せています。
XMLサイトマップだけでなく、未登録・除外・重複URLまで含めて診断したい場合は、親記事の「SEOのインデックス監査」から確認してください。
まず確認｜XMLサイトマップ監査で見る7項目
最初に、監査の対象を次の7項目に分けます。あらかじめ分けておくと、確認漏れを防ぎやすくなります。表の項目は、このあとのSTEP1〜7と同じ順に並んでいます。
| 監査項目 | 確認する内容 | 主な問題例 |
|---|---|---|
| 取得可否 | Googlebotがサイトマップを取得できるか | 404、403、robots.txtブロック |
| XML構文 | XMLとして正しく解析できるか | タグ欠落、エスケープ漏れ、文字コード不備 |
| 掲載URL | インデックスさせたいURLだけが入っているか | 404、3xx、noindex、重複URL |
| canonical | サイトマップURLと正規URLが一致するか | 別URLへのcanonical |
| lastmod | 実際の重要な更新と整合しているか | 全URLが毎日更新扱い |
| 分割 | URL数・ファイル容量・分類が適切か | 50,000 URL超過、巨大ファイル |
| Search Console | 送信・取得・解析エラーがないか | 取得不能、解析エラー、URL不許可 |
表に出てくる用語を補足します。Googlebotは、Googleが検索のためにページを巡回して取得するプログラム（クローラー）の名前です。lastmodは、サイトマップに書くURLごとの最終更新日時の項目です。
XMLサイトマップは、ファイルが存在するかどうかだけで判断せず、取得、URLの品質、更新情報、Search Consoleまで、7つの観点で確認します。
Googleは、サイトマップには検索結果に表示したいURLを含めるよう案内しています。一方、1つのサイトマップに入れられるのは50,000 URLまたは非圧縮50MBまでです。上限を超える場合は複数のファイルに分け、それらをまとめて指すサイトマップインデックスで管理します（STEP6で扱います）。
STEP1｜サイトマップ自体をGoogleが取得できるか確認する
最初に確認するのは、掲載URLではなくサイトマップファイル自体を取得できるかです。
ブラウザで開けるだけでは不十分で、Googlebotがアクセスできることまで確かめる必要があります。主に次の点を見てください。
- サイトマップURLが200を返している
- ログイン認証が不要
- robots.txtでサイトマップ取得を妨げていない
- CDNやWAFでGooglebotを拒否していない
- リダイレクトループがない
- Search Consoleで「取得できませんでした」になっていない
サイトマップの取得に失敗すると、Search Consoleには、robots.txtによるブロック、404、サーバー側の問題などが原因として示されます。
「ブラウザで見える」と「Googleが取得できる」は分けて考える
担当者のブラウザでXMLが表示できても、GooglebotだけがWAFやアクセス制限で拒否されているケースがあります。
そのため監査では、人の目で表示を確認する → HTTPステータスを確認する → Search Consoleで確認するという順に、確認の段階を上げていくと安全です。ブラウザの表示だけで済ませないことで、Googlebotだけが拒否されている状態も見つけやすくなります。
STEP2｜XML構文とサイトマップ形式を確認する
次に、サイトマップがXMLとして正しく解析できるかを確認します。構文に問題があると、Search Consoleで解析エラーになる原因になります。
最低限、次の点をチェックします。
- XML宣言が適切か
urlsetまたはsitemapindexの構造が正しいか- 各URLに
locがあるか &など必要な文字がエスケープされているか- URLが相対URLではなく絶対URLになっているか
- ドメインやプロトコルが意図したものと一致しているか
- UTF-8で扱われているか
STEP3｜掲載URLが「インデックス対象」と一致しているか確認する
XMLサイトマップ監査で最も重要なのは、掲載URLの中身です。
サイトマップは「サイト内に存在するURL一覧」ではありません。原則として、検索エンジンに発見・クロール（ページを巡回して取得すること）してほしく、検索結果に出したい正規URLを掲載します。
掲載してよいかどうかは、URLの状態で決まります。次の表では、左の列でURLの状態を確認し、中央の列で掲載するかどうかを判断し、右の列で対応を決めます。
| URL状態 | サイトマップ掲載 | 対応 |
|---|---|---|
| 200かつindex可能な正規URL | 掲載する | 維持 |
| 301・302リダイレクト | 原則外す | 転送先URLへ置換 |
| 404・410 | 外す | サイトマップから削除 |
| 5xx | 原則外す／障害修正 | サーバー問題を優先確認 |
| noindex | 外す | インデックス方針と整合させる |
| robots.txtでクロール不可 | 原則見直す | 掲載方針とクロール制御を再確認 |
| 別URLへcanonical | 原則外す | canonical先の正規URLへ統一 |
| パラメータ重複URL | 原則外す | 正規URLへ統一 |
つまり、サイトマップへ残すのは、原則として200を返し、インデックス可能で、正規URLとして扱うURLです。判定は、HTTPステータス、index可否、canonicalの順に見ていくと整理できます。
404やリダイレクトが混ざる原因
掲載URLに404やリダイレクトが混ざる原因は、主に次の5つです。原因の見当がつくと、サイトマップの出力設定を直すべきか、個別のURLを直すべきかを判断しやすくなります。
- 記事削除後もCMSが古いURLを出力している
- URL変更後も旧URLがサイトマップに残っている
- 商品・求人・店舗などの終了ページが残っている
- http/https、www有無、末尾スラッシュ違いが混在している
- パラメータ付きURLが生成対象になっている
STEP4｜canonicalとの不一致を確認する
サイトマップに掲載されているURLが200を返していても、canonicalが別のURLを指していることがあります。その場合、サイトマップは「このURLを検索結果に出したい」と伝え、ページ側は「正規URLは別にある」と伝えることになり、両者が食い違います。
重要なのは、サイトマップ、canonical、内部リンク、実際にインデックスさせたいURLをできるだけ一致させることです。STEP3で残したURLについて、canonicalの指す先が同じURLかを照合してください。一致しない場合は、原則としてそのURLを外し、canonical先の正規URLへ統一します。
STEP5｜lastmodが実際の更新を反映しているか確認する
lastmod は「そのURLが最後に重要な変更を受けた日時」を伝えるために使います。
ただし、値を付ければ必ず評価されるわけではありません。実際の変更と一貫して整合していることが前提です。
悪いlastmod運用
次のような運用は、実際の変更を反映できていません。
- 全ページのlastmodが毎日同じ日付へ更新される
- ヘッダーやフッターの軽微変更だけで全URLのlastmodが変わる
- 記事本文を更新してもlastmodが変わらない
- CMSの公開日時だけを固定で出力している
監査時の確認方法
lastmodが実際の更新を反映しているかは、サイトマップの値を次の情報と照らし合わせて確認します。
- サイトマップの
lastmod - CMSの実更新日時
- ページ本文の変更履歴
- 必要に応じてHTTPヘッダーやデプロイ履歴
lastmodは日付を新しく見せるための値ではありません。ページに重要な変更があった時点と合わせて管理します。
STEP6｜サイトマップの分割とサイトマップインデックスを確認する
1つのサイトマップには、次の上限があります。
- 50,000 URLまで
- 非圧縮で50MBまで
どちらか一方でも超える場合は、ファイルを分割します。実務では、ページ種別ごとに分けると監査しやすくなります。ファイル名の例は次のとおりです。
post-sitemap.xmlpage-sitemap.xmlservice-sitemap.xmlproduct-sitemap.xmlcase-sitemap.xml
URL数が多いサイトでは、ページ種別ごとに分割すると、Search Console上でも、どのサイトマップに問題があるのかを特定しやすくなります。分割したら、サイトマップインデックスが各ファイルを正しく参照しているかも確認してください。
STEP7｜Search Consoleのサイトマップレポートを確認する
サイトマップレポートでは、主に次の3つの状態を見ます。
- 成功
- 取得できませんでした
- サイトマップにエラーがあります
ただし、「成功」は掲載URLがすべて適切という意味ではありません。URLの品質は、STEP3〜5のように別途監査する必要があります。
エラーが表示された場合は、次の表で、表示ごとの主な原因と対応を確認します。
| エラー | 主な原因 | 対応 |
|---|---|---|
| 取得できませんでした | 404、robots.txt、サーバー障害 | URL検査・HTTP応答確認 |
| URLにアクセスできません | 掲載URLの取得障害 | 個別URLを検査 |
| URLをたどれません | リダイレクト過多など | 最終URLへ修正 |
| URLが許可されていません | ドメイン・階層不一致 | サイトマップ配置とURLを確認 |
| 解析エラー | XML構文、エスケープ不備 | XMLを修正 |
| URL数超過 | 50,000 URL超過 | ファイル分割 |
| ファイルサイズ超過 | 非圧縮50MB超過 | ファイル分割 |
サイトマップ監査は「差分」で行うと効率が上がる
初回の監査では全件を確認します。その後は、前回との差分を中心に監視すると運用しやすくなります。差分として見る対象は次のとおりです。
- 新しく追加されたURL
- 削除されたURL
- 200から3xx・4xx・5xxへ変わったURL
- indexからnoindexへ変わったURL
- canonical先が変わったURL
lastmodが変化したURL- サイトマップ単位のURL件数変化
XMLサイトマップ監査チェックリスト
ここまでの確認項目を、監査のたびに使えるチェックリストにまとめます。
- サイトマップURLが200を返す
- Googlebotがサイトマップを取得できる
- XML構文が正しい
- URLが絶対URLで記載されている
- 掲載URLが50,000件以内
- ファイルが非圧縮50MB以内
- 掲載URLが200を返す
- 3xx・4xx・5xx URLが混入していない
- noindex URLが混入していない
- robots.txtで意図せずブロックしていない
- canonicalと掲載URLが一致している
- 重複URL・パラメータURLを除外している
lastmodが実際の重要な更新を反映している- 複数サイトマップの分割単位が適切
- サイトマップインデックスが正しく参照している
- Search Consoleで取得・解析エラーがない
- ページインデックスレポートとサイトマップを突合している
よくある質問
XMLサイトマップにnoindexページが入っていても問題ありませんか？
原則として外します。noindexが意図した設定ならサイトマップから除外し、noindexが誤設定ならページ側を修正します。
301リダイレクトURLはサイトマップに残してよいですか？
原則として、リダイレクト元ではなく転送先の最終URLを掲載します。
lastmodは必須ですか？
必須ではありません。使う場合は、実際の重要な更新と一貫して整合させます（STEP5を参照してください）。
Search Consoleで「成功」なら監査は不要ですか？
不要にはなりません。「成功」は、Googleがサイトマップを取得・解析できたことを示すものです。404、noindex、非正規URLなどが一切ないことを保証するものではありません。
小規模サイトでもXMLサイトマップは必要ですか？
約500ページ以下で、ホームページからリンクをたどって全ページへ到達できる小規模サイトでは、必須ではない場合があります。ただし、更新の管理やインデックス状況の把握を考えると、安定して運用できるなら用意しておくメリットがあります。
まとめ｜XMLサイトマップは「送信」より「中身の整合性」を監査する
XMLサイトマップの監査では、ファイルが存在してSearch Consoleへ送信されているかを見るだけでは足りません。
見るべきなのは、インデックスさせたい正規URLだけが掲載され、そのURLのHTTP状態・index可否・canonical・更新日がサイト全体の方針と一致していることです。
監査は、次の順番で進めます。
- サイトマップ自体の取得可否
- XML構文
- 掲載URLのHTTPステータスとindex可否
- canonicalとの一致
lastmodの正確性- 分割とサイトマップインデックス
- Search Consoleの取得・解析エラー
まず着手するなら、1番目の取得可否と、3番目の掲載URLの中身です。一度監査したら、次回以降はURL件数・ステータス・index可否・lastmodの差分を追う運用へ切り替えると、サイトマップの異常を早期に発見しやすくなります。
‹ 親記事: ページがインデックスされない原因は？Search Consoleで未登録・除外・重複URLを確認
