XMLサイトマップの注意点は、大きく「載せるURLの正確性」と「Google公式仕様の遵守」の2点に集約されます。noindexや存在しないURLを含めない、正規化した絶対URLだけを記載する、50MB・50,000URLの上限を超えたら分割する、priorityやchangefreqに頼らない、といった基本を外すとインデックス漏れやGoogle Search Console（GSC）のエラーにつながります。本記事では、Google公式の根拠付きで注意点9つをチェックリスト化し、インデックス漏れの原因切り分けと対処手順まで解説します。
- XMLサイトマップ運用でやりがちな注意点9つ
- Google公式のタグ・サイズ・配置の正しいルール
- インデックス漏れ・GSCエラーの原因切り分けと対処手順
noindexや存在しないURLを除外し、正規化した絶対URLだけを載せることが基本です。
priorityやchangefreqは無視され、lastmodは正確なときのみ使われます。上限超過時は分割します。
サイトマップに載せてもインデックスは保証されないため、GSCで状態を確認し根本対策と併用します。
XMLサイトマップの注意点は何から押さえるべき？
結論から言えば、まず「載せるURLの正確性」と「Google公式仕様の遵守」の2軸を押さえることが最優先です。この2つを外すと、どれだけ質の高いコンテンツを用意してもクロール・インデックスが安定しません。
XMLサイトマップとは、サイト内のページURLと更新情報を検索エンジンに伝えるためのXML形式のファイルです。あくまでクロールを補助する役割であり、送信すれば必ずインデックスされるものではない点を最初に理解しておくと、後述する注意点の意味がつかみやすくなります。
TechSuite株式会社の「AI検索パートナーズ」は、生成AIが引用・推薦する仕組みを構造化データやエンティティ認識の観点から技術的に捉え、サイトマップやインデックス設計といった土台の整備まで一次情報設計に踏み込んで支援しています。
この記事で扱う注意点9つの全体像とは？
注意点は「URLの中身」「ファイル仕様」「運用」の3系統に分けると整理しやすくなります。まずは自サイトのサイトマップが以下の9項目を満たしているかを上から順に点検することが、インデックス漏れ解消の近道です。次に、各項目をGoogle公式の根拠とともに掘り下げます。
- noindex・存在しないURLを載せない
- 正規化した絶対URLだけを記載する
- 50MB・50,000URLの上限を超えたら分割する
- priority・changefreqに頼らない
- lastmodは正確な最終更新日時にする
- UTF-8・エスケープなどXML仕様を守る
- 配置場所とrobots.txtの整合性を保つ
- 定期的に更新・再送信する
- 「載せる＝インデックス保証」ではないと理解する
XMLサイトマップはどんなサイトで特に有効？
結論として、サイト規模が大きい、新規ページの生成頻度が高い、更新頻度が高い、画像や動画などリッチメディアが多いサイトで特に有効とされています（LANY）。小規模で内部リンクが行き届いたサイトなら効果は限定的ですが、規模拡大とともに重要性が増します。逆に言えば、対象サイトの特性を見極めずに導入すると効果を実感しにくくなります。
まずは9項目のチェックリストで自サイトを点検するところから始めてみましょう。
載せてはいけないURLと正規URLの注意点は？
結論は、noindex・存在しないURL・非正規URLを混ぜず、検索結果に表示したい正規URLだけを絶対URLで記載することです。ここを誤るとGSCでエラーが出たり、クロール効率が下がったりします。
Googleは、検索結果に表示したいURL（正規URL/canonical）をサイトマップに含めるよう推奨しています（Google検索セントラル）。サイトマップは「このURLを見てほしい」という意思表示なので、載せるURLの質がそのまま伝わる情報の質になります。
TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・商材に応じてサイト構造や検索導線を個別に設計し、canonicalやnoindexとサイトマップの整合性を含めてボトルネックを特定し、解決策の実行まで伴走しています。
noindexページを載せるとなぜエラーになる？
XMLサイトマップにnoindexページが含まれていると、Google Search Consoleでエラーメッセージが表示されます（LANY）。「インデックスさせたいURL一覧」であるサイトマップに「インデックスさせたくないnoindex」を載せる行為は指示が矛盾しているため警告の対象になります。エラーが出た場合は、該当URLを特定して削除し、修正後に再送信します。404やリダイレクトURL、重複URLも同様に混在させないよう確認します。
相対URLと正規化はどう扱う？
サイトマップには完全修飾された絶対URL（例: https://www.example.com/mypage.html）を使い、相対URL（/mypage.html）は指定しないのが公式ルールです（Google検索セントラル）。PC版とモバイル版でURLが異なる場合は、いずれか一方のURLにのみリンクすることが推奨されています。canonicalタグで指定した正規URLとサイトマップのURLを一致させることが、評価の分散を防ぐ基本です。
載せるURLの点検チェックリストです。
- noindex指定のURLが含まれていないか
- 404・301リダイレクト先URLが混在していないか
- すべて絶対URLで記載されているか
- canonicalで指定した正規URLと一致しているか
載せるURLは「検索結果に出したい正規URLだけ」と覚えておくと迷いませんね。
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援！
ファイル仕様のタグやサイズの注意点は？
結論として、50MB・50,000URLの上限を守り、priorityやchangefreqに頼らず、UTF-8とエスケープなどのXML仕様を厳守することが重要です。仕様違反は読み込みエラーや無視の原因になります。
Google公式は、1つのサイトマップの上限を圧縮していない状態で50MB、URL件数は50,000件と定めており、これを超える場合は分割するかサイトマップインデックスファイルを作成して送信します（Google検索セントラル）。仕様は変わり得るため、公式ドキュメントを定期的に確認する姿勢が欠かせません。
TechSuite株式会社の「AI検索パートナーズ」は、こうしたGoogle仕様の変化を研究とデータで追従し、構造化データや技術要件の最新動向を施策に反映しながらLLMO/GEO/AEOの技術的アプローチを提供しています。
上限を超えたらどう分割する？
URL件数やファイルサイズの上限を超える場合は、サイトマップを分割し、複数の子ファイルを束ねる「サイトマップインデックスファイル」で送信します（PLAN-B）。構造は親ファイルと子ファイルの2階層で構成され、子ファイルをさらに細分化した孫ファイルは使用できません（LANY）。大規模サイトほど、この親子構造を前提に運用を設計しておくと管理が安定します。
priorityとchangefreqは意味がある？
結論として、Googleは<priority>と<changefreq>の値を無視します（Google検索セントラル）。優先度や更新頻度を細かく設定してもクロールの優先順位には反映されないため、そこに労力を割く必要はありません。一方で<lastmod>は、ページの最終更新と比較して一貫して正確だと検証できる場合にのみ使用されます。使われるタグと使われないタグを正しく区別することが大切です。
文字コードとエスケープはなぜ重要？
サイトマップファイルはUTF-8でエンコードする必要があり、他のXMLファイルと同様にすべてのタグ値をエスケープしなければなりません（Google検索セントラル）。アンパサンドやシングルクォートなどの特殊文字を未エスケープのまま記述すると構文エラーになり、ファイル全体が読み込まれないことがあります。手動編集した場合は、送信前にバリデーターで構文チェックを行うと安全です。
| タグ・仕様 | Googleの扱い | 対応方針 |
|---|---|---|
| loc（URL） | 使用する | 絶対URLで正規URLを記載 |
| lastmod | 正確なときのみ使用 | 重要な更新日時を反映 |
| changefreq | 無視される | 設定不要 |
| priority | 無視される | 設定不要 |
| エンコード | UTF-8必須 | UTF-8で保存・エスケープ |
priorityやchangefreqの調整より、正しいlocとlastmod、仕様遵守に力を注ぎたいところです。
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援！
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
lastmodと配置場所の運用上の注意点は？
結論は、lastmodを正確な最終更新日時にし、サイトマップをルートに配置してrobots.txtと矛盾させないことです。ここは見落とされがちですが、クロール効率に直結します。
<lastmod>はページに対する最後の重要な更新日時を反映すべきで、メインコンテンツ・構造化データ・リンクの変更は重要な更新とみなされますが、著作権表記の日付変更は重要な更新とはみなされません（Google検索セントラル）。日付を不正確に更新し続けると信頼されなくなる点に注意が必要です。
TechSuite株式会社の「AI検索パートナーズ」は、技術実装を担う人材とコンテンツ制作の人材が一つのチームで連携し、lastmodの自動出力やサイトマップの自動更新といった運用設計から効果測定・改善までを一気通貫で伴走しています。
どんな変更でlastmodを更新すべき？
本文の書き換えや構造化データの追加、内部リンクの変更といった「重要な更新」があったときにlastmodを更新するのが適切です。軽微な表記修正や著作権年の更新だけで日付を変えると、更新情報の信頼性が損なわれかねません。CMSやプラグインで自動生成する場合は、実際の更新イベントと連動してlastmodが出力される設定になっているかを確認します。
サイトマップはなぜルート配置が推奨される？
サイトマップは任意の場所に置けますが、Search Consoleで送信しない限り、親ディレクトリから下の階層しか伝えられません（Google検索セントラル）。そのため、サイト全体をカバーできるようルート直下に配置することが推奨されています。加えて、robots.txtのDisallowでブロックしたURLをサイトマップに載せると指示が矛盾するため、両者の整合性を保つことが欠かせません。
作成しっぱなしはなぜ危険？
手動作成のサイトマップは更新が漏れやすく、古いURLや削除済みURLが残ったまま放置されがちです。存在しないURLを載せ続けるとクロールの無駄が増え、サイト全体の評価にも影響しかねません。WordPressのプラグインやCMSの自動生成機能を使い、更新と再送信を自動化しておくと、こうした運用ミスを防げます。robots.txtへの記載やSearch Consoleでの送信も併用すると通知が確実になります。
運用面の点検ポイントです。
- lastmodが実際の更新と連動しているか
- サイトマップがルート直下に配置されているか
- robots.txtのDisallowと矛盾するURLがないか
- 更新・再送信が自動化されているか
配置と自動更新を整えるだけで、運用ミスの多くは未然に防げるものですよ。
インデックス漏れやGSCエラーはどう切り分ける？
結論として、サイトマップに載せてもインデックスは保証されないため、Search ConsoleのサイトマップレポートとURL検査ツールで原因を段階的に切り分けます。サイトマップはクロールの補助であり、根本対策と併用する前提が重要です。
「サイトマップに載せる＝インデックスされる」という誤解は多いですが、実際はクロールの手がかりを渡すだけで、インデックスの可否はコンテンツ品質や重複判定などで決まります。だからこそ、漏れが起きたときは順序立てて原因を特定する必要があります。
TechSuite株式会社の「AI検索パートナーズ」は、AI Share of Voiceが高水準の自社サイト運用で培った知見を活かし、支援事例でAI Overviewの引用率を改善した実績をもとに、インデックスの安定とAI検索での露出改善の両面を支援しています。より広い最適化の考え方はAI検索対策の進め方やLLMO対策のチェックリストも参考になります。
サイトマップレポートはどう読む？
Google Search Consoleの「サイトマップ」から送信状況とステータスを確認できます。「成功しました」でも検出URL数と実際のインデックス数の差を見て、漏れの規模を把握することが第一歩です。エラーや警告が表示されている場合は、メッセージ内容に沿って該当URLを特定し、noindexや404、robots.txtでのブロックといった矛盾を解消してから再送信します。
URL検査ツールでは何を確認する？
個別ページの状況は、Search ConsoleのURL検査ツールで確認します。「URLがGoogleに登録されていません」と出た場合は、クロール済みか、canonicalが別URLを指していないか、noindexが残っていないかを順に確認します。ページ単位で原因を切り分けることで、サイトマップ側の問題かページ側の問題かを判別できます。必要に応じてインデックス登録をリクエストします。
送信・認識の確認方法は？
Googleへの送信・認識方法は主に2つで、robots.txtに「Sitemap: 〇〇/sitemap.xml」と記載する方法と、Search Consoleの「サイトマップ」からURLを入力して送信する方法です（LANY）。両方を併用すると、通知の確実性と状況確認のしやすさを両立できます。CMSが生成するRSS/Atomフィードのフィードも送信できますが、提供されるのは最近のURL情報のみである点に留意します。
「レポートで全体、URL検査で個別」の順に見ると、原因がスッと切り分けられますね。
よくある質問
XMLサイトマップの注意点について、担当者から寄せられやすい疑問に簡潔に答えます。TechSuite株式会社の「AI検索パートナーズ」は、こうした技術要件を検索意図や想定質問の分解に沿って整理し、AIにも引用されやすいコンテンツ設計まで一貫して支援しています。
- XMLサイトマップはSEOに必須ですか？
必須ではありません。ただし規模が大きい、新規ページの生成頻度が高い、更新頻度が高い、リッチメディアが多いサイトでは特に有効とされています。小規模で内部リンクが行き届いたサイトでは効果は限定的です。
- HTMLサイトマップとの違いは何ですか？
HTMLサイトマップは主にユーザーがサイト内を回遊するための一覧ページで、XMLサイトマップは検索エンジンにURLと更新情報を伝えるためのファイルです。目的が異なるため、両者は併用しても問題ありません。
- サイトマップに載せればインデックスされますか？
保証されません。サイトマップはクロールを補助する手がかりであり、インデックスの可否はコンテンツ品質や重複判定などで決まります。漏れが出た場合はGSCで原因を切り分け、根本対策と併用します。
- 画像や動画はどう扱えばよいですか？
画像・動画・ニュースは拡張機能（拡張タグ）で情報を追加できます。リッチメディアが多いサイトでは、これらを適切に記述することでクロールの手がかりを増やせます。
まとめ
XMLサイトマップの注意点は、「載せるURLの正確性」と「Google公式仕様の遵守」に集約されます。noindexや存在しないURLを除外し、正規化した絶対URLだけを記載することが基本です。
priorityとchangefreqは無視され、lastmodは正確なときのみ使われます。50MB・50,000URLの上限を超えたら分割し、UTF-8やエスケープなどのXML仕様も守ります。ルート配置とrobots.txtとの整合性、定期的な更新・再送信も欠かせません。
サイトマップに載せてもインデックスは保証されないため、GSCのレポートとURL検査ツールで原因を切り分け、コンテンツ品質や内部リンクといった根本対策と併用することが、安定したクロール・インデックスへの近道です。
参考にした情報源
