XMLサイトマップの作り方と運用 ── 仕様・生成ツールの選び方・送信方法、明日から確認する14項目

目次

1. 01 いま分かっていること — サイトマップは「作って送信して終わり」ではなくなった
   1. プロトコル自体は10年以上前から変わっていない
   2. Googleが実際に使うタグ・無視するタグ
   3. 2023年、送信方法の一つが静かに終わっていた
2. 02 なぜサイトマップが必要なのか — ランキング因子ではないという前提
   1. サイトマップの本来の役割は「発見の補助」
   2. 効果が大きいのはどんなサイトか
   3. クロールの発見経路のひとつでしかない
   4. 大規模サイトでは「クロールバジェット」とも関わる
3. 03 この記事で出てくる用語
   1. robots.txtのSitemapディレクティブ
4. 04 サイトマップの作り方 — 適用範囲・測れないこと・手順
   1. 🅰 適用範囲 — どんなサイトに、どの種類のサイトマップが要るか
   2. 🅱 サイトマップが測っていないこと・保証しないこと
   3. 🅲 作成手順 — 4つの方法
   4. 動的サイトでの実装パターン
   5. 配置場所が、含められるURLの範囲を決める
   6. 送信方法は2系統
5. 05 自分のサイトで確認するチェックリスト
   1. 3つの観点で構成しています
   2. 14項目の内訳と、かかる時間の目安
6. 06 作成手段の選択肢を比較する
   1. それぞれ確認できることと、できないこと
   2. WordPressの自動生成プラグインは、複数の選択肢がある
   3. 検証ツールが確認していること・していないこと
   4. 自作スクリプトを選ぶ場合の判断基準
   5. 送信手段ごとに確認できることが違う
7. 07 当サイトの実測
   1. 実際のsitemap.xmlを開いて数えた
   2. content-typeとgzip圧縮の状態
   3. changefreq・priorityは記載しているが、扱いは仕様どおり
   4. IndexNowは2つのエンドポイントへ送信している
   5. URLが変わらない差し替えでは、lastmodが動かないことがあった
8. 08 このテーマの、これまで
   1. sitemapとcanonicalの不一致を記録した回
   2. 4層整合性をcurl 3行で確認する手順を書いた回
   3. lastmodが動いていなかったことを見つけた回
9. 09 この記事のまとめ

01 いま分かっていること — サイトマップは「作って送信して終わり」ではなくなった

プロトコル自体は10年以上前から変わっていない

XMLサイトマップの仕様は、sitemaps.org protocolとして公開されている業界共通の規格です。<urlset>タグの中に<url>要素を並べ、それぞれに<loc>(URL)・<lastmod>(最終更新日)・<changefreq>(更新頻度の目安)・<priority>(優先度の目安)を記述する、というごくシンプルな構造です。この骨格自体はここ十年以上ほぼ変わっていません。

Googleが実際に使うタグ・無視するタグ

変わったのは、Googleがそれぞれのタグをどう扱うかという運用面です。公式ドキュメントは明確に、Googleは<priority>と<changefreq>の値を無視すると述べています。一方で<lastmod>は活用の対象ですが、「一貫して、かつ検証可能な形で正確である場合」という条件付きです。コンテンツ・構造化データ・リンクなど、意味のある更新があったときに限って値を更新すべきだとされています。「毎日全ページのlastmodを今日の日付にする」ような運用は、この条件を満たさず、かえって信頼を下げます。

2023年、送信方法の一つが静かに終わっていた

この一件が示しているのは、「サイトマップを作ってどこかに送信すれば仕事は終わる」という古い理解が、そのままでは通用しなくなっているということです。プロトコル自体は変わっていなくても、送信の窓口とタグの解釈は静かに変わっています。ネット上には10年近く前に書かれたサイトマップ解説記事が今も上位表示されており、廃止されたping送信を「今すぐやるべきこと」として紹介しているケースが少なくありません。

02 なぜサイトマップが必要なのか — ランキング因子ではないという前提

サイトマップの本来の役割は「発見の補助」

まず前提として押さえておくべきなのは、サイトマップはランキングを直接押し上げる仕組みではないということです。Googleが公開している一連のドキュメントでも、サイトマップの位置づけは一貫して「クローラーがページを発見しやすくするための補助情報」です。すでに内部リンクが充実していて、すべてのページが数クリック以内に辿り着けるような小規模サイトであれば、サイトマップが無くても大きな問題にはなりにくいとされています。

効果が大きいのはどんなサイトか

逆にサイトマップの効果が大きいとされるのは、次のようなケースです。ページ数が非常に多く内部リンクだけでは辿り着きにくい大規模サイト、公開されたばかりで外部からの被リンクがまだ少ない新しいサイト、動的に生成されるコンテンツが多くクローラーが通常のクロールだけでは発見しにくいサイト、あるいはリッチメディア(画像・動画)を多用していてテキストリンクだけでは把握しづらいページを持つサイトです。自分のサイトがこのどれに当てはまるかを最初に見極めることが、労力の配分を考えるうえで重要になります。

クロールの発見経路のひとつでしかない

サイトマップは、クローラーがURLを発見する経路のひとつにすぎません。内部リンク・外部からの被リンク・過去のクロール履歴・Search Console経由のURL検査など、他の経路と並ぶ選択肢のひとつという位置づけです。したがって「サイトマップに載せたのにクロールされない」という状態は起こり得ますし、それ自体が異常というわけではありません。この点は04章で改めて扱います。

大規模サイトでは「クロールバジェット」とも関わる

ページ数が非常に多いサイトでは、サイトマップの整備状況がクロールバジェット(Googleがそのサイトに割く総クロール量)の使われ方にも影響します。公式ドキュメントは、大規模サイト向けのクロールバジェット管理ガイドを別途用意しており、その対象はページ数が100万件以上で週次更新があるサイト、あるいは1万件以上で日次更新があるサイトとされています。この基準に該当しない中小規模のサイトにとって、クロールバジェットそのものがボトルネックになることはまれで、多くの場合は本記事で扱うサイトマップの基本的な整備状況のほうが先に効いてきます。

03 この記事で出てくる用語

本文で繰り返し使う用語を、先に整理しておきます。

robots.txtのSitemapディレクティブ

robots.txtファイルの中にSitemap: https://example.com/sitemap.xmlという1行を書くことで、クローラーにサイトマップの場所を知らせることができます。このディレクティブはUser-agentの指定とは独立していて、robots.txtファイル内のどこに書いても機能し、複数のサイトマップを記載することも可能です。公式ドキュメントもこの方法を、Search Console経由の送信と並ぶ主要な送信手段として案内しています。

04 サイトマップの作り方 — 適用範囲・測れないこと・手順

🅰 適用範囲 — どんなサイトに、どの種類のサイトマップが要るか

サイトマップにはXML形式が最も多機能ですが、それ以外にRSS 2.0・mRSS(メディアRSS)・Atom 1.0、そしてURLを1行ずつ並べただけのテキストサイトマップにも対応しています。用途別に見ると、通常のWebページ向けの標準サイトマップに加えて、画像を多く扱うサイト向けの画像サイトマップ、動画コンテンツ向けの動画サイトマップ、ニュース性の高いコンテンツを公開する媒体向けのニュースサイトマップという専用の拡張枠が用意されています。一般的なコーポレートサイトやオウンドメディアであれば、標準のXMLサイトマップ1本で足りるケースがほとんどです。

🅱 サイトマップが測っていないこと・保証しないこと

🅲 作成手順 — 4つの方法

作成方法は大きく4つに分かれます。1つめは手作業でXMLを書く方法です。ページ数が数十件程度の小規模サイトであれば、テキストエディタで直接記述しても現実的です。2つめはCMSのプラグイン・拡張機能による自動生成で、記事の追加・更新に合わせてサイトマップも自動更新される仕組みが一般的です。3つめは静的サイトジェネレーターの組み込み機能で、ビルド時にページ一覧からサイトマップを生成するプラグインが多くのフレームワークに用意されています。4つめは自作スクリプトによる定期生成で、DBやファイル一覧からURLを取得してXMLを組み立て、cronなどで定期実行する方法です。ページ数が多く更新頻度も高い動的サイトでは、この方法が最も柔軟に運用できます。

動的サイトでの実装パターン

DBを持つ動的サイトで自作スクリプトを選ぶ場合、典型的な実装は次のような流れになります。まず、公開フラグが立っているレコードだけを対象に抽出し、それぞれのURLと更新日時カラムの値からlastmodを組み立てます。次に、抽出件数が上限に近い場合はサイトマップインデックス形式に分割するかどうかを判定し、XMLとして書き出します。最後に、書き出したファイルを本番の公開ディレクトリへ配置し、必要であればSearch Console・IndexNowへの通知まで一連の処理として実行します。この一連の流れをURLが増減するたびに手動で行うのではなく、定期実行に任せることが、動的サイトでサイトマップを陳腐化させない基本形です。

配置場所が、含められるURLの範囲を決める

sitemaps.org protocolには、意外と見落とされがちなルールがあります。サイトマップファイルは自分が置かれた場所より下の階層のURLしか含められないという制約です。たとえばhttps://example.com/catalog/sitemap.xmlという場所に置いたサイトマップには、https://example.com/catalog/配下のURLは含められますが、https://example.com/images/配下のURLは含められません。複数の製品ディレクトリを持つサイトでサイトマップを分割配置する場合、この規則を知らずに作業すると、意図した範囲のURLが受理されない原因になります。全ページ分をまとめて扱いたい場合は、ドメインのルート直下にサイトマップを置くのが最もシンプルです。

送信方法は2系統

作成後の送信は、1章で触れたとおりping送信が廃止されているため、実質的に2つの方法に絞られます。Search Consoleの「サイトマップ」レポートから直接URLを登録する方法と、robots.txtにSitemapディレクティブを1行追加する方法です。両方を併用しても問題はなく、むしろSearch Console上でエラーの有無を確認しながら、robots.txt経由でも常時発見可能な状態にしておくのが実務上は安全です。

05 自分のサイトで確認するチェックリスト

3つの観点で構成しています

ここまでの内容を、公開済みのサイトマップに対して今日から確認できる動作に翻訳しました。観点は、仕様上の上限を超えていないかの確認・実際に使われているタグの内容確認・送信と反映状況の確認の3つです。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• sitemap.xmlを開き、含まれるURLの件数を数える
• ファイルサイズが50MB(非圧縮)を超えていないか、含まれるURL件数が50,000件を超えていないか確認する
• 超えている場合、サイトマップインデックスファイルに分割されているか確認する
• サイトマップインデックスを使っている場合、そこに含まれるサイトマップの数が50,000件を超えていないか確認する
• lastmodタグが付与されているURLの割合を、全体件数に対して算出する
• 直近で更新した3ページを選び、その3ページのlastmodが実際の更新日と一致しているか確認する
• changefreqとpriorityが記載されている場合、それらがGoogleに無視される値であることを社内で共有できているか確認する
• サイトマップに含まれるURLのうち、noindexが指定されているものが混じっていないか3件サンプルで確認する
• サイトマップに含まれるURLのうち、404や301を返すものが混じっていないか3件サンプルで確認する
• robots.txtを開き、Sitemapディレクティブが正しいURLで記載されているか確認する
• Search Consoleの「サイトマップ」レポートを開き、ステータスが「成功しました」になっているか確認する
• 同レポートのエラー・警告の件数を控える
• content-typeヘッダーがXMLとして正しく返っているか、ブラウザの開発者ツールで確認する
• ファイルをgzip圧縮している場合、圧縮後のファイルも50MBの上限内に収まっているか確認する

14項目の内訳と、かかる時間の目安

最初の4項目は仕様上の上限に関する確認、5番目から7番目はタグの内容確認、8番目・9番目はサイトマップに含めるべきでないURLの混入確認、10番目から14番目は送信と技術的な反映状況の確認です。特に6番目のlastmod検証は、「毎回機械的に今日の日付にしている」だけの運用になっていないかを自分の目で確かめる項目で、01章で触れた「一貫して正確」という条件に直接対応しています。すべてを一度に終える必要はなく、まずは上位4項目から着手することを想定しています。14項目すべてに目を通すのにかかる時間の目安は、1サイトあたり20分程度です。

06 作成手段の選択肢を比較する

それぞれ確認できることと、できないこと

サイトマップの作成手段は1つではありません。それぞれ得意な領域と、任せきりにできない領域があります。以下は、04章で挙げた4つの作成方法に加え、既存のサイトマップを検証する専用ツールを含めた比較です。

手段	向いているサイト規模	更新の自動化
手作業でXML編集	数十ページ程度の小規模サイト	されない(手動更新が前提)
CMSプラグイン 自動生成	記事更新が多いブログ・オウンドメディア	される(記事の公開に連動)
静的サイト ジェネレーター組込	ビルド工程を持つコーポレートサイト	される(ビルド時に再生成)
自作スクリプト + cron定期実行	DB駆動の大規模・動的サイト	される(定期実行の設計次第)
オンライン 検証ツール	規模を問わず、既存サイトマップの点検用	対象外(生成ではなく検証専用)

WordPressの自動生成プラグインは、複数の選択肢がある

CMSプラグインによる自動生成は、WordPressを例にすると複数の選択肢が併存している状態です。総合SEOプラグインであるYoast SEO・RankMath・All in One SEO(AIOSEO)は、いずれもSEO機能の一部としてXMLサイトマップの自動生成を内蔵しており、投稿の公開・更新に合わせて自動的にサイトマップを更新します。単機能のサイトマップ専用プラグインを別途 導入する方法もありますが、既に総合SEOプラグインを導入済みであれば、その内蔵機能を使うほうが管理する設定箇所が1つで済みます。どのプラグインを選ぶかより、「今使っているSEOプラグインに、この機能が既に含まれていないか」を先に確認するほうが、実務上は近道になることが多いです。

検証ツールが確認していること・していないこと

「sitemap.xml editor」のようなオンラインの検証・編集ツールは、多くの場合、XMLとしての構文が正しいか、sitemaps.orgのスキーマに沿った要素構成になっているか、URLの記述に誤りがないかといった静的な構文チェックを行います。一方で、それらのツールは「このURLが実際に200を返すか」「noindexが指定されていないか」といった動的な状態までは検証しないものがほとんどです。構文が正しいことと、内容が正しいことは別の話だと理解しておく必要があります。

自作スクリプトを選ぶ場合の判断基準

ページ数が多く、かつ公開・非公開の切り替えや更新日時をDBで管理している場合は、自作スクリプトによる定期生成が最も実態に即した運用になります。CMSプラグインは手軽ですが、DBの構造がプラグインの想定と異なる場合や、独自の公開フラグを持っている場合には、そのままでは対応しきれないことがあります。どの手段を選ぶかは、ツールの多機能さではなく、「今、何を根拠にURLの公開・更新日時を管理しているか」から逆算して決めるのが実務的です。

送信手段ごとに確認できることが違う

作成手段だけでなく、送信手段にも役割の違いがあります。以下は、02章で挙げたSearch Console・robots.txt記載・IndexNowの3手段を、確認できることと即時性の観点で整理した表です。

手段	確認できること	反映の速さ
Search Console サイトマップレポート	取得ステータス・エラー件数・発見済みURL数の推移	定期的な再取得任せ
robots.txt Sitemapディレクティブ	クローラーが巡回時に自動発見できるかどうか	次回巡回時
IndexNow	送信リクエストに対するHTTPステータスの成否のみ	即時通知(反映自体は保証されない)

3つの手段は、いずれも「送ったから必ずクロールされる」ことを保証するものではありません。Search Consoleは取得状況を後から確認できる点が強みで、robots.txt記載は常時発見可能な状態を維持する役割、IndexNowは更新の即時性を伝える役割と、それぞれ性質が異なります。3つを併用しても矛盾は生じないため、実務上はすべて設定しておくのが安全です。

07 当サイトの実測

実際のsitemap.xmlを開いて数えた

本記事の公開時点で、当サイトのsitemap.xmlを実際に開いて数えると、掲載URL数は188件、ファイルサイズは非圧縮で34,417バイトでした。上限とされる50,000件・50MBに対しては、まだ大きく余裕がある状態です。lastmodタグが付与されているURLは188件中184件で、残り4件は/tool/・/ai_ron/・/blog/・/seo_article/という、個別記事ではなく一覧・入口となる固定ページでした。この4件については、内部の個別記事が更新されても入口ページ自体のlastmodが動くわけではないため、意図した設計かどうかを別途 確認する対象になります。

content-typeとgzip圧縮の状態

レスポンスヘッダーを実際に確認すると、Content-Type: application/xmlが正しく返っており、03章で触れたgzip圧縮は現時点では使用していません。34,417バイトという現在のファイルサイズであれば、圧縮しなくても転送コスト上の問題は生じにくい規模です。robots.txtにはSitemap: https://website.usersupports.com/sitemap.xmlという1行が記載されており、Search Console経由の送信と併用しています。

サイトマップに載せたURLがSearch Consoleで未登録のままになっているときは、当サイトの🔧 未登録URLのリンク元とHTTPステータスを調べるツールで、一覧（表.csv）の各URLのHTTPステータスと、サイト内のリンク元をまとめて調べられます。

changefreq・priorityは記載しているが、扱いは仕様どおり

当サイトのsitemap.xmlには<changefreq>と<priority>も記載しています。ただし01章で確認したとおり、これらはGoogleに無視される値です。記載していること自体が問題になるわけではありませんが、これらの値を「調整すればクロール頻度が変わる」と期待するのは誤りだという前提で運用しています。

IndexNowは2つのエンドポイントへ送信している

更新したURLについては、IndexNowの仕様に沿ってapi.indexnow.orgとwww.bing.comの2つのエンドポイントへ通知を送っています。IndexNowは1回のPOST送信で最大10,000件のURLをまとめて送れる仕様になっているため、複数URLを一度にまとめて通知する運用が可能です。

URLが変わらない差し替えでは、lastmodが動かないことがあった

08 このテーマの、これまで

sitemapとcanonicalの不一致を記録した回

以前、sitemapとcanonicalが一致していないと、Googleが「リダイレクトするURL」と誤って判定しインデックスから外してしまうケースを、当サイトの13URL検証結果とともに記録したことがあります(archives/38)。sitemapに載せる値と、ページ自身が名乗るcanonicalの値がずれていると、いくら正しいURLをsitemapに書いても信頼されない、という内容です。

4層整合性をcurl 3行で確認する手順を書いた回

sitemap・canonical・内部リンク・HTTP応答という4つの層が、同じURL文字列で揃っているかどうかを、curlコマンド3行で確認する手順を記録した回もあります(archives/39)。本記事の06章・07章で扱った「静的な構文チェックでは分からないこと」を、実際にHTTPリクエストを飛ばして確かめるという方向性で、本記事とはアプローチが逆から補い合う内容です。

lastmodが動いていなかったことを見つけた回

当サイト自身のsitemapで、lastmodの値が更新した日から動いていなかったことを見つけて記録した回もあります(archives/128)。「出力は在るのに、値だけが古いまま」という見落としを扱った回で、本記事の07章で紹介した実測の教訓は、この回で見つけた問題意識をそのまま引き継いだものです。