サイトマップをディレクトリ別に分けてインデックス漏れを切り分ける

インデックス登録済みのページ数は、全体で見ると7割前後。悪くはない。でも、残りの3割がどこに偏っているのかが分からない。

答えは、サイトマップをディレクトリ単位に分けて送信し、ページ インデックス登録レポートをサイトマップで絞り込むことです。URLの件数が5万件に届いていなくても、分割する理由はあります。分割の目的は容量対策ではなく、「どの区画で登録が止まっているか」を数字で切り分けることだからです。

なぜ1本のサイトマップでは切り分けられないのか

1本の sitemap.xml にブログ記事も商品ページもカテゴリ一覧も入っていると、Search Console に出る数字はすべて合算になります。登録率が下がっても、どの区画が足を引っぱっているのかは見えません。

Search Console のページ インデックス登録レポート（どのページが登録され、どのページがどんな理由で外れているかを一覧できる画面）には、グラフの上にサイトマップの絞り込みがあります。Google のヘルプはこう書いています。

Specific sitemap URL - Show only URLs listed in a specific sitemap or sitemap index submitted using either the Sitemaps report or a robots.txt file on your site. （特定のサイトマップURL: サイトマップ レポートまたは robots.txt で送信した、特定のサイトマップまたはサイトマップ インデックスに載っているURLだけを表示します。）

公式が挙げている絞り込みの単位は、送信したサイトマップです。URLのディレクトリを指定する選択肢は、この説明には出てきません。

だから、ディレクトリごとの状態を見たいなら、サイトマップの境界をディレクトリの境界にそろえておく必要があります。/blog/ だけを載せたサイトマップを送っておけば、そのサイトマップで絞った結果が、そのままブログ区画の登録状況になります。

サイトマップの作り方のページにも、分割して送ることの用途が書かれています。

You can submit multiple sitemaps and sitemap index files to Google. This may be useful if you want to track the search performance of each individual sitemap in Search Console. （複数のサイトマップやサイトマップ インデックス ファイルを Google に送信できます。Search Console で個々のサイトマップの検索パフォーマンスを追跡したい場合に役立つことがあります。）

容量の上限に当たったときの手段であると同時に、追跡の単位を作る手段でもある。分割はこの2つめの用途で使います。

サイトマップ インデックスの仕様で押さえる5点

分割したサイトマップは、サイトマップ インデックス（複数のサイトマップを束ねる目次のようなファイル）でまとめられます。公式ドキュメントから、実装でつまずきやすい点だけを抜き出します。

このうち、ディレクトリ別に分けるときに効いてくるのは4つめの置き場所です。

公式の例では、インデックスが https://example.com/public/sitemap_index.xml にあるなら、参照できるのは /public/ 以下のサイトマップだけです。/blog/sitemap_index.xml にインデックスを置くと、/products/ のサイトマップは参照できません。ディレクトリをまたいで束ねるなら、インデックスはルートに置きます。

5つめの入れ子も見落としやすい点です。ヘルプには、インデックスが自分自身や別のインデックスを指していると「Nested sitemap indexes」というエラーになると書かれています。「ディレクトリごとにインデックスを作って、さらにそれを親インデックスで束ねる」構成は使えません。

もう1つ、ヘルプが挙げるエラーに「incomplete URL」があります。インデックス内の loc に sitemap-blog.xml のような相対パスを書くと出るものです。子サイトマップは https:// から始まる完全なURLで書きます。

ルート直下に置くインデックスの最小形は次のとおりです。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap-blog.xml</loc>
    <lastmod>2026-10-19</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap-products.xml</loc>
  </sitemap>
</sitemapindex>

子サイトマップ自体はルート直下に置いても、各ディレクトリの中に置いても構いません。どちらでもインデックスと同じディレクトリかそれより下になるからです。

分割から切り分けまでの5ステップ

手順は、生成・確認・送信・絞り込み・比較の順に進めます。

1. ディレクトリごとに子サイトマップを生成する。 /blog/ 配下だけ、/products/ 配下だけ、というようにURLの先頭パスで振り分けます。1つのURLを2つの子に重複して入れないことが大事です。理由は後の「よくある誤解」で扱います。
2. 載せるURLを正規URLに絞る。 公式は、サイトマップに載せるURLを「検索結果に出したいURL」、つまり正規URL（重複するページのうち代表として評価してほしいURL）だと書いています。リダイレクト元やパラメータ付きの重複URLが混ざると、絞り込んだ数字がそのぶん濁ります。
3. ルートにインデックスを置き、ブラウザか curl で取得できるか確かめる。 curl -sI https://www.example.com/sitemap_index.xml でステータスが200になるかを見ます。子サイトマップも1本ずつ同じ確認をします。
4. Search Console のサイトマップ レポートで、インデックスと子サイトマップの両方を送信する。 絞り込みの選択肢に子が確実に並ぶようにするための手順です。公式は「特定のサイトマップまたはサイトマップ インデックス」で絞れると書いていますが、インデックスだけを送ったときに子が個別に選べるかまでは明記していません。子も個別に送っておけば、この点に依存せずに済みます。
5. ページ インデックス登録レポートで子サイトマップを1つずつ選び、登録済みと未登録の内訳を比べる。 未登録の理由（「クロール済み - インデックス未登録」など）がどの子に集中しているかを見ます。

4の送信件数について補足します。公式によれば、Search Console で送信できるサイトマップ インデックスは1サイトあたり500件までです。ディレクトリ単位で分けるかぎり、この上限が問題になることはほとんどありません。

ワークスルー: ブログ1,200件・商品1,800件の架空サイト

ここからは架空のサイトで5ステップを一度通します。数字はすべて説明用の仮の値です。

サイトの構成は、/blog/ に記事が1,200件、/products/ に商品ページが1,800件。これまでは1本の sitemap.xml に3,000件をまとめて送っていました。ページ インデックス登録レポートの全体の数字は、登録済み2,100件・未登録900件です。

ステップ1で sitemap-blog.xml（1,200件）と sitemap-products.xml（1,800件）に分けます。ステップ2で、商品ページの並び替えパラメータ付きURLが120件混ざっていたのを外し、sitemap-products.xml は1,680件になりました。ステップ3・4で、ルートの sitemap_index.xml と子2本を送信します。

ステップ5で子を1本ずつ選ぶと、内訳はこうなりました。

全体の「未登録900件」は、ほぼ商品区画の問題だったわけです。

1行目のブログは、未登録が70件と少なく、理由も「検出 - インデックス未登録」です。公開から日が浅い記事が多いなら、まず時間を置いて推移を見る段階です。

2行目の商品ページは事情が違います。「クロール済み - インデックス未登録」が730件まとまっている。ステータス名どおり読めば、取得はされたのに登録に至っていないページの集まりです。色違いやサイズ違いで本文がほぼ同じ商品ページが多い、在庫切れのページが中身の薄いまま残っている、といった区画特有の原因を疑う段階に進めます。全体の数字だけを見ていたら、ブログ記事のリライトに手をつけていたかもしれません。

よくある誤解: 分割すれば登録が増える

分割は、登録を増やす手段ではありません。見える数字の粒度を変える手段です。

公式は、サイトマップに載せても全URLのクロールと登録は保証されないと書いています。

A sitemap helps search engines discover URLs on your site, but it doesn't guarantee that all the items in your sitemap will be crawled and indexed. （サイトマップは検索エンジンがサイトのURLを見つける助けになりますが、サイトマップ内のすべての項目がクロールされ、インデックス登録されることを保証するものではありません。）

1本を2本に分けても、この前提は変わりません。分割後に登録数が動いたとしても、それは分割の効果というより、ステップ2で重複URLを外したことや、時間の経過によるものだと考えたほうが筋が通ります。

数字の読み方にも落とし穴が2つあります。

1つめは、URLの重複です。ヘルプによると、サイトマップ インデックスの「検出されたページ」は子サイトマップ全体のURL数で、重複するURLは1回しか数えません。同じ商品URLを sitemap-products.xml と sitemap-sale.xml の両方に入れると、子の件数の合計とインデックスの件数が合わなくなります。ディレクトリとサイトマップを1対1で対応させておけば、この食い違いは起きません。

2つめは、「送信済み」の扱いです。ヘルプには、別の経路（ほかのページからのリンクなど）で見つかったURLでも、サイトマップに載っていれば送信済みとして扱うと書かれています。リンク経由で先に見つかったページも、子サイトマップに載せたかぎりはその子の数字に入ります。

修正後の確認も、子サイトマップ単位で回す

原因を直したあとの確認でも、分割は役に立ちます。

ページ インデックス登録レポートには「修正を検証」という機能があります。ヘルプは、重要なページだけを載せたサイトマップを作って送信し、そのサイトマップで絞り込んでから検証を依頼すると、検証が早く終わることがあると紹介しています。

ただし注意書きもあります。

If you are filtered to a specific sitemap in your report, the validation will apply only to items in the sitemap at the time you requested validation. （レポートを特定のサイトマップで絞り込んでいる場合、検証は依頼した時点でそのサイトマップに含まれる項目だけに適用されます。）

さきほどの商品区画なら、sitemap-products.xml で絞ったまま検証を依頼すると、対象はその時点の商品ページだけです。ブログ区画の同じ問題は検証されません。区画ごとに原因が違うなら、むしろ好都合です。直した区画だけを、直した順に確認できます。

自社サイトで確かめる点検表

分割を始める前と、送信したあとに1回ずつ当てはめてください。

最後の項目まで埋まれば、次に手をつける区画が決まります。

載せるURLの選び方はサイトマップに載せるURL・載せないURLの判定基準、送信後に「検出されたURL」が0のまま動かないときはサイトマップの検出されたURLが0のときに見る5つの実測を参照してください。区画を特定したあと、個々のページが登録されない原因を調べるには新規ページがインデックスされない原因の切り分けが使えます。