XML Sitemap 最適化：URL の優先度、更新頻度、送信の進め方
1. Sitemap は何を解決するのか
Sitemap には誤解がつきものです。送信すれば順位が上がる、ページがインデックスされると思われがちです。実際の Sitemap はただの「ページ一覧」で、「こういうページがあります、見に来てください」と Google に伝えるだけのものです。Google が見たあとクロールするか、クロールしたあとインデックスするか、インデックスしたあと何位になるかは、Sitemap では一切決まりません。
Sitemap が本当に役立つ場面は 3 つです。1 つ目は、新規サイトや新規ページを Google が内部リンク経由でまだ見つけていないとき。Sitemap があれば早く見つけてもらえます。2 つ目は、深い階層のページが多く（クリック 4 回以上）、Google のクロール頻度が低いサイト。Sitemap が発見までの経路を短くします。3 つ目は、動画や画像、ニュースなど特殊なコンテンツタイプで、Sitemap に追加のメタデータを書けます。500 ページ以内で内部リンク構造が整ったサイトなら、Sitemap の効果はごくわずかです。
| Sitemap の誤解 | 実際の状況 | 判断基準 |
|---|---|---|
| Sitemap を送信すれば順位が上がる | 順位アルゴリズムには影響せず、発見速度だけに影響する | Google 公式の Sitemap ドキュメント |
| priority が高いほど上位に表示される | Google はこのタグの重みはごく低いと明言している | Google Webmaster Central ブログ |
| changefreq=always なら Google が毎日クロールする | Google はこのタグでクロール頻度を決めていない | 同上 |
| すべてのページを Sitemap に入れるべき | 価値のあるページだけを入れ、薄いページは逆効果 | Google の品質評価ガイドライン |
| Sitemap は送信したら放置でよい | GSC レポートを毎週確認する必要がある | 実際の運用経験 |
他の SEO モジュールとの関係：Sitemap はGoogle SEO技術基盤の 1 層で、robots.txt の設定と組み合わせて使います。robots.txt に Sitemap の場所を書き、Sitemap に重要ページを並べます。サイト内リンク構造補完関係です。内部リンクは検出済みページの評価を伝え、Sitemap は新しいページの検出を担います。
2. Sitemap に載せるもの、載せないもの
すべての URL を Sitemap に入れるべきではありません。Sitemap は「このサイトでインデックスする価値のあるページ」を Google に示すものです。載せるべきでないページを入れると、薄いページも重要だと伝えることになります。
| ページの種類 | Sitemap に載せるか | 原因 |
|---|---|---|
| 製品詳細ページ | 載せる | 主要なコンバージョンページ。素早く検出させる必要がある |
| カテゴリページ・部門ページ | 載せる | テーマの入口ページ。リンク評価が高い |
| ブログ記事ページ | 載せる | コンテンツページ。ロングテールキーワードの順位が依存 |
| 会社概要・お問い合わせ | 載せる | 信頼ページ。数が少なく、入れてもコストはかからない |
| タグ集約ページ | 置かない | 内容が薄く、カテゴリページと重複 |
| 絞り込み結果ページ | 置かない | URL にパラメータが付き、内容が重複。クロールを無駄にする |
| サイト内検索結果ページ | 置かない | 実質的な内容がなく、Google が入れないよう明言 |
| ページネーション付きリストの2ページ目以降 | 置かない | rel=next/prev で Google に検出させる |
事例1：B2B の EC サイトで、商品一覧ページに30の絞り込み軸（素材、サイズ、業界など）があり、組み合わせごとに URL が生成されていた。運用チームが絞り込みページをすべて Sitemap に入れた結果、総数は500から5000に増加。その結果、Google はほぼ重複したページのクロールに大量の予算を使い、本当の商品詳細ページのクロール頻度が下がり、全体のインデックス率はむしろ悪化した。修正方法：パラメータ付きの絞り込み URL をすべて Sitemap から削除し、メインカテゴリページと商品詳細ページだけを残す。
Sitemap のサイズ制限：1つの Sitemap ファイルに最大50000 URL、ファイルサイズは50MB（非圧縮）まで。これを超える場合は複数の Sitemap ファイルに分割し、Sitemap Index ファイルでまとめます。ほとんどの中小サイト（500ページ以内）は1つの Sitemap で足り、分割は不要です。
3. priority、changefreq、lastmod：役立つものと役立たないもの
Sitemap XML 形式には4つのタグがあります：loc（URL アドレス）、lastmod（最終更新日）、changefreq（更新頻度）、priority（優先度）。このうち Google が真剣に読むのは前の2つだけで、後の2つはほぼ無視されます。
| ラベル | 役割 | Google は真剣に読むか | 推奨する書き方 |
|---|---|---|---|
| loc | ページの URL アドレス | はい、必須 | https を含む絶対 URL |
| lastmod | ページの最終更新日 | はい、再クロール頻度の判断に使用 | 実際の更新日を YYYY-MM-DD 形式で記入 |
| changefreq | 予想される更新頻度 | ほぼ読まれない | 省略可。書いても意味がない |
| priority | 相対的な優先度 0.0-1.0 | ほぼ読まれない | 省略可。トップページを1.0、他を0.8でもよい |
直感に反する判断：多くの解説では、Sitemap のホームページに priority=1.0、カテゴリページに 0.8、記事ページに 0.5 と書き、そうすれば Google がその優先度どおりにクロールを配分すると説明されています。しかし実際には、Google は 2008 年の時点で priority タグの重みは極めて低いと述べており、2015 年にはほぼ無視するとさらに明確にしています。1.0 と書いても 0.1 と書いても、クロールや順位にまったく影響しません。Google の再クロール頻度に本当に影響するのは lastmod タグと、ページが実際に更新された履歴です。
lastmod の正しい書き方：そのページで最後に実際に内容を変更した日付を入れます。すべて今日の日付にするのはやめましょう。そうすると Google が次にクロールしたとき内容がまったく変わっていないと分かり、あなたの Sitemap への信頼が下がります。ある商品ページが半年間動いていなければ、lastmod には半年前の日付を入れます。ブログ記事は公開後に変更していなければ、lastmod には公開日を入れます。記事をリニューアルして内容を更新したら、lastmod を更新日に変えます。
シナリオ例 2：あるコンテンツサイトが WordPress の Yoast プラグインで Sitemap を自動生成しています。プラグインは初期設定で、すべてのページの lastmod をその日の日付にしています。Google が毎週 1 回クロールに来て、これらのページの内容がまったく変わっていないと分かり、4 回連続したあと、このサイトの Sitemap の信頼度が下がり、再クロール間隔が 7 日から 30 日に延びました。修正方法：プラグインの設定を変更し、lastmod に現在の日付ではなく WordPress の post_modified フィールド（記事の最終更新日）を使うようにします。
四、送信の進め方と検証フロー
Sitemap は生成したらサーバーに置いて終わりではありません。自分から Google に送信し、継続的に監視する必要があります。
| ステップ | アクション | ツール / 場所 | 頻度 | 合格基準 |
|---|---|---|---|---|
| 1. Sitemap を生成 | 自動生成（プラグイン / スクリプト） | /sitemap.xml のパス | 新しいコンテンツを公開するたびに自動更新 | 200 を返し、XML 形式が正しい |
| 2. robots.txt で宣言 | robots.txt の末尾に Sitemap: ディレクティブを追加 | /robots.txt | Sitemap のパスが変わらなければ 1 回だけ | Google が robots.txt から見つけられる |
| 3. Search Console で送信 | GSC で Sitemap URL を手動送信 | GSC → インデックス → Sitemap | 初回送信時、分割したあとの再送信時 | ステータスが「成功」と表示される |
| 4. 検出数を確認 | 検出した URL 数と送信した URL 数を比較 | GSCのSitemapレポート | 週に一度 | 差が 5% 以内なら正常 |
| 5. エラーを確認 | 「読み取れません」「URL が許可されていません」のエラーがないか見る | GSCのSitemapレポート | 週に一度 | エラー数が 0 |
| 6. 新規ページを手動で加速 | 重要な新規ページは URL 検査ツールで手動インデックス登録をリクエスト | GSC の URL 検査ツール | 重要な新規ページを公開するたび | 1 〜 3 日以内にインデックスされる |
Sitemap が正しいか確認する方法：ブラウザで https://あなたのドメイン/sitemap.xml に直接アクセスし、XML 形式のページ一覧が表示されるか見ます。404 が返る場合はパスが間違っているか、サーバー設定に問題があります。HTML ページ（WordPress テーマの 404 ページなど）が返る場合は、Sitemap が正しく生成されていません。Screaming Frog やオンラインの XML Sitemap 検証ツールでフォーマットエラーをチェックしましょう。
とテクニカル SEO 監査チェックリストとの関係：Sitemap は監査チェックリストのクロール象限の 2 番目の項目です。リニューアル、ドメイン変更、大規模なコンテンツ公開のたびに、Sitemap が更新されているか、GSC で再送信が必要かを確認します。サイトリニューアルとドメイン変更時は Sitemap を再生成して送信し、旧 Sitemap 内の URL はすべて新アドレスへ 301 リダイレクトします。
FAQ よくある質問
Sitemap を送信してから Google がクロールするまでどのくらいかかりますか？
priority と changefreq タグは本当に効果があるのですか？
Sitemap にはいくつの URL を入れるべきですか？すべてのページを入れるのですか？
Sitemap Index ファイルはいつ必要ですか？
GSC の Sitemap レポートで「検出された URL 数」が「送信された URL 数」よりはるかに少ない場合はどうすればよいですか？
新しいページを公開したあと、Sitemap を待つ以外にインデックスを早める方法はありますか？
最後に
XML Sitemap はテクニカル SEO で最も過大評価されやすいツールです。順位を上げることも、評価を渡すことも、インデックス率を決めることもありません。唯一の役割は Google にページを早く見つけてもらうことです。内部リンク構造がしっかりしていて500ページ以内の中小サイトなら、Sitemap の限界利益は実はかなり低い。ただしコストはゼロなので、やっても損はなく、やらなくても死にはしません。
実行は3ステップ。今週は Sitemap にアクセスできるか確認します（ブラウザで /sitemap.xml を開いて 200 が返るか）。Screaming Frog で、入れるべきでない薄いページが含まれていないかチェックします。来週は robots.txt の末尾に Sitemap の場所を宣言し、GSC で手動送信します。その後は毎週5分だけ GSC の Sitemap レポートを見て、検出数と送信数の差が正常でエラーがゼロであることを確認します。
覚えておきたい一言。Sitemap は Google に見せる連絡帳であり、順位を上げる加点要素ではありません。正しいページを載せ、lastmod を正しく書き、毎週レポートを確認する。この3つで十分で、priority タグに時間を費やす必要はありません。