XMLサイトマップで失敗しやすいのは、XMLの書き方そのものよりも、検索結果に出したくないURLまで自動出力すること、lastmodを毎回のビルド日時で上書きすること、そしてSearch Consoleで「送信済み」と表示された時点で完了と考えることです。本記事では、URL品質と送信後の検証まで含めて整理します。
先に結論
XMLサイトマップは「検索してほしい正規URLの一覧」。順位を上げる設定ファイルではない
サイトマップは、検索エンジンがサイト内のページ、動画、画像、ニュースなどを発見し、関係性や更新情報を理解するための補助情報です。とくに大規模サイト、新規サイト、内部リンクが弱いサイト、画像・動画・ニュースを多く扱うサイトで役立ちます。
一方で、ファイルに載せたURLがすべてクロール・インデックス登録されるわけではありません。200で取得できる、canonicalと一致する、noindexではない、検索結果に出したい公開URLだけを載せ、送信後はSearch ConsoleとURL検査で状態を分けて確認します。
XMLサイトマップが必要なサイト・なくても困りにくいサイト
Googleは、サイト内の重要ページへ内部リンクで到達できれば、多くのURLを通常のクロールで発見できます。したがって、サイトマップはすべてのサイトに絶対必要なものではありません。ただし、自動生成と監視が正しく行えるなら、規模が小さくてもURL構成の点検やSearch Consoleでの切り分けに役立ちます。
発見漏れや更新把握が起きやすいサイト
- 商品、求人、記事、店舗など検索対象URLが多い
- 公開したばかりで外部リンクが少ない
- ページが深い階層にあり、内部リンクが弱い
- 画像、動画、ニュース、複数言語ページが多い
- ECの在庫・公開状態などURLの入れ替わりが多い
重要URLを通常クロールで見つけやすいサイト
- 検索対象が約500ページ以下
- ホームから重要ページへ内部リンクで到達できる
- 画像、動画、ニュース検索向け情報が少ない
- URL追加が少なく、公開状態が安定している
- CMSの誤出力を管理する負担の方が大きい
サイトマップを置く前に内部リンクも確認する
重要ページがサイトマップにしか存在しない状態は、検索エンジンにも利用者にも分かりにくい設計です。カテゴリ、関連記事、パンくず、グローバルナビゲーションなどから重要URLへ到達できるようにし、サイトマップは発見を補助する役割に留めます。
XMLサイトマップの現行仕様と上限
1ファイルのURL数とサイズには上限があります。上限を超える場合は複数ファイルへ分け、サイトマップインデックスから参照します。サイズは圧縮後ではなく、非圧縮時で判定する点に注意してください。
| 項目 | 現行仕様 | 実務での確認 |
|---|---|---|
| 文字コード | UTF-8 | 生成処理とHTTPヘッダーの文字コードが食い違っていないか確認する |
| URL形式 | 完全修飾された絶対URL | /guide/ではなくhttps://example.com/guide/と記載する |
| 掲載URL | 検索結果に表示させたいcanonical URL | http/https、www有無、末尾スラッシュ、大小文字を統一する |
| 設置場所 | サイト内の任意の場所。ルート設置が推奨 | Search Consoleを使わない場合、設置ディレクトリ配下だけが対象になり得る |
| 圧縮 | gzip圧縮に対応 | 上限は非圧縮時50MB。破損したgzipや二重圧縮を避ける |
| サイトマップインデックス | 複数のサイトマップをlocで参照 | 参照先は原則として同一サイト・同じ階層以下。循環参照を作らない |
| 名前空間 | http://www.sitemaps.org/schemas/sitemap/0.9 | URLがhttp表記でも仕様上正しいため、httpsへ書き換えない |
サイトマップに含めるURL・除外するURL
サイトマップは、公開URLを何でも列挙する在庫表ではありません。検索エンジンへ「このURLを正規版として検索結果に出したい」と伝えるシグナルの一つです。canonical、noindex、HTTPステータス、内部リンクと矛盾しないURLだけを選びます。
| URLの状態 | 掲載 | 理由・対応 |
|---|---|---|
| 200で表示できる正規ページ | 含める | 検索結果に出したいcanonical URLを掲載する |
| 301・308リダイレクト | 除外 | 転送元ではなく最終到達先のURLを掲載する |
| 404・410・5xx | 除外 | 削除済みまたは取得不能なURLを生成元から取り除く |
| noindexページ | 除外 | 検索対象外という指示とサイトマップ掲載を矛盾させない |
| 別URLをcanonicalに指定 | 原則除外 | パラメータ、重複、印刷用URLでは正規URLだけを掲載する |
| ログイン・カート・決済・マイページ | 除外 | 公開検索に不要で、利用者ごとに内容が変わるページは載せない |
| サイト内検索・絞り込みURL | 原則除外 | 無数の組み合わせや薄い重複ページを生成しない |
| ページネーション | 設計で判断 | 各ページが独立した価値を持ち、canonicalも自己参照なら掲載を検討する |
| 多言語の正規ページ | 含める | 各言語URLを正規ページとして掲載し、hreflangとの対応も揃える |
| ステージング・開発環境 | 除外 | 本番データへ混入しないよう生成処理と環境変数を分離する |
シグナルを同じ方向へそろえる
検索結果へ出したい正規URLを載せる。
正規URLと検索可否をページ側でも一致させる。
重要URLへリンクし、200で安定して取得できるようにする。
この3つが同じ方向を向いていれば、検索エンジンはURLの意図を理解しやすくなります。サイトマップへ載せた一方でnoindex、別URLへのcanonical、301リダイレクトが設定されている状態は、まず生成元から直します。
XMLサイトマップの作り方を7ステップで整理
数十URLなら手動作成もできますが、継続運用ではCMSやビルド処理から自動生成する方が安全です。重要なのは「誰が生成を所有するか」を一つに決め、手動ファイルとプラグイン出力を競合させないことです。
生成元と責任範囲を確認する
WordPress本体、SEOプラグイン、静的サイト生成器、独自API、サーバー上のバッチのどれがサイトマップを出力しているか確認します。複数の生成元がある場合は一つへ統一します。
検索対象URLの一覧を作る
ルーティング、CMSの公開データ、商品データベースなど、canonical URLを確実に取得できる一次データから候補を作ります。サイト全体をクロールした結果だけに依存すると、孤立URLを見落とすことがあります。
除外条件を先に定義する
下書き、非公開、noindex、リダイレクト、削除済み、重複、パラメータ、認証必須などを機械的に除外できる条件へ落とし込みます。担当者の目視だけにしないことが重要です。
XMLまたはサイトマップインデックスを生成する
UTF-8、絶対URL、正しい名前空間で出力します。URL数や非圧縮サイズが増える場合は、種類や言語単位で分割し、インデックスから参照します。
lastmodを確かな更新元から設定する
本文や商品情報の更新日時など、意味のある変更日を使用します。デプロイ時刻、キャッシュ再生成、フッターの年表記だけで全URLの日付を更新しないようにします。
公開URLとXMLを検証する
サイトマップ自体がHTTPSで200を返すか、XMLとして解析できるか、掲載URLが200・canonical一致・index可能かをサンプルだけでなく自動テストでも確認します。
送信し、結果と変更履歴を記録する
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.xmlSitemap:行は複数記載できます。サイトマップのURLは絶対URLで書き、http/httpsやwww有無がSearch Consoleの対象プロパティと一致しているか確認します。
lastmod・changefreq・priorityの正しい扱い
lastmodは、Googleが既知URLのクロール時期を判断するシグナルとして利用する場合があります。ただし、現実と継続的に一致していることが前提です。日付だけを新しく見せる運用は、情報の信頼性を下げます。
重要な内容が変わった
本文の追加・修正、商品仕様や価格の変更、構造化データの更新、主要リンクの見直しなど、ページの中心的内容が変わった日を設定します。
軽微な共通部分だけが変わった
フッターの年、ナビゲーションの小変更、CSS調整、広告枠、キャッシュ再生成など、本文の意味が変わらない変更では日付を動かしません。
正確な日付を取得できない
カテゴリやホームのように多数の情報を集約し、重要な更新日を決めにくいページはlastmodを無理に出力しなくて構いません。
changefreqとpriorityはGoogle向けには不要
Googleはchangefreqとpriorityを使用していません。項目を埋めることに時間を使うよりも、正規URLの選別、正確なlastmod、内部リンク、HTTP応答、Search Consoleでの監視を優先してください。他の検索エンジンや社内システムが必要とする場合は、その仕様を別途確認します。
lastmodを動かす変更・動かさない変更の例
サイトマップ内のlastmodはファイルを生成した日時ではなく、対象ページの重要な変更日時です。次は編集運用の判断例です。
| 変更 | 扱いの例 |
|---|---|
| 料金・対応機能・導入手順を改訂 | 内容を検証して本文の更新日とlastmodを合わせる。 |
| ページの重要な構造化データやリンクを修正 | 読者と検索に影響する変更かを確認し、重要な変更ならlastmodへ反映する。 |
| 全ページ共通の著作権年を変更 | 個々の記事が実質更新されたとは扱わない。 |
| 再ビルド・確認のみで本文変更なし | 既存のlastmodを維持し、必要なら確認日を別途記録する。 |
作業日が不明な過去記事へ、推測の日付を埋めないでください。信頼できる更新日を出せない場合は任意のlastmodを省略できます。サイトマップの取得成功と各URLの登録結果は別に確認します。
WordPress・静的サイト・ECでの生成方法
サイトマップの正解は、サイトの技術構成と公開フローで変わります。共通する原則は、公開状態とcanonical URLを把握している仕組みから生成し、同じURLを複数の生成元で管理しないことです。
本体またはSEOプラグインのどちらかへ統一
WordPress 5.5以降の公開サイトでは、コア機能が通常/wp-sitemap.xmlを提供します。SEOプラグインが/sitemap_index.xmlなどを生成する場合は、検索対象、除外設定、lastmodの扱いを比較し、主に使う生成元を一つへ決めます。
- 添付ファイル、著者、タグ、カスタム投稿タイプを載せる必要があるか
- 非公開・noindex・リダイレクトURLが混ざっていないか
- キャッシュやセキュリティ設定がXML取得を妨げていないか
ルート定義やコンテンツ台帳からビルド時に生成
公開対象のルート一覧、Markdownのfront matter、CMS APIの公開データなどを入力にし、canonical URLと更新日を生成します。サイトを外側からクロールして作るより、非公開ページや孤立ページを制御しやすくなります。
- 本番ドメインを環境変数で固定し、localhostやプレビューURLを混ぜない
- lastmodへビルド時刻ではなくコンテンツ更新日を渡す
- CIでURL数、XML構文、重複、HTTP応答を検査する
公開状態の変化をデータベースと同期
販売終了、在庫切れ、募集終了、物件成約などの扱いを先に決めます。一時的に非表示なのか恒久削除なのかで、サイトマップからの除外、HTTPステータス、リダイレクトの方針が変わります。
- 商品・カテゴリ・記事など種類ごとに分割する
- 削除済みURLを古いキャッシュから再出力しない
- 日次差分で件数が急増・急減したら通知する
各言語の正規URLとhreflangを同じ台帳で管理
日本語、英語、中国語など各言語ページをそれぞれ正規URLとして掲載します。hreflangをXMLへ記述する場合は、同じURLグループの全言語版と自己参照をそろえ、HTML側の指定と矛盾しないようにします。
- 翻訳未公開URLを先行して載せない
- 言語ごとのcanonicalを別言語へ向けない
- 言語・地域コードとURL設計を統一する
Google Search ConsoleへXMLサイトマップを送信する手順
Googleへサイトマップを知らせる代表的な方法は、Search Consoleで送信する方法と、robots.txtへ場所を書く方法です。運用状況を確認したい場合は両方を使い、URLを同じものへそろえます。
公開URLを直接開く
https://example.com/sitemap.xmlまたはサイトマップインデックスをブラウザやcurlで開き、ログインなしで200を返すことを確認します。
正しいSearch Consoleプロパティを選ぶ
http/https、www有無、サブドメインを確認します。URLプレフィックスプロパティでは、別のURLバージョンへ送信すると対象が一致しません。
「サイトマップ」レポートから送信する
サイトマップまたはインデックスのパスを入力して送信します。大規模サイトで複数ファイルを管理する場合は、通常はインデックスを送信します。
最終読み込み・ステータス・検出URLを確認する
「成功」だけでなく、最終読み込み日時、検出されたページ数、子サイトマップのエラーを確認します。検出URL数はインデックス登録数ではありません。
robots.txtにも同じURLを記載する
Search Console以外の発見経路としてSitemap:行を追加します。複数ある場合は複数行で記載できます。
Search Consoleへ送る意味
robots.txtだけでもGoogleがサイトマップを発見する場合がありますが、Search Consoleのサイトマップレポートには、レポートまたはAPIから送信したものだけが表示されます。エラー率や最終読み込みを追跡したい場合は、Search Consoleでも送信します。
送信後は「取得・URL品質・インデックス」を3段階で検証する
サイトマップの確認を一つの合否にまとめると、原因を切り分けにくくなります。ファイルが読めるか、掲載URLが正しいか、ページがインデックス対象になっているかを別々に確認します。
HTTPS、HTTP 200、XML応答、robots.txt、認証、CDN・WAF、gzipを確認します。
絶対URL、重複、canonical、noindex、リダイレクト、404、更新日を確認します。
ページのインデックス登録レポートとURL検査で、除外理由や選択canonicalを確認します。
サーバー側で行う基本確認
# ヘッダーとステータスを確認
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.xmlContent-Typeはサーバー実装によってapplication/xmlやtext/xmlなどになります。最重要なのは、検索エンジンがログインなしで取得でき、HTMLのエラーページではなく整形式XMLを受け取れることです。
URLを全件またはサンプル検査する
- すべてのlocがhttpsから始まる絶対URL
- http、www有無、末尾スラッシュがcanonicalと一致
- URLの重複と大小文字違いがない
- 200以外の応答を掲載していない
- noindex、認証、robotsブロックがない
- 別URLをcanonicalに指定していない
- lastmodが未来日や生成時刻になっていない
- URL数と非圧縮サイズが上限以内
Search Consoleと公式仕様の画面で確認するポイント
管理画面の文言や配置は更新されることがあります。スクリーンショットを操作手順の唯一の根拠にせず、対象サイトの現在のレスポンスと公式ドキュメントを併せて確認してください。
「取得できませんでした」などXMLサイトマップのエラー対処
Search Consoleの上位レポートで「取得できませんでした」と表示される場合は、Googleがファイル自体を取得できていません。一方、「サイトマップにエラーがあります」は、ファイルを取得できたものの、一部のURLやXML要素を正しく処理できなかった状態です。まず取得と解析を分けて確認します。
| 症状 | 主な原因 | 確認・対処 |
|---|---|---|
| 取得できませんでした | robots.txtによるブロック、404、サーバー停止、WAF・CDN、手動による対策、低いクロール需要など | URLを直接開き、URL検査のライブテストで「クロール許可」「ページ取得」を確認。原因修正後に再送信する |
| 404 Not Found | 送信URLの入力間違い、生成機能停止、パーマリンク・ルーティング変更 | Search Consoleへ登録した正確なURLを開き、生成元とrewrite設定を確認する |
| 403・認証画面 | Basic認証、IP制限、Bot対策、セキュリティプラグイン | サイトマップだけでなく掲載URLもGooglebotが取得できるか確認し、必要な許可ルールを設定する |
| 5xx・タイムアウト | 動的生成が重い、DB障害、キャッシュ切れ、巨大ファイル | 静的キャッシュ、分割、生成処理の非同期化を検討し、サーバーログでGooglebotの応答を確認する |
| HTMLが表示される | 404ページへの内部転送、ログインページ、キャッシュ誤設定、アプリのフォールバック | Content-Typeだけでなく本文先頭を確認し、XMLルートをアプリのcatch-allより優先する |
| XMLを読み取れない | 閉じタグ不足、不正文字、エスケープ漏れ、BOM・文字コード問題 | XMLバリデータまたはxmllintで解析し、URL内の&などを正しくエスケープする |
| URLが許可されていない | 別ドメイン、http/https違い、www違い、サイトマップより上位・隣接ディレクトリ | 絶対URLと配置階層を確認。必要ならルートへ置くか、Search Consoleでクロスサイト送信の条件を満たす |
| URLをたどれない | 相対URL、リダイレクト連鎖、JavaScriptやmeta refreshによる転送 | 最終的なcanonical URLを絶対URLで直接掲載する |
| ファイルサイズ・URL数超過 | 50MBまたは50,000URLを超えている | ページ種類・言語・更新頻度などで分割し、サイトマップインデックスから参照する |
| 日付形式エラー | W3C Datetime外の形式、タイムゾーン不備、未来日 | YYYY-MM-DDまたはタイムゾーン付き日時を使用し、元データを修正する |
| 検出URLが急減した | 公開フラグ・フィルタ条件の変更、生成処理失敗、子サイトマップ欠落 | 前回ファイルとの差分、URL件数、生成ログ、インデックス内の参照先を確認する |
| 成功だが登録されない | 重複、品質不足、クロール済み未登録、noindex、ソフト404、canonical選択の違い | ページのインデックス登録レポートとURL検査で個別理由を確認し、サイトマップ以外の原因を直す |
エラー修正の順番
同じURLを外部から取得する
管理者としてログインしたブラウザだけでなく、シークレットウィンドウ、curl、外部監視から確認します。認証Cookieで見えているだけの状態を避けます。
サーバーログとSearch Consoleの詳細を照合する
Googlebotのアクセス時刻、ステータス、応答時間、CDN・WAFの拒否記録を確認し、画面の表示だけで推測しません。
XML構文と掲載URLを分けて直す
ファイル自体が読めない問題を先に解決し、その後でリダイレクト、noindex、canonical不一致など個別URLの問題を整理します。
修正後に再送信し、数日間監視する
Googleは取得失敗後もしばらく再試行しますが、失敗が続くと停止します。原因を直したら新しいリクエストとして送信し、最終読み込みとエラーを記録します。
画像・動画・ニュース・多言語サイトの拡張サイトマップ
通常のURL情報に、画像、動画、ニュース、hreflangの名前空間を追加できます。一つのURLへ複数の拡張を組み合わせることも可能ですが、ファイルサイズが増えるため、対象コンテンツと運用目的が明確な場合だけ採用します。
画像URLの発見を補助
JavaScriptで読み込む画像やCDN上の画像など、通常クロールで見つけにくい画像を補足できます。現在の必須情報を公式仕様で確認し、廃止済みタグを残さないようにします。
動画のメタデータを伝える
サムネイル、タイトル、説明、再生ページなどを追加します。動画がページの主要コンテンツであるか、Googlebotが動画とサムネイルを取得できるかも確認します。
公開後2日以内の記事を管理
ニュースサイトマップには原則として直近2日間の記事だけを含め、1ファイル最大1,000件のnews要素に収めます。通常のWeb検索用URLは別の通常サイトマップで継続管理できます。
多言語・地域別URLを対応付け
各URLの言語版をxhtml:linkで記述できます。HTML内の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数の急増・急減を監視
- ページのインデックス登録を別レポートで確認
- 変更前ファイルと切り戻し手順を保存
XMLサイトマップに関するよくある質問
XMLサイトマップを送信すれば、すべてのページがGoogleに登録されますか？
いいえ。サイトマップはURLの発見やクロールを助けるヒントであり、クロール、インデックス登録、検索順位を保証しません。ページ品質、canonical、noindex、内部リンク、重複なども別に確認します。
小規模サイトにもXMLサイトマップは必要ですか？
重要ページがホームから内部リンクでたどれ、検索対象が約500ページ以下で、画像・動画・ニュースを多く扱わないサイトでは必須とは限りません。ただしCMSが正しく自動生成できるなら、URL構成の点検やSearch Consoleでの監視に利用できます。
lastmodは毎日更新した方がSEOに有利ですか？
いいえ。本文、構造化データ、主要リンクなどに重要な変更があった日だけを正確に記録します。毎日またはデプロイのたびに全URLの日付を変えると、lastmodの信頼性を損ないます。確かな日付を出せないページは省略して構いません。
changefreqやpriorityは設定した方がよいですか？
Googleはchangefreqとpriorityを使用していません。Google向けには、正規URLの選別、正確なlastmod、内部リンク、取得可能性、Search Consoleでの検証を優先します。
robots.txtにSitemap行を書けばSearch Consoleへの送信は不要ですか？
Googleへ場所を知らせるだけならrobots.txtでも可能です。ただしSearch Consoleへ送信すると、最終読み込み、ステータス、検出URL、解析エラーを確認できるため、運用では両方を使う方法が分かりやすいです。
sitemap.xmlとsitemap_index.xmlの違いは何ですか？
sitemap.xmlはページURLを直接列挙するファイルです。sitemap_index.xmlは複数のサイトマップをまとめる索引で、URL数やファイルサイズが上限を超えるサイト、記事・商品・言語などで分割したいサイトに使います。
noindexページをXMLサイトマップに含めても問題ありませんか？
検索結果に出したいURLを示すサイトマップとnoindexが矛盾するため、原則として除外します。リダイレクト、404、重複URL、ログイン必須ページも同様です。
Search Consoleからサイトマップを削除するとURLも検索結果から消えますか？
いいえ。レポートから送信情報を削除しても、Googleがすでに把握したURLやインデックス登録は自動的に削除されません。URLを非公開にする場合は、HTTPステータス、noindex、削除ツールなど目的に合う方法を別に検討します。
XMLサイトマップは「作成」よりもURL品質と検証までが重要
XMLサイトマップは、検索結果に出したい正規URLを検索エンジンへ伝え、発見とクロールを助ける仕組みです。50,000URL・非圧縮50MBの上限を守り、200で取得できるcanonical URLだけを掲載します。lastmodは実際の重要な更新日へ合わせ、changefreqとpriority、廃止済みping送信へ時間を使う必要はありません。
公開後は、ファイル取得、XML解析、URL品質、Search Consoleの読み込み、ページのインデックス登録を分けて確認します。この流れをCMSやCI、運用手順へ組み込めば、サイト規模や担当者が変わっても、再現可能な状態で管理できます。
根拠として確認した公式資料 / 以下は本記事の基礎説明の参考資料です。主要項目の再確認日は2026年9月16日。確認対象と参照先は末尾の補足に記載しています。過去の撮影日・測定日は各資料の説明を参照してください。 / 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連携 /
