XMLサイトマップの作り方と送信｜インデックスを促す

XMLサイトマップの役割

XMLサイトマップとは、サイト内でインデックスさせたいページのURL一覧を、検索エンジン向けに機械可読な形式でまとめたファイルです。役割は、クローラーにサイトの構造とページの存在を効率よく伝え、クロールとインデックス登録を促すことにあります。特にページ数が多いサイト、内部リンクだけではたどり着きにくい深い階層のページがあるサイト、新規で被リンクがまだ少ないサイトでは、サイトマップの効果が相対的に大きくなる傾向があります。ただし注意したいのは、サイトマップはあくまで「発見を助ける」ものであって、掲載したURLが必ずインデックスされることを保証するものではないという点です。インデックスされるかどうかは、ページの内容や品質、重複の有無などをGoogleが総合的に判断します。サイトマップは、良質なページをより早く・確実に見つけてもらうための補助手段と理解するのが適切です。

サイトマップに含めるべきURLの選び方

サイトマップには、検索結果に表示させたい正規のURLだけを掲載するのが原則です。具体的には、各ページの正規URL（canonicalで正規とみなしているURL）を、実在してアクセス可能な状態で記載します。逆に、含めるべきでないURLもあります。noindexを設定したページ、リダイレクトされるURL、重複ページの非正規URL、robots.txtでブロックしたパス、エラーを返すURLなどは、サイトマップに載せると信号が矛盾し、Googleに混乱を与えます。たとえば、canonicalでURL-Aを正規としているのにサイトマップにURL-Bを載せる、といった不整合は避けるべきです。サイトマップ内のURLは、canonicalや内部リンクと一貫した正規URLでそろえることが、意図どおりにクロール・評価される可能性を高めます。良質で公開したいページだけを厳選して載せる、という考え方が基本です。

XMLサイトマップの基本的な記述内容

XMLサイトマップは、各URLをlocという要素で記述し、必要に応じて最終更新日（lastmod）などの情報を付与します。lastmodは、そのページが最後に実質的に更新された日時を示すもので、正確に運用されていればクローラーが再クロールの優先度を判断する手がかりになります。逆に、実際には更新していないのにlastmodを常に最新日時にするような運用は、信頼性を損ない、手がかりとして無視される要因になります。かつては更新頻度や優先度を示す要素も使われていましたが、これらは現在のGoogleではほとんど参考にされないとされています。過度に多くの情報を盛り込むより、正規URLの一覧と、正確なlastmodを維持することに注力する方が実務的です。ファイルは文字コードや形式の仕様に沿って生成する必要があるため、手書きよりツールやCMSの自動生成機能を使うのが安全です。仕様は変更される場合があります。最新情報はGoogleの公式ドキュメントをご確認ください。

サイトマップの作成方法

XMLサイトマップの作成方法は、サイトの構築手段によって異なります。多くのCMSでは、サイトマップを自動生成する機能やプラグインが用意されており、ページの追加・更新に合わせてサイトマップが自動的に更新されます。自動生成を使う最大の利点は、ページの増減にサイトマップが追随し、手動更新の手間や漏れがなくなることです。フレームワークで構築したサイトでも、ビルド時にサイトマップを生成する仕組みを組み込むのが一般的です。ページ数が非常に多い場合は、1つのサイトマップに載せるURL数やファイルサイズの上限に配慮し、複数のサイトマップに分割したうえで、それらをまとめるサイトマップインデックスを用意します。いずれの方法でも、生成されたサイトマップに載っているURLが、実際に公開している正規URLと一致しているかを確認することが重要です。自動生成に任せきりにせず、内容を一度は目視で確かめる運用が安全です。

サーチコンソールでの送信手順

作成したサイトマップは、Googleサーチコンソールから送信することで、Googleに存在を明示的に伝えられます。サーチコンソールの「サイトマップ」レポートで、サイトマップのURL（例：https://example.com/sitemap.xml）を入力して送信します。送信後、Googleがサイトマップを読み込むと、レポートに取得状況や検出されたURL数、エラーや警告が表示されます。ここでエラーが出ている場合は、記述形式の問題や、到達できないURLが含まれている可能性があるため、内容を見直します。また、robots.txtにサイトマップの場所を記載しておくと、他の検索エンジンのクローラーもサイトマップを見つけやすくなります。送信はあくまで「発見を促す」行為であり、送信したからといって即座にインデックスされるわけではありません。送信後は、サーチコンソールでインデックス状況を継続的に確認し、登録の進み具合を追っていくことが現実的な運用です。

ページ数が多いサイトでの分割運用

サイトの規模が大きくなると、1つのサイトマップでは扱いきれなくなります。サイトマップには、1ファイルあたりに掲載できるURL数とファイルサイズの上限が仕様として定められており、これを超える場合はサイトマップを複数に分割する必要があります。分割したサイトマップは、それらの場所をまとめて記載する「サイトマップインデックス」を用意し、サーチコンソールにはこのインデックスを送信することで一括して管理できます。分割の仕方に決まりはありませんが、コンテンツの種類ごと（商品・記事・カテゴリなど）や、更新頻度ごとに分けておくと、どの領域のインデックスが進んでいるかを把握しやすくなります。たとえば頻繁に更新するブログと、ほとんど変わらない固定ページを別のサイトマップに分けておけば、更新の多い領域の状況を集中して確認できます。大規模サイトでは、こうした分割運用によって、クロールとインデックスの状態を領域単位で管理する体制を整えておくことが、問題の早期発見につながります。仕様上の上限値は変わる可能性があるため、実装時は最新の仕様を確認することをお勧めします。

送信後の確認とよくある間違い

サイトマップ送信後は、サーチコンソールの「ページのインデックス登録」レポートで、送信したURLがどの程度インデックスされているかを確認します。「検出されたが登録されていない」「クロール済みだが登録されていない」といった状態が多い場合は、サイトマップの問題というよりページの内容や品質、重複が原因であることが多く、コンテンツ側の見直しが必要になります。よくある間違いとしては、noindexページやリダイレクトURLをサイトマップに含めてしまう、canonicalと異なるURLを載せる、古いURLを削除せず放置する、といったものがあります。これらは信号の矛盾を生み、クロールの効率を下げます。サイトマップは一度作って終わりではなく、ページの追加・削除・URL変更に合わせて常に最新の正規URL一覧を保つことが、インデックス促進の効果を維持するうえで重要です。

よくある質問（FAQ）

Qサイトマップを送信するとインデックスされますか？

Aいいえ。サイトマップはページの発見とクロールを促す補助手段であり、掲載したURLが必ずインデックスされることを保証するものではありません。インデックスの可否は内容・品質・重複の有無などをGoogleが総合的に判断します。

Qサイトマップに載せてはいけないURLはありますか？

Anoindexページ・リダイレクトされるURL・重複ページの非正規URL・robots.txtでブロックしたパス・エラーを返すURLは載せるべきではありません。検索に表示させたい正規URLだけを掲載するのが原則です。

Qサイトマップは手動で作るべきですか？

A多くの場合、CMSの機能やプラグイン、ビルド時の自動生成を使う方が安全です。ページの増減に自動で追随し、更新漏れを防げます。ただし生成された内容が正規URLと一致しているかは一度確認することをお勧めします。

Qlastmodはどう扱えばいいですか？

Aそのページが実際に更新された日時を正確に反映させることが重要です。更新していないのに常に最新日時にすると信頼性を損ない、手がかりとして無視される要因になります。正確な運用が前提です。

Qサイトマップはどこから送信しますか？

AGoogleサーチコンソールの「サイトマップ」レポートにサイトマップのURLを入力して送信します。送信後、取得状況や検出URL数、エラーの有無を確認できます。robots.txtにサイトマップの場所を記載しておくのも有効です。

Q送信後にインデックスが進まない場合は何を見ればいいですか？

Aサーチコンソールの「ページのインデックス登録」レポートを確認します。「クロール済みだが登録されていない」などが多い場合は、サイトマップよりページの内容・品質・重複が原因のことが多く、コンテンツ側の改善が必要です。