サーチコンソールのAPIで何ができる？

Search Console のデータを毎回画面から手動で取得するのは手間がかかります。そのため、プログラムで自動的に取得できないかと考える方が多いようです。
API を活用すると、作業の自動化や料金の有無、取得できるデータ範囲を確認できます。これらは事前にチェックしておくことが重要です。

この記事では、サーチコンソール API が提供する4つの主要サービスと利用上限やデータ取得上限、安定運用のためのクエリ設計のポイントを Google の公式情報を基にまとめます。
本文を読み終える頃には、API を自社サイトのどの業務に適用すべきか判断でき、制限に悩むことなくデータ活用の仕組みを設計できるようになるでしょう。まずは小さなクエリから試すと、実際の挙動が掴みやすくおすすめです。

サーチコンソール APIは、検索データの取得や管理を自動化できる、無料で提供されている公式の API です

サーチコンソール API（Google Search Console API）は、Google Search Console の機能の一部をプログラムから呼び出すことができる公式 API です。
検索パフォーマンスの取得、サイトマップの管理、プロパティの確認、URL のインデックス状態の検査を自動化できます。

この API は無料で使用できます。
ただし、リクエスト回数や処理負荷に対してクォータ（利用上限）が設定されており、パフォーマンスデータについては 1 プロパティ・検索タイプごとに 1 日あたり最大 5 万行というデータ上限が設けられています。

そのため、「1日分ずつ小分けに取得して自前で保存する」設計を基本にすれば、安定的に活用しやすくなります。設計を重視することで、運用が格段に楽になると感じます。

APIの機能と制限を把握することが、活用の土台になります

サーチコンソール APIは便利ですが、画面上の操作と同様に無制限に利用できるわけではありません。
この記事では、主要なサービスの概要と、運用時に留意すべき制限について順に説明します。

APIが提供する4つの主なサービス

公式APIリファレンスでは、主要サービスとして以下の4つが紹介されています。

Search Analytics

クリック数や表示回数、CTR、平均掲載順位といった検索パフォーマンスを取得できるサービスです。
日付、ページ、クエリ、国、デバイスなどのディメンションを指定し、求める切り口でデータを抽出できます。
多くの利用者がサーチコンソール APIに期待するのは、まさにこの機能です。実際にデータを絞り込むと、分析の幅が広がるのが実感できます。

Sitemaps

サイトマップの一覧表示・取得・送信・削除を行うサービスです。
複数サイトを管理していても、サイトマップの送信状況を一括で確認しやすくなります。

Sites

Search Consoleに登録されたプロパティの一覧表示・追加・削除・取得を行うサービスです。
多数のプロパティを管理する担当者にとって、棚卸し作業の自動化に活用できるでしょう。

URL Inspection

指定したURLのGoogleインデックス上の情報を取得できるサービスです。
特定のページがインデックスに含まれているかどうかを、プログラムから確認できます。

• Search Analytics：検索パフォーマンスの取得
• Sitemaps：サイトマップの一覧・取得・送信・削除
• Sites：プロパティの一覧・追加・削除・取得
• URL Inspection：URLのインデックス情報の取得

無料で利用できるものの、いくつかの上限が設定されています

APIは無料で利用できますが、いくつかの制限があります。
特にSearch Analyticsを利用する際は、以下のポイントを確認しておくことが重要です。

リクエスト回数の上限と負荷上限は別々に設定されています

公式の「Usage Limits」によれば、Search Analyticsにはクエリ回数の制限に加えて、10分単位と1日単位の「負荷（load）」制限が設けられています。
リクエスト頻度を減らしても、1回のクエリが重いと負荷上限に達することがあります。

上限を超えると、同じ形式のエラーが返されます。
そのため、エラーが発生した際はリクエスト数だけでなく、照会期間の長さやディメンションの組み合わせといったクエリの複雑さも見直すことが推奨されます。

1日あたり最大5万行のデータ上限があります

パフォーマンスデータを取得する際、1プロパティ・検索タイプごとに1日最大5万行という上限があります。
また、1回のレスポンスで取得できる行数にも制限が設けられています。

そのため、APIの結果を「全データの完全な一括出力」や完全なログデータと同等に扱わないことが重要です。
特に、ページ数やクエリが多数ある大規模サイトでは、取得可能な範囲を前提に分析を設計する必要があります。

URL Inspectionは対象を絞った診断向けです

URL Inspection APIには、プロパティごとに1日2,000回、1分に600回という利用上限があります。
大規模サイトの全URLを毎日検査する用途には不向きで、重要なページや問題が疑われるページに絞って利用するのが適切です。

なお、URL Inspectionはインデックス状態を「確認」するための機能であり、インデックス登録を依頼する機能ではない点に注意が必要です。

画面上の機能がすべてAPIで取得できるとは限りません

Search Consoleの画面で確認できるレポートが、APIでも同じ粒度や形式で取得できるとは限りません。
利用前にAPIリファレンスを確認し、必要なディメンションやデータ種別に対応しているかを検証しておくことが重要です。

例えば2026年に、生成AI検索に関するSearch Consoleの新しいインサイトが発表され、8月末までに全世界のサイトへ展開されたとGoogleは説明しています。
ただし、こうした新機能のデータがAPIから取得できるかは、別途APIの仕様を確認する必要があります。
画面上の新機能とAPIで取得できるデータを混同しないよう注意しましょう。

クォータや仕様は変更される可能性があります

APIのクォータや仕様は、将来的に変更される可能性があります。
本記事で示した数値も、実装や運用ルールを決める際には、Googleの公式「Usage Limits」や対象APIのリファレンスで最新情報を確認することをおすすめします。

サーチコンソール APIの活用例を目的別に紹介

以下では、サーチコンソール APIの主な活用シーンを取り上げます。
自社の課題と似たケースを参考にすれば、設計イメージをつかみやすくなるでしょう。

活用例1：検索パフォーマンスを日次で自動取得し蓄積

最も一般的な手法は、Search Analyticsから検索パフォーマンスを定期的に取得し、データベースやスプレッドシートへ蓄積することです。

基本は、1日分ずつ取得することです

Googleは公式資料「Getting your performance data」で、1日分のデータを日々取得する手順を示しています。
過去データを何度も再取得するのではなく、取得結果を自前で保存して活用する設計が有効です。

• 毎日決まった時間に前日分のデータを取得する
• 取得したデータを自社のデータベースなどに保存する
• 分析やレポート作成は、保存済みのデータを使って行う

このやり方なら、広範囲を一括で照会する重いクエリを回避でき、負荷上限に達しにくくなります。
PythonでOAuth認証を設定して実装する例や、BigQueryなどのデータ基盤と連携する例もあります。

ディメンションの組み合わせは、目的に応じて選定します

ページとクエリを同時に細分化すると、データ量が増えて負荷制限に近づくことがあります。
「ページ別の推移を見たい」「クエリ別の傾向を見たい」など、目的別に必要なディメンションだけに絞ってリクエストを分割すれば、効率的に取得できます。

活用例2：サイトマップとプロパティ管理の効率化

複数のサイトやプロパティを運用している場合、Sitemaps と Sites のサービスが有用です。

サイトマップの送信状況を一括で確認

Sitemaps APIを使うと、各プロパティに登録されたサイトマップの一覧を取得したり、新しいサイトマップを送信したりできます。
サイト数が多いほど、画面で1つずつ確認する手間を省ける効果は大きくなると思われます。

プロパティの棚卸しを自動化

Sites APIでプロパティ一覧を取得すれば、管理対象のサイトが漏れなく登録されているかを定期的にチェックできます。
担当者の異動やサイト追加が頻繁な組織では、管理状況の可視化に役立つ可能性があります。

活用例3：重要ページのインデックス状態を定期的にチェック

URL Inspection APIを利用すれば、指定したURLがGoogleインデックスにどのように登録されているかを確認できます。

対象ページを絞り込んで検査

前述のとおり、プロパティごとに1日2,000回、1分600回の上限があります。
そのため、対象を絞って運用するのが現実的です。

• 売上や問い合わせにつながる重要ページ
• 新しく公開したばかりのページ
• 検索流入が急に減ったページ

未登録ページが見つかった際の対応を事前に決めておく

検査の結果、インデックスに未登録のページが見つかることがあります。
その際は、最初にnoindex設定やrobots.txtでのブロック、ページの公開状態、内容の薄さや重複がないかを確認することが先決です。
これらの設定や内容に問題がある場合、修正しなければ登録は期待しにくいでしょう。

問題がないにもかかわらず登録が進まない場合は、Search Consoleの「インデックス登録をリクエスト」を使う方法があります。
ただ、対象のURLが多いと1件ずつの操作は負担になりがちです。
そのような場面では、このブログを運営しているインデックスドライブのように、公開中のページのURLを1行に1つ貼ってまとめて送り、インデックス登録を後押しするサービスも選択肢の1つになります。
インデックスドライブはSearch ConsoleやAPIの登録が不要なため、API実装とは別に、手軽に登録を促したいときに利用できます。

活用例4：Search Console の新機能は API 対応を確認してから導入

Search Console には新しいレポートやインサイトが追加されることがあります。
2026年に導入された生成AI検索に関するインサイトのように、注目度の高い機能は自動取得したいと考える方が多いでしょう。

しかし、画面に表示される機能がすべてAPIで取得できるわけではありません。
社内のレポート設計に組み込む前に、APIリファレンスで対応状況を確認し、未対応の場合は画面での確認を併用するといった運用が安全です。

制約を考慮した設計で、APIは有力な分析基盤となります

サーチコンソール APIは、Search Console の一部機能をプログラムから無償で利用できる公式のインターフェースです。
提供される主なサービスは Search Analytics、Sitemaps、Sites、URL Inspection の４種類で、検索データの取得やサイトマップの管理、インデックス状況のチェックなどを幅広く自動化できます。

しかし、実際に運用する際には以下の点に留意する必要があります。

• リクエスト回数の上限と、10分単位・1日単位の負荷上限は別物である
• パフォーマンスデータは1プロパティ・検索タイプごとに1日最大5万行の上限がある
• URL Inspectionはプロパティあたり1日2,000回、1分あたり600回までで、対象を絞った診断向けである
• 画面上の機能がすべてAPIで取得できるとは限らない
• クォータや仕様は変更される可能性があるため、公式情報で再確認する

1 日単位でデータを取得し、独自に保存するという基本方針を守ることで、クォータに悩むことなく安定したデータ活用基盤を作れるでしょう。

サーチコンソール APIを活用して検索データやインデックス状況を取得できれば、未登録ページへの対策が次の課題として浮かび上がります。
設定や内容に問題がないことを確認したうえで、公開中のページ URL を送信するだけでインデックスを促進できるインデックスドライブを併用すれば、分析から改善への流れがスムーズになるでしょう。ここで、実際に自動化を組み込むと作業効率が格段に上がると実感します。