運営会社

XMLサイトマップとは?Search Consoleへの送信とSEOでの役割

XMLサイトマップの役割、Search Consoleへの送信、含めるURLと除外するURL、エラー確認、BtoBサイトでの運用ポイントまで整理します。
XMLサイトマップとは?Search Consoleへの送信とSEOでの役割

XMLサイトマップは、検索エンジンに対して「このサイトで見つけてほしい重要なURL」を伝えるためのファイルです。サイト内のページを人間向けに案内するHTMLサイトマップとは違い、XMLサイトマップは主にGoogleなどの検索エンジン向けに作成します。

SEOで大切なのは、XMLサイトマップを「全URLを詰め込む一覧」として扱わないことです。サイトマップに載せるべきなのは、検索結果に出したい正規URLです。noindexページ、リダイレクト元URL、404ページ、重複URL、管理用URLなどを混ぜると、Googleに伝えたい重要URLがぼやけます。

結論から言うと、XMLサイトマップは順位を直接上げる魔法ではなく、重要URLの発見と更新理解を助けるためのSEO運用ファイルです。 Search Consoleへ送信したら終わりではなく、取得状況、検出URL、エラー、インデックス状況を見ながら、サイトの重要ページがGoogleに伝わっているかを確認します。

Google公式のサイトマップの概要では、サイトマップはサイト上のページ、動画、その他ファイルと、それらの関係を検索エンジンに伝えるファイルとして説明されています。また、サイトマップの作成と送信では、XML、RSS、テキストなどの形式、Search Consoleでの送信、robots.txtでの参照、サイトマップインデックスなどが整理されています。

XMLサイトマップは、検索に出したい重要URLをGoogleに伝えるための補助線です。すべてのURLを載せることより、載せるURLを選ぶこと、送信後に確認すること、更新時に整えることの方が重要です。

BtoBサイトでは、サービスページ、事例ページ、料金や費用に関するページ、比較記事、ホワイトペーパー導線のあるページなど、問い合わせや商談に近いURLを優先して管理します。記事を増やす前に、重要URLがサイトマップに含まれているか、noindexやcanonicalと矛盾していないか、Search Consoleで処理されているかを確認するだけでも、技術SEOの土台が見えやすくなります。

この記事では、XMLサイトマップの意味、HTMLサイトマップとの違い、SEOでの役割、含めるURLと除外するURL、作成方法、Search Consoleへの送信、エラー確認、lastmodの扱い、CMS別の注意点、BtoBサイトでの優先管理まで整理します。

補足ボックス|この記事でわかること

  • XMLサイトマップの基本的な役割
  • XMLサイトマップとHTMLサイトマップの違い
  • SEOでXMLサイトマップが役立つ場面
  • サイトマップに含めるURLと除外するURL
  • Search Consoleへの送信方法
  • サイトマップエラーの確認ポイント
  • lastmodや更新頻度の扱い
  • BtoBサイトで優先管理すべきURL
  • 自社で確認する範囲と外部に相談する範囲

補足ボックス終了

XMLサイトマップは重要URLをGoogleに伝えるファイル

XMLサイトマップが重要URLをGoogleに伝え、クロールとインデックスの発見を支援するSEO図解

XMLサイトマップとは、検索エンジンに見つけてほしいURLをXML形式でまとめたファイルです。一般的には `sitemap.xml` や `sitemap_index.xml` のようなURLで公開され、Search Consoleから送信したり、robots.txtに記載したりしてGoogleへ伝えます。

基本的なXMLサイトマップは、次のような構造です。

```xml <?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <url> <loc>https://www.example.com/service/</loc> <lastmod>2026-06-07</lastmod> </url> </urlset> ```

`loc` はページのURL、`lastmod` は最終更新日を示します。実務では、CMSが自動生成することも多く、WordPress、Astro、Next.js、Shopify、EC-CUBE、microCMSなど、サイトの構築方法によって生成方法は変わります。

XMLサイトマップの役割は、Googleに重要URLを発見してもらいやすくすることです。 ただし、サイトマップにURLを入れたからといって、必ずクロールされる、必ずインデックスされる、必ず順位が上がるわけではありません。ページの品質、内部リンク、canonical、noindex、robots.txt、HTTPステータスなども関係します。

綱脇耕輔の実務見解として、XMLサイトマップは「SEO担当者が一度送信して終わるファイル」ではなく、サイト運用の状態を映す台帳として扱う方が現実的です。サイトにどのURLがあり、どのURLを検索に出したいのか。どのページが更新され、どのページは除外すべきなのか。これを定期的に確認するための材料になります。

特にBtoBサイトでは、検索流入の入口が数ページに集中することがあります。サービスページ、事例ページ、比較記事、費用記事、ホワイトペーパーLPなどがサイトマップに含まれていない場合、Googleに重要URLを伝える機会を逃している可能性があります。

XMLサイトマップとHTMLサイトマップの違い

XMLサイトマップとHTMLサイトマップの違いを検索エンジン向けとユーザー向けで比較する図解

サイトマップには、XMLサイトマップとHTMLサイトマップがあります。名前は似ていますが、対象が違います。

種類 主な対象 役割
XMLサイトマップ 検索エンジン 重要URLや更新情報を伝える
HTMLサイトマップ ユーザー サイト内のページを探しやすくする

XMLサイトマップは、検索エンジン向けのファイルです。GooglebotがURLを発見しやすくなるように、検索に出したいページをまとめます。Search Consoleで送信でき、エラーや取得状況も確認できます。

HTMLサイトマップは、ユーザー向けのページです。Webサイト内の主要ページを一覧化し、訪問者が目的のページへ移動しやすくする役割があります。内部リンクとしての意味もありますが、XMLサイトマップとは目的が違います。

XMLサイトマップは検索エンジン向け、HTMLサイトマップはユーザー向けです。 どちらか一方があれば必ず十分というものではありません。SEOの技術運用ではXMLサイトマップを確認し、ユーザー導線や回遊改善ではHTMLサイトマップやカテゴリ導線、パンくず、内部リンクを確認します。

混同しやすいのは、「サイトマップを作ったからSEO対策は完了」と考えることです。XMLサイトマップはページの発見を助けますが、ページ自体の内容、内部リンク、検索意図、CTA導線までは改善しません。サイトマップは土台であり、成果につながるページ設計とは別に考える必要があります。

SEOでXMLサイトマップが役立つ場面

XMLサイトマップが新規ページ、更新ページ、大規模サイト、階層の深いページで役立つ場面を整理する図解

XMLサイトマップは、特にGoogleに見つけてもらいたいURLがある時、サイト構造が複雑な時、更新ページを伝えたい時に役立ちます。

代表的な場面は次の通りです。

場面 XMLサイトマップが役立つ理由
新規ページを公開した GoogleにURLを発見してもらいやすくする
記事や事例を更新した 更新URLを伝える材料になる
サイト規模が大きい URL群を整理して伝えられる
階層が深いページがある 内部リンクだけで発見されにくいURLを補助する
画像・動画・ニュースがある 拡張サイトマップで追加情報を伝えられる
リニューアル直後 重要URLの存在を確認しやすい

Googleは内部リンクをたどってページを発見します。そのため、サイトマップだけに頼るのではなく、重要ページへの内部リンクも整える必要があります。サイトマップに含まれていても、サイト内から孤立しているページは、検索エンジンにもユーザーにも重要性が伝わりにくくなります。

サイトマップは内部リンクの代わりではありません。 重要ページはサイトマップに含めるだけでなく、カテゴリ、関連記事、ナビゲーション、パンくず、サービスページからの導線でも見つけやすくします。

一方で、BtoBサイトでは、事例ページやホワイトペーパーLP、セミナーレポート、比較記事などがCMSの都合で深い階層に置かれることがあります。これらのURLが内部リンクで十分に見つけられない場合、XMLサイトマップで補助する意味があります。

XMLサイトマップは、重要URLの発見を補助するものであり、ページの価値そのものを高める施策ではありません。そのため、サイトマップ運用と同時に、記事品質、内部リンク、CTA導線、Search Consoleでの表示回数やクリック数も確認します。

サイトマップに含めるURLと除外するURL

XMLサイトマップに含めるURLと除外するURLをindex対象、noindex、重複、リダイレクトで整理する図解

XMLサイトマップで最も重要なのは、どのURLを含めるかです。サイトマップは、サイト上に存在するすべてのURLを載せる一覧ではありません。検索結果に出したい正規URLを載せます。

含めるべきURLの例は次の通りです。

URL 含める理由
サービスページ 問い合わせに近い
事例ページ 検討段階の判断材料になる
主要なコラム記事 検索流入の入口になる
費用・比較ページ 予算判断につながる
更新した重要ページ Googleに更新を伝えたい

除外すべき、または慎重に判断すべきURLは次の通りです。

URL 除外を検討する理由
noindexページ 検索結果に出さない方針と矛盾する
リダイレクト元URL 代表URLではない
404・削除済みURL 存在しないページ
canonicalで別URLを指すページ 正規URLではない可能性がある
検索結果ページ・絞り込みURL 重複や低価値URLが増えやすい
管理画面・検証環境 検索対象ではない

XMLサイトマップには、検索結果に出したい正規URLを載せるのが基本です。 noindexにしているURLをサイトマップに入れていると、「検索に出したいのか、出したくないのか」が運用上分かりにくくなります。Googleが即座に誤解するというより、担当者が原因を切り分けにくくなることが問題です。

綱脇耕輔の実務見解として、サイトマップの品質を見る時は、URL件数よりも中身を見ます。重要URLが含まれているか。不要URLが混ざっていないか。canonicalと矛盾していないか。リダイレクトや404が混ざっていないか。これらを確認すると、サイト運用の粗さが見えます。

サイト移行やCMS変更の直後に、重要URLを含まないサイトマップを送信し続ける運用は避けてください。重要ページが検索対象として伝わりにくくなり、問題発見も遅れます。

XMLサイトマップの作成方法と基本形式

XMLサイトマップの基本形式、絶対URL、lastmod、サイトマップインデックスを整理する図解

XMLサイトマップの作成方法は、サイトの構築環境によって変わります。WordPressであればSEOプラグインや標準機能で生成されることがあります。静的サイトやフレームワークで作っている場合は、ビルド時に生成することがあります。大規模サイトやECサイトでは、カテゴリ、商品、記事、画像などを分けてサイトマップインデックスで管理することもあります。

作成時に見るべき基本項目は次の通りです。

項目 確認すること
loc 絶対URLで、正規URLになっているか
lastmod 実際の更新日と一致しているか
URL件数 1ファイルあたりの上限を超えていないか
容量 非圧縮で上限を超えていないか
文字コード UTF-8で出力されているか
サイトマップインデックス 複数サイトマップをまとめているか

Google公式のサイトマップ作成ドキュメントでは、1つのサイトマップの上限として、非圧縮で50MBまたは50,000URLの制限が説明されています。これを超える場合は、複数のサイトマップに分割し、サイトマップインデックスを使って管理します。

CMSが自動生成していても、出力内容は必ず確認します。 自動生成だから安心とは限りません。タグページ、著者ページ、検索結果ページ、noindexページ、リダイレクトURL、古いURLが混ざっていることがあります。

また、`priority` や `changefreq` を細かく設定することに時間を使うより、まずはURLの正しさ、lastmodの正確さ、noindexやcanonicalとの整合性、Search Consoleでの処理状況を確認した方が実務的です。

XMLサイトマップは、作ることよりも、検索に出したいURLだけが正しく出力されているかを確認することが重要です。

Search ConsoleへXMLサイトマップを送信する手順

Search ConsoleでXMLサイトマップを送信し、処理状況と検出URLを確認する手順の図解

XMLサイトマップは、Google Search Consoleから送信できます。Search Consoleの対象プロパティを開き、左メニューの「サイトマップ」からサイトマップURLを入力して送信します。

送信の流れは次の通りです。

1. サイトマップURLを確認する 2. Search Consoleで対象プロパティを開く 3. 「サイトマップ」メニューを開く 4. サイトマップURLを入力して送信する 5. ステータス、検出されたURL数、最終読み込み日時を確認する 6. 必要に応じてページのインデックス登録レポートやURL検査で確認する

Google公式のサイトマップレポートでは、Search Consoleで送信したサイトマップの管理、ステータス確認、エラー確認について説明されています。なお、サイトマップレポートに表示されるのは、そのレポートやSearch Console APIで送信されたサイトマップです。Googleが他の方法で見つけたサイトマップが必ず同じように表示されるわけではありません。

Search Consoleでサイトマップを送信した後は、送信できたかだけでなく、Googleが取得できたか、どのURLが検出されたかを確認します。 送信成功とインデックス登録は同じではありません。

BtoBサイトでは、送信後にサービスページ、事例ページ、主要記事、資料ページなどをURL検査で確認するとよいです。サイトマップ全体の件数だけでは、重要URLが正しく扱われているか分かりません。

サイトマップエラーは原因別に確認する

XMLサイトマップの取得エラー、URL不一致、noindex混在、リダイレクト混在を原因別に確認する図解

Search Consoleでサイトマップを送信すると、取得できない、形式に問題がある、URL数が想定と違う、インデックスされないURLが多いなどの問題に気づくことがあります。エラー名だけで判断せず、原因別に確認します。

よくある確認ポイントは次の通りです。

状態 確認すること
取得できない サイトマップURL、HTTPステータス、認証、robots.txt
形式エラー XML構造、文字コード、エスケープ
URL数が少ない CMS出力条件、noindex、カテゴリ除外
URL数が多すぎる タグ、検索結果、パラメータURLの混在
noindex URLが混ざる 検索対象外URLを含めていないか
リダイレクトURLが混ざる 転送先の正規URLを載せているか
404 URLが混ざる 削除済みURLを出力していないか

サイトマップエラーは、サイトマップだけの問題とは限りません。 CMS設定、noindex、canonical、リダイレクト、公開状態、プロパティ違い、サーバー設定、Basic認証、WAFなどが関係することがあります。

特に、httpとhttps、wwwありなし、サブドメイン、別ドメイン、ステージング環境があるサイトでは、Search ConsoleのプロパティとサイトマップURLの組み合わせを確認します。サイトマップ自体は存在していても、送信先プロパティやURLのホストが違うと、期待通りに確認できないことがあります。

サイトマップにエラーが出た時は、対象URLを1つずつURL検査で確認します。Google公式のURL検査ツールでは、Googleに登録されているか、クロール可否、インデックス可否などを確認できます。サイトマップの問題と、ページ単体の問題を分けるために使います。

lastmodと更新頻度は正確に扱う

XMLサイトマップのlastmodを実際の更新内容と一致させ、更新通知として正確に扱うSEO図解

XMLサイトマップでは、`lastmod` にページの最終更新日を入れられます。これは、ページがいつ更新されたかをGoogleへ伝えるための情報です。ただし、実際の更新と一致していないlastmodを大量に出すと、運用上の信頼性が落ちます。

たとえば、全URLのlastmodを毎日自動で今日の日付にする設定は、便利そうに見えます。しかし、ページ内容が実際には変わっていないのに毎日更新扱いにすると、どのページが本当に更新されたのか分かりにくくなります。

lastmodの運用は次のように考えます。

状態 lastmodの扱い
本文や主要情報を更新した 更新日を反映する
タイトルや見出しを大きく変えた 更新日を反映する
CTAや内部リンクを重要変更した 変更内容に応じて反映する
誤字修正だけ 必要性を判断する
実変更なし 更新日を変えない

lastmodは、更新を誇張するためではなく、実際の変更を伝えるために使います。 更新日が正確であれば、公開後の改善履歴、Search Consoleの変化、クロール状況を見比べやすくなります。

綱脇耕輔の実務見解として、データを扱う企業らしいサイト運用では、記事更新日、サイトマップlastmod、Search Consoleの変化、GA4の流入・CV変化をセットで見ます。更新したのに表示回数が増えないのか。更新後にクリック率が下がったのか。重要URLがサイトマップに入っているのにインデックスされていないのか。こうした切り分けができると、改善判断が速くなります。

lastmodは、SEOのために日付を動かすものではなく、実際の更新とデータ確認をつなぐための情報です。

CMS別にサイトマップ生成の仕組みを確認する

XMLサイトマップはCMSが自動生成することが多いですが、CMSごとに出力仕様が違います。WordPressではSEOプラグインや標準機能で出力されることがあります。ヘッドレスCMSや静的サイトでは、ビルド時に生成することがあります。ECサイトでは、商品、カテゴリ、記事、画像を分けることがあります。

確認したいポイントは次の通りです。

環境 確認ポイント
WordPress 投稿、固定ページ、カテゴリ、タグ、著者ページの出力範囲
ヘッドレスCMS ビルド時に最新URLが反映されるか
静的サイト sitemap生成スクリプトと公開URLの一致
ECサイト 商品終了、在庫切れ、カテゴリ変更時の扱い
多言語サイト hreflangや言語別URLの整理
複数ドメイン Search ConsoleプロパティとURLの対応

CMS任せにする場合でも、サイトマップの中身は定期的に確認します。 特に、タグ一覧や著者ページが大量に出ている、noindexページが混ざっている、削除した商品ページが残っている、公開予約前のURLが出ている、ステージングURLが混ざる、といった問題は実務で起きやすいです。

サイトリニューアルやCMS移行では、旧URLと新URL、リダイレクト、canonical、内部リンク、サイトマップが連動します。サイトマップだけを直しても、canonicalが旧URLを向いていたり、内部リンクが旧URLのままだったりすると、Googleへの伝わり方が不安定になります。

BtoBサイトでは問い合わせに近いURLを優先管理する

BtoBサイトでサービス、事例、費用、比較記事など問い合わせに近いURLをサイトマップで優先管理する図解

BtoBサイトでは、XMLサイトマップを単なる技術ファイルとして見るのではなく、問い合わせや商談に近いURLを管理する材料として使います。すべてのページを同じ重要度で扱うのではなく、事業上の役割で優先順位を付けます。

優先して管理したいURL群は次の通りです。

URL群 優先理由 確認
サービスページ 問い合わせに近い index対象、内部リンク
事例ページ 検討段階の判断材料 カテゴリ、タグ、更新日
費用・比較記事 予算判断につながる 正規URL、更新日
課題解決記事 検索流入の入口 サイトマップ、内部リンク
資料・セミナーLP リード獲得につながる noindex方針、計測

一方で、優先度が低いURLや除外候補もあります。

URL群 注意点
薄いタグ一覧 検索意図に対する独立価値が弱い場合がある
検索結果ページ 重複や低品質URLが増えやすい
フォーム完了ページ 検索流入の入口にする必要がない
古いキャンペーンLP 現在のサービス導線とずれる可能性がある
重複記事 canonicalや統合の判断が必要

BtoBサイトでは、問い合わせに近いURLがサイトマップに含まれているかを優先して確認します。 流入が増えても、問い合わせに近いページが検索対象から外れていると、成果につながりにくくなります。

試算例として、月100件の自然検索流入がある記事より、月20件でも商談化率が高いサービス比較ページの方が事業貢献が大きいことがあります。サイトマップではURL件数だけを見るのではなく、CV距離、商談化率、更新頻度、検索意図、内部リンクを合わせて管理します。

自社で確認する範囲と外部に相談する範囲

XMLサイトマップ運用で自社確認と外部相談を分ける判断図解

XMLサイトマップは、自社で確認できる範囲と、外部に相談した方がよい範囲を分けて考えます。まずはサイトマップURLを開き、重要URLが含まれているか、Search Consoleで送信されているか、エラーが出ていないかを見ます。

自社で確認しやすい項目は次の通りです。

自社で確認 確認方法
サイトマップURL ブラウザで開く
Search Console送信 サイトマップレポートを見る
重要URLの有無 サービス・事例・記事を探す
noindex混在 URL検査やCMS設定を見る
エラー 取得不可、形式エラー、URL数を見る

外部に相談した方がよいケースは次の通りです。

外部に相談 理由
大量URLの整理が必要 CMS・URL設計・canonicalが絡む
リニューアル後に流入が落ちた リダイレクト、内部リンク、サイトマップを横断確認する
Search Consoleでエラーが多い サーバー、WAF、認証、形式の確認が必要
重要URLがインデックスされない No34〜36の領域も含めて切り分ける
複数ドメイン・多言語 プロパティ、hreflang、サイトマップ管理が複雑

相談前には、サイトマップURL、Search Consoleのスクリーンショット、重要URLリスト、直近の公開・更新履歴を用意すると診断が進みやすくなります。 何が問題か分からない状態でも、サイトマップ、Search Console、URL検査、ページ登録状況を見れば、原因の方向性を切り分けられます。

まとめ:XMLサイトマップは重要URLを管理するSEO運用ファイル

XMLサイトマップは、Googleに重要URLを伝えるためのファイルです。順位を直接上げる施策ではありませんが、検索に出したいページの発見、更新理解、技術状態の確認を助けます。

XMLサイトマップとHTMLサイトマップは役割が違います。XMLサイトマップは検索エンジン向け、HTMLサイトマップはユーザー向けです。SEO運用ではXMLサイトマップを確認し、ユーザー導線ではHTMLサイトマップや内部リンクを確認します。

サイトマップに含めるURLは、検索結果に出したい正規URLです。noindexページ、リダイレクト元URL、404、重複URL、管理画面、検証環境を混ぜないようにします。

Search Consoleへ送信した後は、送信完了で終わらせず、取得状況、検出URL、エラー、ページのインデックス登録状況を確認します。重要URLはURL検査も併用し、Googleがどう認識しているかを見ます。

BtoBサイトでは、サービスページ、事例ページ、費用・比較記事、課題解決記事、資料LPなど、問い合わせや商談に近いURLを優先して管理します。記事を増やす前に、重要URLがサイトマップに含まれているか確認することは、SEOの土台を整えるうえで有効です。

よくある質問

XMLサイトマップは必要ですか?

小規模で内部リンクが整っているサイトでは必須ではない場合もあります。ただし、BtoBサイトでも記事や事例が増えると、重要URLをGoogleに伝えるためにXMLサイトマップを整備しておく方が管理しやすくなります。

XMLサイトマップを送信すると順位は上がりますか?

サイトマップ送信だけで順位が上がるわけではありません。サイトマップは重要URLの発見や更新理解を助けるものです。順位にはページ内容、検索意図、内部リンク、被リンク、技術状態、ユーザー行動など複数の要素が関係します。

サイトマップには全URLを入れるべきですか?

全URLを入れる必要はありません。検索結果に出したい正規URLを入れるのが基本です。noindex、リダイレクト、404、重複URL、管理用URLなどは除外を検討します。

Search Consoleに送信したのにインデックスされないのはなぜですか?

サイトマップに含まれていても、必ずインデックスされるわけではありません。noindex、robots.txt、canonical、低品質、重複、内部リンク不足、クロール状況などが原因になることがあります。URL検査やページのインデックス登録レポートで確認します。

lastmodは毎日更新した方がいいですか?

実際に内容が更新された時に反映するのが基本です。実変更がないのに毎日更新日だけを変えると、どのページが本当に更新されたか分かりにくくなります。

WordPressならプラグイン任せで十分ですか?

プラグインで生成できることは多いですが、出力内容の確認は必要です。タグページ、著者ページ、noindexページ、古いURL、リダイレクトURLなどが混ざっていないか確認します。

参考情報

執筆者情報
LOads 代表取締役 綱脇 耕輔

執筆者情報

LOads 代表取締役 綱脇 耕輔

Webマーケティング会社・大手Web系企業を経て独立し、デジタルマーケティング業界で14年のキャリア。2018年より東京・福岡を中心に、Web広告運用やSEO対策・AIO対策などのデジタルマーケティング支援を大手・中小企業問わず行っています。100社以上のマーケティング支援の現場で得た知見をもとに、独自の知見とナレッジでコラムを発信しています。

登録が完了しました。

ログインしました。

LOadsへの登録が完了しました。

ログイン用リンクをメールで送信しました。

請求情報を更新しました。

請求情報は更新されませんでした。