XMLサイトマップとは？作り方・送信・エラー対処

XMLサイトマップが必要なサイト・なくても困りにくいサイト

Googleは、サイト内の重要ページへ内部リンクで到達できれば、多くのURLを通常のクロールで発見できます。したがって、サイトマップはすべてのサイトに絶対必要なものではありません。ただし、自動生成と監視が正しく行えるなら、規模が小さくてもURL構成の点検やSearch Consoleでの切り分けに役立ちます。

サイトマップを置く前に内部リンクも確認する

重要ページがサイトマップにしか存在しない状態は、検索エンジンにも利用者にも分かりにくい設計です。カテゴリ、関連記事、パンくず、グローバルナビゲーションなどから重要URLへ到達できるようにし、サイトマップは発見を補助する役割に留めます。

XMLサイトマップの現行仕様と上限

1ファイルのURL数とサイズには上限があります。上限を超える場合は複数ファイルへ分け、サイトマップインデックスから参照します。サイズは圧縮後ではなく、非圧縮時で判定する点に注意してください。

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

サイトマップは、公開URLを何でも列挙する在庫表ではありません。検索エンジンへ「このURLを正規版として検索結果に出したい」と伝えるシグナルの一つです。canonical、noindex、HTTPステータス、内部リンクと矛盾しないURLだけを選びます。

シグナルを同じ方向へそろえる

この3つが同じ方向を向いていれば、検索エンジンはURLの意図を理解しやすくなります。サイトマップへ載せた一方でnoindex、別URLへのcanonical、301リダイレクトが設定されている状態は、まず生成元から直します。

XMLサイトマップの作り方を7ステップで整理

数十URLなら手動作成もできますが、継続運用ではCMSやビルド処理から自動生成する方が安全です。重要なのは「誰が生成を所有するか」を一つに決め、手動ファイルとプラグイン出力を競合させないことです。

1. 生成元と責任範囲を確認する

   WordPress本体、SEOプラグイン、静的サイト生成器、独自API、サーバー上のバッチのどれがサイトマップを出力しているか確認します。複数の生成元がある場合は一つへ統一します。

2. 検索対象URLの一覧を作る

   ルーティング、CMSの公開データ、商品データベースなど、canonical URLを確実に取得できる一次データから候補を作ります。サイト全体をクロールした結果だけに依存すると、孤立URLを見落とすことがあります。

3. 除外条件を先に定義する

   下書き、非公開、noindex、リダイレクト、削除済み、重複、パラメータ、認証必須などを機械的に除外できる条件へ落とし込みます。担当者の目視だけにしないことが重要です。

4. XMLまたはサイトマップインデックスを生成する

   UTF-8、絶対URL、正しい名前空間で出力します。URL数や非圧縮サイズが増える場合は、種類や言語単位で分割し、インデックスから参照します。

5. lastmodを確かな更新元から設定する

   本文や商品情報の更新日時など、意味のある変更日を使用します。デプロイ時刻、キャッシュ再生成、フッターの年表記だけで全URLの日付を更新しないようにします。

6. 公開URLとXMLを検証する

   サイトマップ自体がHTTPSで200を返すか、XMLとして解析できるか、掲載URLが200・canonical一致・index可能かをサンプルだけでなく自動テストでも確認します。

7. 送信し、結果と変更履歴を記録する

   robots.txtとSearch Consoleで場所を案内し、送信日、最終読み込み、検出URL数、エラー、生成バージョンを記録します。変更前のファイルと切り戻し方法も残します。

XML・サイトマップインデックス・robots.txtの記述例

基本形はシンプルです。XML内のURLに&が含まれる場合は&へエスケープし、相対URLではなく完全なURLを記述します。

基本的なsitemap.xml

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/</loc>
    <lastmod>2026-07-29</lastmod>
  </url>
  <url>
    <loc>https://www.example.com/guide/</loc>
    <lastmod>2026-07-20T14:30:00+09:00</lastmod>
  </url>
</urlset>

lastmodは省略可能です。ページの実際の重要な更新日を取得できない場合は、曖昧な日付を出すより省略します。

複数ファイルをまとめるsitemap index

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemaps/pages.xml.gz</loc>
    <lastmod>2026-07-29</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/articles.xml.gz</loc>
    <lastmod>2026-07-28</lastmod>
  </sitemap>
</sitemapindex>

インデックス側のlastmodは、参照するサイトマップファイル自体の更新日時です。各ページの更新日ではありません。

robots.txtから場所を案内する

User-agent: *
Disallow:

Sitemap: https://www.example.com/sitemap-index.xml

Sitemap:行は複数記載できます。サイトマップのURLは絶対URLで書き、http/httpsやwww有無がSearch Consoleの対象プロパティと一致しているか確認します。

lastmod・changefreq・priorityの正しい扱い

lastmodは、Googleが既知URLのクロール時期を判断するシグナルとして利用する場合があります。ただし、現実と継続的に一致していることが前提です。日付だけを新しく見せる運用は、情報の信頼性を下げます。

changefreqとpriorityはGoogle向けには不要

Googleはchangefreqとpriorityを使用していません。項目を埋めることに時間を使うよりも、正規URLの選別、正確なlastmod、内部リンク、HTTP応答、Search Consoleでの監視を優先してください。他の検索エンジンや社内システムが必要とする場合は、その仕様を別途確認します。

WordPress・静的サイト・ECでの生成方法

サイトマップの正解は、サイトの技術構成と公開フローで変わります。共通する原則は、公開状態とcanonical URLを把握している仕組みから生成し、同じURLを複数の生成元で管理しないことです。

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

Googleへサイトマップを知らせる代表的な方法は、Search Consoleで送信する方法と、robots.txtへ場所を書く方法です。運用状況を確認したい場合は両方を使い、URLを同じものへそろえます。

1. 公開URLを直接開く

   https://example.com/sitemap.xmlまたはサイトマップインデックスをブラウザやcurlで開き、ログインなしで200を返すことを確認します。

2. 正しいSearch Consoleプロパティを選ぶ

   http/https、www有無、サブドメインを確認します。URLプレフィックスプロパティでは、別のURLバージョンへ送信すると対象が一致しません。

3. 「サイトマップ」レポートから送信する

   サイトマップまたはインデックスのパスを入力して送信します。大規模サイトで複数ファイルを管理する場合は、通常はインデックスを送信します。

4. 最終読み込み・ステータス・検出URLを確認する

   「成功」だけでなく、最終読み込み日時、検出されたページ数、子サイトマップのエラーを確認します。検出URL数はインデックス登録数ではありません。

5. robots.txtにも同じURLを記載する

   Search Console以外の発見経路としてSitemap:行を追加します。複数ある場合は複数行で記載できます。

Search Consoleへ送る意味

robots.txtだけでもGoogleがサイトマップを発見する場合がありますが、Search Consoleのサイトマップレポートには、レポートまたはAPIから送信したものだけが表示されます。エラー率や最終読み込みを追跡したい場合は、Search Consoleでも送信します。

送信後は「取得・URL品質・インデックス」を3段階で検証する

サイトマップの確認を一つの合否にまとめると、原因を切り分けにくくなります。ファイルが読めるか、掲載URLが正しいか、ページがインデックス対象になっているかを別々に確認します。

サーバー側で行う基本確認

# ヘッダーとステータスを確認
curl -I https://www.example.com/sitemap.xml

# XMLとして解析できるか確認（xmllintがある環境）
curl -fsSL https://www.example.com/sitemap.xml | xmllint --noout -

# リダイレクトを含む最終応答を確認
curl -IL https://www.example.com/sitemap.xml

Content-Typeはサーバー実装によってapplication/xmlやtext/xmlなどになります。最重要なのは、検索エンジンがログインなしで取得でき、HTMLのエラーページではなく整形式XMLを受け取れることです。

URLを全件またはサンプル検査する

• すべてのlocがhttpsから始まる絶対URL
• http、www有無、末尾スラッシュがcanonicalと一致
• URLの重複と大小文字違いがない
• 200以外の応答を掲載していない
• noindex、認証、robotsブロックがない
• 別URLをcanonicalに指定していない
• lastmodが未来日や生成時刻になっていない
• URL数と非圧縮サイズが上限以内

Search Consoleと公式仕様の画面で確認するポイント

管理画面の文言や配置は更新されることがあります。スクリーンショットを操作手順の唯一の根拠にせず、対象サイトの現在のレスポンスと公式ドキュメントを併せて確認してください。

Search Consoleの確認画面画像を取得できない環境でも、本文の手順に沿って「ステータス」「最終読み込み」「検出URL」「エラー詳細」を確認できます。

Google公式仕様の確認画面ファイル上限、設置範囲、絶対URL、canonical、lastmodなどはCMS独自の説明ではなく公式仕様を優先して確認します。

「取得できませんでした」などXMLサイトマップのエラー対処

Search Consoleの上位レポートで「取得できませんでした」と表示される場合は、Googleがファイル自体を取得できていません。一方、「サイトマップにエラーがあります」は、ファイルを取得できたものの、一部のURLやXML要素を正しく処理できなかった状態です。まず取得と解析を分けて確認します。

エラー修正の順番

1. 同じURLを外部から取得する

   管理者としてログインしたブラウザだけでなく、シークレットウィンドウ、curl、外部監視から確認します。認証Cookieで見えているだけの状態を避けます。

2. サーバーログとSearch Consoleの詳細を照合する

   Googlebotのアクセス時刻、ステータス、応答時間、CDN・WAFの拒否記録を確認し、画面の表示だけで推測しません。

3. XML構文と掲載URLを分けて直す

   ファイル自体が読めない問題を先に解決し、その後でリダイレクト、noindex、canonical不一致など個別URLの問題を整理します。

4. 修正後に再送信し、数日間監視する

   Googleは取得失敗後もしばらく再試行しますが、失敗が続くと停止します。原因を直したら新しいリクエストとして送信し、最終読み込みとエラーを記録します。

画像・動画・ニュース・多言語サイトの拡張サイトマップ

通常のURL情報に、画像、動画、ニュース、hreflangの名前空間を追加できます。一つのURLへ複数の拡張を組み合わせることも可能ですが、ファイルサイズが増えるため、対象コンテンツと運用目的が明確な場合だけ採用します。

公開前・更新後に使えるXMLサイトマップ確認チェックリスト

サイトマップは一度作って終わりではありません。CMS更新、URL変更、ドメイン移行、多言語追加、大量削除などのタイミングで再検証します。次の項目を公開手順やCIへ組み込むと、人的な見落としを減らせます。

ファイルと生成処理

• 生成元が一つに決まり、重複出力していない
• UTF-8の整形式XMLとして解析できる
• HTTPSの公開URLが200を返す
• 認証、robots.txt、WAFで取得を妨げていない
• URL数50,000、非圧縮50MB以内
• 上限超過時はインデックスで分割している
• gzipファイルを正常に展開できる
• 本番以外のドメインが混入していない

掲載URLの品質

• locは完全な絶対URL
• canonicalとhttp/https、www、末尾スラッシュが一致
• 200以外のURLを含めていない
• noindexや認証必須URLを含めていない
• サイト内検索、カート、パラメータ重複を除外
• 削除・統合済みURLが再出力されていない
• 重要URLへ内部リンクでも到達できる
• 多言語URLとhreflangの組が一致している

更新日と送信後の監視

• lastmodが重要な実更新日を表している
• ビルド時刻で全URLを更新していない
• 確かな日付がないURLはlastmodを省略
• robots.txtとSearch ConsoleのURLが同一
• Search Consoleの最終読み込みを記録
• 検出URL数の急増・急減を監視
• ページのインデックス登録を別レポートで確認
• 変更前ファイルと切り戻し手順を保存

根拠として確認した公式資料

仕様は検索エンジンやCMSの更新で変わる可能性があります。以下の一次資料を基準にし、2026年7月29日に内容を確認しました。

• Google Search Central｜サイトマップについて学ぶ役割、必要なサイト、約500ページ以下の目安、クロール・登録を保証しない点
• Google Search Central｜サイトマップの作成と送信50,000URL・50MB、UTF-8、絶対URL、canonical、生成・送信方法
• Google Search Central｜サイトマップインデックス大規模サイトの分割、50,000 loc、Search Consoleでの送信上限
• Google Search Console ヘルプ｜サイトマップレポート成功・取得失敗・解析エラー、再試行、検出URL、トラブルシューティング
• Google Search Central Blog｜ping廃止とlastmodpingエンドポイントの廃止、正確なlastmod、changefreq・priorityの扱い
• Google Search Central｜サイトマップ拡張の組み合わせ画像・動画・ニュース・hreflangの名前空間と複合利用
• Google Search Central｜画像サイトマップ画像URLと廃止済みタグの現行仕様
• Google Search Central｜ニュースサイトマップ直近2日、1ファイル1,000件、必須要素
• WordPress Developer Resources｜WP_SitemapsWordPressコアのサイトマップ機能、ルーティング、robots.txt連携

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

XMLサイトマップは「作成」よりもURL品質と検証までが重要

XMLサイトマップは、検索結果に出したい正規URLを検索エンジンへ伝え、発見とクロールを助ける仕組みです。50,000URL・非圧縮50MBの上限を守り、200で取得できるcanonical URLだけを掲載します。lastmodは実際の重要な更新日へ合わせ、changefreqとpriority、廃止済みping送信へ時間を使う必要はありません。

公開後は、ファイル取得、XML解析、URL品質、Search Consoleの読み込み、ページのインデックス登録を分けて確認します。この流れをCMSやCI、運用手順へ組み込めば、サイト規模や担当者が変わっても、再現可能な状態で管理できます。