2026年8月22日

サイトマップ「取得できませんでした」の原因と確認手順｜40日直らなかった実例

Search Consoleのサイトマップ画面に、赤い文字で「取得できませんでした」。最終読み込み日時は、空欄。

私のブログ（WordPressではなく、自作の静的サイト）では、この表示が40日続いた。先に、もう一度やるならこの順で見る、という手順を置く。結果だけ言うと、私が当時やったcurlとURL検査では、問題は見つからなかった。直ったのは、ドメインを移した当日だった。ただ、移したことが原因で直ったのかは、今も証明できていない。

先に結論（急いでいる人向け）

1. Search Consoleの中で見る。 サイトマップの行を開いてエラーの詳細を読む。「セキュリティと手動による対策」に何も出ていないかも見る
2. URL検査に、サイトマップのURLそのものを入れて「公開URLをテスト」を押す。 見るのは「クロールを許可？」が「はい」か、「ページの取得」が「成功」か。「URLはGoogleに登録できます」かどうかは、見なくていい
3. ブラウザでサイトマップのURLを開き、XMLが表示されるかを見る。 ターミナルが使えるなら、curlで200が返るかも見る（コマンドは下に載せた）
4. 全部問題なかったら、「今回の確認では問題が再現しなかった」ところまでが言えること。 原因はまだ分からない。待つか、何か1つ変えるかを決める。私は40日目にドメインを変えた

2026年10月11日更新：確認の目安を、Googleのヘルプの項目に合わせて直しました。 2026年11月7日更新：Googleのヘルプが挙げる原因5つの早見表を足しました。

Googleのヘルプが挙げる原因は5つ

Search Consoleのヘルプ（サイトマップ レポート）は、「取得できませんでした」の原因として次の5つを挙げている（ヘルプ自身、これですべてではないと断っている）。直し方はヘルプの案内に沿い、どこで確かめるかは私が足した。

上の4つは、手順を踏めば自分で確かめられる。5つ目だけは、私が見た範囲では、Search Consoleに判定が出る場所が見当たらなかった。

送信したばかりなら、もう一つ知っておくといい。ヘルプには、サイトマップは送信するとすぐ取得される、取得に失敗しても数日は再試行する、とある。送信した当日に赤い文字が出ても、数日は様子を見ていい。ただしヘルプによると、失敗が続くとGoogleは取得をやめるので、その後は問題を直して送り直す必要がある。

私の40日では、サイトマップのURLは当時のcurlで200が返り、URL検査も「URLはGoogleに登録できます」と出ていた。robots.txtと手動による対策は、当時見た記録が残っていない（下の手順1と3）。5つ目に当たっていた可能性もあるが、確かめる方法は見つけられなかった。

確認する順番

1. Search Consoleの中で、エラーの詳細を読む

サイトマップのレポートで、「取得できませんでした」の行をクリックすると、詳細が開く。まずここに書いてあることを読む。

Googleのヘルプは、「取得できませんでした」の原因として、サイトマップのURLがrobots.txtでブロックされている場合などのほかに、サイトに手動による対策が残っている場合も挙げている。左のメニューの「セキュリティと手動による対策」も一度開いておく。当時の私はこの2つを確認した記録が残っていないので、ここは私がもう一度やるなら見る項目として書いている。

2. URL検査で、サイトマップのURLそのものをテストする

上の検索窓（URL検査）に、記事のURLではなく、サイトマップのURLそのものを入れる。結果が出たら「公開URLをテスト」を押す。

見るのは2か所だ。

• 「クロールを許可？」が「はい」か
• 「ページの取得」が「成功」か

ここで取得に失敗していたら、表示されるエラーが一番の手がかりになる。

注意点がある。テスト結果の一番上に「URLはGoogleに登録できます」と出るかどうかは、サイトマップの場合は見なくていい。サイトマップは検索結果に出すためのページではないので、WordPressのSEOプラグインの中には、サイトマップに「検索結果に出さない」という指定をわざと付けるものがある。その場合、正常でも「登録できません」寄りの表示になる。

当時の私は、この2か所ではなく、一番上の「URLはGoogleに登録できます」を目安にしていた。結果はそう表示されていた。Googleが登録できると判定するには取得できている必要があるので、少なくとも取得はできていたと読める。

3. ブラウザとcurlで、返ってくるものを見る

ブラウザのシークレットウィンドウでサイトマップのURLを開き、XMLが表示されるかを見る。ここまではターミナルなしでできる。

ターミナルが使えるなら、私が実際に叩いたコマンドを置いておく。まず、ステータスとContent-Type。

curl -s -o /dev/null -w "%{http_code} %{content_type}\n" https://example.com/sitemap.xml

200 application/xml が返れば、少なくとも配信の入口は正常だ。ここでtext/htmlが返っていたら、サイトマップではなくエラーページやトップページを返している可能性がある（ブラウザで見ると何か表示されるので気づきにくい）。なお、これで分かるのはステータスと種別だけで、XMLとして正しいかまでは分からない。

次に、Googlebotを名乗って同じことをする。ボット対策で弾かれていないかの確認だ。ただしUser-Agentを変えただけなので、本物のGooglebotが届くことの証明にはならない（本物かどうかは、IPアドレスの逆引きで判定する）。分かるのは「名前だけで弾いてはいない」までだ。

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -o /dev/null -w "%{http_code} %{content_type}\n" https://example.com/sitemap.xml

robots.txtも実物を見る。

curl -s https://example.com/robots.txt

見るのは、Googlebotに当てはまるルールで、サイトマップのURLがブロックされていないか。Disallowに入っていても、同じグループのAllowで許可されていればブロックされない。Sitemap:の行は、Search Consoleで送信するのとは別の知らせ方なので、なくても、送信したURLと違っていても、それだけで異常とは言えない。私は念のため、送信したURLと同じものを書いている。

私の環境では、HTTP/1.1でもHTTP/2でも、IPv4でもIPv6でも200が返った。

結果の読み方

私の環境ではcurlとURL検査に問題がなかったので、以下は「こう出たら、ここを疑う」という対応表だ。実際に踏んだ原因ではない。

どれかに当てはまったなら、直せばたぶん動く。全部問題なかったなら、私と同じような状況にいる。 その場合に言えるのは「今回の確認では問題が再現しなかった」までで、原因は分かっていない。私がその先でやったことが、次の節だ。

curlとURL検査で問題が出なかった私の40日

このブログは、自作のスクリプトでHTMLを作り、Cloudflare Pagesに置いているだけの静的サイトだ。WordPressではなく、プラグインもない。壊れる場所が少ない構成なのに、サイトマップだけが読まれなかった。

8/19のファイル名変更は苦し紛れだ。Search Console側でそのURLの状態が固まっているのでは、と疑って、別のURLとして送り直した。それでも変わらなかった。

その間、サイトマップのレポートで取得の成功は一度も確認できなかった。Googleが認識していたのは4ページだけで、うち3つはトップページ・about・プライバシーポリシー。記事は8本中1本しか載っていなかった。

ドメインを移した理由

当時のブログは◯◯◯.pages.devという、Cloudflareが無料で貸しているサブドメインで動いていた。

ドメインを変えれば直る、と思っていたわけではない。移した理由は3つあった。curlとURL検査で見られる範囲は確認していて、ほかに変えられるものが思いつかなかったこと。ドメインの年齢は時間でしか積めないので、いつか取るなら早いほうがいいと考えたこと。そして、載っているのが4ページ・3ヶ月で検索クリック2回という規模で、移して失うものがほぼなかったこと。.comを1つ、年およそ1,600円で取った。

移したその日に「成功しました」になった

移行作業は30分ほどだった。Cloudflare Pagesに独自ドメインをつなぎ、設定ファイルのサイトのURLを1行書き換えて作り直す。サイトマップやrobots.txtに書かれるURLは、そこから自動で作られる。

新しいドメインでSearch Consoleにプロパティを作り、sitemap-1.xmlを送信した。

送信       2026/08/22
最終読み込み  2026/08/22
ステータス   成功しました

8/22にサイトマップの作り方は何も変えていない。8/19の時点と比べて変わったのは、中に書かれるURLのドメインと、送信先のプロパティだ。

2日後、記事が登録された

サイトマップが読まれることと、記事が検索結果に載ることは別の話だ。

確認したのはトップページと、/posts/domain-doko-de-toru/、/posts/sitemap-shutoku-dekimasen/（この記事）、/posts/ai-agent-ec/、/posts/server-erabi/ の5つだ。

このうち/posts/server-erabi/は、新しいドメインで一度も個別の登録リクエストをしていない。それでも登録されていた。サイトマップから見つけたのか、記事どうしのリンクから見つけたのかまでは分からない。言えるのは、1日1本ずつ登録リクエストを積む作業は、今回は必要なかったということだけだ。

レポートとURL検査で、表示が食い違った

同じ8/24、Search Consoleの「ページのインデックス登録」レポートはこう出ていた。

登録済み: 0
未登録:   5（クロール済み - インデックス未登録）

その「未登録5」に入っていた/posts/ai-agent-ec/を、URL検査（公開URLのテストではない、通常の検査）にかけると、「URLはGoogleに登録されています」と出た。

レポートだけ見ていたら、私は「まだ1本も入っていない」と書いていた。この日は、レポートよりURL検査の表示のほうが先に変わっていた。

それでも、原因は分かっていない

ここで「独自ドメインにしたら直りました」と締めたいところだが、それは言い過ぎになる。

共有のサブドメインだったから読まれなかったのか。古いプロパティ側の登録がどこかで壊れていて、新しいプロパティなら何でも通ったのか。ちょうどそのころに何か別の理由で直ったのか。私の手元のデータでは区別がつかない。

言えるのは事実だけだ。curlとURL検査で問題が見つからないまま40日動かず、ドメインと送信先のプロパティを変えたら当日読まれ、2日後に記事が登録された。

私ならこうする

同じ症状で止まっている人に、私が言えることは1つ。

確認を2周する前に、「このドメインであと何ヶ月粘るか」を決めたほうがいい。

私は対処法の記事にある手を一通りやったが、状況は動かず、そのまま40日が過ぎた。

私自身は、この件でドメインだけは自分のものを持つことにした。年1,600円は、40日の停滞と比べれば小さい。サーバー代を0円で運用する話は別記事に書いたし、その考えは今も変えていない。ドメインはお名前.comのような専業の会社でも取れるし、私はサイトと同じ管理画面にまとめたかったのでCloudflareで取った。

おまけ：移行作業で踏んだ落とし穴2つ

① Search Consoleの「Cloudflareで自動確認」は、DNSへのアクセス権を渡す操作

ドメインの所有権確認で、Googleが「ワンクリックで確認」を勧めてくる。便利だが、あれはGoogleにCloudflareアカウントのDNSへのアクセスを承認するという意味だ。プルダウンを「任意のDNSプロバイダ」に切り替えれば、TXTレコードを自分で貼るだけの手順に変わる。結果は同じで、権限は渡さずに済む。私は後者にした。

② Cloudflare Pagesは、ダイレクトアップロードで作ると後からGit連携にできない

wrangler pages deployで作ったプロジェクトは、あとから「GitHubにpushしたら自動公開」に切り替えられない。公式ドキュメントに明記されている。やるならプロジェクトを作り直して、ドメインを付け替えることになる。

登録されても、読まれるとは限らない

サイトマップが読まれ、記事が登録されても、検索から人が来るとは限らない。

10月11日時点の数字を出しておく。サイト全体で、直近28日の表示は34回、クリックは1回。同じ28日で、19本の記事のうち検索結果に1回でも出たのは9本だった。この記事自体は「サイトマップ 取得できませんでした」で平均20位前後に出ていて、90日の表示は10回、クリックは0回だった。11月6日時点では、直近90日の表示は31回、平均20位前後、クリックは0回だった。

AIエージェントに副業の運用を任せている全体像はこの記事に、その運用に月いくらかかっているかはこちらに書いている。