誤診と原因の記録・2026年8月15日
Search Console APIで「表示ゼロ」と誤診した｜次元をひとつ足すと数字の4割が消える
Search Consoleの数字を見て「このページは表示ゼロだ」と判断する前に、この記事を読んでください。私たちは集計の指定をひとつ間違えて、実際には8位に付いているページを削除候補に入れるところでした。数字が消える箇所は決まっています。
このサイトはAnthropicの公式サイトではありません。Claude Codeの機能・料金・提供範囲は変わる可能性があるため、重要な判断の前には公式のドキュメントと自分のアカウント設定を確認してください。
先に結論
私たちがSearch Consoleの数字で実際に誤診した・誤診しかけた箇所は、次の4つです。
- ページの実力は
page単独で測る。集計の次元にqueryを混ぜると、少量の検索語が匿名化で落ち、合計が実際より小さく出ます。私たちの実測では4割消えました - 削除やnoindexにつながる判断ほど、次元を最小にして取り直す。多めに誤ると様子見で済みますが、少なめに誤ると消してはいけないページを消します
- sitemap APIの「インデックス済み」欄は読まない。廃止済みで常に0が返ります。見るのは最終取得日とエラー件数です
- 「0件」「全滅」という結果が出たら、まずページではなく測り方を疑う。URL末尾のスラッシュ違いだけでも、エラーにならず丸ごと空が返ります
以下、それぞれ実際に踏んだときの状況と、確かめ方です。
ページの実力は page 単独で測る
使い分けはこの表のとおりです。
| 知りたいこと | dimensions |
|---|---|
| ページごとの表示・クリック・順位 | ["page"] |
| 語ごとの表示・クリック・順位 | ["query"] |
| そのページに来ている語（探索用） | ["page","query"] ただし合計値の判定には使わない |
3つめは「見る」用途としては有用です。使ってはいけないのは、そこから出た合計をページの実力として扱うことです。「このページは0だから外す」という判断に使うと、実際には順位が付いているページを消すことになります。
この件で危なかったのは、誤診の方向が「消す」側だったことです。表示回数を多めに誤ると「まだ様子を見よう」で済みますが、少なめに誤ると削除やnoindexに進んでしまいます。判定が削除につながる集計は、次元を最小にしてもう一度取り直す価値があります。
証拠：何を間違えたか
ページごとの実力を測るつもりで、次のようなリクエストを投げていました。
{
"startDate": "2026-05-17",
"endDate": "2026-08-15",
"dimensions": ["page", "query"],
"rowLimit": 25000
}「ページごとに、どの語で来ているかも一緒に見たい」と思って query を足したわけです。ところがこの1語が判定を壊しました。
Search Consoleは検索語ごとの行数が少ないものを匿名化して返しません。個人が特定されうる稀な検索語を出さないための仕様です。query を次元に入れると集計の単位が「ページ×語」まで細かくなるため、1語あたりの数が小さいページは行そのものが返ってこなくなります。
結果として、実際には表示があるページが集計結果に1行も現れず、「表示ゼロ」に見えました。実測では、query を混ぜると混ぜない場合に比べて表示回数の合計が4割ほど少なくなりました。ロングテール中心のサイトほど差が大きく出ます。
sitemap APIの「インデックス済み」は常に0
もうひとつ、同じ日に引っかかったものがあります。Sitemaps API の応答に含まれるインデックス済み件数のフィールドはすでに廃止されていて、どのサイトでも常に0が返ります。
これを知らずに読むと「全サイト、インデックス0本」という壊滅的な数字が出ます。実際にはどのサイトも普通にインデックスされていました。
sitemapの健全性を見たいときに実際に使える値は次の2つです。
- 最終取得日（
lastDownloaded）— これが何週間も前なら、そもそも読まれていません - エラー・警告の件数と登録URL数 — 手元のsitemapの本数と一致するか
個々のURLがインデックスされているかどうかを知りたい場合は、URL検査APIを使います。ただしこちらは1日あたりの呼び出し回数がすぐ上限に達します。全URLを回すような使い方はできないので、判定したいURLを先に絞ってから投げてください。
「取得できませんでした」が一過性のことがある
sitemapを送信した直後、ステータスが「取得できませんでした」になることがあります。2026年8月15日に実際に起きた例では、同じ構成で同じ日に作った2サイトのうち、片方だけが失敗になりました。
ここで直しに行く前に、自分の側から実測して切り分けます。見るのは4点です。
- HTTPステータスが200か
Content-Typeがapplication/xml系か- ブラウザのUAとGooglebotのUAで応答が変わらないか
- robots.txt がsitemapを塞いでいないか、
X-Robots-Tagが付いていないか
この例では4点とも正常でした。つまりサーバー側に直すものが無い。思い当たる原因は、Googleが取得しに来た瞬間が .htaccess を書き換えている最中と重なったことくらいでした。再送信して待ったところ、翌日には「成功しました」10ページ検出に変わりました。
逆に言うと、「待つ」対応でよいのは、自分の側の実測が4点とも正常なときだけです。どれかが異常なら一過性ではないので、直すものがあります。実測せずに待つのは、直せる欠陥を放置する側に倒れます。実測して待つのと、不安なまま待つのとでは、同じ「待つ」でも意味が違います。
「クロールされていない」と「順位が付かない」を分ける
表示が出ない原因は大きく2つあり、対処が正反対です。あなたのページがどちらなのかを先に確かめてください。
| クロールされていない | 順位が付かない | |
|---|---|---|
| URL検査の結果 | 「検出 - インデックス未登録」「URLがGoogleに認識されていません」 | インデックス済み。ただし平均順位が20位前後 |
| やるべきこと | 内部リンクを増やす・sitemapを整える・クロールの無駄を減らす | 本文を厚くする・重複を解く・titleを見直す |
| やってはいけないこと | 本文をいくら足しても読まれていないので効かない | リンクを足しても順位の理由は変わらない |
この切り分けをせずに「表示が出ないから加筆しよう」と進めると、読まれていないページに時間を使うことになります。逆に「クロール枯渇だ」と決めつけて内部リンクだけ増やしても、インデックス済みのページには効きません。
実際に測ってみると、あるサイトでは表示ゼロのページの8割がインデックス済みでした。つまりクロールの問題ではなく、内容の問題でした。別のサイトでは逆に7割が未クロールで、こちらはリンクとクロール配分の問題でした。同じ症状でも原因は逆です。
集計コードで気をつけている点
- 日付は絶対値で書く。「過去90日」のような相対指定は、後から結果を見返したときに何の期間か分からなくなります
- rowLimit の上限に当たっていないか確認する。返ってきた行数が上限とぴったり同じなら、切り捨てられている可能性があります
- 0件の結果を「0」として保存しない。「取得できなかった」と「本当に0だった」を区別できる形で残します
- サイトのURLは末尾のスラッシュまで一致させる。プロパティの指定がずれていると、エラーではなく空の結果が返ってきます
4つめは特に静かに失敗します。https://example.jp と https://example.jp/ の違いで、丸ごと空になります。
よくある質問
なぜ匿名化されるのですか？
検索語には個人が特定できる内容が入りうるためです。件数の少ない語は返さない仕様になっています。ページ単位の集計では起きないので、次元を分ければ回避できます。
画面（Search Consoleの管理画面）でも同じことが起きますか？
起きます。「クエリ」タブの合計と「ページ」タブの合計が一致しないのは同じ理由です。画面でもページの実力を見るときはページ側で見てください。
APIとブラウザ操作、どちらがいいですか？
集計はAPIが速くて正確です。ただしインデックス登録のリクエストのように画面からしかできない操作もあり、そちらは手で押すことになります。回数の上限があるので、押す前に本命を決めておくのが現実的です。