Search Consoleでサイトマップが「取得できませんでした」になるときの確認ポイント

個人サイトを公開したあと、Google Search Consoleにサイトマップを送信したら「取得できませんでした」と表示されることがあります。

これを見ると、かなり不安になります。

「サイトがGoogleに見えていないのか」 「sitemapの作り方を間違えたのか」 「Cloudflare Pagesの設定が悪いのか」

こう考えがちです。

ただ、送信直後に「取得できませんでした」と出ても、すぐに致命的な問題とは限りません。この記事では、Astroで作った個人サイトをCloudflare Pagesで公開したあとに、Search Consoleで実際に確認したポイントを整理します。

まず見るのはSearch Consoleではなくブラウザ

最初にやることは、Search Consoleの画面を何度も更新することではありません。

まず、サイトマップURLをブラウザで直接開きます。

たとえば、次のようなURLです。

• https://example.com/sitemap.xml
• https://example.com/sitemap-index.xml
• https://example.com/sitemap-0.xml

ここでXMLらしい表示になっているかを確認します。

<sitemapindex> や <urlset>、<loc> のような文字が見えていれば、少なくともURL自体は存在しています。

逆に、404、HTMLページ、トップページのような見た目が出るなら、Search Console以前にサイト側の出力を直す必要があります。

SoloOps Labでも、最初は /sitemap-index.xml と /sitemap-0.xml はXMLでしたが、/sitemap.xml の扱いで迷いました。最終的には /sitemap.xml でもXMLを返せるようにして、Search Consoleで送信しやすい状態にしました。

sitemap.xml と sitemap-index.xml の違いで詰まりやすい

静的サイトジェネレーターやフレームワークによっては、サイトマップのURLが sitemap.xml ではなく sitemap-index.xml になることがあります。

Astroのsitemap連携でも、環境や構成によって sitemap-index.xml と sitemap-0.xml のような形で生成されることがあります。

ここで初心者がつまずきやすいのは、Search Consoleに何を送ればよいか分からなくなることです。

基本的には、ブラウザで開いてXMLが返るURLを送ります。

もし sitemap-index.xml が正しくXMLを返しているなら、それを送ればよいです。sitemap.xml も用意できるなら、Search Console上で迷いにくくなります。

ただし、同じサイトのサイトマップを複数送ったからといって、それだけでSEOに悪いという話ではありません。大事なのは、送ったURLがXMLを返し、サイト内のURLを正しく指していることです。

robots.txt の Sitemap 行も確認する

次に見るのは robots.txt です。

ブラウザで次を開きます。

https://example.com/robots.txt

そこに、次のような行があるか確認します。

Sitemap: https://example.com/sitemap-index.xml

または、

Sitemap: https://example.com/sitemap.xml

robots.txtは、検索エンジンにサイトマップの場所を伝える手がかりになります。

ここに古いURL、開発用URL、example.com、localhost が残っていると、検索エンジンへ間違った情報を渡してしまいます。

AIやCodexで作ったサイトでは、仮URLが設定ファイルや生成物に残ることがあります。AIでサイトを作った後に確認すべき公開前チェックリストでも、このあたりは公開前に必ず見る項目にしています。

「取得できませんでした」は送信直後に残ることがある

Search Consoleの「取得できませんでした」は、送信ボタンを押した瞬間にすべてを再取得して結果を返しているわけではありません。

送信直後は、前回の失敗状態が残っているように見えたり、Google側の処理待ちになっていたりすることがあります。

そのため、ブラウザでXMLが見えていて、robots.txtも問題なく、トップページもURL検査で登録済みなら、すぐに何度も再送信する必要はありません。

むしろ、次のような動きは避けた方がよいです。

• 何度もサイトマップを削除して送信し直す
• sitemap.xml と sitemap-index.xml を短時間で何度も入れ替える
• URL検査で全記事を一気にリクエストしようとする
• 表示だけを見て、サイト側の設定を何度も変える

Search Consoleは反映に時間がかかるものとして見た方が落ち着いて対応できます。

トップページが登録済みならかなり安心してよい

サイトマップがまだ「取得できませんでした」のままでも、URL検査でトップページが「Googleに登録されています」になっているなら、かなり安心してよいです。

これは少なくとも、次の状態を意味します。

• Googleがサイトを発見できている
• トップページにアクセスできている
• HTTPSで配信できている
• noindexで弾かれていない
• ページとしてインデックス対象になっている

つまり、サイト全体がGoogleから完全に見えていない状態ではありません。

新しいサイトでは、トップページが先に登録され、記事ページはあとから内部リンクやサイトマップ経由で徐々に拾われることがあります。

ここで焦って全記事を手動リクエストするより、トップページから重要記事への内部リンクを整える方が現実的です。

URL検査は主力ページだけに使う

URL検査は便利ですが、インデックス登録リクエストには1日の上限があります。

実際に、主力記事をリクエストしようとしたところ、1日の割り当て量を超えたという表示が出ることがあります。

そのため、URL検査は全記事に使うものではなく、優先ページに絞って使います。

たとえば、個人サイトなら次のような順番です。

• トップページ
• 主力の収益記事
• 公開直後に読ませたい記事
• サイト全体の導線になる記事

SoloOps Labの場合は、トップページの登録を確認したあと、サーバー選び、会計ソフト、AIライティング系の記事など、収益導線に近いページを優先して確認する方針にしました。

Cloudflare PagesやAstroで確認するポイント

AstroやCloudflare Pagesで作ったサイトなら、最低限次を確認します。

• astro.config.mjs の site が本番URLになっている
• SITE_URL のfallbackが example.com になっていない
• robots.txt が本番URLのサイトマップを指している
• sitemap.xml または sitemap-index.xml がXMLを返している
• sitemap-0.xml に記事URLが入っている
• canonicalが本番URLになっている
• build後の dist に仮URLが残っていない

ここまで確認して問題なければ、Search Console側の反映待ちとして扱える場面が増えます。

サーバーや公開先を選ぶ段階で迷っている場合は、個人サイトを作る前にサーバーをどう選ぶかも合わせて見ると、WordPress、静的サイト、LP作成サービスの違いを整理しやすくなります。

まとめ

Search Consoleでサイトマップが「取得できませんでした」になっても、すぐに壊れていると決めつけなくて大丈夫です。

まずは、次の順番で確認します。

• サイトマップURLをブラウザで開く
• XMLが返っているか見る
• robots.txtのSitemap行を見る
• トップページをURL検査する
• トップページが登録済みなら少し待つ
• URL検査は主力ページだけに使う

個人サイトの公開直後は、Search Consoleの表示に振り回されやすいです。

でも、ブラウザでXMLが見えていて、トップページがGoogleに登録されているなら、まずは土台は通っています。

そこから先は、何度も再送信するより、トップページから主力記事への内部リンクを整えたり、読まれたあとに次へ進める導線を作ったりする方が、個人サイト運営としては前に進みやすいです。