サイトマップとは？XMLとHTMLの違い・作成と送信の確認手順

サイトマップには、検索エンジンへURLを知らせるXMLサイトマップと、利用者が内容を探すためのHTMLサイトマップがあります。XMLは、公開する正規URLをファイルにまとめ、Search Console等から場所を知らせます。作成・送信が成功しても、掲載した全URLのクロールやインデックス登録が保証されるわけではありません。

実務では「載せるURLを決める→ファイルを生成する→取得できるか確認する→送信する→個別URLの状態を確認する」の順に進めます。このページはその判断と確認を扱います。ツール全体の用途はGoogleサーチコンソールとは、所有権の確認等の導入作業はSearch Consoleの設定手順を参照してください。

XMLとHTMLは目的が異なる

XMLがあっても、利用者向けのナビゲーションが不要になるわけではありません。通常のカテゴリやパンくずリストから記事へたどれる構成を維持します。逆に、HTMLの一覧ページを作っただけでXMLの送信も済んだとは扱いません。両者は併用できます。

Googleのサイトマップ作成の公式ガイドは、大規模サイト、新しいサイト、内部リンクで十分に発見できない内容などでの用途を説明しています。サイトマップは発見の補助であり、品質や公開設定に関する問題を解決する代わりにはなりません。

掲載対象は「公開する正規URL」を基準にする

まず、検索で見つけてもらいたいページの台帳とCMSの公開状態を照合します。候補は、公開され、通常の成功応答で本文を提供し、検索登録を意図する正規URLです。認証が必要なページ、削除済みのURL、転送専用URL、検索対象にしないURLを機械的に混ぜないようにします。

これは、混入したURLが一つあるだけでサイト全体に一律の罰があるという意味ではありません。運営者の意図を一貫させ、確認すべき対象を明確にするための整理です。Googleが選ぶ正規URLはサイト側の指定と異なる場合もあるため、canonicalの設定と確認も併せて行います。

XMLを生成するときの仕様と更新ルール

URL数と容量は、圧縮前で確認する

通常のXMLサイトマップは、1ファイルにつき50,000 URL、圧縮前50MBの上限があります。どちらかを超える前に分割し、必要に応じてサイトマップインデックスから案内します。gzipで小さくなった容量だけを見て上限内と判断しません。詳細はSitemapsプロトコルとGoogleの作成ガイドで確認できます。

文字コードはUTF-8を使い、XMLとして必要な文字のエスケープと、URLとして必要なエンコードを区別します。例えばクエリ文字列の区切り記号をXML内へ書く場合、XMLの文法に合う表現が必要です。CMSやライブラリが自動生成する場合も、ファイルが最後まで正しく読み取れるかを確認します。

lastmodは実際の重要な変更を表す

lastmodを付けるなら、本文、構造化データ、重要なリンク等の実質的な変更日時と対応させます。ファイルを生成し直した時刻や、フッターの年だけの変更を、全記事の更新日として書き換えないようにします。Googleは、継続的に正確なlastmodを利用しますが、priorityとchangefreqは無視すると説明しています。

CMSで更新日時を管理していても、誤字修正・公開処理・システム処理のどれが反映されるかは実装次第です。記事更新の定義、生成処理、時刻の扱いを運営者と開発担当で決めておくと、運用上のずれを減らせます。

作成から送信までの手順

1. CMSやサイト生成機能が既にサイトマップを出力しているか確認する。
2. 実際のファイルURL、分割ファイル、更新方法を控える。
3. 公開する正規URLが含まれ、削除・転送・非公開URLが混ざっていないかを点検する。
4. 許可された方法でファイルが取得でき、XMLとして読み取れるかを確認する。
5. 対象のSearch Consoleプロパティと権限を確認し、サイトマップの場所を送信する。
6. 取得結果、最終読み込み、検出URL数を記録する。
7. 重要URLを個別検査し、ファイル取得と検索登録を分けて確認する。

サイトマップのURLは必ずルートの同じ場所にあるとは限りません。CMSの設定、robots.txtの案内、運営資料等から実際の場所を確認します。Search Consoleへ送信することは、GoogleへXMLファイルそのものをアップロードすることではなく、取得してほしい場所を知らせる操作です。

プロパティの種類やレポート画面によって、入力する場所やURLの扱いが異なります。対象サイトと権限を確かめてから操作し、別テナント・別ドメインのファイルを送信しないようにします。現行の手順と必要な権限はSearch Consoleのサイトマップレポートで確認します。

「成功」と「そのURLが登録済み」は別の証拠

レポートの取得成功は、Googleがその時点でファイルを取得・処理できたという証拠です。現在のXMLに特定URLが入っていることや、全URLが検索に登録されたことまでは示しません。最終取得日時、現在のファイル内容、URL検査の結果を別々の記録として扱います。

架空の確認例です。ある記事のURLを現在のXMLで確認できても、URL検査が「検出・インデックス未登録」であれば、掲載と登録を分けて記録します。「クロール済み・未登録」なら、Googleはページを取得したが登録していない状態として扱い、公開内容、正規化、重複、内部リンク、技術条件等を追加で調べます。原因を本文品質だけと決めつけません。

架空の更新台帳を使った確認例

記事を100本公開しているサイトで、新規記事2本を公開し、1本を別URLへ移し、1本を削除したとします。期待する掲載数は、新規追加と削除を反映した101本です。移転は旧URLを新URLに置き換えるため、単純な追加として数えません。ただしCMSがカテゴリ一覧も含めて出力する設計なら、記事数とファイル内の全URL数は一致しません。最初に対象の範囲を決めます。

確認担当は、新規2本の掲載、新旧URLの入れ替え、削除URLの除外を点検し、ファイルの生成日時を控えます。その後、Search Consoleの最終読み込みがその版より後かを確認し、重要な記事の個別状態を記録します。「数が101だから完了」とせず、変わったURLそのものを照合するのがポイントです。

取得できない・数が合わないときの切り分け

ブラウザでファイルを開けない場合は、表示側の拡張機能や環境、実際のアクセス制限、配信エラー等の可能性を分けます。許可された別の確認方法で取得できない限り、個別URLの掲載を確認済みとは記録しません。Search Consoleの過去の成功だけで、現在のファイルが正しいとも断定しません。

URL数が台帳と合わないときは、公開条件、言語、重複の除外、カテゴリ別分割、生成時点の差を調べます。多いほど良い指標ではありません。記事を新規公開・移転・削除した際に、CMS、内部リンク、サイトマップがどの順で更新されるかを確認すると、ずれの原因を探しやすくなります。

毎回の確認記録には、サイトマップURL、確認日、取得方法、最終読み込み、期待するURL数、実際のURL数、抽出した重要URLの状態、担当者を残します。基本的な検索対策の全体像はSEO対策の基本で確認し、登録状況と検索表示・クリックの変化を混同せず追っていきます。