ECサイトのXMLサイトマップ作成方法｜含めるURLと更新ルール
目次
XMLサイトマップは、検索エンジンに発見してほしいURLと更新情報を伝えるファイルです。ECサイトでは商品やカテゴリが多く、内部リンクだけでは新商品や深い階層のページが見つかるまで時間がかかることがあるため、正規URLの一覧を補助的に提供します。
サイトマップへ載せれば必ずクロール・インデックスされるわけではありません。検索対象にしたい200の正規URLだけを含め、公開・終了・URL変更に合わせて自動更新することが重要です。
XMLサイトマップの役割
サイトマップは、サイト側が重要と考えるURLを検索エンジンへ知らせます。内部リンクの代わりではなく、リンク構造を補助するものです。利用者がたどれない孤立ページをサイトマップだけで支える設計は避けます。
商品、カテゴリ、記事を分けて作成すると、Search Consoleで種類ごとの送信・登録状況を確認しやすくなります。更新頻度が異なるページ群を分ける運用にも向いています。
含めるURL
検索結果へ出したい、200で表示される正規URLを含めます。販売中の商品、主要カテゴリ、公開中の特集や記事が基本です。自己参照canonicalを持ち、サイト内の通常リンクでも使われているURLとそろえます。
色やサイズのバリエーションを個別ページとして検索対象にする場合は、各URLが固有内容と正しいcanonicalを持つか確認します。代表商品へまとめる設計なら、代表URLだけを含めます。
含めないURL
404や410、5xx、転送元、noindex、別URLへcanonical指定したページは原則として含めません。カート、ログイン、注文履歴、サイト内検索、任意の並び替えURLなども、検索対象でなければ除外します。
サイトマップに載せながらnoindexを返すと、検索対象にしたいという手掛かりと除外指示が矛盾します。URL生成時点で公開状態とインデックス方針を確認します。
絶対URLで記述する
URLはhttpsから始まる完全な絶対URLで記述します。wwwの有無、末尾スラッシュ、大文字・小文字などを正規URLのルールへそろえます。
XML内の特殊文字は適切にエスケープします。パラメータ付きURLを意図的に含める場合は、ファイルが正しいXMLとして解析できるかを確認します。
ファイル数とサイトマップインデックス
一つのサイトマップにはサイズとURL数の上限があります。商品数が多いECサイトでは複数ファイルに分け、サイトマップインデックスからまとめて参照します。
分割は商品IDの範囲、カテゴリ、言語、公開年など、運用しやすい単位にします。毎回URLが別ファイルへ大きく移動する方式より、障害や変化を追いやすい安定した分割が適しています。
lastmodを正確に管理する
lastmodは、ページの重要な内容が最後に更新された時期を示します。価格、在庫、商品説明、主要画像など、検索結果や利用者に影響する変更と連動させます。
サイトマップを生成した時刻を全URLへ一律に入れると、実際の更新情報として信頼しにくくなります。changefreqやpriorityの値に頼るより、URLとlastmodの正確性を優先します。
販売終了商品の更新
商品を終了したときは、そのページを今後どう扱うかを先に決めます。後継商品へ転送する、情報を残す、404にするなどの状態に合わせ、サイトマップから除外または維持します。
一時的な在庫切れでページを継続するなら、サイトマップから即座に外す必要はありません。商品公開フラグだけで機械的に判断せず、インデックス方針と連動させます。
Search Consoleへ送信する
サイトマップまたはサイトマップインデックスをSearch Consoleへ送信し、取得状況と検出URL数を確認します。robots.txtにSitemapの場所を記載する方法もあります。
送信後は、取得できない、形式が正しくない、URLが別ホストになっているなどのエラーを確認します。検出URL数と実際の公開商品数に大きな差があれば、生成条件を見直します。
サイトマップを監視する
毎日の生成成否、ファイルサイズ、URL数、HTTP応答を監視します。商品データの連携障害で空ファイルになったり、古いURLが残ったりすることがあります。
ページ種別ごとのURL数を前日や前週と比較すると、急な増減を見つけやすくなります。増減が施策や商品入れ替えで説明できるかを担当者が確認します。
よくある間違い
- サイト内で生成される全URLを載せる
- 転送元やnoindexページを残す
- 内部リンクがないページをサイトマップだけで支える
- 全URLのlastmodを毎日更新する
- 生成エラーやURL数の急変を監視しない
確認項目
- 200で表示される正規URLだけか
- URL表記が内部リンクとcanonicalに一致するか
- 商品・カテゴリ・記事を必要に応じて分けたか
- lastmodが実際の更新を反映するか
- 販売終了時の除外ルールがあるか
- Search Consoleで取得状況を確認したか
商品公開システムと連携する
サイトマップは、商品ページを表示するデータと同じ公開状態を参照して生成します。管理画面で「公開」と表示されても、販売開始日時、在庫、カテゴリ承認など別条件でページが見えない場合があります。
生成条件を文書化し、販売中、予約、在庫切れ、終売、非公開、削除の各状態で、ページ応答とサイトマップ掲載がどうなるかをテストします。人が毎回URLを追加・削除する方法は、大量商品では更新漏れにつながります。
サイトマップを分割する実務上の利点
商品とカテゴリを分けるだけでなく、必要に応じてブランド、言語、商品ID帯など安定した単位に分けます。あるファイルだけ取得に失敗した、URL数が急減したといった異常を見つけやすくなります。
ただし、小規模サイトで細かく分けすぎると管理が複雑になります。ページ種別の問題を判断できる最小限の分割にし、サイトマップインデックスから全体を参照します。
画像サイトマップの判断
商品画像がJavaScriptやCDN配信のため発見されにくい場合、画像情報をサイトマップへ含める方法があります。まず商品ページ内の画像が通常のHTMLやレンダリング結果で取得でき、robots.txtで許可されているかを確認します。
画像URLは安定させ、商品更新のたびに意味なく変えないようにします。サイズ違いの同一画像を大量に列挙するのではなく、検索利用者に見せたい主要画像を正確に伝えます。
異常を検知する指標
ファイルごとのURL数、生成時刻、取得ステータス、ファイルサイズ、前回との差分を記録します。URL数がゼロになる、前日比で大幅に増える、古いドメインが混ざる場合は送信前に通知します。
Search Consoleの検出URL数と自社の公開URL数を定期的に照合します。完全一致を求めるのではなく、差が商品状態やファイル分割で説明できるかを確認します。
ECサイトでの生成例
商品サイトマップには、販売中と情報を残す終売商品を含め、404、転送済み、noindexの商品を除外します。カテゴリサイトマップには、商品があり検索対象として整えたカテゴリだけを含めます。
商品を終売へ変更したときは、ページの扱いを決めた後でサイトマップを更新します。後継商品へ301を設定したなら旧URLを除外し、過去情報を200で残すなら掲載を維持できます。
この判断を商品マスタの単純な在庫数だけに任せず、公開状態とSEO上のページ状態を持たせます。サイトマップ生成ログには、除外理由ごとの件数も残すと、設定変更による急増を発見しやすくなります。
まとめ
ECサイトのXMLサイトマップは、検索対象にしたい正規URLを伝える補助手段です。載せるURLを増やすのではなく、200、indexable、canonicalという条件をそろえます。
商品公開や終了に連動して自動更新し、URL数とエラーを監視してください。内部リンク、canonical、サイトマップが同じURLを示すことで、サイト側の意図が明確になります。
