先日、Google Search Console でサイトマップのステータスが「取得できませんでした」になっているのを見つけました。
結論から書くと、何も直しませんでした。そして数時間後、勝手に「成功しました」に変わりました。
※たまたま私が確認したタイミングが良く、数時間と感じただけで、実際には数日後あるいは数週間後なのかもしれません。
ただ、この記事は「放っておけば直りますよ」という話ではありません。
放っておいてよいと判断するまでに、サーバー側を一つずつ潰していく必要がありました。
その切り分けの手順と、どこまで確認できたら手を引いてよいのか、という判断基準の話です。
WordPress を大きく更新した直後だった
背景として、直前にかなり大きな更新をしています。
- WordPress 5.9.16 → 7.1
- PHP 8.2.30 → 8.5.9
長いこと 5.9 系で止まっていたものを一気に最新まで持っていって、そのあと PHP も上げました。
表示崩れがないことは確認済みでしたが、見た目に出ない部分がどうなっているかは別の話です。
この更新作業そのものは、別の記事にシリーズでまとめています。
まずは何がどれだけ古いのかを把握するところから始めました。
そこで検索まわりが機能しているかを点検していたところ、まず記事の表示回数が 0 になっていることに気づきました。それでサイトマップを見に行ったら、こうなっていたわけです。
sitemap.xml（インデックス） → 成功しましたpost-sitemap.xml→ 取得できませんでしたarchives-sitemap.xml→ 取得できませんでした- 他の子サイトマップも同様（4 つほど、すべて「取得できませんでした」）
インデックスを送信すると、その中に並んでいる子サイトマップもサイトマップ一覧に出てきます。私が送信したのは sitemap.xml の 1 本だけですが、そこからたどられた子が全部エラーになっている、という見え方でした。
正直、最初に思ったのは「自分が壊したかな」でした。更新直後というのは、何を見ても更新のせいに見えます。
サイトマップのプラグインが WordPress 7.1 に追いついていないのか、それとも PHP 8.5 で動かなくなったのか。そのあたりを疑いながら調べ始めました。
使っているのは XML Sitemap Generator for Google です。
最初の手がかりは「親は成功、子だけ失敗」
気になったのは、この非対称です。
sitemap.xml はサイトマップインデックスで、中に子サイトマップへのリンクが並んでいます。その親は読めていて、子だけが読めていない。サーバーが丸ごと落ちているとか、ドメイン単位でブロックされているという話ではなさそうです。
なお、この時点で確認しておきたいことがありました。
前提：子サイトマップは個別に送信しなくていい
サーチコンソールに送信するのは、インデックスである sitemap.xml の 1 本だけで十分です。Google が中身をたどって子サイトマップを取得してくれます。
とはいえ、子が全部エラーになっているのを見ると、何かしたくなります。私は試しに post-sitemap.xml を 1 ファイルだけ手動で送信してみました。子を名指しで送れば、そちらは取得されるんじゃないかと思ったわけです。
ただ、これは余計だったかもしれません。インデックス経由ですでに Google に渡っているものを重ねて送信した形になるので、処理の優先度が下がって後回しにされかねない。実際、手動送信したあとも状況は変わりませんでした。
同じことをしてしまった方は、個別送信した分をサイトマップ一覧から削除して、sitemap.xml の 1 本に戻してしまってよいと思います。
ただし、それで話が終わるわけではありません。インデックスに載っている子サイトマップが本当に取得できるのかは、別途確認しないと分かりません。「成功しました」はインデックスファイル自体が読めたという意味でしかないからです。もし子が 404 なら、Google も中身を読めていないことになります。
というわけで、サーバー側を潰していきます。
サーバー側を curl で潰す
ここからが本題です。ブラウザで開いて「見えたから大丈夫」で済ませると見落とすので、curl でヘッダを見ます。以下はすべて Mac 側のターミナルで実行しています。
1. ステータスコードを見る
まず、そもそも 404 になっていないか。
curl -sI "https://blog.rcwas.com/post-sitemap.xml" | head -n 1
curl -sI "https://blog.rcwas.com/archives-sitemap.xml" | head -n 1結果はこうでした。
HTTP/2 200
HTTP/2 200 両方とも 200 です。これで 「ファイルが存在しない」という線が消えました。
ちなみにこの前に、sitemap.xml の中身も確認しています。
curl -s "https://blog.rcwas.com/sitemap.xml" | head -n 30先頭にこういうコメントが入っていました。
<!-- sitemap-generator-url='http://www.arnebrachhold.de' sitemap-generator-version='4.1.24' -->
<!-- generated-on='2026年9月8日 12:01 AM' -->末尾には Request ID やクエリ数まで出力されています。つまりこの XML は静的ファイルではなく、WordPress を通って動的に生成されているということです。古いプラグインが残した化石ファイルが返っている、という可能性もここで消えました。
2. Content-Type とリダイレクトを見る
次に、中身の形式です。
curl -sIL "https://blog.rcwas.com/post-sitemap.xml" | grep -iE "^HTTP|^content-type|^location"HTTP/2 200
content-type: text/xml; charset=utf-8text/xml になっています。ここが text/html だと Google が XML として解釈できず、別のエラーになります。location の行が出ていないので、余計なリダイレクトも挟まっていません。
3. Googlebot の UA で叩く
ここが個人的にいちばん確認したかったところです。自分のブラウザからは見えても、クローラーからは見えていないという状況がありえます。Xserver の WAF や、サーバー側の UA 制限が悪さをしているパターンです。
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "https://blog.rcwas.com/post-sitemap.xml" | head -n 1HTTP/2 200 Googlebot を名乗っても 200 でした。UA による出し分けやブロックはされていません。
4. robots.txt を見る
最後に、そもそもブロックしていないか。
curl -s "https://blog.rcwas.com/robots.txt"User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://blog.rcwas.com/sitemap.xml
Sitemap: https://blog.rcwas.com/sitemap.htmlサイトマップをブロックする記述はありません。
ここでひとつ、副産物として分かったことがあります。WordPress の「設定 → 表示設定 → 検索エンジンがサイトをインデックスしないようにする」にチェックが入っていると、robots.txt に Disallow: / が出力されます。それがないということは、サイト全体を止めている線も消えたということです。地味ですが、これが確認できたのは大きかったです。
（sitemap.html の行については後述します）
200 が返る。ここで考え方を変えた
というわけで、サーバー側は全部シロでした。
- ファイルは存在する（200）
- 形式も正しい（
text/xml） - Googlebot からも取得できる
- robots.txt でもブロックしていない
正直、ここで少し困りました。自分の側では 200 が返っているのに、Google は「取得できませんでした」と言っている。
このとき最初に考えたのは「Google が意図的にインデックスから除外しているのでは」ということでした。次に疑ったのがサーチコンソール側の設定ミスです。プロパティの設定を間違えているとか、送信した URL の書き方が悪いとか。
いま振り返ると、この瞬間が分かれ道でした。ここで「まだサーバー側に原因があるはずだ」と思い込むと、.htaccess をいじったり、プラグインを入れ替えたり、壊れていないものを触り始めてしまいます。更新直後という状況もあって、そちらに引っ張られる誘惑はそれなりにありました。
そうせずに済んだのは、上の 4 つがすべて確定していたからです。疑うべき場所は自分のサーバーではなく、Google 側にある。そう切り替えました。
「公開 URL をテスト」で確定させる
Google 側から実際に取得してもらえば白黒つきます。サーチコンソールの URL 検査ツールに子サイトマップの URL を入れて、「公開 URL をテスト」を実行しました。
結果は「URL は Google に登録できます」。
つまり、Google はいまこの瞬間、その URL を問題なく取得できているわけです。サーバー側が正常であることが、Google 自身の口から確認できました。
調べてみると、実体が取得できるのにサイトマップのステータスが「取得できませんでした」と表示される件は、以前から知られているようです。本来のステータスは「保留中」で、それが表示上エラーとして見えているだけではないか、という報告が複数見つかりました。ライブテストで「ページの取得: 成功」となっているなら保留中と判断してよい、という整理をされている方が何人かいます。
ただし、これは Google の公式ドキュメントに書かれている内容ではありません。私が探した範囲では、公式に「保留中が取得できませんでしたと表示される」と説明しているものは見つけられませんでした。あくまで第三者の検証と、自分の環境で実際にそうなったという 2 つにもとづく話として読んでください。
待ち時間もまちまちのようで、数週間以上かかったという報告もあれば、私のように数時間で切り替わることもあります。ここは運の要素が大きそうです。
なおこのとき、URL 検査の結果が「URL が Google に登録されていません」と出て一瞬ぎょっとしました。ただこれはエラーではありません。URL 検査は「そのページが検索結果に登録されているか」を見る道具なので、XML ファイルが未登録なのはむしろ正常です。サイトマップが検索結果に出てきたら困りますからね。
待つと判断した
そして数時間後、サイトマップ一覧を見ると post-sitemap.xml のステータスは「成功しました」に変わっていました。保留中だった処理が回ってきただけ、ということです。
ここまでで、私が直したものはゼロです。
判断基準としては、次の 5 つが揃ったら手を引いてよいと考えています。
curl -sIでステータスが 200content-typeがtext/xml- Googlebot の UA でも 200
- robots.txt でブロックしていない
- URL 検査の「公開 URL をテスト」で取得成功
この 5 つが通っているなら、サーバー側にできることはもうありません。再送信を繰り返しても処理が早まるわけでもないので、放っておくのが正解です。
トラブル対応で怖いのは、直せないことよりも、壊れていないものを直そうとしてかえって壊すことだと思っています。今回でいえば .htaccess を書き換えたり、動いているプラグインを別のものに入れ替えたりです。そうしていたら、たぶん本当に何かが壊れていました。
かかった時間は 1 時間ほどでした。何も直していないので成果物はありません。ただ、「ここは触らなくていい」と根拠を持って言えるようになったこと自体が結果だと思っています。次に同じ表示を見たときは、5 分で同じ結論に行けるはずです。
ついでに直した robots.txt の 1 行
ひとつだけ、実際に手を入れた箇所があります。さきほどの robots.txt に出てきたこの行です。
Sitemap: https://blog.rcwas.com/sitemap.htmlSitemap: ディレクティブは、サイトマップの場所をクローラーに伝えるためのものです。仕様としては次の 2 つが参照先になります。
読んでみたかぎり、サイトマップの形式として挙げられているのは XML・RSS/Atom フィード・テキストファイルの 3 つで、HTML サイトマップは出てきません。ただし、「HTML を書いてはいけない」と明言されているわけでもありませんでした。
なので仕様違反だと断じるのはやめておきます。私がこの行を消したのは、単純にこのサイトでは HTML サイトマップを使っていないからです。使っていないファイルの場所をクローラーに知らせても意味がないので、不要と判断しました。害があるかどうかは分かりませんが、なくていい行だとは思います。
ちなみに sitemaps.org のほうには、サイトマップインデックスがある場合はそのファイルの場所だけを書けばよく、中の個別サイトマップを列挙する必要はないと書かれています。前半の「子サイトマップは個別に送信しなくていい」という話と同じ考え方ですね。
これは XML Sitemap Generator for Google の設定から出力されていたものです。プラグインの設定で HTML サイトマップの出力を止めたら、この行も消えました。
ここで少し面白かったのが、robots.txt の実体を探しても見つからなかったことです。
WordPress は、robots.txt の実ファイルがなくても動的に生成して返します。「仮想 robots.txt」と呼ばれるものです。今回の内容も、Disallow: /wp-admin/ と Allow: /wp-admin/admin-ajax.php という WordPress 標準の出力に、プラグインが Sitemap: の行を足したものでした。
なので、こういうときはサーバーのファイルを探すのではなく、プラグインの設定を見に行くのが正解です。逆に、ドキュメントルートに robots.txt の実ファイルが置かれている場合はそちらが優先され、仮想 robots.txt は無効になります。設定をいじっても内容が変わらないときは、実ファイルの有無を疑ってみてください。
設定を外したあとの結果がこちらです。
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://blog.rcwas.com/sitemap.xmlsitemap.xml の行は残したままにしています。こちらは正しい使い方なので、あっていいものです。
まとめ
- サイトマップの「取得できませんでした」は、実体が取得できていても表示されることがある
- サーバー側は
curlで 4 点（ステータス / Content-Type / Googlebot UA / robots.txt）を潰せる - そのうえで URL 検査の「公開 URL をテスト」が通れば、あとは待つ
- 更新直後は何でも更新のせいに見えるが、根拠なく触ると本当に壊す
そういえば、そもそもの発端だった「表示回数が 0」のほうですが、これはサイトマップとは無関係でした。単純に読まれていないだけです。インデックスはされていて、検索結果にも出てくる。ただ順位が低くて誰の目にも触れていない、という身も蓋もない話でした。
そちらはそちらで調べていくと別の発見があったので、また別の記事に書こうと思います。
