Google Search Consoleから1,000行を超えてデータを取得する方法

Search Consoleの画面を迂回すれば、1,000行を超えて取得できます。Search Analytics APIは1回のリクエストで最大25,000行を返し、startRowでさらに先のページを取得できます。Looker Studioコネクタも同じAPIを読み取ります。BigQueryへの一括データエクスポートは、匿名化されたクエリを除くすべての行を送信しますが、有効にした日からのデータに限られます。1,000行の上限は画面とそのエクスポートボタンのものであり、Googleもそのとおりに明言しています。「Search Consoleのユーザーインターフェースからエクスポートできるのは、最大1,000行のデータです」。

この疑問にたどり着く多くの人にとって例外となるのがクロール統計レポートで、これについての正直な答えは、あまり嬉しいものではありません。Search Console APIがカバーするのはSearch Analytics、Sitemaps、Sites、URL Inspectionだけで、クロール統計にはAPIがまったくないため、サンプルのURLを完全な形で取り出せるツールはありません。それらのサンプルを超えるクロールデータが必要なら、自分のサーバーのログファイルを使うことになり、Bingの場合はBing Webmaster ToolsのAPIにあるクロールデータが使えます。どちらも以下で取り上げます。あわせて、GSC Wizardでこの制限をどう越えているか、どこで限界になるかも説明します。

1,000行の制限が適用される場所と、適用されない場所

上限が効くのは、クエリやURLを列挙する表だけです。国、デバイス、検索での見え方のように、クエリやURLのディメンションがないリクエストについては、Googleが「Search Consoleはすべてのデータを表示してエクスポートする」と書いています。パフォーマンスレポートの上部にあるグラフの合計も完全です。匿名化されたクエリはすべての表から除外されますが、Googleは「クエリで絞り込まない限り、グラフの合計には含まれる」と注記しており、そのため表の行の合計が、その上に表示された数字と一致することはほとんどありません。

各方法の手順は、Search Consoleのデータをエクスポートする方法、BigQueryへの一括データエクスポート、クロール統計レポートで何が分かるかをご覧ください。

Search Analytics API：1回のリクエストで25,000行、startRowでページ送り

Search Console APIは、1,000行を超えるための標準的な方法です。rowLimitパラメータの有効範囲は1–25,000で、デフォルトは1,000なので、これを省略したスクリプトは、画面とまったく同じ1,000行を受け取ります。さらに先へ進むには、startRowを毎回25,000ずつ増やして同じリクエストを繰り返します。Googleのガイドは、「最後のページ、つまり0行のレスポンスに達するまで」続けるよう示しています。

POST https://www.googleapis.com/webmasters/v3/sites/sc-domain%3Aexample.com/searchAnalytics/query
{
  "startDate": "2026-10-01",
  "endDate": "2026-10-01",
  "dimensions": ["query", "page"],
  "type": "web",
  "rowLimit": 25000,
  "startRow": 25000
}

ただし、ページを送っても、大規模サイトのすべての行が手に入るわけではありません。Googleのドキュメントには、このメソッドは「検索タイプ（ウェブ、画像など。クリック数順）ごとに1日最大50K行のデータを公開する」とあり、パフォーマンスデータの詳細解説では、この上限には「すべての場合に達するとは限らない」とも付け加えられています。結果はクリック数順に並ぶため、落ちるのはクリックが少ない、またはゼロのクエリとページというロングテールです。匿名化されたクエリ、つまり2〜3か月のあいだに数十人を超えるユーザーが検索していないクエリは、どの行にも一切現れません。また、ページまたはクエリでグループ化すると、計算を妥当な時間とリソースに収めるために「システムが一部のデータを除外する場合がある」とGoogleは警告しています。

この上限は1日分のデータごとに数えられます。Googleが、1日分のデータには検索タイプごと（ウェブ、画像、動画、ニュース、Discover、Googleニュースはそれぞれ別のリクエストが必要）に1日1クエリずつ実行することを勧めているのはそのためです。30日間の範囲を30回の1日単位のリクエストで取得すると、1か月分を1回のリクエストで取得するよりもはるかに多くの行が返ることがあります。クォータがその妨げになることはまずありません。Search Analyticsでは、サイトごと・ユーザーごとに1分あたり1,200クエリ、Cloudプロジェクトごとに1分あたり40,000クエリ、1日あたり30,000,000クエリまで利用できます。実際に影響するのは、10分単位と1日単位で測られる負荷クォータで、ページとクエリ文字列の両方でグループ化または絞り込んだクエリが最もコストが高く、6か月の範囲は1日の範囲よりはるかにコストがかかると、Googleは明言しています。

BigQueryへの一括データエクスポート：有効にした日から、すべての行

一括データエクスポートは、パフォーマンスデータを毎日Google BigQueryプロジェクトにダンプするようスケジュールします。Googleはこれを「匿名化されたクエリを除く、プロパティについてSearch Consoleが利用できるすべてのパフォーマンスデータ」を含むものと説明し、公開時の投稿では「一括データエクスポートは1日の行数上限の影響を受けない」とはっきり述べています。作成されるテーブルは3つで、searchdata_site_impression（プロパティ単位で集計）、searchdata_url_impression（URL単位で集計）、成功したエクスポートのExportLogです。設定できるのはプロパティのオーナーだけです。

落とし穴は2つあります。1つ目は、ゼロから始まることです。最初のエクスポートは設定の48時間後までに行われ、「エクスポート当日のデータを含む」とされています。それ以前のデータについては、Google自身が「Search Console APIまたはレポートを使う」と案内しています。つまり、Search Consoleがすでに保持している16か月分はAPIから取得するしかなく、待った日数だけ、エクスポートには永久に残らない日が増えます。2つ目はコストです。請求が有効なGoogle Cloudプロジェクトが必要で、Googleは「データにはGoogle Cloudのストレージ費用とクエリ費用がかかるが、無料の利用枠がある」と書いています。パーティションの有効期限を設定しない限りデータは永遠に蓄積されるため、ストレージは毎日増えます。Google自身の公開時の投稿でも、このエクスポートは主に大規模サイト向けであり、「小規模・中規模のサイトは、画面、Looker Studioコネクタ（旧称Data Studio）、Search Analytics APIを通じて、すでにすべてのデータにアクセスできる」と指摘されています。

クロール統計レポートから1,000行を超えて取得するには？

完全な一覧は取得できません。回避策を試す前に、その理由を知っておくと役に立ちます。クロール統計レポート（設定 > クロール統計。ドメインプロパティとルートレベルのURLプレフィックスプロパティでのみ利用可能）には、クロールリクエスト、ダウンロードサイズ、レスポンス時間の合計が表示され、レスポンスコード、ファイルタイプ、クロールの目的、Googlebotタイプをそれぞれクリックして、サンプルのURLを確認できます。Googleはそのサンプルを次のように説明しています。「URLの例は網羅的ではなく、代表的な例にすぎない。一覧にURLがなくても、リクエストしなかったという意味ではない」。Googleのヘルプページにはこれらの一覧の行数は書かれていませんが、画面ではサンプルの表とそのエクスポートは1,000行で止まります。これはGoogleがページのインデックス登録のサンプルについて明記している上限と同じで、エクスポートには、いま見ているグラフと表しか含まれません。

画面を迂回できるAPIもありません。GoogleのAPIリファレンスが挙げているサービスはSearch Analytics、Sitemaps、Sites、URL Inspectionの4つで、クロール統計はその中にありません。つまり、私のものも含め、サードパーティのツールがGoogleのクロール統計を代わりに取得することはできません。有効な方法は次のとおりです。

1. サーバーのログファイルを読む。Googlebotがリクエストしたすべてを漏れなく記録した、唯一のものです。すべてのURL、ステータスコード、タイムスタンプ、ユーザーエージェントが残っています。カウントする前に、そのリクエストが本当にGoogleから来たものか確認してください。Googleの通常のクローラーはcrawl-***-***-***-***.googlebot.comまたはgeo-crawl-***-***-***-***.geo.googlebot.comに名前解決され、GoogleはそれらのIPレンジをcommon-crawlers.jsonとして公開しています。レポートとの小さな差は想定しておいてください。Googleは、クロール統計が「現在はほとんどのクロールリクエストを報告するが、カウントされないリクエストもある」と注記しています。
2. スライスごとに別々にエクスポートする。レスポンス、ファイルタイプ、目的、Googlebotタイプの各表の行にはそれぞれ専用のサンプルリストがあるため、404の行、301の行、HTMLの行、refreshの行などを個別にエクスポートすれば、1つではなく複数の異なるセットが手に入ります。ドメインプロパティでは、ホストをクリックしてその子ドメインに絞ったレポートを開くこともできますが、Googleが一覧に表示するのは、過去90日間にトラフィックがあった上位20件の子ドメインだけです。
3. 定期的にエクスポートして統合する。Googleによると、サンプルの件数は「日ごとに重み付けされることがある」ものの、それは「時間の経過とともに均等になるはず」とのことなので、サンプルは日によって入れ替わります。必要なスライスを毎週エクスポートして重複を取り除けば、1回のエクスポートよりずっと長いリストができます。これはGoogleが文書化している方法ではなく、私なりの回避策です。
4. 重要なURLを検査する。URL Inspection APIは、1つのURLについてlastCrawlTimeとcrawledAsを返します。クォータはサイトごとに1日2,000件、1分あたり600件です。クロール統計の代わりにはなりませんが、主要なテンプレートについて「Googleがこのページを最後にクロールしたのはいつか」には答えられます。
5. Bingのクロールデータも併用する。Bing Webmaster ToolsはAPIでクロールデータを公開しています。GetCrawlStatsは、クロールされたページ数、2xx・301・302・4xx・5xxのレスポンス、robots.txtでブロックされたページ、DNSの失敗、接続タイムアウトの日次件数を返し、GetCrawlIssuesはクロールの問題があるURLを一覧にします。これはGooglebotではなくBingbotのデータですが、Bingbotが踏んだ壊れたリダイレクトチェーンや連続した404は、たいていGooglebotにとっても同じ状態です。2つのツールの違いはBing Webmaster ToolsとGoogle Search Consoleの比較にまとめています。

Looker StudioコネクタにもAPIと同じ上限がある

Looker Studio用のSearch Consoleコネクタは、コードを書かずに1,000行を超える便利な方法ですが、APIの上限を超える方法ではありません。Googleの詳細解説には、上限は「Search Analytics API（およびLooker Studioコネクタ）でエクスポートするデータについては、サイト・検索タイプごとに1日50,000行」と書かれています。コネクタにはサイトのインプレッションテーブルとURLのインプレッションテーブルがあり、1つのデータソースで使えるのはどちらか一方だけなので、両方の集計が必要なレポートにはデータソースが2つ必要です。Googleのドキュメントにはいま「Looker Studioは現在Data Studioという名前になっている」という注記があるため、どちらの名前も目にすることがあります。

行数を増やす方法の比較

これらの方法はどれもクロール統計レポートをカバーしません。そもそもできないからです。このデータは管理画面の外では入手できません。

GSC Wizardが1,000行の壁を超える方法

GSC Wizardは同じSearch Analytics APIを通じてSearch Consoleを読み取るため、Googleが出さないデータは見えませんが、ページ送りと保存は代わりに行います。APIで接続したプロパティでは、クエリとページの全件テーブルが、1,000行で止まる代わりに、Googleの結果を25,000行ずつ、最大500,000行までページ送りして取得します。フルストレージのプロパティでは、直近480日分（Googleが保持する約16か月に相当）をウェアハウスにバックフィルし、その後は新しい日のデータを入ってくるたびに追加します。Googleの推奨どおり、1日ずつ別々に、ウェブ、画像、動画、ニュース、Discoverについて、また、クエリ、ページ、国、デバイスと、その組み合わせ（ページ×クエリ、国×クエリ、デバイス×クエリ、国×ページ、デバイス×ページ）について取得し、Googleが返すすべての行を保存します。ウェアハウスにある大規模なプロパティの1つでは、2026年9月のある1日だけで37,601件の異なるクエリがあり、その日を1,000行でエクスポートしても到底及びません。

データを保存しているため、履歴はGoogleの16か月を超えて伸び続けます。フルストレージで1年経つと、プロパティには約28か月分の履歴があり、プランによっては最大10年まで保持されます。どのテーブルも、すべての行を含むCSV、または自己完結型のHTMLレポートとしてエクスポートできます（詳しくはエクスポートのドキュメントを参照）。エクスポートのファイル名には期間が入ります。プロパティのサンプリングレポートでは、お使いのプロパティでGoogleがクエリとページのテーブルから除外しているクリック数が分かります。これはどのツールでも復元できない部分です。フルストレージはすべてのプランに含まれています（Starterは5プロパティ、Proは25、Businessは150）。詳しくは料金をご覧ください。

限界もあります。GSC WizardはGoogleのクロール統計を表示しません。読み取れるAPIがないからです。一方、Bing Webmaster Tools APIからBingのクロールデータは表示しており、Bingの概要にはクロールされたページ数、クロールエラー、robots.txtでブロックされたページを、Bingクロールの問題レポートにはURLごとの一覧を表示します。また、Googleの最終クロール日時はURLごとにURL Inspectionで表示します（Googleの1日2,000件のクォータの範囲内）。Googlebotのリクエストをすべて確認したい場合はログファイル解析ツールのほうが適しています。エンジニアとCloud予算を持つ非常に大規模なサイトなら、ほかに何を使っていても、BigQueryへの一括エクスポートを今すぐ設定する価値があります。開始前の日々を後から埋めることは決してできないからです。