Google Search Consoleでサイトマップインデックスが「成功」と表示されているのに発見ページがゼロで、子サイトマップが何度再送信しても「フェッチできません」のままなら、サーバーの問題ではなく、おそらくGoogleのサイトマップスケジューラー内での1URL単位のバックオフを見ています。これを証明する最速の方法は、同じファイルを少し異なるURLで再送信して、何が起きるか観察することです。
その診断に6か月、5つの個別監査、4つのAIモデルを要しました。それをついに解決したテストにかかった時間は14秒です。
重要なポイント：サイトマップインデックスは「成功」と報告できますが、その中のすべての子サイトマップはGoogleから見えない状態になります。エッジログで「フェッチできません」の子に対してGooglebotのリクエストがまったくない場合、失敗はあなたの側ではなくGoogle側です。/sitemap/0.xml?v=20260815のようなバージョン付きURLで同じファイルを再送信するとバックオフをバイパスし、数秒で処理されます。
「成功」が実際に報告していたもの
サイトはDeluxe Astrology、私の両親のヴェーダ占星術プラットフォームで、私が運営する最大規模のもの。30言語にわたる約240,000個のURLで、Supabaseから公開され、その下に63個の子サイトマップを持つサイトマップインデックスとして配信されています。このアーキテクチャについてはDeluxe Astrology project pageで書いています。
インデックス登録ページ数が数週間にわたって下降しています。6月下旬に表示回数が急落しました。そして、Googleに新規URLの一覧を渡すのが唯一の仕事のシステムが緑のチェックマークを表示していました。
Search Consoleでサイトマップインデックスを開くと「サイトマップインデックスが正常に処理されました」と表示されます。クリックするとサイトマップ読み込み表に0～0が0と表示されます。Googleは3週間にわたり3回インデックスをフェッチし、インデックスとして正しく解析したのに、その子を1つも登録しませんでした。1つの子サイトマップさえもフェッチされたことがありません。3つを直接送信した場合、数時間「フェッチできません」のままでした。
これが落とし穴です。サイトマップインデックスのステータスはインデックスファイルのみについての陳述です。XMLが解析され、子URLが適切な形式に見えたことを示します。Googleが実際にそれらを読みに行ったかどうかについては何も教えてくれません。その区別はほとんどの人がスクロールしないテーブルに埋もれており、サイトマップインデックスが必要なほど大きいサイトではゲーム全体がそこにあります。
サーバー上のすべてが5回別々に正常でした
「フェッチできません」にぶつかったことがあるなら、次の1時間がどう進むか知っています。URLをcurlします。robots.txtをチェックします。ファイアウォールをチェックします。CDNキャッシュをチェックします。URL検査でライブテストを実行します。すべてクリアで返ってきます。だからあなたは自分に言い聞かせます。Search Consoleの古典的な嘘：時間が必要なだけです、24～72時間後にチェックバックしましょう。
数か月にわたり、これは本当に徹底的な調査になりました。そして私だけではありません。この問題を複数のフロンティアモデルを独立した監査役として実行しました：Claude、Kimi、GLM、そしてカップル個のカスタムエージェント、それぞれコードベース、Search Consoleデータ、エッジログへのアクセス権を持ちながら。私は以前、実際に同時に実行する価値のあるAIモデルの数について書きました。これがそれを最も厳しくテストしたケースでした。
ほぼすべてに同意し、ほぼすべてについて正しかった：
- ライブサイトマップインデックスは、すべての63個の子を持つ有効な
<sitemapindex>、正しいコンテンツタイプ、バイトオーダーマーク無し、クロスホストURLなしで配信されました。 - すべての子は予想されるURL数で有効な
<urlset>を配信しました。 - Googlebot自身がURL検査を通じてインデックスと子サイトマップの実ライブ取得を行った結果、実際のXMLが返されました。「URLはGoogleが利用可能です」。
- エッジログには、インデックスへの実際のGooglebotリクエストが許可され、キャッシュから200が返されたことが示されていました。
- robots.txt、ミドルウェア、リダイレクト、CDN設定のいずれもサイトマップパスに影響を与えていませんでした。
以前の1つの誤りは実際のもので、既に修正されていました。数ヶ月前にホスティング料金を跳ね上げるボットファームに対抗するために追加されたWAFのIPごとのレート制限が、一時期クローラートラフィックにチャレンジを突きつけていました。そのルールは修正されました。修正後、すべての監査は同じ結論に達しました。サーバー側はクリーン、Googleは時間が必要、24～72時間後に再確認してください。
5回の監査。同じ結論。同じ推奨。数字は動きませんでした。
その兆候は、エラーではなく、欠落でした。
不都合な事実は、エッジログに隠れていました。そこにはないもののなかに。3つの子サイトマップを送信した後、それらのいずれについてもGooglebotリクエストがありませんでした。許可されたものではなく、チャレンジされたものでもなく、拒否されたものでもありませんでした。Googleはそれらを取得できていなかったのではなく、試さないことを選択していたのです。
サーバーからそれを診断することはできません。構造上、何も到着して検査することはありません。標準ツールキットのすべてのツールは、失敗したリクエストを説明するために構築されており、リクエストはありませんでした。これがログファイル分析が証拠ではなく欠落によって解決する唯一のクラスの問題です。ヒットを探しに行って、答えが空の結果セットなのです。
Search Consoleのライブテストはそれを悪化させます。その選択を行うスケジューラをバイパスするからです。別のコードパスからオンデマンドで取得し、サイトマップサブシステムがキューに入れることのないURLについて「利用可能」と陽気に報告します。緑色のライブテストは、サイトマップパイプラインがファイルに触れることになるという証拠ではありません。
APIはUIが言わない真実を語った
Search Console Sitemaps APIは最初の誠実なシグナルを与えました。UIは「取得できませんでした」と表示されており、これは原因を伴う失敗として読めます。APIはisPending: trueとerrors: 0、そして全くlastDownloadedタイムスタンプなしで返します。
これらは異なるクレームです。「取得できませんでした」は失敗したアテンプトを意味します。isPendingでゼロエラーということは、アテンプトが行われなかったという意味です。6ヶ月のデバッグは、存在しなかった失敗に向けられていました。
スケールで何かを実行する場合は、それが必要になる前にAPIを配線してください。それは1つのOAuthスコープと数行のコード、そしてそれは安心のために設計されたステータス文字列と記録の実際の状態の違いです。まさにこの理由で、Claude Code SEO audit workflowで頻繁に利用しています。
管理された実験
6回目の監査を実行する代わりに、コントロールを実行しました。
まず、ベースライン。Googleがこれまで見たことのないサイトマップ、サイトの小さなセクション用の小さなものを送信しました。それは送信後34秒でダウンロードおよび処理されました。だからパイプラインは健全で、ホストは到達可能で、Googleはこの時点でこのドメインからサイトマップを取得する気があったのです。
その後、実際のテスト。詰まった子のうちの1つを、バイトごとに完全に同じ、同じサーバー上の同じルートで提供された状態で再送信しました。ただ1つの違いあり：末尾のクエリ文字列。/sitemap/0.xml?v=20260815。
| 送信 | Googleの状態 | 処理時間 |
|---|---|---|
| `/sitemap/0.xml`（元） | 2時間30分後は保留中 | なし |
| 新しいサイトマップ、以前は送信されたことがない | 処理済み | 34秒 |
| `/sitemap/0.xml?v=20260815`（同一ファイル） | 処理済み、2,187個のURL | 14秒 |
同じファイル。同じサーバー。同じバイト数。異なるクエリ文字列。一方は2時間半以上見えない状態が続き、もう一方は14秒で読み込まれた。
これが診断のすべてであり、私が制御されたテストが別の検証ラウンドに勝ると主張し続ける理由だ。すべての監査はサーバーについての事実を確認した。重要だと判明した唯一の入力値を変えた監査は一つもなかった。
実際に起きていたこと
Googleのサイトマップシステムが、その正確に63個のURLをURL単位の障害バックオフで保持していた。
数ヶ月前、インデックスを読むたびに、単一のGoogle IPから数秒以内に63個の子フェッチのバースト送信が発生していた。これはインデックスに対する正常なGooglebotの動作だ。親を読んでから、ほぼ同時に子を取得する。平均的な人間のトラフィック用にサイズ設定されたWAFのIP単位レート制限は、1つのアドレスからの63個のリクエストのバーストを見て、設定されたとおりに対応した。チャレンジしたのだ。毎サイクル。数週間にわたって。
インデックスリクエスト自体は常に通過した。1つのリクエストはバーストではないからだ。だからこそインデックスは「成功」と読み続けたのに、子は決して存在しなかった。そのルールはまさに私がGoogleに読ませたいURLを壊すために完璧に形成されていて、それらを報告する唯一のURLには手をつけないままだった。
ファイアウォールを修正してもGoogleのメモリから失敗したURLはクリアされなかった。新しい障害の発生を止めただけだ。その63個の特定の文字列についてのバックオフは修正後も残り、待機では観測できるタイムスケールで失効することはなかった。
修正：63個の送信、ゼロのデプロイ
Search Console APIを通じてバージョンクエリ文字列を使ってすべての63個の子を再送信した。約2分以内にそれらすべてがフェッチされ処理された。155,545個のURLがGoogleに登録され、エラーはゼロ、警告はゼロだった。半年間ゼロで推移していた検出ページが、私が見ている間に取り込まれた。
永続的な修正は次のリリースの2行の変更だ。サイトマップインデックスがバージョン付きの子URLを出力するようにして、インデックスとrobots.txtはGoogleが読む意思のあるURLを指すようにする。生成ロジックが変わるたびにバージョントークンを上げて、無料でキャッシュバスティングメカニズムを手に入れる。
正直な注釈が1つある。インデックス登録は発見ではない。Googleはこのホストを数ヶ月の不信のあとで弱弱しく爬巡していて、155,000個のURLが1週間で一掃されることはない。発見が再び機能することは前提条件であり、結果ではない。クロール予算が既に薄い場合、サイトマップの修正は仕事が始まるところだ。
5つの監査が間違った答えに収束した理由
これは私が何度も立ち戻る部分だ。
モデルは検証に優れていた。コンテンツタイプ、キャッシュヘッダー、robots指令またはミドルウェアについての主張を与えられれば、正確にチェックして誠実に報告した。しかし、それらのどれもが自分たちだけで提案したことがなかったのは、同じファイルを別の名前で送信して何が起きるかを見ることだ。
共有された盲点への収束は、コンセンサスとまったく同じに見える。同じ証拠を同じ仮定で読む5人の監査人―フェッチ障害は実行を意味するという仮定―は、5つの自信に満ちた合意とゼロの進捗を生成する。その合意は確認のように感じる。それは実は監査人同士の相関であり、監査人と現実の相関ではない。
膠着状態を壊したのは、別の監査ではなかった。6ヶ月の「72時間待つ」が計画ではなく仮説だと判断して、唯一の変数がURLの文字列であるテストを設計したことだ。それは人間の仕事であり、それがすぐに止まるとは思わない。
私が得た5つの教訓
- サイトマップインデックスの成功は、インデックスファイル自体に関するもので、子ファイルではありません。「Sitemaps read」までスクロールしてください。ゼロと表示されていれば、緑のチェックマークは飾りに過ぎません。
- UIの「Couldn't fetch」はAPIでは「未処理」を意味します。APIドキュメントを読んでください。
isPendingとlastDownloadedが実際に知りたい情報で、UIはどちらも表示していません。 - Googleはあなたのインフラの問題をあなた自身より長く覚えています。数週間クローラーを制限したレート制限は、そのルールがなくなった後も特定のURLをバックオフ状態に置き続けることができます。待つだけでは確実にクリアできません。URLのバージョン管理で対応してください。
- レート制限はクローラーの平均トラフィックではなくバースト時のトラフィック向けにサイズ設定してください。インデックス読み取りは1つのIPから数秒以内にN個の子ファイル取得をトリガーします。IPごとの制限がNより低い場合、Googleが最も読む必要があるURLに対して正確に制限が働き、インデックス自体は成功して報告します。
- 複数のモデルがサーバーが正常で待つべきだと同意している場合、おそらくサーバーについては正しくても待機についは間違っています。6番目の監査の代わりにコントロール実験を実行してください。
同じ問題があると思ったら
以下の手順で進めてください。約15分で完了し、サーバー問題とGoogle側のバックオフを明確に分離できます。
- Search Consoleでサイトマップインデックスを開き、ステータスではなくSitemaps read数を読んでください。健全なインデックスで子ファイル読み取りがゼロであることが特徴的な症状です。
- Search Console APIを通じて同じサイトマップを取得します。各サイトマップの
isPending、errors、lastDownloadedを記録してください。 - 過去30日間のGooglebotリクエストについて、エッジまたはCDNのログで特定の子パスを検索してください。ステータスに関係なくリクエストがまったくない場合、問題はサーバー側にありません。
- Googleがまだ見たことのない完全に新しいサイトマップURLを送信してください。1分以内に処理されれば、ホストとパイプラインは問題ありません。
- 停止している子ファイルを1つ、バージョンクエリ文字列を付けて再送信してください。それが処理されてプレーンURLが処理されない場合、答えと解決策が同じステップで得られます。
- WAFレート制限を平均値ではなくバースト動作に対して監査し、バックオフが再構築されないようにしてください。その後、大規模サイトのインデックス関連の基本項目の残りをチェックしてください。
これすべての参考資料については、Googleのサイトマップ構築・送信ガイドとsitemaps.orgプロトコルが依然として唯一重要なドキュメントです。どちらもURLごとのバックオフについて言及しておらず、それがこれに時間がかかった理由の一部です。
100,000以上のURLを持つサイトを運営していて同じ症状で詰まっている場合、これは私が生業としている仕事です：大規模サイトのテクニカルSEOで、プログラマティックSEOビルドも含まれており、サイトマップは形式的な存在から全流通チャネルになります。APIスクリプト、診断手順、そして経験を持っています。
FAQ
サイトマップインデックスが成功と表示されているのに、発見されたページがゼロなのはなぜですか？
ステータスはインデックスファイルのみに関するためです。Googleは<sitemapindex>を解析して良好に形成された子URLを見つけました。これが「成功」が主張するすべてです。その後、それらの子を取得したかどうかは、Sitemaps readテーブルで別々に報告されます。有効なインデックスで読み取りがゼロは、子が処理されなかったことを意味し、緑のチェックマークは有用な情報を何も提供していません。
Search Consoleの「Couldn't fetch」は実際には何を意味していますか？
思われているより少ないです。Search Console APIでは同じサイトマップは通常、isPending: trueでerrors: 0、lastDownloaded値なしを返します。これはGoogleが取得を試みて失敗した可能性ではなく、まだ試みていないことを意味します。実際に起きなかった可能性のある失敗のデバッグに時間を費やす前にAPIを確認してください。
サイトマップが本当に止まっているかを判断するまで、どのくらい待つべきですか？
Googleが読み込みを進める標準的なサイトマップは、数日ではなく秒から分単位で処理されます。子サイトマップが24時間以上保留中のままで、同じホスト上の新しいサイトマップURLがすぐに処理される場合、更に待つことは戦略ではありません。代わりにバージョン付き再送信テストを実行してください。
サイトマップURLにクエリ文字列を追加するとコンテンツの重複やその他のSEO上の問題が発生しますか？
いいえ。サイトマップは検出用ファイルであり、インデックス可能ページではなく、その中のURLは変わりません。Googleはとをとして扱い、これがまさにあなたが活用しているプロパティです。インデックスとrobots.txtをバージョン付きURLで指定して、実行中の正規セットが1つになるようにしてください。
WASのレート制限がサイトマップ検出を中断させても、他に何も破壊しませんか？
はい。サイトマップインデックスの読み込みは単一のGoogle IPから秒単位で子フェッチのバーストをトリガーするため、人間のトラフィック用に設定されたIP単位の制限は子に対して課題が生じますが、単一のインデックスリクエストは通ります。ライブURLインスペクションテストを含むサイト上の他のすべてはしっかり動作し続けます。
サイトマップを修正すると、失われたインプレッションがすぐに復元されますか？
いいえ。検出とインデックス登録は別のステージです。155,000のURLをパイプラインに登録するのは入力を復元しますが、数ヶ月間失敗しているホストのクロール率は段階的に回復し、インデックス登録の決定はクロールに続きます。数週間を見込み、その間に検出されるページがインデックス登録する価値があることを確認してください。