サイトマップインデックスとは、複数のXMLサイトマップの場所をまとめて検索エンジンに伝えるファイルのことです。1つのサイトマップには入れられるURLの数と容量に上限があり、それを超えるサイトは、分けたファイルをこのインデックスでまとめます。
XMLサイトマップの書き方、Search Consoleへの送り方、IndexNowはXMLサイトマップの記事で書きました。この記事は、URLが多いサイトでファイルをどう分け、分けたものをどう見るかに絞ります。
上限を超えたら、どうする?
Googleのサイトマップの作り方は、1つのサイトマップの上限を、50,000 URLと、圧縮しない状態での50MBとしています。どちらかを超えたら、複数のサイトマップに分けます。分けたら、インデックスファイルを作って、それだけをGoogleに送ることもできます。
大きなサイトマップの説明には、インデックスファイルの決まりがまとまっています。
| 決まり |
内容 |
| 1ファイルに書ける数 |
サイトマップの場所が50,000件まで |
| 送れる数 |
1サイトにつきインデックスファイル500個まで |
| 子の置き場所 |
同じサイトの、同じディレクトリかその下 |
| 要件 |
サイトマップの要件がインデックスにも当てはまる |
インデックスファイルの書式は、通常のサイトマップとよく似ています。urlsetの代わりにsitemapindexで囲み、子のサイトマップごとにsitemapとlocを書きます。説明用の例です。
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemaps/products.xml</loc>
<lastmod>2026-10-29</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemaps/columns.xml</loc>
<lastmod>2026-10-20</lastmod>
</sitemap>
</sitemapindex>
置き場所の決まりに注意します。インデックスを/sitemaps/の中に置き、子をサイトのルートに置くと、子のほうが上の階層になります。迷ったらインデックスをルートに置き、子をその下にまとめます。
何で分けると、あとで見やすい?
何を単位に分けるかは、Googleの説明には決まりがありません。私たちが勧めるのは、ページの種類で分けることです。理由は、次の節のSearch Consoleで、種類ごとに登録の状況を見られるからです。
製造業のサイトなら、たとえば次のように分けます。
| ファイル |
中身 |
増え方 |
| products.xml |
製品・型番のページ |
新製品のたびに増える |
| makers.xml |
会社のページ |
掲載する会社が増えると増える |
| lists.xml |
地域・業種の一覧 |
切り口を足すと増える |
| columns.xml |
技術記事 |
月に数本 |
1つの種類が50,000 URLを超えそうなら、その種類の中で番号を付けて分けます(products-1.xml、products-2.xml)。分ける境目は、ID順や公開順のように、URLが別のファイルへ移らない決め方にします。カテゴリ名で分けると、製品のカテゴリを付け替えたときに、URLがファイルの間を移ります。
更新の頻度で分けるのは、補助にとどめる
よく更新されるページだけを1つのファイルに集める分け方もあります。ただ、更新の頻度はページの種類とずれることが多く、Search Consoleで見るときに何の集まりか分かりにくくなります。種類で分けた上で、各ファイルのlastmodを正しく付けるほうが管理しやすいと考えています。
インデックスのlastmodは、何の日付?
大きなサイトマップの説明では、インデックスのlastmodは、対応するサイトマップのファイルが変わった時刻を示すものです。Googleはこれを、クロールの予定を立てる助けにするとしています。
子のサイトマップの中で、URLが増えた、消えた、ページのlastmodが変わった日が、そのファイルが変わった日です。サイトを組み立て直しただけで中身が同じなら、日付は動かしません。製品のファイルだけが変わったなら、記事のファイルの日付は前のままです。
子の中のページのlastmodも同じ考え方で、Googleは一貫して正確だと確かめられる値を使うとしています。組み立てるたびに全ページを今日の日付にすると、変えていないページまで変わったと伝えることになります。ページの日付の考え方は更新日の見せ方で書きました。
Search Consoleでは、どこを見る?
インデックスファイルのURLを、Search Consoleのサイトマップ レポートから送ります。レポートに出るのは、種類(サイトマップかインデックスか)、最終読み込み日時、ステータス、検出されたページ数です。
インデックスの場合、検出されたページ数は、すべての子サイトマップのURLの合計です。重なっているURLは1回だけ数えます。ヘルプは、この数がクロールやインデックス登録の数ではないと書いています。
登録された数は、インデックス登録のレポートで見ます。グラフの上にあるフィルタで、次の4つから選べます。
- すべての既知のページ
- すべての送信済みページ
- 未送信ページのみ
- 特定のサイトマップのURL
種類ごとに分けておくと、4つ目で products.xml だけ、makers.xml だけを選べます。製品ページは登録されているのに、会社のページだけ「クロール済み - インデックス未登録」が多い、という差が種類ごとに分かります。1つの大きなファイルにまとめていると、この差はURLを1件ずつ見ないと分かりません。登録されなかった理由の読み方はインデックス未登録の理由にまとめています。
レポートの表示は1,000件まで
サイトマップ レポートに表示される送信は、最大1,000件です。それ以上送ることはできても、表示は1,000件までで、送信順にもなりません。子のサイトマップを個別にたくさん送るより、インデックスを送るほうが一覧で追いやすくなります。
検索に出さないページは、入れない
Googleの作り方の説明は、サイトマップに入れるのは検索結果に表示したいURLだとしています。そう読むと、noindexを付けたページ、別のURLへ正規化しているページ、転送しているURLは入れないことになります。
私たちが運営するメーカー図鑑は、2026年10月24日の時点で、検索に出すURLとしてサイトマップに16,265件を載せていました。1ファイルの上限より手前の数です。カイシャのホントは、数字が少ない会社をnoindexにしていて、検索に出す会社ページは6,695です(2026年10月25日0時に本番)。ページの数と、検索に出す数が違うサイトでは、サイトマップを作る処理が、noindexを決める処理と同じ条件を読むようにしておきます。条件がずれると、noindexのページがサイトマップに載り、送信したのに登録されないURLとして数え続けることになります。noindexにする基準の決め方は薄いページとはで書きました。
ページ数が多いサイトで、クロールの量そのものが足りるかはクロールバジェットで扱っています。サイト設計の全体はサイト設計から読めます。
仕様・出典の確認日:2026年10月25日。