サーバー運用ガイド

XMLサイトマップの作り方|現行仕様・送信・検証手順

XMLサイトマップは、検索エンジンへクロール候補のURLと更新情報を伝えるファイルです。登録すれば順位やインデックスが保証されるものではありません。生成元、URL品質、送信結果、再確認までを一つの運用手順にします。

更新 2026-07-25 Finite Field 編集部

電子的な設定を操作する手元のイメージ
サイトマップは検索エンジンへの補助情報です。公開URLの品質と内部リンクを先に整え、送信後の状態を記録します。

本記事は一般的な技術情報です。Googleの仕様・管理画面・CMSの実装は更新されます。公開前に対象サイトの現在の生成元と公式ドキュメントを確認し、送信結果やインデックス状況を順位保証と解釈しないでください。

このガイドで判断できること

sitemap.xmlを置く前に、含めるURL、形式、送信先、検証証拠を決めます。

含めるURLを選ぶ

正規URLで、検索結果に表示させたい公開ページだけを候補にします。noindex、リダイレクト、エラーURLは除外します。

形式と分割を決める

通常のURL一覧かサイトマップインデックスかを選び、件数・ファイルサイズの上限を超える場合は分割します。

送信経路をそろえる

Search Console、robots.txt、HTTPレスポンスで同じ正規URLを案内し、環境ごとのURL混在を防ぎます。

結果を保証と誤解しない

サイトマップはクロール候補の発見を助けるヒントです。登録・取得・インデックス・順位は別々に確認します。

サイトマップは「発見を助ける補助情報」であり、登録や順位の保証ではない

Google公式資料では、サイトマップは検索エンジンがサイト内URLを発見するためのヒントと説明されています。作成・送信は有用ですが、クロール、インデックス登録、検索順位を直接決める仕組みではありません。

含めるもの

200系で取得でき、正規URLで、検索結果に表示させたいページ。lastmodは実際の重要な更新を反映する場合だけ使います。

含めないもの

重複URL、リダイレクト先でないURL、404、noindexページ、ログイン必須ページ、検索結果に出したくない一時URL。

完了条件

XML構文、HTTP応答、URLのcanonical、Search Consoleの送信状態を記録し、変化を監視できること。

sitemap.xmlとサイトマップインデックスの使い分け

通常のサイトマップはURL要素を並べ、ファイル数やURL数が多い場合はインデックスから複数ファイルを参照します。画像・動画・ニュース用の拡張は対象コンテンツがある場合だけ選びます。

サイトマップ形式の比較
形式使いどころ注意点
通常のsitemap.xml小〜中規模サイトの公開URLを1ファイルで管理するURL数・圧縮前サイズの上限、XML名前空間、絶対URLを守る
sitemap index複数のsitemap.xmlをまとめ、大規模サイトや分割運用を管理するインデックス自身を参照先にし、循環参照や環境違いを避ける
画像・動画・ニュース画像・動画・ニュース情報を検索エンジンへ補足する対象コンテンツと公式仕様に合う場合だけ使い、情報を重複管理しない

生成・公開・送信を安全な順序で行う

CMSや静的生成器の設定を変える前に、生成元と現在の公開ファイルを保存します。手動編集と自動生成を同時に行わないことが重要です。

  1. 1

    候補URLと正規URLを抽出する

    公開対象を一覧化し、canonical、noindex、リダイレクト、認証、404を確認します。サイトマップには最終的な正規URLだけを残します。

  2. 2

    生成元とXMLを確認する

    CMSプラグイン、フレームワーク、ビルド処理のどれが出力を所有するか決め、XML宣言・名前空間・lastmod・URLを検査します。

  3. 3

    公開・robots.txt・Search Consoleをそろえる

    HTTPSの公開URLで200を返すことを確認し、robots.txtのSitemap行とSearch Consoleの送信先を同じURLにします。

  4. 4

    送信後の差分を記録する

    取得日時、検出URL、エラー、インデックス状況を記録し、更新後に再確認します。送信済みだけで成功と判定しません。

検証画像で見る確認ポイント

画像は管理画面や公式仕様の確認例です。画面の数値や表示は変わるため、実サイトの現在のレスポンスと公式ドキュメントを併せて確認します。

送信前後の検証チェック

ファイルが存在することだけでなく、含めたURLが検索対象として妥当か、送信後の状態が変化していないかを分けて確認します。

ファイルとHTTP

  • 公開URLがHTTPSで200を返し、Content-Typeと文字コードが想定どおり
  • XML構文、名前空間、絶対URL、URL数、ファイルサイズを確認
  • lastmodが実際の重要な更新日と一致し、毎回変化していない

URL品質

  • 各URLのcanonical、noindex、リダイレクト、認証、404を確認
  • 重複URL、パラメータURL、検索結果に不要なページを除外
  • 内部リンクとサイトマップの対象範囲が意図どおりに一致

送信後の記録

  • Search Consoleの送信・最終読み込み・エラーを保存
  • 検出URLとインデックス登録状況を順位保証と混同せず観測
  • 生成元・変更日時・ロールバック手順を運用記録に残す

根拠として参照した公式資料

仕様と検証手順は、Google Search CentralおよびSearch Consoleヘルプの現行資料を基準にしています。

XMLサイトマップに関するよくある質問

サイトマップを送信すれば、すべてのURLが登録されますか?

いいえ。サイトマップはURL発見のヒントです。クロール、インデックス登録、検索順位はページ品質、重複、canonical、noindex、内部リンクなど別の要因も確認します。

lastmodは毎日更新した方が有利ですか?

いいえ。重要な更新がないのに日付だけを変えると、情報の信頼性を損ないます。実際の更新履歴と一致するときだけ更新します。

robots.txtにSitemap行を書けば十分ですか?

robots.txtで場所を知らせる方法はありますが、公開URLが取得できること、Search Consoleの送信、HTTP応答、XML内容を別々に確認します。

サイトマップにnoindexページを入れても問題ありませんか?

検索対象にしないページを含めるとシグナルが矛盾します。noindex、リダイレクト、エラーなどを除外し、正規URLだけを掲載します。

サイトマップを『送信した』で終わらせない

生成元、URL品質、HTTP応答、送信結果、インデックス状況を分けて記録すれば、仕様変更やCMS更新にも安全に追従できます。順位保証の主張ではなく、再現可能な検証証拠を残しましょう。

サイト構成の確認を相談

この記事の監修

Finite Field 編集部

サーバー運用、公開設定、検索エンジン向け技術情報を、公式資料と実際の検証結果に照らして編集しています。