WordPressのサイトマップが「成功」なのに表示回数0。XMLを確認する手順

2026.09.05

Search Consoleのサイトマップ欄には「成功」と出ている。それでも記事が検索結果に出ない。この状態で同じサイトマップを送り直しても、原因は切り分けられません。

「成功」で確認できるのは、Googleがサイトマップファイルを取得して処理できたことです。ファイル内のURLがすべてクロールされ、インデックスに登録されたという判定ではありません。Googleも、サイトマップの送信はヒントであり、ダウンロードやクロールを保証しないとサイトマップの公式ガイドで説明しています。

先に、検索に出したいURLが現在のXMLに入っているかを確かめます。Search Consoleの集計と公開サイトでは更新時刻がずれるため、同じ時点の結果だと思い込まないことも大切です。

「成功」で分かる範囲

Search Consoleのサイトマップレポートを開いたら、ステータスに加えて最終読み込み日時と検出されたページ数を見ます。最終読み込みが記事の公開日より前なら、その画面だけでは新しいURLを確認できません。

検出されたページ数は全体を見る手がかりになります。ただし、数が増えたかどうかだけでは特定の記事が含まれるか分かりません。対象URLは、公開中のXMLで完全一致を確認します。

WordPress 5.5以降では、コアのサイトマップインデックスが通常/wp-sitemap.xmlにあります。WordPress Coreの案内にも、このパスが記載されています。SEOプラグインなどが無効化または置換している場合もあるので、Search Consoleへ送ったURLと、現在200で開けるXMLを照合します。

公開中のXMLで対象URLを探す

ブラウザでサイトマップインデックスを開き、投稿用の子サイトマップへ進みます。子サイトマップ名はサイトによって変わるため、最初から決めつけず、インデックス内のlocを確認してください。

コマンドで見る場合は次の形です。example.comは、自分が管理する公開ドメインへ置き換えます。ログイン情報や管理画面URLは付けません。

set -o pipefail

curl --fail --show-error --silent --location \
  --connect-timeout 10 --max-time 20 \
  'https://example.com/wp-sitemap.xml' |
grep -oE '<loc>[^<]+</loc>'

--failはHTTPエラーを正常扱いせず、--show-errorは失敗理由を表示します。--locationでリダイレクトをたどり、通信が止まった場合はタイムアウトします。pipefailも付けると、curlが失敗したのにgrepだけ成功したように見える事故を防げます。

表示された投稿用の子サイトマップを指定し、確認したい公開URLを完全一致で探します。

set -o pipefail

curl --fail --show-error --silent --location \
  --connect-timeout 10 --max-time 20 \
  'https://example.com/wp-sitemap-posts-post-1.xml' |
grep -oE '<loc>[^<]+</loc>' |
grep -Fx '<loc>https://example.com/example-post/</loc>'

何も出なかったときは、curlとgrepのエラーを先に確認します。取得失敗を「URLなし」と数えてはいけません。末尾のスラッシュやURLエンコードが違っても単純な文字列検索は一致しないため、ブラウザで表示したURLも見比べます。

XMLと公開ページを分けて確認する

XMLにURLがあっても、公開ページの応答は別です。最終HTTPステータスと、リダイレクト後のURLを確認します。

curl --fail --show-error --silent --location \
  --connect-timeout 10 --max-time 20 \
  --output /dev/null \
  --write-out '%{http_code} %{url_effective}\n' \
  'https://example.com/example-post/'

最終ステータスが200で、想定した公開URLが表示されれば、現在のページは取得できます。301や302を経由した場合は、最後に表示されたURLを確認対象にします。403、404、5xx、タイムアウトでは、サイトマップを再送する前に公開ページの取得問題を直します。

公開34記事を照合した結果

2026年9月8日に、このサイトで公開中の34記事をサイトマップと機械照合しました。公開URLのHTTP応答、canonical、robots.txt、HTMLとHTTPヘッダーのnoindexも同じ母集団で確認しています。

サイトマップ掲載：34件中34件
確認時点の公開記事はすべてXMLにありました。Googleが34件すべてをクロール、登録したという結果ではありません。
最終HTTP 200：34件中34件
各公開URLは正常な応答を返しました。検索需要や順位はこの数値から分かりません。
self-canonical：34件中34件
公開HTMLは別URLを正規版として指定していませんでした。Googleが選んだ正規URLはURL検査で確認します。
robots.txtでGooglebot取得可：34件中34件
robots.txtによる公開記事のクロール阻止は確認されませんでした。実際のクロール日時は別の情報です。
noindex：HTML 0件、HTTPヘッダー0件
確認時点の公開ページはnoindexを返していませんでした。Googleが以前取得した状態までは分かりません。
Search Consoleの記事別データ：対象URLの行なし
2026年8月9日から9月5日の28日間では、トップページ以外の記事行を取得できませんでした。記事ごとの測定値がないため、各記事の表示回数を0と確定していません。

公開サイト側で今回確認したHTTP応答、サイトマップ、self-canonical、robots.txt、HTML・HTTPのnoindexには、34記事共通の障害は見つかりませんでした。公開34記事のうち13件は9月4日から6日に公開され、インデックス登録レポート画面の最終更新日は9月4日でした。この時間差があるため、現在値と過去集計だけでサイトマップ失敗とは判断できません。

結果から次の作業を選ぶ

サイトマップを取得できない
送信URLの入力、認証、HTTPステータス、XMLの構文を確認します。ログアウト状態で取得できるまでは、検索表示の評価へ進みません。
サイトマップは開くが、対象URLがない
投稿の公開状態、投稿用の子サイトマップ、プラグインの投稿タイプ除外を確認します。Search Consoleへ別のサイトマップURLを送っていないかも見直します。
XMLにはあるが、公開URLが200を返さない
最終URLと公開状態を直します。意図したリダイレクトなら、転送後のURLを以後の確認対象にします。
XML掲載、HTTP 200、self-canonical、クロール許可、noindexなし
同じサイトマップの再送は繰り返しません。Googleがいつ何を取得したかは、URL検査で取得日時と登録状態を確認する手順へ進みます。
公開ページにnoindexがある
WordPress記事のnoindexをHTMLとHTTPで確認する手順を使い、どこから指示が出ているか切り分けます。
Search Consoleの更新日が公開日や修正日より古い
過去の取得結果と現在の公開状態を分けて、次の更新を待ちます。古い取得結果を見ながら同じ記事を続けて改稿すると、変更前後を比べられません。
登録済みだが記事ページの表示データがない
関連ページから読者が進める道があるか、内部リンク元を選ぶ順番で確認します。検索需要や本文の答えもサイトマップとは分けて見ます。
十分な表示があり、クリックされていない
検索語、タイトル、説明文と本文の約束を見比べます。数回の表示だけで良し悪しは決めません。

対象URLをXMLで探し、公開ページの200を確かめる。ここまで通ったら、同じサイトマップを再送せずURL検査へ進みます。公開から検索表示までの確認順は、検索表示がないときに行った確認の一覧から続けられます。

コメント

タイトルとURLをコピーしました