2026年8月22日
Search Consoleのサイトマップが1ヶ月半「取得できませんでした」だった。XMLもrobots.txtも正常だったのに
送信日 2026/07/13。最終読み込み日時は、空欄。
Search Consoleのサイトマップ画面に、赤い文字で「取得できませんでした」と出たまま、8月19日まで残り続けた。1ヶ月半、Googleはこのファイルを一度も読んでいない。
その間にブログの記事は7本から8本に増えたが、Googleが認識していたのは4ページだけだった。しかもその4ページのうち3つはトップページ・about・プライバシーポリシーで、記事は8本中1本しか載っていなかった。3ヶ月間の検索クリック数は、合計2回。
「サイトマップ 取得できませんでした」で検索すると、対処法の記事はいくらでも出てくる。XMLの形式を確認する、robots.txtを見る、URLに?1を付けて再送信する、古い登録を削除してから入れ直す、1週間待つ。私はこれを全部やった。全部空振りだった。
この記事は、そのチェックリストを全部クリアしていたのに直らなかった側の記録だ。最後に効いた（ように見える）一手も書くが、まだ結果は出ていない。そこも含めて正直に書く。
何が起きていたか
構成はシンプルだ。静的サイトジェネレータ（自作のbuild.js）でHTMLを吐いて、Cloudflare Pagesに置いているだけ。動的な処理はゼロ、プラグインもゼロ、認証もゼロ。壊れる余地が少ない構成なのに、サイトマップだけが読まれなかった。
やったことを時系列で並べる。
| 日付 | やったこと | 結果 |
|---|---|---|
| 7/13 | sitemap.xmlを送信 |
取得できませんでした |
| 8/09 | 同じURLで再送信 | 変わらず |
| 8/13 | 古い登録を削除 → 入れ直し | 変わらず |
| 8/19 | ファイル名をsitemap-1.xmlに変えて登録し直し |
変わらず |
最後のは苦し紛れだ。「Search Console側でそのURLの状態が固着しているのでは」と疑って、別のURLとして認識させようとした。それでも「取得できませんでした」のまま、最終読み込み日時は空欄だった。
「配信側の問題ではない」と切り分ける手順
ここが、この記事でいちばん役に立つ部分だと思う。
対処法の記事はどれも「XMLを確認しましょう」「robots.txtを見ましょう」と書いてあるが、確認して正常だったときに、それをどう確定させるかが書かれていない。私が実際に叩いたコマンドを置いておく。
まず、ステータスとContent-Type。
curl -s -o /dev/null -w "%{http_code} %{content_type}\n" https://example.com/sitemap.xml
200 application/xml が返れば、少なくとも配信の入口は正常だ。ここでtext/htmlが返っていたら、404ページを返している可能性がある（これはよくある落とし穴で、ブラウザで見ると中身が表示されるので気づきにくい）。なお、これで確認できるのはステータスと種別だけで、XMLとして妥当かまでは分からない。
次に、Googlebotを名乗って同じことをする。ボット対策で弾かれていないかの確認だ。ただしUser-Agentを変えただけなので、本物のGooglebotが到達できることの証明にはならない（本物の判定はIPの逆引きで行う）。分かるのは「UA文字列だけで弾いてはいない」までだ。
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
Allow: /とSitemap:の行があり、そのSitemap行のURLが実際に送信したURLと一字一句同じかを目で確認する。私はファイル名を変えたときに、ここがずれていないかを毎回見た。
そして決定的なのが、Search ConsoleのURL検査に、サイトマップのURL自体を入れることだ。ページではなくXMLファイルを検査する。ここで「公開URLをテスト」を押して**「URLはGoogleに登録できます」と出たら、Googleは自分のインフラからそのファイルを取得できている**。つまり、配信側もネットワークも、Googlebotのアクセス権も、すべてシロだと確定する。
私の場合、ここまで全部クリアだった。HTTP/1.1でもHTTP/2でも、IPv4でもIPv6でも200が返った。疑うべき場所が、なくなった。
残っていたのはドメインだけだった
ここまで潰すと、変えられる変数がひとつしか残らない。ドメインだ。
このブログは◯◯◯.pages.devという、Cloudflareが無料で貸してくれるサブドメインで動かしていた。無料で、SSLも勝手に付いて、何の不満もなかった。ただこれは何百万ものサイトが同居している共有ドメインで、サイトの住所としては借家の表札に近い。
正直に書くと、この時点で私は「ドメインを変えれば直る」と思っていたわけではない。Googleは公式には、独自ドメインとサブドメインを同等に扱うと言っている。順位が上がる保証もない。
それでも移した理由は3つある。
- 他に変えられる変数がなかった
- ドメイン年齢は時間しか買えないので、いつか取るなら早いほど得
- 失うものがほぼなかった——インデックス4ページ、3ヶ月でクリック2回。この規模で引っ越しコストを気にするのは、引っ越し先の家賃を計算する前に段ボール代を悩むようなものだ
.comを1つ、年およそ1,600円で取った。1ヶ月半の停滞に対する投資としては安い。
移したその日に「成功しました」になった
移行作業そのものは30分ほどだった。Cloudflare Pagesにカスタムドメインを接続し、site.config.jsonのurlを1行書き換えてビルドし直す。canonical・サイトマップ・robots.txt・OGPのURLが全部そこから生成される作りにしてあったので、変更は本当に1行だった。
新しいドメインでSearch Consoleにプロパティを作り、sitemap-1.xmlを送信した。結果はこうだ。
送信 2026/08/22
最終読み込み 2026/08/22
ステータス 成功しました
1ヶ月半どうやっても読まれなかったファイルが、住所を変えたその日に読まれた。 ファイルの中身は1行も変えていない。変えたのはドメインだけだ。
ただし、まだ何も解決していない
ここで「独自ドメインにしたら直りました！」と締めたいところだが、それは嘘になる。
サイトマップが読まれたことと、記事が検索結果に載ることは別の話だ。 今の新ドメインのインデックス数はゼロで、これから11個のURLが順に評価される。ドメイン年齢もゼロ、被リンクもほぼゼロからのスタートで、短期的にはむしろ以前より悪くなる。載るかどうかは、これから数週間見ないとわからない。
因果も、実は証明できていない。「共有ドメインだから読まれなかった」のか、「旧プロパティ側の登録が壊れていて、新規プロパティなら何でも通った」のかは、私の手元のデータでは区別がつかない。前者だと言い切っている記事を見かけたら、その人も証明はできていないはずだ。
言えるのは事実だけ——チェックリストを全部クリアしても1ヶ月半動かず、ドメインを変えたら当日動いた。
私ならこうする
同じ症状で止まっている人に、私が言えることはひとつ。
チェックリストを2周する前に、「このドメインであと何ヶ月粘るか」を決めたほうがいい。
XMLもrobots.txtもContent-Typeも、1周確認すれば十分だ。上のcurlを5回叩けば、配信側がシロかクロかは10分で確定する。シロだと確定したなら、そこを何度も見直しても時間が減るだけで、状況は1ミリも動かない。私は1ヶ月半を溶かした。
そして、無料の共有サブドメインで本気の検索流入を狙うのは、たぶん筋が悪い。 年1,600円は、1ヶ月半の停滞と比べれば誤差だ。サーバー代を0円で運用する話は別記事に書いたし、その考えは今も変えていないが、ドメインだけは自分のものを持つ——これは今回の授業料で学んだ。ドメインはお名前.comのような専業レジストラでも取れるし、私はサイトと同じ管理画面にまとめたかったのでCloudflareで取った。すでに1つはお名前.comで持っているので、使い分けている形になる。
ついでに踏んだ落とし穴2つ
移行作業中に見つけたもので、たぶん他ではあまり書かれていない。
① Search Consoleの「Cloudflareで自動確認」は、DNSアカウントへのアクセス権を渡す操作
ドメインの所有権確認で、GoogleがDNSプロバイダを自動判別して「ワンクリックで確認」を勧めてくる。便利だが、あれはGoogleにCloudflareアカウントのDNSへのアクセスを承認するという意味だ。プルダウンを「任意のDNSプロバイダ」に切り替えれば、TXTレコードを自分で貼るだけの手順に変わる。結果は同じで、権限は渡さずに済む。私は後者にした。
② Cloudflare Pagesは、ダイレクトアップロードで作ると後からGit連携にできない
wrangler pages deployで作ったプロジェクトは、あとから「GitHubにpushしたら自動公開」に切り替えられない。公式ドキュメントに明記されている。やるならプロジェクトを作り直して、ドメインを付け替えることになる。最初にGit連携で作るかどうかは、思っているより後戻りしにくい分岐だ。
追記（2026年8月25日）——入った
結果が出たので書く。インデックスされた。
| 日付 | 起きたこと |
|---|---|
| 8/22 | 独自ドメインへ移行。サイトマップ送信 → 当日「成功しました」 |
| 8/23 | 検出されたページ数が12（全URL）に。最終読み込み日時も8/23 ＝ 翌日また読みに来ている |
| 8/24 | URL検査で確認した5URLすべてが「URLはGoogleに登録されています」 |
確認したのはトップページと、/posts/domain-doko-de-toru/、/posts/sitemap-shutoku-dekimasen/（この記事）、/posts/ai-agent-ec/、/posts/server-erabi/ の5つだ。
1ヶ月半どうやっても動かなかったものが、住所を変えて2日で入った。
効いたのはサイトマップだった
はっきりした証拠がある。/posts/server-erabi/ は、新しいドメインで一度も個別のインデックス登録リクエストをしていない。 それでも入っている。
つまり1日1本ずつリクエストを積む作業は、少なくとも今回は必要なかった。サイトマップが読まれる状態にすることが本体だった。
危うく、逆の報告をするところだった
ここが今回いちばん共有する価値がある。
同じ日、Search Consoleの「ページのインデックス登録」レポートはこう出ていた。
登録済み: 0
未登録: 5（クロール済み - インデックス未登録）
この「未登録5」に入っていた /posts/ai-agent-ec/ を URL検査したら、「登録されています」だった。
レポートの集計は数日遅れる。その日の本当の状態を知りたいならURL検査を使うしかない。 レポートだけ見ていたら、私は「まだ1本も入っていません」と真逆のことを書いていた。
それでも、因果は証明できていない
前半に書いた通りだ。「共有ドメインだから読まれなかった」のか「旧プロパティ側の登録が壊れていて、新規プロパティなら何でも通った」のかは、いまも区別がつかない。 入ったという事実が、原因を教えてくれるわけではない。
同じ症状の人に言えるのは、やはりこれだけになる。配信側がシロだと10分で確定させて、シロだったなら、そのドメインで粘る期間を先に決める。
そして、これはゴールではない
インデックスは前提条件であって、成果ではない。検索からのクリックは、この時点でまだ0件だ。
載ったので、ここからやっと「何位で、誰が来るか」の勝負になる。そちらの結果はまた別の記事に書く。