言語

ECサイトのXMLサイトマップ

ECサイトの大規模カタログで、商品・カテゴリ・ブランドごとにXMLサイトマップを分割し、50 000 URL／50MBの上限、在庫切れ・販売終了URL、lastmod、IndexNowを実務的に管理する方法を解説します。カテゴリ分割はクロールバジェットではなく監視のために行います。

初回公開：2026年7月3日 · 最終更新：2026年8月11日 · Advanced
言語
AI執筆者：AI v2
このページには証拠シグナルが1件あります

ECサイトのXMLサイトマップは、ストアがクロールを希望する正規URLを、商品、カテゴリ、ブランド、静的ページなどの種類ごとに1つのサイトマップインデックスへまとめた一覧です。設計上の上限は、1ファイルあたり50 000 URL／50MB、1インデックスあたり最大50 000ファイルです。分割はGoogle Search ConsoleやBing Webmaster Toolsで監視するためのもので、クロールバジェットや順位を上げる手段ではありません。正規かつインデックス可能で200を返すURLだけを含め、lastmodは最後の重要な変更日に合わせ、priorityとchangefreqは無視します。多くの解説が扱わない在庫切れ・販売終了商品には判断ツリーを用意し、サイトマップからの削除を内部リンクの整理と同期します。生成を自動化して古くならないようにし、価格や在庫の変化が速い場合はlastmodとIndexNowを組み合わせます。

要点 — ECサイトのサイトマップは、商品・カテゴリ・ブランド・静的ページなどの種類ごとに分け、1つのサイトマップインデックスから管理します。その理由は、モニタリングのためです。Search ConsoleやBing Webmaster Toolsで確認する診断手段であり、クロールバジェットや順位を上げる仕掛けではありません（Mueller）。設計上の上限は、1ファイルあたり 50 000 URL／50MB、1つのインデックスあたり最大 50 000ファイルです。エンタープライズ向けには、GSCは最大500サイトマップを受け付け、Bingはインデックスモデルが数十億URL規模に対応すると説明しています。正規化済みでインデックス可能な200ステータスのURLだけを含め、ファセット、トラッキングパラメータ、薄いバリエーション、リダイレクト、4xx、noindexを除外します。lastmodは両エンジンが使う 唯一 の属性なので、最後の 重要な 変更日に正直に合わせ、priorityとchangefreqは無視します（Googleは両方を明示的に無視します）。生成を自動化して古くならないようにし、価格や在庫の変化が速い場合はlastmodと IndexNowを組み合わせます。多くの解説が扱わない差別化ポイントは、在庫切れ・販売終了商品を、恒久的か一時的か、状態不明かという判断ツリーで管理し、内部リンクの整理と同期してサイトマップから削除することです。すべてを404にする運用は避けます。

カタログ規模で一般的なサイトマップ論が行き詰まる理由

「サイトマップの作り方」を扱う記事は、50 000 URLの上限、インデックスへの分割、不要URLの除外、lastmodの正確さを同じように説明します。どれも正しいのですが、ECサイトが実際に苦労する点はそこではありません。大規模カタログの問題は運用にあります。毎日入れ替わる在庫、何千件もの在庫切れ・販売終了SKU、サイズや色のほぼ重複したバリエーション、そして気づかないうちに止まる自動生成です。この記事は、サイトマップをすでに持っていて、こうした問題に対処したい人を対象にしています。

サイトが大きくなるほどサイトマップが役立つ理由は明快です。Googleは “Generally, on large sites it’s more difficult to make sure that every page is linked by at least one other page on the site.” (翻訳) 「大規模サイトでは、すべてのページがサイト内の少なくとも別の1ページからリンクされていることを確認するのが難しくなります。」と説明しています。内部リンクが少ない商品でも、サイトマップによって発見されやすくなります。John MuellerはXMLサイトマップを “a minimal baseline for any serious website.” (翻訳) 「本格的なウェブサイトにとって最低限の基盤」と呼んでいます。 Muellerの「最低限の基盤」という発言は、X/Twitterへの返信をSearch Engine Roundtableが報じたものです。一次資料を直接取得した引用ではなく、報道された発言として扱います。

設計時に押さえるハードリミット

サイトマップのプロトコルには1ファイルの上限があり、それを超えるためのサイトマップインデックスが用意されています。

  • 1ファイル: Googleは “All formats limit a single sitemap to 50MB (uncompressed) or 50 000 URLs. If you have a larger file or more URLs, you must break your sitemap into multiple sitemaps.” (翻訳) 「すべての形式で、1つのサイトマップは非圧縮50MBまたは50 000 URLに制限されます。これを超える場合は複数のサイトマップに分割する必要があります。」 Evidence for this claim Each Google sitemap file is limited to 50,000 URLs or 50 MB uncompressed. Scope: Protocol and Search Console submission limits are separate constraints. Confidence: high · Verified: Google: Large sitemaps
  • サイトマップインデックス: “A sitemap index file may have up to 50,000 loc tags” (翻訳) 「1つのサイトマップインデックスファイルには最大50 000個の loc タグを含められます。」 — つまり最大50 000個の子サイトマップを参照できます。さらに “submit up to 500 sitemap index files for each site in your Search Console account.” (翻訳) 「Search Consoleアカウントの各サイトにつき、最大500個のサイトマップインデックスを送信できます。」
  • Bingの上限: さらに大きく、1ファイルあたり50 000 URL、インデックスあたり50 000個の子ファイルです。Bingは “a single sitemap index file can reference up to 2.5 billion URLs. At scale, multiple index files can support up to 2.5 trillion URLs across a domain, making this approach ideal for large, complex sites.” (翻訳) 「1つのサイトマップインデックスで最大25億URLを参照できます。大規模環境では、複数のインデックスでドメイン全体の最大2.5兆URLを支えられるため、大規模で複雑なサイトに適しています。」

ほとんどのストアにとっての実務的な結論は、1ファイル50 000 URLを上限に種類ごとに分割し、1つのインデックスにまとめることです。数十万、数千万SKUを設計する場合にだけ、数十億・数兆という数字が意味を持ちます。それでも、プロトコル自体がボトルネックにならないことは分かります。

分割戦略と、分割の本当の目的

カタログを商品、カテゴリ／コレクション、ブランド、静的／CMSページといった論理的なサイトマップに分け、1つのインデックスから参照します。多くの解説が誤るのは、種類ごとの分割でクロールバジェットが増えたり、インデックス登録ページが増えたりするかのように示す点です。そうはなりません。Muellerは、分割はクロールを増やす手段ではなく、診断のための選択だと明確に述べています。

  • “The size & number of sitemap files generally won’t affect the crawling, unless your server is so bogged down that even fetching a handful of sitemap files would slow it down…” (翻訳) 「サイトマップファイルのサイズや数は、通常クロールに影響しません。ただし、サーバーが非常に過負荷で、少数のサイトマップを取得するだけでも遅くなる場合は別です。」
  • “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually…” (翻訳) 「通常は、サイトマップをサイトの論理的な部分に分け、それぞれを個別に監視できるようにすることを勧めます。」 いずれもReddit AMAをSearch Engine Journalが報じた内容です。実務上重要なのは、クロールのためではなく監視のために分けるという点です。

商品サイトマップとカテゴリサイトマップを分ける実益は、GSCのサイトマップレポートとBing Webmaster Toolsで、セグメントごとの送信済み対インデックス登録済みの比率を見られることです。「商品ページ」は40%、「カテゴリページ」は95%なら、どこを調べるべきかがすぐ分かります。分割は問題を見える化しますが、解決はせず、クロールバジェットも増やしません。

サイトマップに含めるもの、含めないもの

Googleのルールがそのままフィルターになります。Googleは “Include the URLs in your sitemap that you want to see in Google’s search results. Google generally shows the canonical URLs in its search results, which you can influence with sitemaps.” (翻訳) 「Googleの検索結果に表示したいURLをサイトマップに含めてください。Googleは通常、検索結果に正規URLを表示し、それにはサイトマップで影響を与えられます。」としています。したがって、サイトマップのURLは正規URLで、インデックス可能で、200を返す必要があります。 Evidence for this claim Google recommends listing the canonical URLs that a site wants shown in Search. Scope: Sitemap inclusion is a canonicalization hint and does not override noindex or response status. Confidence: high · Verified: Google: Build and submit a sitemap

含める: 正規の商品ページ（PDP）、検索結果で評価してほしいカテゴリ／コレクションページ、ブランドページ、インデックス可能な静的ページ。

除外する:

  • ファセット／フィルター／並べ替えURL — ?sort=、?color=、フィルターの組み合わせ。これらはサイトマップではなく、ファセット戦略（ブロックまたは正規化）で扱います。Joshua HardwickのAhrefsサイトマップ解説も、ECサイトでは “worth checking for duplicate and near-duplicate pages on ecommerce sites as these often slip through the net.” (翻訳) 「ECサイトでは重複ページやほぼ重複したページを確認する価値があります。こうしたページは見落とされがちです。」と指摘しています。
  • セッションIDとトラッキングパラメータ。
  • **リダイレクト（3xx）**と エラー（4xx／410） — リダイレクトURLのサイトマップは、Googleに表示したくないURLを表示するよう伝える一覧になってしまいます。
  • noindexページ — 送信しながらnoindexにするのは矛盾しており、クロールを無駄にします。
  • 薄いほぼ重複のバリエーション。 独自コンテンツのないサイズ／色違いURLは別のサイトマップエントリにせず、正規の商品URLを載せます。Googleの2024年の商品バリエーション構造化データ（ProductGroup／hasVariant／variesBy）は、サイズや色の選択肢をN個のほぼ重複ページではなく、1商品内のバリエーションとして表す現代的な方法です。バリエーションの関係はサイトマップではなく、こちらで表現します。

商品画像は別一覧ではなく、所有ページのエントリに載せます。 画像URLだけの独立したサイトマップは作らず、画像サイトマップ拡張を使い、正規の商品URLの <url> エントリに <image:image> ブロックを追加します。Googleによれば、1つの <url> タグには “Each <url> tag can contain up to 1,000 <image:image> tags” (翻訳) 「各 <url> タグには最大1 000個の <image:image> タグを含められます」ので、PDPのギャラリーには十分です。 Evidence for this claim Product images can be added to an existing product URL entry with the image sitemap extension instead of a separate image sitemap. Scope: Each <url> entry can carry up to 1,000 <image:image> tags, and the images still have to be crawlable (not blocked by robots.txt) and, if served from another domain, verified in Search Console. Confidence: high · Verified: Google: Image sitemaps 大規模カタログで見落としやすいクロール要件が2つあります。画像パスを robots.txt で拒否しないこと、商品画像を別ドメインやCDNから配信する場合はSearch Consoleでそのホストを確認することです。そうしないと画像が取得されません。どのバリエーションの画像をエントリに載せるかは、URL自体と同じ正規化設計の判断に従います。すでに除外した薄いバリエーションURLごとではなく、正規の商品エントリに画像を付けてください。

在庫切れ・販売終了商品の判断ツリー

ECサイトのサイトマップが差別化できるのはここです。ほとんどの解説はこの判断を細かく扱わず、しかし実際にはURLをサイトマップに載せるかどうかを決めます。私はAhrefsブログで完全な枠組み（在庫切れ商品をどう扱うか？場合によります）を書いています。「場合による」と呼ぶのには理由があります。完璧な解決策はありません。 重要なのは答えを暗記することではなく、事業上の目的に沿った一貫したルールを作ることです。

判断は2つの軸で分かれます。商品は 恒久的に終了したのか、一時的な在庫切れなのか。そしてページには 価値（流入、レビュー、有用な情報）が残っているのか。

  • 一時的な在庫切れで、再入荷が確定 → ページを有効に保ち、サイトマップにも残します。再入荷見込み、ウェイトリスト、再入荷通知を提示します。在庫の切り替えのたびにサイトマップから出し入れするのはノイズになるため避けます。
  • 一時的な在庫切れで、状態が不明 → すぐにサイトマップから削除するのではなく、UIと内部リンクでの優先度を下げます（並び順を下げ、フィルターで目立たなくする）。早すぎる削除は、Googleにページが放棄されたと判断され、取り戻しにくい順位を失うリスクがあります。
  • 恒久的に終了し、適切な代替商品がある → リンク評価を引き継ぐため、類似商品へ301リダイレクトし、サイトマップから削除します。
  • 恒久的に終了し、代替はないが、ページに流入や有用な内容（レビュー、購入ガイド）がある → ページとサイトマップのエントリを残せます。
  • 恒久的に終了し、価値もない → 削除して 404／410を返し、サイトマップから削除します。

重要な運用上のポイントがあります。削除は、サイトマップだけを編集する単発作業ではなく、連携したクリーンアップです。 私がその記事で述べたように、“when redirecting a page, many systems will automatically remove internal links from categories, facets, sitemaps, and internal search pages” (翻訳) 「ページをリダイレクトすると、多くのシステムはカテゴリ、ファセット、サイトマップ、内部検索ページから内部リンクを自動的に削除します」。だからこそ、URLをサイトマップから削除する だけでなく、同じ運用でそのURLを指す内部リンク（カテゴリモジュール、関連商品ウィジェット、内部検索）も整理してください。サイトマップから消えたURLが20個のカテゴリページからリンクされ続けているなら、まだ本当に整理できていません。

Google自身のガイダンスが警告することもあります。販売終了商品を反射的に 一斉404 にしないでください。Googleは、すべてを404にするより、代替商品を示してURLを有効に保つか、関連カテゴリへリダイレクトすることを推奨し、大量のソフト404を生成しないよう警告しています。新たに404になった商品ページの壁は、まさにその警告に触れるパターンです。

更新頻度、lastmod、自動化

生成を自動化する。 毎日変化するカタログでは、これは必須です。エンタープライズサイトについて私は “Add sitemaps. I would make sure this is automated. If you are asked to manually create them, you can do it, but just know that if it’s manual these will rarely be kept up-to-date.” (翻訳) 「サイトマップを追加し、自動化されていることを確認します。手作業で作るよう求められたら可能ですが、手作業ではほとんど最新に保たれないと理解しておいてください」と助言しています。Bingは具体的な失敗も記録しています。“Too often, Bing discovers stalled sitemaps which have the same URLs listed for months – sometimes years” (翻訳) 「Bingは、同じURLが何か月も、時には何年も掲載された停止状態のサイトマップを発見することがあまりに多い」と述べ、サイトマップは “should ideally be automatically generated at least once a day.” (翻訳) 「理想的には少なくとも1日1回自動生成すべきだ」と勧めています。

lastmodが重要な唯一の属性です。 GoogleとBingはこれを積極的に利用し、ほかの属性は使いません。正直な値を保ちます。

  • Google: “Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.”
    (翻訳) 「Googleは、<lastmod>の値が一貫して検証可能な形で（たとえばページの最終更新と比較して）正確な場合に利用します。」また、“reflect the date and time of the last significant update to the page… an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.” (翻訳) 「ページの最後の重要な更新日時を反映させるべきです。本文、構造化データ、ページ上のリンクの更新は通常重要とみなされますが、著作権年の更新はそうではありません。」
  • Bingはアンチパターンを率直に示しています。“Do not set the <lastmod> value set to the time you generate the sitemap. <lastmod> should be the date of the last modification of the content.” (翻訳) 「サイトマップを生成した時刻を<lastmod>に設定してはいけません。<lastmod>はコンテンツを最後に変更した日付にします。」ISO 8601の時刻付き形式を使います。

ここには正直に扱うべきグレーゾーンがあります。価格変更や在庫状態の切り替えは「重要な」更新でしょうか。Googleの定義（本文、構造化データ、リンク）では、価格だけの変更は必ずしも該当しません。ただし、Productの構造化データ（availability、price）が変わるなら、重要な変更に近いと言えます。私の見解は、賢く見せようとしないことです。小さな切り替えのたびにlastmodを更新するとノイズが増えますし、時間に敏感な値下げをすぐ伝える手段としてlastmodだけに頼るべきでもありません。

変化の速い更新では、lastmodとIndexNowを組み合わせます。 Bingは両者を二者択一ではなく補完関係として説明しています。“While real-time URL submission protocols such as IndexNow help notify search engines of immediate content changes, sitemaps remain a foundational signal for ensuring comprehensive URL coverage across your site.” (翻訳) 「IndexNowのようなリアルタイムURL送信プロトコルは検索エンジンに即時の変更を知らせますが、サイトマップはサイト全体を包括的にURLカバレッジするための基盤シグナルであり続けます」。さらにAI検索向けには、“The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling and reindexing, or skip them entirely if the content hasn’t changed since the last crawl.” (翻訳) 「サイトマップのlastmodフィールドは、Bingが再クロール・再インデックス登録するURLを優先したり、前回のクロール以降コンテンツが変わっていなければ完全にスキップしたりする際の重要なシグナルです」。つまり、サイトマップはカバレッジと毎日の鮮度、IndexNow（Bing／Yandexなど。Googleではない）は次の再クロールを待たずに価格や在庫の個別変更を送るために使います。

priorityとchangefreqを無視する

これらの保守にエンジニアリングの時間を使わないでください。Googleは明確に “Google ignores <priority> and <changefreq> values.” (翻訳) 「Googleは<priority>と<changefreq>の値を無視します」としています。Gary Illyesはpriorityフィールドを “essentially a bag of noise.” (翻訳) 「本質的にはノイズの袋」と表現したと報じられています。 Illyesの発言はSMX Advanced 2017についてSearch Engine Roundtableが報じたものです。一次資料を直接取得した引用ではありませんが、Googleの文書でも現在この2フィールドを無視すると明記されているため、結論は変わりません。プラットフォームが自動入力する値は害になりませんが、計算ロジックを組む必要はありません。

監視と診断

これが、分割の 目的 です。

  • GSCのサイトマップレポート — セグメントごとの送信済み対インデックス登録済みを確認します。商品サイトマップの比率がカテゴリサイトマップより大幅に悪ければ、薄いコンテンツ、ブロックされたバリエーション、正規化の問題など、商品ページ側の問題を直接疑えます。
  • Bing Webmaster Tools — Bing側でも同じセグメント別の表示を確認でき、IndexNowの送信状態も見られます。
  • GSCのページのインデックス登録レポート — ファセットやパラメータURLの除外数が膨らんでいないか確認します。膨らんでいれば、ファセット戦略が発見経路へ漏れている可能性があります。
  • サイトクロール／監査（Ahrefs Site Audit、Screaming Frog） — 在庫切れ表示が残る商品、どこからもリンクされない孤立商品、リダイレクトや削除の後に残った壊れた内部リンクを見つけます。

エンタープライズ規模の構成例

数百万SKUのカタログでは、後から場当たり的にファイルを増やすのではなく、実際の件数と送信上限を基準に階層を設計します。

/sitemap-index.xml            ← the one index you submit to GSC + BWT
  ├── /sitemaps/products-1.xml      (URLs 1–50,000)
  ├── /sitemaps/products-2.xml      (50,001–100,000)
  ├── … products-N.xml              (chunk every 50,000 canonical PDPs)
  ├── /sitemaps/categories.xml      (all category / collection pages)
  ├── /sitemaps/brands.xml          (all brand pages)
  └── /sitemaps/static.xml          (homepage, guides, policy pages)

商品が500万件なら、商品サイトマップは約100ファイルに加えて数個の補助ファイルになります。50 000ファイル／インデックスの上限にも、GSCの500サイトマップ受付上限にも十分収まります。仮に1つのインデックス（50 000 × 50 000 = 25億URL）を超えるなら、複数のインデックスファイルに分けてそれぞれ送信します。重要なのは、チャンクの大きさを先に決めておき、毎日の再生成では各ファイルの内容だけを書き換えられるようにすることです。想定を超えたからといって、ツリー全体を再設計する必要がなくなります。

全体の中での位置づけ

ECサイトのサイトマップは、掲載するページと密接に関係します。何をサイトマップに 含める かは、カテゴリページとファセットナビゲーションの戦略（どの絞り込みURLを正規かつインデックス可能にするか）で決まります。商品が在庫切れになったURLをどう扱うかは、在庫切れ・販売終了商品の判断です。また、サイトマップはクローラーがストアを発見する方法の1つにすぎません。内部リンク、IndexNow、Googleショッピング向けのMerchant Center商品フィードと並ぶ手段です。サイトマップはそれらの代わりではなく、URLが取り残されないようにするカバレッジの最後の安全網です。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.