サイトマップURL自体を確認。
この記事は、Search Consoleへサイトマップを送信した後に「サイトマップを読み込めませんでした」と出る場合だけを切り分ける記事です。送信URLの入力ミスだけでなく、サイトマップ自体が開けない、HTTPエラー、robots.txt、キャッシュ、プラグイン競合などを順番に確認します。送信方法そのものはXMLサイトマップ送信手順、記事単体が検索に出ない場合はインデックス未登録の確認へ分けます。
SEO全体の確認順： サイトマップ以外も含めて何から確認するかはSEO改善ロードマップで整理しています。
- ブラウザでサイトマップURLを直接開く
- 正しいURLを送信しているか確認
- HTTPステータスを確認
- robots.txtや認証でブロックしていないか確認
- サイトマップ生成機能・キャッシュを確認
まずサイトマップURLを直接開く
WordPressでは、環境によってsitemap_index.xmlやwp-sitemap.xmlなどが使われます。Search Consoleへ送ったURLをブラウザで直接開き、XMLが表示されるか確認してください。
404、403、500、ログイン画面、メンテナンス画面などが表示されるなら、Search Console以前にサイトマップURL自体の問題を解決します。
よくある原因
| 原因 | 確認内容 |
|---|---|
| URL入力ミス | https、www、末尾、ファイル名を確認 |
| サイトマップが404 | 生成機能・SEOプラグイン設定を確認 |
| 403や認証 | WAF・Basic認証・アクセス制限を確認 |
| 500系 | PHP・プラグイン・サーバーログを確認 |
| 古いキャッシュ | キャッシュ削除後に再確認 |
Search Consoleへ送るURLを確認する
サイトマップは、相対URLではなく完全なURLで公開されている必要があります。Googleは、サイトマップに記載されたURLをそのままクロールしようとします。
WordPressでYoast SEOなどのSEOプラグインを使っている場合、WordPress標準サイトマップとは別のインデックスが生成されることがあります。実際にブラウザで開ける方を確認してから送信します。
robots.txtを確認する
サイトマップ自体をrobots.txtでブロックする必要は通常ありません。さらに、サイトマップ内の重要ページがrobots.txtでクロール拒否されていないかも確認します。
robots.txtの確認方法は、WordPressのrobots.txt確認方法で詳しく解説しています。
HTTPステータスを見る
ブラウザで開けても、HTTP 200だけでサイトマップ正常とは判断しません。最終URLと内容を確認し、XMLの代わりにログイン画面・HTMLのエラーページ・メンテナンス案内が返っていないか見ます。サイトマップインデックスなら、記載された子サイトマップも開きます。403ならアクセス制限、404なら送信URLと生成元、500系ならサーバーや生成機能を調べ、再送信だけを繰り返しません。
サイトマップ生成機能を確認する
- SEOプラグインのサイトマップ機能が有効か
- 複数のSEOプラグインで重複生成していないか
- パーマリンク変更後に再生成されているか
- キャッシュプラグインがXMLを古い状態で保持していないか
- セキュリティプラグインがGooglebotの取得を妨げていないか
送信済みサイトマップを消して再登録すべき？
URLが誤っている場合は、正しいサイトマップを送信し直します。ただし、原因がサーバーエラーやサイトマップ生成不良なら、登録操作だけ繰り返しても解決しません。まずブラウザから正常取得できる状態にします。
関連する記事
サイトマップの送信方法そのものはSearch ConsoleでXMLサイトマップを送信する方法、検索に記事が出ない場合はGoogleに記事が出てこないときの確認手順もあわせて確認してください。
よくある質問
サイトマップを送れば必ずインデックスされますか？
保証されません。サイトマップはGoogleへURLを知らせる手段の一つであり、クロールやインデックス登録はページ内容やサイト状態など複数の要因で決まります。
sitemap_index.xmlとwp-sitemap.xmlは両方必要？
必須ではありません。現在利用しているSEOプラグインやWordPress構成に合わせ、正しく生成されるサイトマップを使います。
「読み込めませんでした」でも、先に送信し直さない
Search Console側の表示だけを見て再送信を繰り返すと、原因がURLなのかサーバー応答なのか分からなくなります。まずブラウザでサイトマップURLを直接開き、正常に取得できる状態を確認します。
直接取得でき、XML内容と子サイトマップに問題が見当たらない場合は、Search Consoleに送信したURL・プロパティ・最終読み込み日時・表示されたエラーを照合します。手元から取得できることとGoogleが取得できることは別なので、必要に応じてURL検査やサーバーログも確認します。サイトマップが正常でも記事が未登録なら個別URLの確認、本文とcanonicalのURLが違うなら正規ページの確認へ分けます。未確認のログは取得済みとして記録しません。
HTTPステータス別の最初の行動
| 状態 | 最初にすること |
|---|---|
| 200 | XML内容・URL・Search Console側の再確認 |
| 301 / 302 | 移動先の最終URLを確認し、直接取得できるサイトマップURLを送信する |
| 403 | WAF・認証・アクセス制限を確認 |
| 404 | サイトマップ生成機能とURLを確認 |
| 500系 | プラグイン・PHP・サーバーログを確認 |
再送信する？確認結果で選ぶ3つの対応
- 取得エラーの原因を修正した：同じURLが正常に取得できることを確かめて再送信します。
- 「成功」で重要な変更もない：通常の再クロールを待ちます。チェック項目を満たしただけで削除・再登録する必要はありません。
- 手元では開けるのにエラーが続く：サイトマップの詳細画面からURLをコピーし、URL検査の「公開URLをテスト」でクロールの許可とページ取得結果を確認します。
Googleの取得結果と手元の結果が違う場合は、確認日時・対象URL・エラー詳細を記録してサーバー側のアクセス制限やログと照合します。WAF全体を無効にせず、該当ルールと対象URLを調べます。再送信はインデックス登録や順位上昇を保証しません。
公式の再送信・取得エラー確認手順（確認日：2026年10月10日）
直った後に確認する3項目
- 最終読み込み日時が更新されるか
- 検出されたURL数が不自然に0件でないか
- サイトマップ内URLが現在のcanonical・HTTPS・www設定と一致しているか
「成功」に変わっただけで終わらず、送っているURL群が現在のサイト構成と合っているかを確認します。古いURLやリダイレクトURLが大量に残る場合は、サイトマップ生成元を見直します。
過去の確認記録｜2026年10月10日の親XML・子XML
YOHAKU LIVE SITEMAP｜2026-10-10確認
実測例｜親XMLと3本の子サイトマップを確認
2026年10月10日、公開URLへHTTP GETでアクセスし、返されたXMLを解析しました。sitemap_index.xml はHTTP 200で取得でき、次の3本を参照していました。
| 子サイトマップ | HTTP応答 | XML内のURL要素数 |
|---|---|---|
| post-sitemap.xml | 200 | 203件 |
| page-sitemap.xml | 200 | 6件 |
| category-sitemap.xml | 200 | 8件 |
robots.txt もHTTP 200で取得でき、Sitemap: https://zero-web.site/sitemap_index.xml の記載を確認しました。親XMLだけでなく子XMLまで確認することで、途中の取得失敗を切り分けられます。
確認範囲：これは外部からの取得とXML構文・URL要素数の確認です。掲載した各記事URLへの到達性、Googlebotの取得成功、Search Consoleの検出ページ数、インデックス登録数を確認した結果ではありません。数値は確認時点のもので、記事の公開・削除に伴って変わります。
サイトマップが「成功」になっても、すべてのURLが自動で検索表示されるわけではありません。個別記事が出ない場合はインデックス未登録の確認手順へ進み、登録済みならSearch Consoleの表示・クリック・CTR・順位へ切り替えます。
過去の確認記録｜2026年10月20日のページURLと画像URL
実測｜記事URLと画像URLを分けて数える
2026-10-20 13:17（日本時間）に当サイトの投稿サイトマップを外部から取得し、HTTP 200とXMLの解析成功を確認しました。同じXMLでも、数える要素を混ぜると記事数を多く見積もってしまいます。
| 数えた要素 | 確認件数 | 意味 |
|---|---|---|
| url / loc | 205 | 記事204件と記事一覧 /articles/ 1件 |
| image:loc | 204 | 画像URL。記事のページ数へ足さない |
確認に使った投稿XMLのページURLと画像URLは別の名前空間・要素です。全種類のlocを足した409件を「記事409本」とは扱いません。この数値は取得時点のもので、投稿の公開・削除で変わります。
ここでは分からないこと：Googlebotが取得できたか、Search Consoleが処理したか、各記事を登録したかは未確認です。管理画面では送信URL・最終読み込み日時・状態を別に記録します。外部でXMLが開けたことだけで、Google側の取得失敗が解消したとは判断しません。
個別ページの指定先を比べる場合はcanonicalと掲載URLの実測へ、転送がある場合は転送元と転送先の実測へ進みます。Google公式：画像サイトマップ。
再確認の実例｜記事・固定ページ・カテゴリ・画像を分ける
2026年10月23日 21:08（日本時間）に、当サイトの親XML・子XML3本・robots.txtを通常の公開URLから取得しました。すべてHTTP200で、4本のXMLはXMLとして解析できました。これは外部からの取得結果で、Search Consoleの処理成功やGoogleへの登録を確認した結果ではありません。
投稿・固定ページXMLのページURLは、重複を除いて217件でした。WordPressの公開記事・固定ページ一覧で取得した217URLと、URLの文字エンコードをそろえて照合した範囲で一致しました。カテゴリ9件や画像227件は記事数へ加えません。image:locとページのurl / locを分けて数えます。
親XMLは上記3本を参照し、robots.txtには親XMLのSitemap行がありました。以前の記録と件数が違っても、それだけで異常とは判断せず、公開・追加・削除の履歴と照合します。この表の件数は取得時点のもので、自動更新ではありません。
次に確認すること：Search Consoleでは送信URL・詳細エラー・最終読み込み日時を確認します。記事ごとの掲載拒否を調べるなら公開HTMLのnoindex確認とHTTPヘッダーの確認へ進み、登録状況はURL検査で別に確認します。