Search Console APIで自動診断｜クリック9割が非開示クエリの罠と無料SEO監査術

Search Console の管理画面からエクセル（CSV）をダウンロードすれば十分じゃと思っていたんじゃが、わざわざ API を使うとそんなに違うものが見えるんかのう？

実は「まったく別世界」と言っていいほど情報量が変わります！管理画面のエクスポートは 『ページ一覧』と『検索ワード一覧』がバラバラの表に分かれてしまう うえ、上位 1,000 件までしか出せません。API で両方を掛け合わせた生データを引いてみると、普段の画面では隠れていた「衝撃の氷山構造」が一目でわかるんですよ。

クリックの9割が見えない『匿名化クエリ』の衝撃

まず最初に、当サイト（sc-domain:lab.chihouzakki.com）で Search Console API の searchanalytics.query を呼び出し、①日付別（date）、②ページ単体（page）、③ページ×検索語句（page + query） の 3 種類のディメンションを同じ期間で取得して突き合わせた実測表をご覧ください。

※ date（サイト全体集計）より page（ページ別延べ集計）の数値が少し大きいのは、1 回の検索結果画面に当サイトの関連 2 記事が同時に並んだ場合、date では「サイトとして 1 表示」と数えるのに対し、page では「それぞれの記事に 1 表示（計 2 表示）」と数える Google 公式の集計仕様によるものです。

クエリ一覧を全部足しても全体の1割しかない理由

上の表を見て、多くの方が二度見されるのではないでしょうか。直近 28 日間で記事ページが合計 211 回 クリックされているにもかかわらず、「どの検索ワードでクリックされたか（page × query）」の行をすべて足し合わせても わずか 22 回（10.4%） しかありません。残りの 89.6%（90 日間でも 76.5%） のクリックは、検索ワード欄から完全に消えているのです。

これはバグではなく、Google が検索ユーザーのプライバシー保護のために設けている 『匿名化されたクエリ（Anonymized queries）』 という公式仕様です。

見える検索語だけでタイトルを削ると流入が崩壊する

この「氷山の水面下に 9 割のクリックがある」という事実を知らないまま SEO 対策を行うと、取り返しのつかないリライト事故を起こしてしまいます。

たとえば当サイトの主力記事である CTEK充電器の長期検証レビュー は、28 日間で 251 表示 / 10 クリック を獲得していますが、そのうち開示クエリ分はわずか 2 クリック / 49 表示で、残りの 8 クリック / 202 表示はすべて匿名化ロングテール検索 です。

ここで既存の「使い方・RECOND・SUPPLY・成層化解消」という骨格を削ってしまえば 202 表示の土台が壊れます。逆に骨格を守ったまま、API のクエリ表で「記事内には書いてあるのに title にだけ入っていなかった 『モード』（ctek リコンディション モード で 11.4 位・16 表示）」を補うことで、既存の流入を 1 ミリも減らさず 1 ページ目上位へ引き上げることができるのです。

API生データの取得で判明した3つの集計トラップ

さらに公式 googleapis パッケージ（searchconsole v1、1 リクエスト最大 25,000 行ページング対応）を使って生データを自動集計するスクリプトを組んだところ、「API の返り値をそのまま単純合算すると数字が大きく狂う 3 つの罠」 があることが実測で判明しました。

目次サイトリンクで表示回数が最大7倍に水増しされる

1 つ目の罠は、記事内に目次（TOC）を置いているブログ特有の 『/#見出し（フラグメント付き URL）の重複計上』 です。

dimensions: ["page", "query"] を指定して API を叩くと、通常の記事 URL だけでなく、検索結果の下に小さなジャンプ先リンク（サイトリンク）として同時表示された目次アンカー URL まで別々の行として返ってきます。実際に当サイトの生 CSV に記録されていた実例がこちらです。

• 親記事行：/blog/ctek/（クエリ：ctek mxs7 0 使い方 → 3 表示 / 8.0 位）
• 目次行①：/blog/ctek/#論旨（同クエリ → 3 表示 / 8.0 位）
• 目次行②：/blog/ctek/#対象となる方（同クエリ → 3 表示 / 8.0 位）
• 目次行③〜⑥：#アイドリングストップ... 他 4 見出し（同クエリ → 各 3 表示 / 8.0 位）

なんと たった 3 回検索されただけなのに、親 URL と 6 個の目次リンクの計 7 行すべてに「3 表示」が付与され、単純に足し算すると「21 表示（7 倍の水増し）」に化けてしまう のです。当サイトの 28 日データ全体でも、この # 付き重複行が 32 行（計 102 表示分の水増し） 含まれていました。

これを放置すると「表示回数ばかり多くてクリック率（CTR）が異常に低い記事」と誤診してしまうため、集計スクリプトでは必ず以下の正規化ルールを入れる必要があります。

移転後301リダイレクト74件の評価分裂と名寄せ合算

2 つ目の罠は、WordPress などから Astro へ移行したりディレクトリ構造を整理したりしたサイトで起きる 新旧 URL のデータ分裂 です。

.htaccess で完璧に 301 リダイレクト（恒久転送）を設定していても、Search Console の過去 28 日〜90 日の集計期間内には「移転前の旧 URL で表示・クリックされた履歴」と「移転後の新 URL で表示・クリックされた履歴」の両方が残ります。当サイトの 28 日データでも、生の URL 数は 527 件 あったのに対し、.htaccess の転送ルールを読み込んで正規パスへ自動名寄せしたところ 395 記事（旧 URL 履歴 74 件を統合） に集約されました。

名寄せを行わないと「本当は合計 30 クリック稼いでいる首位のエース記事」が「旧 URL 18 クリック・新 URL 12 クリック」のように半分ずつに割れて見え、内部リンクの発射台選びを誤ってしまいます。詳しくは Xserver×Astroの500エラー解決と.htaccess設計録 でも解説している通り、ローカルの .htaccess をそのまま名寄せ辞書として使うのが最も確実です。

謎の『site:無料サーバー』検索19件の混入と除外

そして 3 つ目の罠は、API で全クエリを吸い上げて初めて気づいた 奇妙な検索コマンド群の写り込み です。当サイトの Amazonマーケットプレイス返金体験記 の生クエリを確認したところ、人間が普通に入力するはずのない以下のような長文クエリが 計 19 行（平均 3.0〜10.0 位） も並んでいました。

site:vercel.app "amazon" "返金可能" -site:amazon.co.jp -site:amazon.com -site:amazonaws.com -site:aboutamazon.jp -site:primevideo.com
site:pages.dev "amazon" "返金可能" -site:amazon.co.jp ...
site:github.io "amazon" "返金可能" -site:amazon.co.jp ...
site:fly.dev "amazon" "返金可能" -site:amazon.co.jp ...
site:netlify.app / render.com / firebase.com / herokuapp.com / blogspot.com / wixsite.com / jimdo.com / livedoor.jp / hatena.ne.jp / lolipop.jp / sakura.ne.jp ...（計18ドメイン）

ちょっと待って！site:vercel.app とか site:github.io って「その無料サーバーの中だけを検索しろ」という指定よね？なんで全然関係ない独自ドメインのこのブログが 3 位〜7 位に表示されてカウントされているの！？気持ち悪いわ！

本当に不思議ですよね！サイトが乗っ取られたわけでは一切ないので安心してください。これには 「誰が検索しているのか」 と 「Google 検索側の挙動」 の 2 つの裏事情があるんです。

まず誰がこんな検索を回しているのかという点ですが、推論 として最も可能性が高いのは フィッシング詐欺サイトを自動パトロールしているセキュリティ調査ボット（または攻撃側の偵察スクリプト） です。近年、「Amazon の欠品・返金を PayPay 等で行う」と騙る詐欺サイトが Vercel や Cloudflare Pages（pages.dev）、GitHub Pages などの無料ホスティングや無料ブログに大量に使い捨て設置されるため、公式ドメイン（-site:amazon.co.jp 等）を除外した特殊検索コマンド（Google Dork）で定期スキャンが行われています。

そして、指定された無料サーバー内に "amazon" "返金可能" に一致するページが 0 件（または極少）だった際、Google 検索が「条件に完全一致する結果がないため、関連語句を含む他サイトの結果を表示」とソフトフォールバック展開した結果、たまたま「Amazon」「返金」の実体験を詳しく書いていた当サイトの記事が検索結果画面の下部に並び、インプレッションが記録されたというカラクリです。

もしこうした site: や -site: 付きのボット検索をそのままキーワード欠落診断にかけてしまうと、「あなたの記事タイトルには site:vercel.app という重要語が足りません！」というとんでもない誤判定が起きてしまいます。自動診断スクリプトでは、検索演算子（site:・-site:・inurl:・filetype: 等）を含むクエリを最初に入口で弾くフィルタが必須です。

URL検査API×SQLiteで未露出154件を仕分ける

searchanalytics.query が「すでに検索結果に出ている記事の伸ばし方」を教えてくれる API だとすれば、もう 1 つの公式 API である urlInspection.index:inspect（URL 検査 API） は、「公開したのに過去 90 日間 1 回も表示されていない記事（表示ゼロ記事）の真因」を教えてくれる聴診器です。

URL 検査 API には 1 プロパティあたり 1 日 2,000 件（1 分あたり 600 件）まで完全無料 という十分な枠があります。そこで当サイトの過去 90 日間で表示 0 回だった公開記事 154 件 を並列数 5 で一括検査し、手元の SQLite 知識 DB に記録されている「サイト内の被リンク数（inbound_links）」と結合してみたところ、思い込みを覆す内訳が出ました。

※ なお API 仕様上の注意点として、まだ一度もクロールされていない記事（検出 - インデックス未登録 や URL が Google に認識されていません）を検査すると、indexingState フィールドが INDEXING_STATE_UNSPECIFIED で返ってきます。これをプログラム側で「異常エラー」と誤判定せず、正しく「未クロール（内部リンク強化対象）」へ振り分けるのがコツです。

表示ゼロ記事の過半数は登録済みの『検索語ズレ』だった

一番の発見は、「90 日間まったく検索に表示されていない 154 記事のうち、過半数の 87 件（56.5%）は、とっくの昔に Google のインデックスに登録されていた」 という事実でした。

管理画面で検索流入がない記事を見ると、つい「まだ Google にインデックスされていないのかな？手動でインデックス登録リクエストを送ろうかな？」と考えてしまいがちです。しかし実際には半分以上の記事がすでに検索台帳に載っており、ただ 「書き手が付けた抽象的なタイトル（例：『雇用破壊のアルゴリズム』や『愛用品のメンテナンス録』）」と「読者が実際に打ち込む検索ワード」が噛み合っていないために 100 位圏外に沈んでいただけ だったのです。

被リンク数と掛け合わせた3バケット別の最短改善ルート

原因が 3 つに割れている以上、すべての記事に同じ対策をしても時間の無駄になります。URL 検査 API の結果と SQLite の被リンク数を組み合わせると、迷いゼロで最短の手が打てます。

• 🟢 登録済（87 件）への処方箋 : すでに Googlebot は中身を認めて台帳に載せているため、内部リンクを増やすよりも title の先頭 25〜28 文字に「製品名・型番」や「直球の悩み検索語」を配置する改善 が数日単位で最も早く効きます。

• 🟡 クロール済未登録（20 件）＆ 🔴 未クロール（47 件）への処方箋 : こちらはタイトルだけをいじってもクローラーが再訪してくれません。先ほどの searchanalytics.query で特定した 「直近 28 日間の主力エース記事トップ 25（Googlebot が頻繁に巡回している人気ページ）」の冒頭『合わせて読みたい深まる関連情報』枠からルート相対リンクを繋ぐ のが特効薬になります。

月額0円！毎朝8時15分の無人SEO監査と改善実測

一度きりの手動分析で終わらせず、「寝ている間にサイトの健康診断と改善候補のリストアップが終わっている状態」を作るため、当サイトでは macOS 標準の launchd（毎日 08:15 ＋ ログイン時起動）に定期自動診断スクリプトを組み込みました。

launchdと起動フックでお宝記事を自動起票する

GCP（Google Cloud）で発行したサービスアカウントのメールアドレス（client_email）を、Search Console の「設定 ＞ ユーザーと権限」に 『制限付き（読み取り専用）』 で登録しておけば、ブラウザのログイン画面を開くことなく Node.js から半永久的に無人実行できます（※秘密鍵 JSON と取得生データは .gitignore 管理下の _local_db/ に隔離し、Git への誤コミットを二重ロックで防いでいます）。

毎朝の自動ルーチンでは、以下の 「守りの 5 大不具合監視」 と 「攻めのお宝記事ピックアップ」 を同時に実行します。

クールダウン14日ルールと週間クリック3.4倍の成果

自動起票を作るときに一番大切な工夫が 『改修後 14 日間のクールダウン（効果測定待ち）フィルタ』 です。

今日タイトルを改善した記事は、Google が再クロールして検索順位や CTR に変化が出るまで最低でも 1〜2 週間かかります。それなのに過去 28 日間の累計データだけを見て毎日「この記事は CTR が低いです！」と通知し続けたら、オオカミ少年になってしまいます。そこでファイルの更新日時から 14 日未満の記事は自動的に『⏳ GSC 効果測定中』の別枠へ退避させ、まだ手を付けていない新しいお宝記事（平均 12.5 位以内・20 表示以上で重要検索語がタイトルから漏れている記事）だけを起票する設計 にしました。

この仕組みで「旧 URL の 301 正規化 → 匿名化骨格を守った 1 ページ目記事の欠落語統合 → エース記事からの双方向リンク注入」を回した結果、直近の実測パフォーマンスは以下のように推移しています。

• 直近 7 日間の検索クリック数 : 108 回（前 7 日間の 32 回から +237.5% ＝ 約 3.4 倍）
• 直近 28 日間の検索クリック数 : 208 回（前 28 日間の 101 回から +105.9% ＝ 約 2.1 倍）
• 直近 28 日間の検索表示回数 : 3,974 回（前 28 日間の 1,291 回から +207.8% ＝ 約 3.1 倍）
• 要対応の SEO 不具合件数 : 全 555 記事で 0 件 を継続維持

毎月 1 万 5,000 円もするような海外製 SEO ツールを契約せんでも、公式の無料 API と手元の Mac だけでここまで正確に「次に直すべき記事」が毎朝出てくるんじゃな！年間で 18 万円以上の節約になるし、何より自分のサイトの一次データじゃから嘘がないのう。

そうなんです！外部の推定ツールは個人・中小規模サイトのロングテール検索をほとんど捕捉できませんが、Search Console API なら Google 自身の本物の台帳データ を 1 円もかけずに直接扱えますからね。

まとめ：生データの癖を知りAIに毎朝の点検を任せる

今回の Search Console API 実測検証で得られた要点をまとめます。

もしご自身の Astro ブログや個人サイトでも、今回ご紹介したような 「匿名化クエリ比率の算出・#見出し 重複除外・URL 検査 API 仕分け・定期自動診断スクリプト」 を構築したい場合は、認証鍵の保護設定や API 集計ロジックの読み飛ばしを防ぐため、軽量モデルではなく 必ず『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、以下のプロンプトを貼り付けて事前調査から進めてみてください。

以下の参考記事の仕様（Search Console APIでのdate / page / page×query一括取得、匿名化クエリ比率の算出、目次サイトリンク #anchor の重複インプレッション除外、リダイレクト名寄せ、site:演算子ノイズ除外、およびurlInspection.index:inspect APIによる未露出記事の3分類診断）を踏まえて、私のサイト環境向けのSEO自動診断CLIスクリプトを設計してください。

参考記事URL: https://lab.chihouzakki.com/blog/review/search-console-api-anonymized-queries-auto-audit/

【重要ルール】
1. いきなりコードを書き始めず、まず私のプロジェクトの記事ディレクトリ構造、フロントマター形式、リダイレクト設定ファイル、.gitignore の状態を調査してください。
2. GCPサービスアカウントJSON鍵や出力データは必ず .gitignore で保護されたローカル専用フォルダに配置し、既存記事ファイルを勝手に書き換えない「読み取り・レポート出力専用」として設計案を提示し、私の合意を得てから実装してください。

▲ 毎朝の細かい数字チェックは自動スクリプトに任せて、人間も猫もゆったり朝を迎えましょう