XMLサイトマップとは？SEO効果・作り方・送信方法を実務者向けに解説

XMLサイトマップは、サイト内のURLをすべて並べるためのファイルではありません。Googleにクロール・インデックスの候補として見てほしい正規URLを整理して伝えるためのファイルです。

SEOの実務では、サイトマップを「作ったかどうか」よりも、次のような観点を継続的に見る必要があります。

この記事では、XMLサイトマップの基礎から、入れるべきURLの判断基準・canonicalとの整合・lastmodの正しい運用・Search Consoleでの確認ポイント・サイトマップ分割の戦略まで、実務でそのまま使える形で解説します。

サイトマップはGoogleにサイトを正しく伝えるための土台です。SEO対策全体の中での位置づけはSEO対策とは？仕組み・基本施策・やり方をわかりやすく解説で詳しく解説しています。

XMLサイトマップは、Googleに見てほしい正規URLを整理して伝えるファイル

XMLサイトマップとは、Googleにクロール・インデックスの候補として見てほしいURLを整理して伝えるためのファイルです。サイト内のURLをすべて詰め込むファイルではなく、検索結果に表示してほしい正規URLを中心に管理するのが基本です。

SEOの観点で言うと、サイトマップは「Googleに評価を主張する」ためのファイルではありません。GooglebotがURLを発見し、正規URLを選び、インデックスするかどうかを判断する過程で、サイト側が重要URLを誤解なく渡すための情報整理です。順位を上げる手段ではなく、Googleが迷わずにサイトを把握できるようにするための基本施策と捉えてください。

XMLサイトマップはURL発見だけでなく、重要URLの整理にも使われる

XMLサイトマップの役割は、URLを発見してもらうことだけではありません。サイト側として「どのURLを検索結果に出してほしいのか」「どのURLが正規URLなのか」「どのURLに重要な更新があったのか」をGoogleに伝える役割もあります。

そのため、サイトマップにURLを載せるという行為は、単に「このURLがあります」と申告することではなく、「このURLを見てほしい・正規として扱ってほしい」と意図を伝えることになります。後述するように、noindexページやリダイレクトURLを混ぜるべきでない理由はここにあります。

HTMLサイトマップはユーザー向け、XMLサイトマップは検索エンジン向け

「サイトマップ」と一口に言っても、目的が異なる2種類があります。SEO文脈で重要なのはXMLサイトマップです。

HTMLサイトマップはナビゲーションの補助としては有用ですが、SEOへの直接的な効果は限定的です。本記事では以降、XMLサイトマップを「サイトマップ」と呼んで解説します。

XMLサイトマップのSEO効果は、順位上昇ではなくURL発見とインデックス状況の把握にある

XMLサイトマップを設置しても、検索順位が直接上がるわけではありません。SEO効果は、Googleにとっての「URL発見の補助」と、サイト運営者にとっての「インデックス状況の診断」が中心です。

「サイトマップを送れば順位が上がる」ではなく、「サイトマップでGoogleの判断を助け、自分でも状態を確認しやすくする」という整理で考えてください。

サイトマップはGoogleのクロール・インデックスを補助する

サイトマップを設置・送信すると、Googleはサイト内のURLを効率的に発見できます。特に、内部リンクだけでは見つけにくいページ・新しく公開したばかりのページ・深い階層のページに対する発見補助として機能します。

ただし、ここで重要なのは「補助」であり、「インデックス保証」ではない点です。サイトマップに載せたURLでも、Googleはページの内容や品質、canonical、noindex、robots.txt、内部リンクの状況などを総合的に見て、最終的にクロール・インデックスするかどうかを判断します。

サイトマップを送信しても、インデックスや順位上昇は保証されない

Google公式ドキュメントでは、「サイトマップ内のすべての項目がクロールされてインデックスに登録されることが保証されるわけではない」と明記されています。

サイトマップはランキング要因ではなく、URL発見とインデックス処理を助けるための補助ファイルです。順位やインデックスは、ページ品質・内部リンク・canonical・サーバー応答など他の要素と合わせて判断されます。

画像・動画・ニュース情報をGoogleに伝えやすくなる

通常のサイトマップに加えて、画像サイトマップ・動画サイトマップ・ニュースサイトマップを使うと、検索結果での表示に役立つ追加メタ情報をGoogleに渡せます。リッチメディアを多く扱うサイトでは、専用サイトマップで情報を整理しておく価値があります。

Search Consoleでインデックス状況を確認しやすくなる

サイトマップを送信しておくと、Search Consoleの「サイトマップ」レポートで「送信URL数」と「インデックスURL数」を比較できるようになります。この比較は、サイトの状態を診断するための材料として機能します。

サイトマップを記事・商品・求人・カテゴリなどで分けておくと、どの領域にインデックス問題があるのかも見えやすくなります（後述）。

XMLサイトマップが特に重要なのは、GooglebotがURLを見つけにくいサイト

XMLサイトマップは、すべてのサイトに必須ではありません。Googleが内部リンク経由でページを十分に発見できる小規模サイトでは、必須ではない場合もあります。

ただし、URLが多いサイト・新しいサイト・外部リンクが少ないサイト・リッチメディアを扱うサイトでは、サイトマップの設置を強くおすすめします。

ページ数が多いサイトでは、重要URLを整理して伝える必要がある

ページ数が数百〜数万にのぼる大規模サイトでは、Googlebotがすべてのページを巡回しきれない可能性があります。サイトマップで「サイト側として重要なURL」を整理して伝えると、Googleがクロール候補を判断しやすくなります。

EC・求人・不動産・データベース型サイトのようにURL数が多いサイトほど、サイトマップで「indexさせたい正規URL」を絞って伝える設計が重要になります。

新しいサイトや外部リンクが少ないサイトでは、URL発見の補助になる

新しく公開したばかりのサイトは、外部リンクがまだ少ないため、Googleが自然な経路でページを発見しにくい状態です。サイトマップを送信しておくと、Googleにサイト内のURLを直接知らせることができます。

小規模で内部リンクが整っているサイトでは、必須ではない場合もある

逆に、約500ページ以下の小規模サイトで、すべての重要ページが内部リンクから自然に到達できる状態なら、サイトマップが必須ではない場合もあります。

ただし、設置のコストはほぼゼロなので、迷う場合は設置することをおすすめします。設置するなら、サイトマップの中身を正しく保つ運用が前提です。次の章から、その判断基準を具体化します。

サイトマップには、検索結果に出したい正規URLだけを載せる

XMLサイトマップに載せるURLは、基本的に検索結果に表示してほしい正規URLです。「サイト内に存在するURLをすべて載せる」のではなく、「Googleに見てほしい正規URLだけを整理して載せる」と考えてください。

これが、サイトマップ運用で最も判断を間違えやすい部分です。

サイトマップに入れるべきURLの判断基準

サイトマップに載せるURLは、次の条件を満たすものを基本にしてください。

これらは「Googleに見てほしいURLとして自然に成立する条件」です。1つでも欠けると、サイトマップとしての一貫性が崩れる原因になります。

noindex・リダイレクト・404 URLはサイトマップに入れない

サイトマップから除外すべきURLは、次のとおりです。それぞれ「なぜ入れないのか」をセットで理解しておきましょう。

比較表

除外すべきURL	なぜ入れないのか
noindexページ	「インデックスさせたくない」と「見てほしい」という矛盾した情報になる
リダイレクト元URL（3xx）	最終URLを載せるべき。Googlebotに無駄な転送を辿らせる必要がない
404・410 URL	存在しないURLを「見てほしい」と伝える意味がない
5xx URL	サーバーエラー中のURLは判断材料として機能しない
別URLをcanonicalにしているURL	正規URLではないため、サイトマップに載せると正規URL選択が濁る
robots.txtでブロックしているURL	クロールしないでほしいURLを「見てほしい」と渡すのは矛盾

別URLをcanonicalにしているページはサイトマップから除外する

canonicalタグでBを正規URLとして指定しているのに、サイトマップではAを送信していると、Googleにどちらを代表として扱ってほしいのか伝わりにくくなります。

サイトマップに載せるべきは、canonicalタグが自己参照している「正規URL本体」です。canonicalタグが別URLを指しているページは、サイトマップには入れません。canonicalの詳細は「canonicalタグとは？書き方・設定が必要なケース・確認方法をわかりやすく解説」を参照してください。

パラメータURLや空ページを混ぜると、Googleに伝えたいURLが分かりにくくなる

?sort=price のような並び替えパラメータURL、絞り込み条件が多いパラメータURL、空ページ、サイト内検索結果ページなどをサイトマップに入れると、本当にindexさせたい正規URLが埋もれます。

これらは検索結果に出す価値が低く、Googleもインデックス対象として優先しません。サイトマップに入れる必要はなく、入れるとSearch Console上で送信URL数とインデックス数の差が広がる原因にもなります。

サイトマップとcanonicalが違うURLを指すと、Googleに正規URLが伝わりにくくなる

XMLサイトマップは、正規URLをGoogleに伝える情報源の1つです。canonicalタグだけ正しくても、サイトマップや内部リンクが別のURLを指していると、Googleに「どのURLが正規なのか」が伝わりにくくなります。

Googleは通常、検索結果に正規URLを表示します。そのため、サイトマップには正規URLを載せるのが基本です。

canonicalタグ・内部リンク・サイトマップは同じURLを指すように揃える

サイトの正規URLは、複数の場所からGoogleに伝わります。次の5箇所が同じURLを指していると、Googleの判断が安定します。

比較表

確認する場所	確認すべきポイント
canonicalタグ	正規URLに自己参照しているか
XMLサイトマップ	正規URLだけを送信しているか
内部リンク	正規URLへ直接リンクしているか
パンくずリスト	正規URLと同じURL設計になっているか
構造化データ内のURL	url や mainEntityOfPage が正規URLと一致しているか

これらが揃っているほど、GoogleはどのURLを代表として扱えばよいかを判断しやすくなります。

非正規URLをサイトマップに入れると、Search Consoleの分析もしづらくなる

非正規URLをサイトマップに混ぜると、Googleはそれらを正規URLとして採用しません。結果として、Search Consoleの「サイトマップ」レポートで送信URL数とインデックス数の差が広がり、原因が「品質の問題」なのか「canonicalの矛盾」なのかが切り分けにくくなります。

サイトマップを汚さないことは、運用効率と診断のしやすさにも直結します。

XMLサイトマップは内部リンクの代わりにはならない

「サイトマップを送信していれば内部リンクは不要」という理解は誤りです。サイトマップはURLの存在をGoogleに伝えるためのファイルですが、ページ同士の関係や重要度・ユーザー導線・Googlebotの巡回経路までは伝えません。

サイトマップはURLの存在を伝え、内部リンクはページ同士の関係を伝える

サイトマップと内部リンクは、役割が違います。

比較表

役割	サイトマップ	内部リンク
URLの存在を伝える	○	○
ページ同士の関連性を伝える	×	○
サイト内での重要度を伝える	×	○
ユーザーの導線を作る	×	○
Googlebotの巡回経路を作る	△	○
トピッククラスターを形成する	×	○

サイトマップだけに載っているページは、Googleに発見される可能性はあっても、サイト内での文脈や重要性が伝わりにくい状態です。

重要ページはサイトマップだけでなく、関連ページからもリンクする

重要なページは、サイトマップに載せるだけでなく、関連する本文中リンク・カテゴリページ・パンくずなどから自然に到達できる状態にしてください。サイトマップと内部リンクは、両方を整えることで初めてGoogleにページの存在と重要性が伝わります。

内部リンクの設計の詳細は「内部リンクとは？SEO効果を高める貼り方と最適化のポイント」を参照してください。XMLサイトマップとは別に、人がサイト全体の階層・URL構造を俯瞰したい場合は「サイト構造を可視化する方法とおすすめツール10選」で詳しく解説しています。サイト構造そのものの設計原則は「SEOに強いサイト構造とは？4つの設計原則と作り方」で詳しく解説しています。

lastmodは更新アピールではなく、重要な変更をGoogleに伝えるために使う

lastmodは、単なる更新日表示ではありません。Googleに「このURLには重要な変更があった」と伝え、再クロール判断の材料を渡すための情報です。

Googleは、lastmodが一貫して正確だと判断できる場合に利用することがあります。逆に、実際には変更していないページに毎日lastmodを書き換えると、Googleがlastmodを信頼しなくなる可能性があります。

本文・構造化データ・価格・求人情報を更新した場合はlastmodを更新する

lastmodを更新すべきタイミングは、ユーザーやGoogleにとって意味のある変更があったときです。

これらは「再クロールする価値がある変更」と言えます。

フッター変更や全ページ一律更新でlastmodを変えるのは避ける

逆に、次のような変更ではlastmodを更新しないのが正しい運用です。

CMSやプラグインによっては、保存ボタンを押すたびにlastmodが現在時刻に書き換わる設定がデフォルトになっていることがあります。lastmodは「新しそうに見せる日付」ではなく、「重要な変更があったことを正確に伝える日付」として運用しましょう。

priorityとchangefreqより、URL選定とlastmodの正確さを優先する

サイトマップのXML構造には4つの主要タグがありますが、Googleの扱いは均一ではありません。priorityとchangefreqは、Googleが無視すると公式に明記しています。

Googleはpriorityとchangefreqを無視する

比較表

タグ	意味	Googleの扱い
loc	URL（絶対URLで記述）	必須。正規URLに揃える
lastmod	最終更新日	正確で検証可能な場合に利用される
changefreq	更新頻度の目安	無視される（公式明記）
priority	URLの相対的重要度	無視される（公式明記）

priorityで「このURLは重要度1.0」と書いても、Googleはその数値をクロール優先度に使いません。同様にchangefreqの値も、Googleが再クロール頻度を決める根拠にはなりません。

細かい優先度設定より、正しいURLを載せることが重要

priorityやchangefreqを丁寧に調整するより、次のことに時間を使ったほうが実務効果があります。

なお、1つのサイトマップファイルには50,000URL / 50MB（非圧縮）という上限があります。これを超える場合は、後述するサイトマップインデックスで分割が必要です。

サイトマップは作成して終わりではなく、Search Consoleで状態を確認する

XMLサイトマップは、作って送信したら終わりではありません。Search Consoleで状態を継続的に確認することで、Googleがサイトマップをどう処理しているか・どのURLがインデックスされているかを把握できます。

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

ただし、サイトマップは送信して終わりではありません。ここからが運用の本番です。

robots.txtにSitemapディレクティブも記述する

Search Consoleでの送信に加えて、robots.txtにもサイトマップの場所を記述しておきましょう。Googlebotがrobots.txtをクロールしたときにもサイトマップを発見できます。

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Sitemap: ディレクティブはrobots.txt内のどこに書いても構いません。複数のサイトマップがある場合は複数行で記述できます。

詳しくは「robots.txtとは？書き方・設置場所・確認方法をわかりやすく解説」を参照してください。

ping APIは廃止済みで、現在はSearch Console送信とrobots.txtが基本

以前は、HTTPリクエストでサイトマップ送信を通知できる「ping API」が存在しましたが、2023年に完全廃止されました。リクエストを送っても404が返ります。

ping APIが廃止された背景には、認証なしのping送信がスパム的に使われやすく、有用性が低かったという事情があります。現在は「何度も通知すること」よりも「Googleが見たときに信頼できるサイトマップを維持すること」のほうが重要です。URLの選定とlastmodの正確さを重視しましょう。

サイトマップ送信後に見るべき項目

サイトマップ送信後は、単に「成功しました」を見るだけでは不十分です。次の項目を継続的に確認します。

比較表

確認項目	見るべきポイント
サイトマップの読み取り状態	正常に読み取れているか、エラーが出ていないか
送信されたURL数	意図したURL数と一致しているか
検出されたURL数	Googleがサイトマップから何件のURLを認識したか
インデックスされたURL数	送信URLのうち何件がインデックスされたか
送信数とインデックス数の差	差が急に広がっていないか
最終読み込み日時	Googlebotが直近でいつサイトマップを読んだか
サイトマップごとのインデックス率	分割している場合、どの領域に問題があるか

URL検査ツールを使えば、個別ページのインデックス可否やcanonicalの認識状態も確認できます。新規ページや更新ページのクロールを早めたい場合は、サーチコンソールでインデックス登録をリクエストする方法で具体的な手順とリクエスト時の注意点を解説しています。

送信URL数とインデックス数の差は、Googleからのフィードバックとして読む

Search Consoleの「サイトマップ」レポートで表示される「送信URL数」と「インデックスURL数」の差は、単なるエラー数値ではありません。サイト側の意図とGoogleの判断のズレを示すフィードバックとして読みましょう。

サイト側は「このURLを見てほしい」と伝えているのに、Googleは「検索結果に出す必要がある」とは判断していないURLがある——これが乖離の意味です。

差が大きい場合は、品質・重複・canonical・内部リンクを確認する

送信数とインデックス数の差が大きい、または広がっている場合、サイトマップ自体ではなくページ側に原因があることがほとんどです。

サイトマップ送信後にインデックスされない場合は、ページ側の問題を確認する

サイトマップを送信してもインデックスされないページがある場合、サイトマップは正しく動いている可能性が高いです。次の順で原因を切り分けてください。

サイトマップに入れていないURLが先にインデックスされている場合の読み方は、「インデックス登録されましたが、サイトマップに送信していませんとは」で解説しています。

Search Consoleの「ページのインデックス登録」レポートに表示されるステータスの意味は、「インデックスカバレッジの全18ステータス」で網羅しています。

特に「クロール済み - インデックス未登録」が増えてきた場合は、「「クロール済み - インデックス未登録」の原因と対処」でケース別の判断基準を確認できます。

サイトマップ分割は、上限対策だけでなくインデックス問題の切り分けに役立つ

1つのサイトマップファイルには50,000URL / 50MBの上限があります。これを超える大規模サイトでは、サイトマップインデックスファイルを使って分割管理します。

ただし、分割の目的は上限対応だけではありません。Search Console上でインデックス問題を領域単位で切り分けるための診断セグメント設計としても有効です。

記事・商品・求人・カテゴリごとに分けると問題箇所を見つけやすい

URLの種類ごとにサイトマップを分けると、どの領域に問題があるかを切り分けやすくなります。

比較表

分割方法	向いているサイト	メリット
記事・固定ページ別	メディア、ブログ	投稿タイプごとに状態を見やすい
商品別	ECサイト	商品ページのインデックス状況を追いやすい
求人別	求人サイト	求人詳細のインデックス状況を確認しやすい
地域別	地域ページが多いサイト	地域ごとの問題を切り分けやすい
カテゴリ別	大規模メディア、EC	カテゴリ単位で問題を把握できる
画像・動画・ニュース別	リッチメディアが多いサイト	専用情報をGoogleに伝えやすい
更新頻度別	頻繁に更新されるサイト	更新ページの確認がしやすい

たとえば、すべて同じサイトマップに混ぜると「全体のインデックス率が低い」としか分かりませんが、分割すれば「記事は問題ないがカテゴリページだけインデックス率が低い」「求人詳細ページの一部がクロールされていない」といった切り分けができます。

大規模サイトでは、サイトマップインデックスで管理する

サイトマップインデックスは、複数のサイトマップを束ねるファイルです。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-posts.xml</loc>
    <lastmod>2026-03-15T10:00:00+09:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-03-20T08:30:00+09:00</lastmod>
  </sitemap>
</sitemapindex>

サイトマップインデックス自体にも50,000件 / 50MBの制限がありますが、理論上は50,000 × 50,000 = 25億URLまで対応可能なので、実務上はまず問題になりません。

XMLサイトマップを正しく作るには、CMSの自動生成結果を必ず確認する

XMLサイトマップの作成方法は、利用しているCMS・環境によって異なります。WordPressやフレームワークの自動生成は便利ですが、生成結果を確認せずに使うと、indexさせたくないURLが混ざるリスクがあります。

WordPressの標準サイトマップは、不要な投稿タイプが含まれていないか確認する

WordPress 5.5以降は、プラグインなしで wp-sitemap.xml が自動生成されます。https://あなたのドメイン/wp-sitemap.xml にアクセスすれば確認できます。

ただし、標準サイトマップには次のような不要URLが含まれているケースがあります。

SEOプラグインを使う場合は、noindex設定とサイトマップ除外の連動を確認する

より細かい制御が必要な場合は、SEOプラグインの利用が定番です。

比較表

プラグイン	特徴
Yoast SEO	SEO全般の設定と合わせてサイトマップを自動管理。noindex設定と連動して除外できる
Rank Math	noindex設定と連動。複数の投稿タイプを細かく制御可能
XML Sitemap Generator for Google	サイトマップ生成に特化。除外条件の細かい設定が可能

SEOプラグインを使う場合は、プラグインのnoindex設定とサイトマップ除外が連動しているかを確認してください。連動していないと、noindex設定したページがサイトマップに残り続け、Googleに矛盾した情報を送り続ける状態になります。

静的サイト・フレームワークでは自動生成パッケージを利用する

静的サイトジェネレーターを使っている場合は、フレームワーク側のパッケージで自動生成するのがおすすめです。

比較表

フレームワーク	サイトマップ生成パッケージ
Astro	`@astrojs/sitemap`
Next.js	`next-sitemap`
Nuxt.js	`@nuxtjs/sitemap`
Gatsby	`gatsby-plugin-sitemap`

これらのパッケージは、ビルド時にサイトマップを生成するため、ページの追加・削除に追従します。

自動生成サイトマップは、必ず一度ブラウザで開いて中身を確認する

CMSやプラグインで自動生成された場合でも、生成結果は必ず一度ブラウザで開いて確認してください。「自動生成だから安心」ではなく、生成結果を確認するのが実務の基本です。

確認すべき点は、前章で挙げた「サイトマップに入れるURL・入れないURL」の判断基準と一致します。

XMLサイトマップのよくあるエラーは、読み取れない・URL記述ミス・中身の品質低下に分けられる

Search Consoleでサイトマップを送信した際に表示されるエラーは、大きく3種類に分けて対処できます。

「サイトマップを読み取れませんでした」エラーの主な原因

このエラーが表示された場合、次の原因を順に確認してください。

比較表

主な原因	対処
robots.txtでブロックされている	robots.txtで sitemap.xml へのアクセスを禁止していないか確認
URLの記述ミス	送信したURLにタイプミスがないか、httpsとhttpの違いを確認
サーバーエラー（5xx）	サーバーが正常に応答しているか確認。ブラウザで直接 sitemap.xml にアクセス
ファイルが存在しない	サイトマップファイルが正しいディレクトリにアップロードされているか確認
XML形式が壊れている	XMLバリデータでサイトマップの構文を検証

まずブラウザで https://あなたのドメイン/sitemap.xml に直接アクセスして、XMLが表示されるかを確認するのが最も手早い方法です。

URLの書き方が原因のエラー

サイトマップが読み取れていても、URLの記述に問題があるケースもあります。

サイトマップの中身に問題があるケース

Search Consoleで「成功しました」と表示されても、中身に問題があると分析が難しくなります。

これらは「読み取れる/読み取れない」のエラーとしては表示されませんが、長期的にはGoogleのサイト理解を濁らせる原因になります。サイトマップを定期的に開いて中身を確認する運用が必要です。

AI検索時代でも、まずGoogleが正規URLを理解できる状態を作る

AI Overview、ChatGPT検索、Perplexityなど、生成AIを活用した検索体験が広がっています。これらのAI検索でも、まずGoogleがページを発見し、正規URLを理解し、インデックスできる状態にしておくことが前提です。

サイトマップだけでAI検索に出るわけではない

「サイトマップを送信すればAI検索に引用されやすくなる」という単純な話ではありません。AIに引用されるかどうかは、コンテンツの質・関連性・サイト全体のURL設計など多くの要素が関わります。

サイトマップは、そのURL設計の土台の1つです。AI検索のための特別な施策ではなく、通常のSEOで重要なURLを整理して伝える基本作業を、ていねいに積み上げるという位置づけで考えてください。

正規URL・内部リンク・構造化データと合わせて情報の出どころを整理する

AI検索時代には、ページ単位だけでなく情報の出どころや代表URLの一貫性も重要になります。サイトマップで正規URLを整理することは、canonicalタグや内部リンク、構造化データと合わせて、サイト全体の情報をGoogleが理解しやすくするための土台です。

重複URLや旧URLが散らばっていると、サイト内のどのURLが代表なのかが分かりにくくなり、AI検索以前に通常のインデックス理解が濁ります。サイトマップは、その混乱を減らすための補助ファイルとして機能します。

XMLサイトマップ運用チェックリスト

サイトマップは作って送信したら終わりではありません。次のチェックリストで定期的に運用状態を確認しましょう。

よくある質問

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

直接的なランキング要因ではありません。サイトマップの役割は、GoogleにURLの存在を伝えてクロール・インデックスを促すこと。クロールやインデックスが改善されることで、間接的にSEO効果が得られる仕組みです。

サイトマップに入れたURLは必ずインデックスされますか？

必ずではありません。Google公式でも「サイトマップ内のすべてのURLがクロール・インデックスされることを保証するものではない」と明記されています。インデックスされない場合は、ページ品質・canonical・noindex・内部リンクなども確認しましょう。

noindexページをサイトマップに入れてもいいですか？

避けるべきです。「インデックスさせない」と「インデックス候補として伝える」が矛盾するため、Googleに食い違った情報を送ることになります。SEOプラグインを使っている場合は、noindex設定とサイトマップ除外が連動しているかを確認してください。

リダイレクトURLをサイトマップに入れてもいいですか？

入れないのが基本です。サイトマップには最終URL（リダイレクト先）だけを載せましょう。リダイレクト元を載せ続けると、Googleに古いURLを「まだ見てほしいURL」として伝えることになります。

canonical先ではないURLをサイトマップに入れてもいいですか？

避けるべきです。Googleは通常、検索結果に正規URLを表示するため、サイトマップには正規URLを載せるのが基本です。canonicalタグとサイトマップが食い違うと、Googleに矛盾した情報を送ることになります。

priorityやchangefreqは設定すべきですか？

細かい設定は不要です。Googleは公式ドキュメントで「priorityとchangefreqの値は無視します」と明記しています。設定しても害はありませんが、クロールの優先順位には影響しません。

lastmodは毎日更新したほうがいいですか？

いいえ。実際に重要な変更があったときだけ更新するのが正しい運用です。更新していないのに毎日lastmodを現在時刻に書き換えると、Googleがlastmodを信頼しなくなる可能性があります。

サイトマップは内部リンクの代わりになりますか？

なりません。サイトマップはURLの存在を伝えるためには役立ちますが、内部リンクが持つ「ページ同士の関連性」「サイト内での重要度」「ユーザー導線」などの役割は代替できません。重要ページは、サイトマップに載せるだけでなく、サイト内の関連ページからも自然にリンクされている状態にしましょう。

WordPress標準のサイトマップだけで十分ですか？

多くの場合、十分機能します。ただし、indexさせたくない投稿タイプ・タクソノミー・添付ファイルが含まれていないかは必ず確認してください。細かい除外条件がある場合や、SEO設定と連動させたい場合はYoast SEOやRank Mathなどのプラグインを検討しましょう。

サイトマップはrobots.txtにも書くべきですか？

はい、書くのが基本です。Search Consoleでの送信に加えてrobots.txtにSitemapディレクティブを書いておくと、Googlebotがrobots.txtをクロールしたときにもサイトマップを発見できます。

サイトマップを分割するメリットは何ですか？

50,000URL/50MBの上限対応だけでなく、Search Console上でインデックス問題を切り分けやすくなるメリットがあります。記事・商品・求人・カテゴリなどに分けると、どの領域にクロール・インデックスの問題があるかを領域単位で確認できます。

サイトマップ送信後にインデックスされない場合はどうすればいいですか？

サイトマップではなくページ側に問題があることがほとんどです。ページ品質、noindex、canonical、内部リンク、サーバー応答などを順に確認してください。Google公式でも「サイトマップ送信はインデックスを保証しない」と明記されています。

AI検索時代でもXMLサイトマップは必要ですか？

はい。AI検索時代でも、まずGoogleがページを発見・理解・インデックスできる状態にしておくことが前提です。サイトマップは、Googleに見てほしい正規URLを整理して伝える基本施策として有効です。ただし「サイトマップを送ればAI検索に出やすくなる」という単純な話ではなく、コンテンツの質や全体のURL設計とセットで考えましょう。

HTMLサイトマップはSEOに必要ですか？

HTMLサイトマップの主な目的はユーザビリティの向上です。SEO効果は限定的で、クロール効率を改善したいならXMLサイトマップが重要です。HTMLサイトマップは「あると親切」程度の位置づけと考えてください。

サイトマップ運用は、SEO施策全体の中の1パーツです。優先度を含めたSEO作業の全体像は「SEOチェックリスト」で確認できます。サイトマップが効いてくる前提となるGooglebotのクロール挙動については「クロールバジェットとは？確認方法と最適化のポイント」、自サイトのインデックス数を継続的に追いたい場合は「インデックス数とは？調べ方・増やし方とSEOへの影響」が参考になります。

XMLサイトマップは、作って送るだけでなく正しいURLを載せ続けることが重要

XMLサイトマップは、作成してSearch Consoleに送信すれば終わりではありません。Googleに見てほしい正規URLを整理し、不要なURLを混ぜず、lastmodを正確に保ち、Search Consoleで状態を確認し続けることが重要です。

サイトマップを「作成するもの」ではなく、「Googleに見てほしい正規URLを整理して伝え続けるためのファイル」として捉えると、SEO実務で見るべきポイントが明確になります。

実務で意識すべきポイントを整理すると、次のとおりです。

サイトマップ運用を含む、サイト全体のSEOをこれから自社で立ち上げる方は「インハウスSEOとは？始め方から成果を出すまでの実践ロードマップ」で、最初の3ヶ月の進め方や社内体制の作り方まで体系的に整理しています。