大規模サイトのためのサイトマップ運用法: lastmod、分割、送信方法

TL;DR

サイトマップは、内部リンクが弱いページの発見、大規模サイトのクロール効率向上、複雑な構造によるクローラーの混乱軽減に役立ちます。

XMLサイトマップは50,000 URL/50MBの制限を考慮し、必要に応じてsitemap indexと.gz圧縮を活用する運用が一般的です。

<priority>、<changefreq>は入れられますが、運用では<lastmod>の正確さのほうが重要な場合が多いです。

サイトマップは作成することよりも、運用することのほうが重要です

サイトマップを一度作成して終わりにしてしまうチームは多くあります。
しかし、サイトが大きくなるほど、サイトマップは検索露出の基盤インフラに近い存在になります。 実際、サイトマップは次のような問題を減らすうえで直接的な役割を果たします。

• 内部リンクがほとんどなく、検索システムが見つけにくいページが生じる

• サイト規模が大きくなるにつれて、クロールが非効率に浪費される

• 構造が複雑だったりセクションに一貫性がなかったりして、クローラーが混乱する

サイトマップとは何ですか？

サイトマップは、検索システム（またはユーザー）に対して「当サイトの重要なURLはここにあります」と伝えるための地図です。
形式は通常、以下の3種類が代表的です。

XMLサイトマップ：基本原則から先に押さえる必要があります

1) XMLサイトマップは通常どこにありますか？

ほとんどのサイトは、以下のようにアクセスできます。

• https://yourdomain.com/sitemap.xml

規模が大きくなると、「1つのsitemap.xml」だけでは管理が難しくなり、そのときに登場するのがsitemap indexです。

2) 50,000 URL / 50MB制限、そしてsitemap index

運用段階で最も頻繁に発生する問題は「容量と件数」です。

• サイトマップファイル1つは最大50,000 URLまたは50MB（圧縮前基準）を超えないように推奨されます。

• それ以上大きくなる場合は、sitemap indexファイルで複数のサイトマップをまとめて管理します。

方法は以下のとおりです。

ただし、ファイル名はそれほど重要ではありません。もしSitemapのリアルタイム運用だけが必要であれば、下記のようなツールでレンダリングしても問題ありません。

タグをすべて入れればよくなるという誤解: lastmod中心で整理

XMLサイトマップにはさまざまなタグを入れることができます。しかしたくさん入れることが正解ではありません。

つまり、実際の運用で力を入れるべきなのは、たいてい正確なURL一覧 + 信頼できるlastmodです。 当然、更新が頻繁に発生するウェブサイトであれば、古いプラットフォームではない可能性が高いからです。逆に言えば、lastmodが不正確だと「シグナル品質」が下がります。 そのため、サイトマップを運用する際には、サイトの変更に応じてSitemap.xmlを更新することが非常に重要です。

XMLサイトマップの作成：CMS別/ツール別で最も現実的な方法

サイトマップの作成方法は非常に多様です。自動で作成されることもあり、Next.jsで自動化することもでき、チームのスタックと運用方式に応じて、最も効率的な方法を選ぶ必要があります。

方法 A) WordPress

WordPressでは、代表的にYoast SEOなどのプラグインでXMLサイトマップを有効化します。
運営チームが多く、コンテンツの変更が頻繁であれば、プラグインベースのほうが保守管理に有利です。無料のものが大半のため、おすすめです。

Yoast Sitemap.xmlプラグイン

XML sitemaps in the Yoast SEO plugin Read about XML sitemaps in the Yoast SEO plugin. Find out how to enable XML sitemaps, how to limit the number of entries and more.

YoastJoost de Valk

方法 B) Shopify / Wix / Squarespace

EC/ビルダー系は、概ね「標準搭載」または「プラットフォーム方式」が強いです。

• Shopify: 通常sitemap.xmlが自動生成され、内部的に複数のサイトマップを束ねる構造を持ちます。

• Wix: SEO設定の流れの中でサイトマップの生成/更新が管理されます。

• Squarespace: 基本的にサイトマップが提供され、構造はプラットフォームのポリシーに従います。

以下のように選択されます。

ただし、このサイトマップも各自の目的に合わせてカスタマイズできます。

方法C）クロールベースの生成（例：Screaming Frog）

開発リソースが限られている場合や、レガシーサイト／静的サイトでよく使われる方法です。
サイトをクロールした後、サイトマップを生成して書き出す流れです。 ただし、この方法は「生成」は速い一方で、更新周期／自動デプロイは別途対応が必要です。

サイトマップ送信方法 Google Search Console + robots.txt

1) Google Search Console（GSC）に送信

サイトマップの送信 実務では、「サイトマップのURLを知っていること」と「Googleが読み取っていること」は別です。
通常は Google Search Console でサイトマップを送信し、ステータスを確認します。

2) robots.txt に Sitemap ディレクティブを追加

robots.txt に sitemap.xml を追加 運用の観点では、robots.txt にサイトマップの場所を明記する方法のほうがより安定しています。 例は以下のように1行です。

• Sitemap: https://www.example.com/sitemap.xml

この1行で、クローラーがサイトマップの場所をより簡単に見つけられます。

7つのサイトマップ例から学ぶ「運用パターン」

しかし、サイトマップがなくても問題なく運営されているケースも多く、各Webサイトに合わせた運用が非常に重要です。
そのため、似た業種の企業のサイトマップを見ながら、なぜそのように運用しているのかを確認することが大きな助けになります。

XMLサイトマップの例 3つ

1) Samsung: グローバル/地域単位の分割 + sitemap index

Samsung Sitemap.xml Samsungは地域別に複数のサイトマップを設け、これを sitemap index で連結するパターンを示しています。
国/言語/ドメイン構造が複雑なエンタープライズでよく使われる方法です。

2) Best Buy: 複数の.gz圧縮サイトマップ

BestBuy Sitemap.xml

Airbnb サイトマップ（robots.txt） Best BuyやAirbnbのように、sitemap index の下に複数の圧縮済み（.gz）サイトマップを置く形です。
カタログが膨大であれば、ファイル単位で分割し、圧縮することでクロール効率を確保する運用が有利です。

サイトマップを運用する際に確認が必要な基準

以下は、運用で繰り返されがちなミスを防ぐためのチェックリストです。

サイトマップは検索インフラです

サイトマップは一度作って終わりの文書ではありません。
サイト構造とコンテンツが変われば、サイトマップもそれに合わせて変える必要があります。特にページ数が増え始める段階からは、なおさらです。 Search OSを使うチームは、ここで運用負荷を減らします。
サイトマップを含め、「検索露出を妨げる構造・生成・更新の問題」を人手で継続的に修正しないよう、繰り返し作業をシステムに任せる方向に近い考え方です。最終確認だけを残し、あとは自動で回るようにする方式です。Search OSを導入したときに、最初に効果が出やすい領域も、通常はこうした「基本インフラ」です。

Search OSでサイトマップ運用を自動化する

サイトマップを自分で設計し、分割基準を決め、変更のたびに再生成・再送信する作業は、想像以上に多くの運用リソースを必要とします。特に多言語ページ、地域・カテゴリベースのURL、頻繁な更新が発生するサイトほど、管理の難易度は急速に高まります。

サイトマップ最適化履歴 Search OSは、このような負担を軽減するためのSEO/AI検索自動最適化ソリューションです。その中でサイトマップやrobots.txtなども当然自動で提供します。 URL生成から重要度の判定、変更履歴の追跡、検索エンジンへの送信、robots.txt管理まで
検索エンジンが読み取る構造を基準に、全工程を自動で管理します。すでにグローバル大企業からスタートアップでも運用中です。 単なるサイトマップ、Robots.txtだけでなく、Search OSがCore Web Vitalのクロール速度を最大300倍速くし、数百万ページのキーワードを変更しながら自動でページを生成して、AI検索とSEOに自動で最適化してください。 導入前にSearch OSの無料分析と、より詳しい内容をご希望でしたら、いつでもお問い合わせください。