サイトマップは、サイトの構造を検索エンジンとユーザーに伝える基本的な仕組みです。SEOの教科書には必ず登場し、実装も難しくないにもかかわらず、「なんとなく設置している」「2種類あるのを知らなかった」という運用が驚くほど多いのも事実です。

本記事では、XMLサイトマップとHTMLサイトマップの違いから、必要性の判定基準、作り方・書き方の網羅的な解説、設置・送信の手順までを一気通貫で整理します。さらに、SEGOで実施した1,075サイト・累計1,800件の診断データから、サイトマップ周辺のクローラビリティ実装の実態も独自データとして公開します。

結論を先に述べると、サイトマップは「設置すれば終わり」の施策ではなく、canonical・robots.txt・内部リンク構造といったクローラビリティ施策とセットで設計してこそ効果が出るものです。本記事を最後まで読めば、サイトマップを単独施策ではなく「クローラビリティ全体の一部」として扱える視点が手に入ります。

サイトマップとは？2種類の役割の違い

サイトマップとは、Webサイト内に存在するページの一覧を構造化して伝える仕組みのことです。日本のSEO実務では「サイトマップ」と一括りに呼ばれがちですが、実際には目的も対象読者も異なる2種類のサイトマップが存在します。

この2つを混同したまま運用しているサイトは少なくありません。まず両者の違いを正しく理解することが、サイトマップ設計の出発点です。

XMLサイトマップ：検索エンジン向け

XMLサイトマップは、検索エンジンのクローラーに対して「このサイトにはどんなURLがあり、いつ更新されたか」を伝えるための機械可読なファイルです。sitemap.xml というファイル名でルートディレクトリに配置するのが慣例で、Google Search Consoleから送信することで、Googleにサイトの全URLを効率的に伝えることができます。

XMLサイトマップの効果は、クローラビリティ（クロール効率）の向上とインデックス漏れの防止です。特にページ数が多いサイト、内部リンクが弱いページを抱えるサイト、新規立ち上げで外部リンクがまだ少ないサイトでは、XMLサイトマップなしでは発見されないページが出てくる可能性があります。

HTMLサイトマップ：ユーザー向け

HTMLサイトマップは、サイト訪問者がサイト内の全体構造を把握するためのページです。グローバルナビゲーションだけでは辿れない深い階層のページを一覧化したり、カテゴリ別に整理したりすることで、ユーザーの回遊性を高めます。

HTMLサイトマップ自体には直接的なSEO効果は期待できませんが、サイト内のすべてのページに少なくとも1本の内部リンクが張られる状態を確保するという意味で、間接的にクローラビリティへ貢献します。

サイトマップのSEO効果と必要性の判定

「サイトマップは絶対に必要」という主張をよく見かけますが、Google公式ドキュメントでは「必要なケース」と「不要なケース」が明確に分かれていると説明されています。サイト規模や運用フェーズによって判断するのが正しい姿勢です。

XMLサイトマップが必要なケース

以下のいずれかに当てはまるサイトでは、XMLサイトマップの設置が強く推奨されます。

サイト規模が大きい（数百ページ以上）：内部リンクだけでは全ページを発見しきれない可能性がある
新規立ち上げサイト：外部リンクがまだ少なく、クローラーがサイトを発見する手がかりが弱い
内部リンクが弱いページがある：サイト内の他ページからのリンクが少ない孤立ページが存在する
更新頻度が高い：ニュースサイト・ブログメディアなど、新規ページが頻繁に追加される
リッチコンテンツが多い：画像・動画・ニュースコンテンツなど、専用サイトマップで通知すべき要素がある

必須ではないケース

逆に、以下の条件を全て満たすサイトでは、XMLサイトマップなしでも問題なくクロール・インデックスされます。

サイト規模が小さい（500ページ以下程度の目安）
サイト内の全ページが内部リンクで適切に繋がっている
外部リンクが十分に存在する
更新頻度が安定している

ただし、上記の「必須ではないケース」に該当しても、XMLサイトマップを設置するデメリットは基本的にありません。設置コストが低く、運用負荷もほとんどないため、実務的には「迷ったら設置する」が無難な判断です。

XMLサイトマップの作り方（4つの方法）

XMLサイトマップを生成する方法は大きく4つに分かれます。サイトの規模・技術スタック・運用フェーズに応じて選択します。

方法A：CMSプラグインで自動生成

WordPressやMovable Typeなど、メジャーCMSを利用している場合は、SEOプラグインによる自動生成が最も簡単です。WordPressなら「Yoast SEO」「Rank Math」「All in One SEO」などが代表的で、インストール後の初期設定でXMLサイトマップが自動生成・自動更新される状態になります。

新規ページの追加・既存ページの更新が自動でサイトマップに反映されるため、運用の手間がかからないのが最大の利点です。

方法B：フレームワークの機能で動的生成

Next.js・Nuxt.js・Astroなどのモダンフレームワークを使った自社開発サイトでは、フレームワーク標準のサイトマップ生成機能が利用できます。たとえばNext.jsのApp Routerでは、app/sitemap.ts というファイルを設置することで、ビルド時または動的にサイトマップを生成可能です。

// Next.js App Router の例：app/sitemap.ts
import { MetadataRoute } from 'next';

export default function sitemap(): MetadataRoute.Sitemap {
  return [
    {
      url: 'https://example.com',
      lastModified: new Date(),
      changeFrequency: 'weekly',
      priority: 1.0,
    },
    {
      url: 'https://example.com/blog',
      lastModified: new Date(),
      changeFrequency: 'daily',
      priority: 0.8,
    },
  ];
}

動的生成にすれば、CMSやデータベースから取得した記事一覧を都度サイトマップに反映できます。中規模以上のメディアサイトや、頻繁にコンテンツが追加されるサービスサイトに適した方法です。

方法C：オンラインツールで一括生成

CMSもフレームワークも使っていない静的サイトの場合は、オンラインのサイトマップ生成ツールが手軽です。「XML-Sitemaps.com」などが代表的で、サイトのURLを入力するだけでクロール結果を元にサイトマップが生成されます。

ただし、ツールが取得したタイミングのスナップショットなので、ページが追加・更新されるたびに再生成・アップロードが必要になります。更新頻度が低いサイトにのみ向いた方法です。

方法D：手書きで作成

ページ数が10〜20程度の小規模サイトや、特定のページだけをサイトマップに含めたい場合は、手書きでXMLファイルを作成する方法もあります。テキストエディタで記述し、ルートディレクトリにアップロードするだけです。

選定マトリクス：規模×技術スタック別の推奨

4つの方法の使い分けは、以下の基準で判断します。

サイト構成	推奨される作り方
WordPress / 主要CMS	方法A（プラグイン自動生成）
Next.js / Nuxt.js / Astro 等	方法B（フレームワーク機能で動的生成）
静的HTMLサイト（数十ページ規模）	方法C（オンラインツール）
小規模・特殊用途（10ページ前後）	方法D（手書き）

XMLサイトマップの書き方（記述ルール完全網羅）

自動生成に頼る場合でも、生成されたXMLの中身を理解しておくことは重要です。プラグインの設定ミスや動的生成のバグでサイトマップが壊れているケースが少なくないからです。

必須要素

XMLサイトマップは、以下の3要素で構成される最小構造を持ちます。

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

<urlset>：サイトマップ全体のルート要素。xmlns 属性で名前空間を指定
<url>：個別URLの定義。1ページにつき1つ
<loc>：ページの絶対URL。プロトコル（https://）から記述

オプション要素（lastmod / changefreq / priority）

必須ではないが追加できる要素として、lastmod（最終更新日）changefreq（更新頻度）priority（優先度）があります。

<url>
  <loc>https://example.com/blog/article-1</loc>
  <lastmod>2026-05-08</lastmod>
  <changefreq>weekly</changefreq>
  <priority>0.8</priority>
</url>

ここで重要なのは、2026年現在、Googleは changefreq と priority をほぼ無視しているということです。Google公式ドキュメントでも「これらの値は参考情報として扱われる」と明言されています。実務的には lastmod のみを正確に管理すれば十分で、changefreq と priority は省略しても問題ありません。

ただし lastmod は依然として重要なシグナルです。実際のページ更新日と一致していない（毎回現在時刻を入れるなど）場合、Googleがその値の信頼性を評価して、最終的に無視されるようになります。嘘の lastmod を入れるくらいなら、書かない方がマシというのが原則です。

50,000URL / 50MBの上限とサイトマップインデックス

XMLサイトマップには、Google・Bingが共通で定めている2つの上限があります。

1ファイルあたり最大50,000URL
1ファイルあたり最大50MB（非圧縮時）

この上限を超える場合は、複数のサイトマップに分割し、それらを束ねる「サイトマップインデックスファイル」を作成します。

<?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-05-08</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-05-08</lastmod>
  </sitemap>
</sitemapindex>

大規模ECサイトやニュースメディアでは、コンテンツ種別ごとにサイトマップを分けてインデックスにまとめる運用が一般的です。

特殊サイトマップ（画像・動画・ニュース）

通常のXMLサイトマップに加え、特定のコンテンツ種別に特化した拡張サイトマップも存在します。

種類	用途	推奨されるサイト
画像サイトマップ	画像のURL・タイトル・キャプションを伝達	画像主体のメディア・ECサイト
動画サイトマップ	動画のサムネイル・再生時間・カテゴリを伝達	動画コンテンツを多数掲載するサイト
ニュースサイトマップ	Google Newsへの素早い掲載を促進	Google Newsパートナーのニュースサイト

これらの特殊サイトマップは、必要なケースが限定的です。一般的なコーポレートサイトやブログメディアでは、通常のXMLサイトマップだけで十分です。

HTMLサイトマップの作り方

HTMLサイトマップは、ユーザーがサイト全体を俯瞰できるページとして設計します。XMLサイトマップと違って厳密なフォーマットは存在しないため、サイト構造に合わせて柔軟に設計できます。

構造設計の3原則

HTMLサイトマップを設計する際は、以下の3原則を意識します。

カテゴリ階層を反映する：トップ→大カテゴリ→中カテゴリ→個別ページの階層をそのままインデント表現
全ての公開ページを網羅する：noindex設定のページを除き、原則として全ページを掲載
定期的に更新する：手書きの場合、ページ追加時の更新漏れに注意

大規模サイトでの設計パターン

ページ数が数千を超える大規模サイトでは、HTMLサイトマップを単一ページに収めるのは現実的ではありません。以下のような分割設計が有効です。

カテゴリ別サブサイトマップ：大カテゴリごとにサイトマップページを分け、トップサイトマップから誘導
動的生成：CMSやフレームワーク機能で、コンテンツの追加・削除に応じて自動更新
絞り込みUI：検索フィールドやフィルター機能で目的のページに辿り着きやすくする

サイトマップの設置と送信

XMLサイトマップを作成したら、検索エンジンに認識してもらうための「設置」と「送信」を行います。

設置場所：ルート配置の原則

XMLサイトマップは、原則としてドメインのルートディレクトリに配置します。

https://example.com/sitemap.xml  ← 推奨
https://example.com/blog/sitemap.xml  ← /blog配下のみが対象になる

サブディレクトリに配置することも可能ですが、その場合はそのサブディレクトリ配下のURLしか含められないという制約があります。サイト全体を対象にしたい場合は、必ずルートに配置します。

robots.txtへの記述

XMLサイトマップの場所をクローラーに伝える方法として、robots.txt に Sitemap: ディレクティブを記述する方法があります。

User-agent: *
Allow: /

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

この記述により、Google Search Consoleから明示的に送信していなくても、クローラーがrobots.txt経由でサイトマップを発見できるようになります。robots.txtの書き方の詳細はrobots.txtの書き方と注意点を解説した記事で詳しく扱っています。

Google Search Consoleでの送信

Google Search Consoleから直接サイトマップを送信することで、Googleにより明示的に通知できます。手順は以下の通りです。

Google Search Consoleにログインし、対象プロパティを選択
左サイドメニューから「サイトマップ」を選択
「新しいサイトマップの追加」欄にサイトマップのURLを入力（例：sitemap.xml）
「送信」をクリック

送信後、数時間〜数日でステータスが「成功しました」に変わり、検出されたURL数が表示されます。エラーが出た場合は、XMLの構文エラー・URLの記述ミス・robots.txtでブロックされているURLが含まれているなどの可能性を確認します。

インデックス状況の確認

送信後は、Search Consoleの「ページのインデックス登録」レポートから、サイトマップ経由で発見されたURLのうち、実際にインデックスされているURLの割合を確認します。送信URL数とインデックス数に大きな乖離がある場合、コンテンツの品質・重複・noindex設定などに問題がある可能性があります。

SEGO診断1,800件から見る「サイトマップ単独最適化の限界」

ここまでサイトマップの作り方・書き方を網羅的に解説してきましたが、実務では「サイトマップだけ完璧にしても効果が出ない」という状況がしばしば発生します。サイトマップは単独施策ではなく、canonical・robots.txt・内部リンクといった「クローラビリティ施策群」の一部として機能するものだからです。

SEGOで実施した1,075サイト・累計1,800件の診断データから、クローラビリティ関連項目の不合格率を集計したところ、興味深い実態が見えました。

データから読み取れる3つの事実

事実1：クローラビリティ系施策は全体的に「実装の浸透度が高い」

不合格率トップの canonical でも18.3%、最低の meta_robots は0.7%。日本のサイトのおよそ8〜9割では、クローラビリティの基本群がきちんと実装されているという結果です。これは、ある意味では当然の結果でもあります。クローラビリティは技術SEOの基礎中の基礎であり、CMS・フレームワーク・主要SEOプラグインがほぼ自動で対応してくれる領域だからです。

事実2：canonicalの18.3%という数字が示す「サイトマップとセットで考えるべき項目」

1,800件中329件で canonical タグが正しく設定されていません。canonicalはサイトマップと並ぶ「正規URLをクローラーに伝える」施策で、両者は実質的にセットで機能します。サイトマップで「このURLをクロールしてほしい」と伝えても、canonicalで別URLを正規としていれば、サイトマップで指定したURLはインデックスから外れる挙動になります。

サイトマップだけ完璧にしても、canonicalがズレていれば意図したURLはインデックスされません。これがクローラビリティ施策を単体ではなく群として捉えるべき理由です。

事実3：問題はクローラビリティ層の外にある

SEGOでは、クローラビリティ以外の領域、特にAI検索対応領域の項目で大きな不合格率が観測されています。たとえばアンサーファースト構造（answer_first）は不合格率95%超、FAQ構造化データは90%超といった水準です（参考：日本サイトのAI検索対応ギャップ）。

つまり「サイトマップやcanonicalで時間をかけるよりも、AI検索対応のような新しい層に投資すべき」というのが、1,800件のデータから示唆される実務上の優先順位です。

サイトマップ周辺で意識すべき3つのチェックポイント

サイトマップを設置・運用する際は、以下の3点をセットで確認することで、施策の効果が大きく変わります。

canonicalタグとの整合性：サイトマップに含めるURLとcanonicalで指定する正規URLが一致しているか
robots.txtでのブロック有無：サイトマップに含めるURLがrobots.txtでDisallowされていないか（robots.txtの正しい書き方を参照）
noindex設定との整合性：サイトマップに含めるURLが個別ページのmeta robotsでnoindex指定されていないか

これらの不整合は、サイトマップだけ眺めていても発見できません。SEGOのような診断ツールを使ってサイト全体のクローラビリティを横断的にチェックすることで、初めて気づける問題です。

サイトマップに関するよくある質問

Q1. サイトマップを設置すれば必ずインデックスされますか？

いいえ、サイトマップはあくまで「クローラーに発見してほしいURLを伝える」ものであり、Googleがそれらを必ずインデックスすることを保証するものではありません。インデックスされるかどうかはコンテンツの品質・重複の有無・サイトの権威性など複数の要因で決まります。サイトマップに登録したURLの一部だけがインデックスされるのは正常な挙動です。

Q2. サイトマップに含めないほうがいいページはありますか？

はい、以下のページは含めるべきではありません。noindex設定したページ、canonical で他URLを正規指定しているページ、404を返すページ、robots.txtでDisallowされているページです。これらをサイトマップに含めるとSearch Consoleでエラー扱いとなり、サイト全体のクロール評価に悪影響を与える可能性があります。

Q3. priority と changefreq は今でも書く意味がありますか？

2026年現在、Googleは priority と changefreq をほぼ無視しているため、書く実益はあまりありません。lastmod は依然として有効なシグナルなので、こちらだけは正確に管理することを推奨します。Bingなど他の検索エンジンでは参照されている可能性があるため、自動生成されている分には削除する必要もありません。

Q4. XMLサイトマップとHTMLサイトマップ、どちらを優先すべきですか？

SEO観点ではXMLサイトマップが優先です。HTMLサイトマップは間接的な貢献にとどまるため、まずXMLサイトマップを正しく設置・送信することを優先してください。HTMLサイトマップは「ユーザーの回遊性向上」という別目的で、サイト規模が大きくなってから検討するので十分です。

Q5. サイトマップを更新したらGoogleに再送信する必要はありますか？

基本的には不要です。一度Search Consoleに送信したサイトマップは、Googleが定期的にクロールして再取得するため、URLの追加・削除があった際に自動で反映されます。明示的に再送信したい場合は、Search Consoleのサイトマップ画面から該当サイトマップを削除し、再度送信することで強制的に最新状態を読み込ませることができます。

まとめ

本記事では、サイトマップの2種類の役割から、必要性の判定、作り方・書き方の網羅的な解説、設置・送信の手順、そしてSEGO診断1,800件のデータから見たクローラビリティ実装の実態までを整理しました。

サイトマップは「設置すれば終わり」の単独施策ではありません。canonicalタグ・robots.txt・内部リンク構造といったクローラビリティ施策群の一員として、整合性を持って設計してこそ効果が出るものです。SEGOのデータが示すように、クローラビリティ系の不合格率は概ね10%前後で、ほとんどのサイトでは大きな問題はありません。むしろ伸び代があるのは、AI検索対応のような新しい層です。

自社サイトのクローラビリティ実装が適切か、サイトマップ・canonical・robots.txt・内部リンクが整合しているかを横断的にチェックしたい場合は、SEGOの無料診断をご利用ください。1,800件以上の診断データに基づくベンチマークと比較しながら、サイトの現状を30秒で把握できます。

SEGOで無料診断を試す

サイトマップの作り方とSEO効果！XML/HTMLの違いと診断1,800件で見えた実態