XML サイトマップ：検索エンジンにページを見つけてもらう

XML サイトマップ（Extensible Markup Language のサイトマップ）は、ウェブサイトにどのページがあり、検索エンジンにどれを見つけてほしいかを伝える、構造化されたファイルです。各項目は、機械が即座に解析できるタグで囲まれた URL と、任意のメタデータからなります。クローラーがすべての内部リンクをたどるのに頼るのではなく、サイトマップは、正規ページのすっきりした優先順位付きのリストを渡します。

サイトマップはインデックスを保証するものではありませんが、サイトの構造について送れる最も確かなシグナルの一つです。Google のサイトマップのドキュメントは、大規模なサイト、新しいサイト、外部リンクの少ないサイト、リッチメディアを含むサイトにサイトマップを推奨しています。2026 年は、OpenAI、Anthropic、Perplexity の AI クローラーが Googlebot と同じサーバーのリソースを奪い合っているので、すっきりしたサイトマップはこれまで以上に価値があります。

XML サイトマップに含まれるもの

中核となる要素は URL です。クロールしてほしい各ページは、<url> ブロックの中に置かれ、<loc> タグに完全修飾された絶対アドレス（相対ではなく、https:// から始まる完全なパス）を入れます。ファイルは <urlset> の宣言で始まり、UTF-8 のエンコードを使う必要があります。

URL のほかに、プロトコルは 3 つの任意のタグをサポートしています。<lastmod>、<changefreq>、<priority> です。<lastmod> の値は、ページが最後に意味のある変更を受けた日時を記録します。<changefreq> タグはページの更新頻度を示し、<priority> は相対的な重要度を示唆します。

Google がこれらをどう扱うかを知っておくことが重要です。Google は、値が一貫して検証可能な形で正確であれば <lastmod> を使いますが、<priority> と <changefreq> は完全に無視します。教訓は、優先度のスコアの調整に時間を費やさないことです。適切な URL を選び、<lastmod> を正直に保つことに時間を使いましょう。

サイズの上限とサイトマップのインデックスファイル

1 つのサイトマップのファイルは、50,000 URL か、非圧縮で 50MB の、どちらか先に達するほうが上限です。帯域を節約するために gzip でファイルを圧縮できますが、上限には非圧縮のサイズが数えられます。ほとんどのウェブサイトはこの上限に近づきませんが、大規模な EC サイトやメディアのサイトは超えます。

どちらかの上限を超えたら、URL を複数のサイトマップのファイルに分割し、1 つのサイトマップのインデックスファイルから参照します。インデックスはそれ自体が XML ファイルで、各子サイトマップの場所を一覧にするので、1 つのマスターの URL を送信しながら、何千、何百万のページを論理的に整理できます（たとえば、商品カテゴリーやコンテンツの種類ごとに 1 つのサイトマップ）。

サイトマップをセクションごとに分割すると、診断も簡単になります。Google Search Console のサイトマップのレポートを確認するとき、区別のない巨大な 1 つの一覧を眺める代わりに、どのページのグループに発見やインデックスの問題があるかが正確にわかります。

含める URL

検索結果に実際に表示させたい、正規でインデックス可能なページだけを載せましょう。サイトマップは、CMS が生成できるすべての URL を放り込む場所ではありません。重複したページ、ページ分割されたアーカイブ、パラメーターのバリエーション、サンクスページ、noindex の指示でブロックされたものはすべて除きます。正規でない URL を含めると、矛盾したシグナルを送り、ファイルの有用性が薄まります。

よくある間違いは、サイトマップが公開中のサイトとずれていくのを放置することです。404 を返す、またはリダイレクトする URL が載っていると、クローラーがファイルに寄せる信頼を損ないます。定期的に監査し、すべての項目が、公開されていて、正規で、ステータス 200 のページに解決されるようにしましょう。この規律はクロールバジェットに直結します。引き締まったサイトマップは、クローラーを重要なものに向け、無駄から遠ざけます。

専門的なサイトマップの種類

標準のページのサイトマップのほかに、プロトコルはメディア固有の拡張をサポートしています。画像と動画のサイトマップは、クローラーが見逃しかねないビジュアルのコンテンツを、キャプション、タイトル、再生時間などの詳細とともに浮かび上がらせます。ニュースの発行元は、Google ニュースのサイトマップを使って、時事性のある記事をより早く取り上げてもらうよう示せます。

すべての種類が必要なわけではありません。サイトが画像中心だったり、動画のライブラリを運営していたりするなら、該当する拡張が、それらの資産の発見を助けます。多くのコンテンツのサイトでは、記事、ランディングページ、主要なリソースをカバーする、すっきりした標準のサイトマップがあれば、強力なクロールとインデックスを支えるのに十分です。

サイトマップの送信方法

検索エンジンにサイトマップを知らせる主な方法は 3 つあります。最も直接的なのは Google Search Console で、サイトマップのレポートからファイルの URL を送信し、発見、クロール、インデックスされたページの数が時間とともにどう変わるかを監視できます。Bing も、Bing Webmaster Tools で同じことができます。

2 つ目の方法は、1 行で robots.txt ファイルの中にサイトマップを記載することです：Sitemap: https://example.com/sitemap.xml。robots.txt を読むクローラーなら、どれでもその場所がわかります。3 つ目は、プログラムから送信する Search Console API で、サイトマップを自動で再生成する場合に便利です。

Google は、認証なしの古い ping のエンドポイントを廃止したので、URL に ping を送る従来の方法はもう機能しません。代わりに Search Console か robots.txt で送信しましょう。IndexNow は、次のクロールを待つのではなく、参加しているエンジンに URL の変更を即座に通知することで、サイトマップを補います。

2026 年の XML サイトマップと AI のクローラー

サイトマップは今や、Google だけのものではありません。ChatGPT、Perplexity、Gemini などの AIは、引用するコンテンツを集めて更新するために、独自のクローラー（GPTBot、OAI-SearchBot、PerplexityBot、ClaudeBot）を展開しています。最新で正確なサイトマップは、これらのシステムがページを発見し、AI が生成する回答に表示する助けになります。

2025 年のサーバーログのデータでは、AI クローラーのトラフィックが急増し、前年比で数百パーセント伸びたボットもありました。そのトラフィックは、Googlebot が使うのと同じリソースを奪い合います。クローラーを最良のコンテンツに向ける焦点を絞ったサイトマップと、正確な <lastmod> の日付を組み合わせれば、すべてのエンジンが、限られたクロールの労力を、発見され引用されたいページに使えるようになります。

よくある XML サイトマップの間違い

priority と changefreq に固執するのは典型的な間違いです。Google はどちらも無視するので、労力が無駄になります。そのほかによくある問題には、正規でない URL やリダイレクトされる URL を載せる、404 をファイルに残す、コンテンツが実際に変わったときに <lastmod> を更新し忘れる、インデックスに分割せずに 50,000 URL の上限を超えるといったものがあります。

もう一つの見落としやすい問題は、<lastmod> の日付の偽装です。再生成のたびにすべての URL に今日の日付を付けると、シグナルは意味をなさなくなり、Google はそれを信頼しなくなります。ページのコンテンツが本当に変わったときだけ、日付を更新しましょう。正確さが、このタグを再クロールの優先づけに価値あるものにします。

サイトマップの監視とメンテナンス

サイトマップは、一度設定して終わりではなく、生きたファイルとして扱いましょう。Search Console のサイトマップのレポートを毎月確認して、ファイルが読み込まれていること、発見されたページとインデックスされたページの差、解析エラーを早めにとらえます。送信した URL とインデックスされた URL の差が広がっているなら、多くの場合、サイトマップの不具合ではなく、コンテンツの質や重複コンテンツの問題を示しています。

現代のコンテンツのプラットフォームの多くは、サイトマップを自動で生成して更新するので、公開のたびに最新の状態が保たれます。手作業で管理しているなら、新しいページがすばやく載り、削除したページが消えるよう、公開のワークフローに再生成の手順を組み込みましょう。これを定期的なテクニカル監査と組み合わせて、サイト全体のクロールのシグナルをきれいに保ちます。

XML サイトマップはどう作成しますか？

多くのプラットフォームでは、XML サイトマップを手で書く必要はありません。CMS や SEO プラグインが生成し、公開のたびに更新します。自分で作る必要があるのは、独自開発や静的なサイトの場合だけで、正規 URL を一覧にしてビルドのたびにファイルを生成します。

プラットフォーム	サイトマップの作成方法	一般的なアドレス
WordPress	バージョン 5.5 以降はコアに標準搭載。Yoast SEO や Rank Math を導入すると独自のインデックスに置き換わる	/wp-sitemap.xml または /sitemap_index.xml
Shopify	商品、コレクション、ページ、ブログ記事について自動生成	/sitemap.xml
Webflow	サイトの SEO 設定で自動生成を有効にする	/sitemap.xml
Wix、Squarespace	自動生成	/sitemap.xml
独自開発または静的なサイト	フレームワークの機能やビルドスクリプト、または URL 一覧を書き出すクローラー	任意。通常は /sitemap.xml

独自開発のサイトでは、次の手順で進めます。

1. インデックスさせたい URL を一覧にします。ステータス 200 を返す正規版だけにし、パラメータ付き URL、リダイレクト、noindex のページは除きます。
2. 標準形式でファイルを生成し、ページごとに url 要素を一つ置き、lastmod には実際の更新日を使います。
3. URL が 50,000 件、または非圧縮で 50MB を超える場合は、サイトマップ インデックスで複数ファイルに分割します。
4. ドメインのルートに配置し、ブラウザで開いて読み込めることを確認し、robots.txt に記載します。
5. 生成をデプロイのたびに実行されるようにし、新しいページが手作業なしで追加されるようにします。

どのプラットフォームでも、生成されたファイルは一度開いて確認してください。プラグインがタグのアーカイブ、添付ファイルのページ、テストページなど、除外したいページを含めていることがあります。

まとめ

XML サイトマップは、検索エンジンと AI のクローラーに見つけてほしい正規 URL を一覧にする、シンプルで効果の高いファイルです。インデックスを強制するものではありませんが、特に大規模、新規、または頻繁に更新されるサイトで、発見を速めます。インデックス可能な正規ページだけに限定し、インデックスファイルで 50,000 URL と 50MB の上限を守り、<lastmod> の日付を正直に保ち、Google も無視している priority と changefreq は気にしないようにしましょう。Search Console から送信して robots.txt に記載し、発見とインデックスの差を毎月監視します。2026 年は、すっきりしたサイトマップが、Google から ChatGPT まで、あらゆるエンジンがクロールの労力を最も重要なページに使う助けになります。Sorank の GEO SEO 診断が、サイトマップとクロールの健全性をどう自動で確認するかをご覧ください。