サイトマップXML作成で失敗しない実装運用と公開後監視の判断基準

検索流入が伸びない時期に `sitemap.xml` を再送信し続ける現場は少なくありません。ただ、そこで手が止まるなら優先順位を誤っています。実務で本当に多い失敗は、サイトマップを置いていないことではなく、載せるべきではない URL を混ぜたまま自動生成だけを回していることです。

Google も サイトマップの概要 で、サイトマップは URL の発見を助ける手段だと案内する一方、適切な内部リンクがあれば多くのページは見つけられると説明しています。つまり、サイトマップは万能ではありません。内部リンク、正規 URL、クロール制御、ページ品質が崩れたままでは、XML を整えても安定しません。

結論を先に示します。サイトマップ XML で失敗したくないなら、最初に掲載条件を文章で固定し、次に監視単位で分割し、その後に Search Console とログの確認順を決めるべきです。逆に、自動生成から着手して判断基準を後回しにすると、後から調査コストが必ず膨らみます。

掲載URLは正規URLだけに絞り込む理由

サイトマップは「存在する URL の一覧」ではなく、検索結果に出したい代表 URL の一覧として扱う必要があります。Google のサイトマップの作成と送信 でも、検索結果に表示させたい URL を含めるよう案内されていますし、重複した URL の正規化 では canonical を評価の中心に据える考え方が示されています。ここを曖昧にしたまま全 URL を吐き出すと、`canonical`、`noindex`、リダイレクト、パラメータ URL が混在し、その後の確認が一気に難しくなります。

中小規模の事業サイトでも、掲載対象を 2,000 URL から 1,400 URL に絞っただけで、2 週間から 6 週間の間に「重複」系の除外理由が落ち着くことは珍しくありません。反対に、誤って載せた URL が 100 件を超えると、担当者は毎週同じ理由を追い続けることになります。誤掲載率が 5% を超えた時点では、送信回数を増やすより、掲載ルールをいったん止めて見直すほうが妥当です。

先に固定したい掲載条件を六つに絞る

実務では、掲載条件を増やしすぎるより、誰が見ても同じ判定になる六つ前後に絞るほうが運用しやすくなります。最低限、次の条件を満たした URL だけをサイトマップに載せるべきです。

• `200` を返す最終到達 URL である
• `rel="canonical"` がその URL 自身、またはその URL を正規 URL として指している
• `noindex` が入っていない
• `robots.txt` や認証設定で Googlebot の取得を妨げていない
• サイト内リンクから到達できる
• 検索流入を受けるだけの本文量と固有価値がある

この条件に当てはまらない URL は、CMS で公開状態でも外すべきです。特に、`?page=` `?sort=` `?utm=` のような派生 URL、在庫切れ後に空テンプレートだけ残るページ、リダイレクト元の旧 URL は混ぜるべきではありません。「公開中だから載せる」ではなく、「評価対象だから載せる」に切り替えることが重要です。

載せるURLと外すURLを同じ表で管理する

掲載判断を担当者の勘に任せると、数か月後には必ずぶれます。最初から比較表にしておけば、CMS の追加改修や新テンプレートの投入時にも迷いません。

内部リンクが弱い状態でサイトマップだけ整えても効きにくいのは、このためです。回遊導線の整理が追いついていないなら、内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 と アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 を先に見直したほうが立て直しは早まります。

`lastmod`は信頼を守る条件だけで動かす

`lastmod` を毎晩全件更新する実装は、熱心に見えて実際には逆効果です。Google のサイトマップ作成ガイド はサイトマップを更新情報の伝達手段として認めていますが、本文が変わっていないのに 5,000 URL、10,000 URL の日時だけ毎日動けば、鮮度情報への信頼は下がります。

`lastmod` を動かす条件は、次の三つに限定するのが妥当です。

• 見出しや本文が変わった
• 主要画像、FAQ、料金、仕様など検索評価に影響しやすい要素が変わった
• 正規 URL、`canonical`、構造化データなど、評価判断に関わる設定が変わった

レイアウトの余白調整、追跡タグの変更、軽微な CSS 修正で `lastmod` を更新する必要はありません。更新条件を文書化しておかないと、担当者ごとに基準がずれ、サイトマップ全体の信用を自分で削ることになります。

分割方法は件数より監視単位を優先して決める

Google の仕様 では、1 ファイルあたり `50MB` または `50,000 URL` が上限です。ただし、ここだけ見て「5 万件までは 1 枚でよい」と判断するのは早計です。実務では、上限より先に調査しやすさを優先するべきです。

目安は、1 ファイルあたり `2,000` から `10,000 URL` に収め、テンプレート単位または責任者単位で分けることです。異常時の切り分けが速く、Search Console で落ちている群を追いやすく、`lastmod` の精度も保ちやすくなります。5 万 URL を 1 枚に押し込む方式は、実装が楽でも障害時に弱すぎます。

分割軸ごとの向き不向きを比較する

多くのサイトで最初に選ぶべき分割方法は、日付別ではなくテンプレート別です。記事、サービス、カテゴリ、事例ページでは、起きる不具合の種類が違うからです。

まずテンプレート別を選ぶべき条件

次の条件に二つ以上当てはまるなら、最初から `sitemap index` を採用すべきです。

• 管理 URL が `5,000` を超える
• 記事とサービスページが同居している
• 更新担当が 2 名以上いる
• テンプレートごとに `canonical` や `noindex` の条件が違う
• Search Console を週次で監視する運用を置きたい

反対に、URL が `5,000` 未満、テンプレートが 2 種類以下、担当者が 1 名、改修頻度が月 1 回以下なら、全件 1 枚でも回せます。例外が成立する条件はかなり狭いと見ておくほうが安全です。

`robots.txt`には発見経路として必ず残す

Search Console で送信しているから `robots.txt` の `Sitemap:` 行は不要だ、と考えるのは勧めません。Google は robots.txt 経由の発見も案内 しています。Search Console 送信と `robots.txt` 記載は、両方そろえておくべきです。Search Console は監視用、`robots.txt` は発見経路を単純に保つために使います。

CDN の切り替え、ドメイン統合、ステージングから本番への移行直後は、`Sitemap:` 行が残っているだけで初動の安定感が変わります。設定ファイルの棚卸しから漏れやすいため、公開前チェックに必ず含めてください。

Search Consoleは調査順を固定して使う

Search Console を「送信ボタン」としてしか使わない運用は、早めに改めるべきです。Search Console の価値は送信ではなく、調査順を固定できる点にあります。 順番がない現場では、URL 検査、ページのインデックス登録レポート、ログ確認を場当たりで往復し、時間だけが過ぎます。

勧める順番は四段階です。`1. サイトマップ取得状況`、`2. 代表 URL の URL 検査`、`3. 群としてのインデックス登録レポート`、`4. Googlebot のログ確認`。この順番を崩さないだけで、原因特定にかかる時間は体感で半分近くまで下がります。

最初に見る取得状況の三つの確認点

Search Console のサイトマップ画面では、次の三点だけ先に確認してください。

• 最終読み取り日時が更新されているか
• 取得エラーや処理エラーが出ていないか
• 送信 URL 数と実ファイルの件数が大きくずれていないか

小規模サイトで 3 日以上、中規模以上で 7 日以上「最終読み取り」が止まるなら、送信回数を増やすのではなく配信経路を疑うべきです。`404`、`403`、`5xx` が見えているなら、問題はインデックス以前にあります。WAF、認証、CDN キャッシュ、ファイル配置、リバースプロキシの設定を先に確認してください。

代表URLは一件ではなく五件確認する

次に、URL 検査ツール で代表 URL を見ます。ここで一件だけ調べる運用では足りません。最低でも同じテンプレートから `3` から `5` 件、重要テンプレートなら `10` 件見るべきです。一件だけでは個別の例外に引っ張られます。

確認項目は次に絞れます。

• URL が Google に登録されているか
• ユーザー指定 canonical と Google 選択 canonical が一致しているか
• クロールが許可されているか
• 参照サイトマップとして意図したファイル名が出ているか

ここで Google 選択 canonical が別 URL になっているなら、サイトマップの再送信では解決しません。`canonical` と内部リンクの設計を直すのが先です。Search Console を道具として使い切る考え方は、Googleインデックス登録を早めたいときの実務手順。Search Consoleを道具として使い切る でも共通しています。

群の傾向はページレポートでつかむ

個別 URL の確認だけでは、全体像をつかめません。ページのインデックス登録レポート で、理由別の増減を見るべきです。特に注目したいのは次の四つです。

• 重複、Google により別の canonical が選択された
• クロール済み、インデックス未登録
• 検出済み、インデックス未登録
• `robots.txt` によりブロック

このレポートで週次の変化が `10%` を超えて悪化したら、URL 単位の再送信より先に、テンプレート単位の不具合を疑うべきです。群の傾向を見ずに一件ずつ再送信する運用は、手数が増えるだけで再発防止につながりません。

最後にログでGooglebotの動きを裏取る

Search Console の反映を待ち続けるより、最後はログで裏を取ったほうが早い場面があります。送信や差し替えの `24` から `72` 時間後に、Googlebot が対象ファイルへ来ているか、代表 URL へ再訪しているかを確認してください。月間 PV `100 万` を超えるサイト、または URL が `50,000` を超えるサイトでは、この確認を運用に組み込むべきです。

Search Console が正常でも、CDN や WAF が一部の User-Agent だけ弾くことがあります。特にリニューアル直後は、アプリケーションは `200` を返していても、配信側の設定で Googlebot にだけ `403` を返している例があります。大規模サイトでログを見ない運用は避けるべきです。

robotsとcanonicalの矛盾を先に潰す

サイトマップ運用で本当に多い事故は、XML の文法ミスではありません。`robots.txt`、`canonical`、`noindex`、リダイレクトの矛盾です。ここが崩れているのにサイトマップだけ直しても、インデックスは安定しません。

Google の robots.txt の概要 では、`robots.txt` は主にクロール制御の仕組みであり、検索結果から除外するための手段ではないと説明されています。さらに noindex のガイド では、`noindex` を効かせるには crawler がページを取得できる必要があると案内されています。ここから導ける実務上の結論は一つです。検索結果から外したいなら `noindex`、完全に閉じたいなら認証、クロール量を抑えたいなら `robots.txt` と役割を分けるべきです。

矛盾しやすい設定を一覧でつぶす

サイトマップ周辺の不具合は、単独ではなく組み合わせで起きます。初回監査でよく出る組み合わせを表にすると次の通りです。

Google の重複 URL 統合ガイド でも、別の技術で別 URL を正規だと示さないよう求めています。サイトマップ、`canonical`、内部リンクの三つは、必ず同じ URL を指すように揃えるべきです。

`robots.txt`に期待しすぎる運用はやめる

`robots.txt` で見せたくないページを消そうとする運用は、何度も同じ失敗を繰り返します。`robots.txt` は「取得量を抑える」ための仕組みであって、「検索結果から消す」ための仕組みではありません。非公開にしたい資料や管理画面は認証で閉じるべきですし、検索対象から外したい一覧や重複ページは `noindex` で制御すべきです。

ここを曖昧にしたままサイトマップだけ整えると、設定変更のたびに整合が崩れます。インデックス制御の主語を `robots.txt` に置かないこと。これだけでも事故の数はかなり減ります。

JavaScript依存の生成方式を早めに見直す

JavaScript サイトや headless CMS では、フロント側のルーター情報や一覧 API の返り値からサイトマップを組み立てる実装を見かけます。この方式は勧められません。サイトマップの生成元は、画面の見え方ではなく、正規 URL を管理しているデータソースに置くべきです。

Google の JavaScript SEO 基本ガイド では、Google が発見しやすいのは `href` 属性を持つ `<a>` 要素だと説明されています。ボタン押下でしか到達できないページや、`#/products` のようなフラグメント URL に依存する設計は避けるべきです。SPA の画面遷移が成立していても、Googlebot にとって十分な発見経路になっていない場合があります。

先に直したい四つの実装ポイント

JavaScript 依存が強いサイトでは、次の四点を先に確認してください。

• `#/path` のようなフラグメント URL を使っていないか

使っているなら、通常の URL に切り替えるべきです。

• 重要ページへ `<a href>` のリンクで到達できるか

ボタンや script 依存の遷移しかないなら、内部リンクを作り直すべきです。

• `canonical` がレンダリング後にしか入らない設計になっていないか

可能なら初期 HTML で出すほうが安全です。

• サイトマップをフロント一覧 API から作っていないか

CMS や DB の公開判定テーブルから生成するほうが壊れにくくなります。

この四点のどれかが崩れているなら、サイトマップ改善より基礎の修正を優先すべきです。発見経路が弱いまま XML だけ増やしても、長くは持ちません。

空ファイルを返さない原子更新を採る

もう一つ軽視されやすいのが、差し替え時の更新方法です。デプロイ中に空の `sitemap.xml` や中途半端な `sitemap index` を返す実装は避けるべきです。大規模サイトでは、数分だけ空のファイルが返ったタイミングで Googlebot が取りに来て、その後の調査が面倒になります。

対策は単純です。一時ファイルへ書き出し、形式確認と件数確認を通してから最後に差し替える。差し替え直後に `200` 応答と件数を自動検証する。日次で数百 URL が増減するサイトほど、このやり方のほうが事故を抑えられます。

サイト規模別に選ぶ実装方式と監視体制の基準

「結局、自分たちは何を選ぶべきか」が曖昧なままでは、実装に落ちません。ここでは数値で区切ります。中小規模では掲載条件の厳密化を優先し、中規模では分割と監視を先に固め、大規模ではログと責任分担を運用に組み込むべきです。

月間PV十万未満なら一枚運用から始める

月間 PV `10 万` 未満、管理 URL `5,000` 未満、テンプレート `2` 種以下なら、最初は 1 本のサイトマップで十分です。ただし、全件出力ではなく、正規 URL に絞ったうえで始めるべきです。

推奨する進め方は次の通りです。

• 代表 URL を `50` 件サンプリングして `200`、`canonical`、`noindex` を確認する
• 公開後 `2` 週間だけは毎日 Search Console を見る
• 問題がなければ週 1 回へ落とす
• 分割は URL `5,000` を超えた時点で再検討する

例外は、少数 URL でもニュースとサービス詳細が混在し、担当者が複数いる場合です。そのときは件数が少なくてもテンプレート別に分けたほうが監視しやすくなります。

月間PV十万から百万人は分割を先に決める

月間 PV `10 万` から `100 万`、URL `5,000` から `50,000` の帯では、`sitemap index` を採用すべきです。記事、サービス、カテゴリ、事例といった単位で分け、1 ファイル `2,000` から `10,000 URL` を目安に運用するのが無難です。

この帯で起きやすい失敗は、件数不足ではなくテンプレートごとの品質差です。記事は正常でもカテゴリだけ `canonical` が崩れる、サービスだけ `noindex` の条件がずれる、といった事故が増えます。分けていないと、どこから崩れたのかが分かりません。

月間PV百万人超ならログ監視を外さない

月間 PV `100 万` 超、または URL `50,000` 超なら、事業単位とテンプレート単位を掛け合わせて分けるべきです。`/media/article.xml` のような単純な切り方ではなく、監視担当が責任を持てる単位へ分けてください。

この規模では次の三つが必須です。

• Googlebot ログの定期確認
• `lastmod` 更新条件の文書化
• CDN、WAF、アプリケーションの三層監視

例外は、URL 数が多くても更新頻度が非常に低いアーカイブ型サイトです。その場合は分割数を増やしすぎると保守が重くなります。とはいえ、ログ確認だけは外すべきではありません。

JavaScript依存が強いなら基礎修正を先に行う

SPA や headless CMS 構成で JavaScript 依存が強い場合は、サイトマップ改善より クロール可能なリンクと通常 URL の整備を優先すべきです。`href` を持つリンク、初期 HTML の `canonical`、公開判定テーブルからの生成。この三つが整っていないなら、XML を磨いても効果は鈍いままです。

このタイプのサイトは、内部リンク設計の立て直しと一緒に進めると改善しやすくなります。JPSM SEO でも、サイトマップだけを単独で直すより、`canonical` と内部リンクの整合まで含めて整理した案件のほうが再発率は低く抑えられています。

公開後三か月で差がつく運用手順と確認頻度

サイトマップ XML は、公開した瞬間より、その後の三か月で差がつきます。障害の多くは初日ではなく、テンプレート改修、CMS 更新、配信基盤の切り替えが入った `2` 週目、`4` 週目、`8` 週目に出ます。だから、公開前から確認頻度を決めておく必要があります。

公開直後二週間は毎日確認する

公開から `14` 日間は、少なくとも毎日確認してください。見るポイントは固定で構いません。

• サイトマップの最終読み取り日時
• 取得エラー、処理エラーの有無
• 代表 URL `10` から `20` 件の URL 検査
• Googlebot の取得ログ
• インデックス登録レポートで新しい除外理由が増えていないか

ここで異常が出たら、送信し直す前に原因を切り分けます。最終読み取りが止まっているなら配信経路、canonical がずれるなら正規 URL の設計、`検出済み` が増えるなら内部リンクとページ価値、という順です。

三週目から八週目は変化率で追う

公開後 `3` 週目から `8` 週目は、週 `2` 回で十分です。ただし、ただ見るのではなく、前週との差分で追うべきです。

• URL 数が急減していないか
• `lastmod` が不自然に全件更新になっていないか
• 「重複」「検出済み」「クロール済み、インデックス未登録」が前週比 `10%` 以上悪化していないか
• 新規テンプレートが掲載条件を満たしているか

ここで悪化したら、改善対象をサイト全体に広げないことが大切です。落ちている群を絞り、そのテンプレートだけを見直したほうが復旧は早くなります。

九週目以降は週次定例へ移して回す

`9` 週目以降は、週 `1` 回の定例に落として構いません。月 `1` 回は掲載条件から外れた URL の棚卸しを入れ、リニューアルやテンプレート改修の前後は臨時で代表 URL を再検証してください。大きな改修のたびにゼロから慌てるより、定例の運用型を持っていたほうが安定します。

運用の型づくりまで含めて支援が必要なら、JPSM SEO では XML の生成条件だけでなく、Search Console の見方、`canonical` の統一基準、公開後三か月の監視手順までまとめて整理しています。実装そのものより、判断基準を残すことのほうが長期的に効きます。

実装前後で必ず回す実務チェックリストの全体像

最後に、実装と公開の前後で必ず回したい確認項目です。抽象論ではなく、そのまま運用表へ移せる粒度で置きます。

公開前に終える確認項目を十個置く

• サイトマップ掲載 URL のうち、最低 `50 URL` をサンプリングし、`200` 応答を確認したか
• 代表 URL `20` 件で `canonical` とサイトマップ掲載 URL が一致しているか
• `noindex` ページ、リダイレクト元 URL、パラメータ URL が混ざっていないか
• `robots.txt` に `Sitemap:` 行が残っているか
• `lastmod` が本文更新や主要情報更新と連動しているか
• サイトマップを差し替える処理が空ファイルを返さない構成になっているか
• Search Console の対象プロパティで送信先 URL が正しいか
• 内部リンクから到達できない孤立 URL を載せていないか
• JavaScript テンプレートで重要リンクが `<a href>` になっているか
• ステージング URL や認証下 URL が生成元から除外されているか

異常が出たときの対処順も先に決めておく

• サイトマップ取得エラーが出た場合

送信し直す前に、`404` `403` `5xx` と配信経路を確認する

• URL 検査で Google 選択 canonical がずれた場合

サイトマップではなく `canonical` と内部リンクを修正する

• `検出済み、インデックス未登録` が増えた場合

サイト構造、内部リンク、一覧導線を見直す

• `クロール済み、インデックス未登録` が増えた場合

内容重複、薄い本文、一覧との差別化不足を疑う

• `robots.txt` ブロックが理由に出た場合

インデックス制御を `robots.txt` に任せていないか確認する

サイトマップ XML は、作れば終わる施策ではありません。掲載条件を先に決め、監視単位で分け、確認順を固定して初めて機能する施策です。今週やるべきことは五つです。掲載条件を一枚の表にまとめる、代表 URL を `20` 件抜いて URL 検査を行う、`robots.txt` と `canonical` の矛盾を洗う、分割単位を決める、公開後 `14` 日間の確認担当を決める。この五つを先に終えれば、サイトマップ運用はかなり安定します。