はじめに
ブログの記事テーマを考えるうえで、Google Search Consoleは非常に役に立つ。
筆者はこのブログ「社内SE3割増し」で、社内SEや情シス担当者向けの記事を書いている。記事を増やしていく中で、次に何を書くべきかを考える場面が増えてきた。
そのとき、単にAIへ「記事テーマを考えて」と頼むだけでは弱い。
そこで筆者は、Search Consoleのデータを使って、実際に検索結果に表示されているクエリから記事候補を見つける仕組みを作ることにした。
今回作ったのは、Search Console APIから検索パフォーマンスデータを取得し、CSVとして保存する処理である。
取得したデータは、その後の工程で以下のように使う。
Search Console APIから検索クエリを取得
↓
WordPress既存記事と照合
↓
新規記事・リライト・追記候補に分類
↓
承認キューに出力
↓
人間が採用したものだけ記事化
本記事では、このうち最初の入口である「Search Console API取得」の部分について紹介する。
Search Consoleは記事テーマ探しの宝庫である
Search Consoleを見ると、自分のサイトがどの検索語句で表示されているかが分かる。
たとえば、社内SE向けブログであれば、次のような検索語句が見つかる可能性がある。
Teams 添付ファイル 開けない
Outlook 文字化け UTF-8
SharePoint 404 復旧
Windows.old 削除していい
Microsoft Authenticator 強制
こうした検索語句は、読者が実際に困っている内容に近い。
AIが考えた抽象的なテーマよりも、Search Consoleに出てくる検索語句の方が、読者の悩みを直接表している場合がある。
たとえば、AIにテーマを考えさせると、次のような案が出るかもしれない。
Teamsを業務効率化に活用する方法
一方で、Search Consoleには次のような具体的な検索語句が出ることがある。
Teams 添付ファイル 開けない
後者の方が、困っている読者の姿を想像しやすい。
記事としても、原因、確認手順、管理者側の確認ポイント、一般ユーザーへの案内文などに展開しやすい。
画面で見るだけでは続きにくい
Search Consoleの管理画面は便利である。
しかし、ブログ運営の作業として継続的に使うには、画面を眺めるだけでは続きにくい。
筆者が感じた問題は以下である。
- 毎回Search Consoleを開いて確認するのが面倒
- 気になった検索語句を手作業でメモする必要がある
- 既存記事との照合が手作業になる
- リライト候補と新規記事候補を分けにくい
- 外部テーマ収集や記事構成案生成につなげにくい
Search Consoleの画面を見るだけでは、データが作業フローに乗りにくい。
そのため、筆者はSearch Console APIを使って、検索パフォーマンスデータをCSVとして保存することにした。
CSVになれば、Pythonで読み込み、既存記事と照合し、優先度を付け、記事候補として扱える。
つまり、Search Consoleを「見るもの」から「処理できる材料」に変えるのである。
取得したかったデータ
今回取得したかったデータは、主に以下である。
- query
- page
- clicks
- impressions
- ctr
- position
- start_date
- end_date
- source
それぞれの意味は、ざっくり言えば以下である。
| 項目 | 意味 |
|---|---|
| query | 検索語句 |
| page | 検索結果に表示されたページ |
| clicks | クリック数 |
| impressions | 表示回数 |
| ctr | クリック率 |
| position | 平均掲載順位 |
| start_date | 集計開始日 |
| end_date | 集計終了日 |
| source | データ取得元 |
この中で、記事テーマ探しに特に重要なのは、query、page、impressions、ctr、position である。
筆者が見たかったのは、単にクリック数が多いキーワードではない。
むしろ、次のような検索語句である。
表示回数はある
クリック率が低い
平均掲載順位が8〜30位くらい
既存記事で十分に扱えていない
このような検索語句は、記事を追加したり、既存記事を改善したりすることで伸ばせる可能性がある。
query単位とquery×page単位を分けた理由
Search Console APIからは、ディメンションを指定してデータを取得できる。
今回、筆者は大きく2種類のCSVを出力するようにした。
query単位
query × page単位
query単位
query単位では、検索語句ごとにデータを見る。
出力イメージは以下である。
query,clicks,impressions,ctr,position,start_date,end_date,source
teams 添付ファイル 開けない,10,500,0.02,12.4,2026-02-01,2026-05-01,search_console_api
この形式では、どの検索語句でサイトが表示されているかを把握できる。
記事テーマ候補の入口としては、これだけでもかなり役に立つはずだ。
query×page単位
一方で、query単位だけでは足りない。
なぜなら、その検索語句で、どの記事が表示されているのかが分からないからである。
そこで、queryとpageを組み合わせたデータも取得するようにした。
出力イメージは以下である。
query,page,clicks,impressions,ctr,position,start_date,end_date,source
teams 添付ファイル 開けない,https://example.com/teams-file-error/,10,500,0.02,12.4,2026-02-01,2026-05-01,search_console_api
この形式にすると、特定の検索語句に対して、どの記事が表示されているかが分かる。
これは後工程で非常に重要である。
queryだけでは次の行動が決めにくい
たとえば、Search Consoleに次の検索語句が出ていたとする。
Outlook 文字化け UTF-8
query単位では、この検索語句があることは分かる。
しかし、どの記事が表示されているかは分からない。
もし既存のOutlook記事が表示されているなら、その記事にUTF-8関連の見出しを追記すればよいかもしれない。
一方で、まったく関係の薄い記事が表示されているなら、新規記事を作った方がよい可能性がある。
つまり、次の行動が変わる。
既存記事が表示されている
→ 追記・リライト候補
関係の薄い記事が表示されている
→ 新規記事候補
複数ページが表示されている
→ カニバリや重複テーマの確認候補
この判断をするために、query×page単位のデータが必要である。
ブログ改善では、検索語句だけでなく「どの記事がその検索語句に反応しているか」を見ることが重要である。
Codexに作らせた処理
今回、筆者はCodexにSearch Console API取得処理を実装させた。
Codexに依頼した内容は、ざっくり言えば以下である。
Search Console APIから検索クエリを取得する
query単位とquery×page単位の2種類を取得する
取得結果をCSVに保存する
OAuth認証に対応する
トークンを保存して次回以降も使えるようにする
API取得に失敗したら手動CSVにフォールバックする
ログを残す
実装した主なファイルは以下である。
scripts/fetch_search_console_api.py
data/search_console_queries_api.csv
data/search_console_query_pages_api.csv
logs/search_console_api.log
実際の運用では、次のようなコマンドで取得できるようにした。
python scripts/fetch_search_console_api.py --days 90
また、期間を指定して取得することもできるようにした。
python scripts/fetch_search_console_api.py --start-date 2026-02-01 --end-date 2026-05-01
これにより、必要に応じて直近90日分を取得したり、特定期間を再取得したりできる。
API認証は一度通せば次回から楽になる
Search Console APIを使うには、Google Cloud側でAPIを有効化し、OAuthクライアントを作成する必要がある。
今回の仕組みでは、初回実行時にブラウザでGoogleアカウント認証を行い、認証後にトークンを保存するようにした。
保存先は次のようなファイルである。
secrets/google_token.json
2回目以降は、保存済みトークンを使う。
ただし、secrets 配下には認証情報が含まれるため、GitHubには上げない。
このあたりは、自動化ツールを作る上でかなり重要である。
API連携そのものよりも、認証情報を安全に扱うことの方が事故りやすい。
OAuthクライアント
OAuthクライアントだが、項目名が微妙に違ったりしながらもchatGPTに聞いて簡単に設定できた。
OAuthクライアントの設定としてクライアントシークレットを取るのとテストユーザのGoogleアカウントを登録する必要がある。
今回のようなAPI通信アプリを登録する場合、自分しか使わないので公開ステータスはテスト中のままでよく、その場合はアクセスできるテストユーザを登録しておく必要がある。
テストユーザの設定を忘れるとSearch Console APIがエラーを返すので注意（何回かやった）。
しかしこの辺りのメニューはGoogleCloudの画面を開いて右上のコンソール→ダッシュボードという流れで開いていたがもっと直接開けるルートはないのだろうか。
APIが失敗してもCSVで続けられるようにした
今回の実装で重視したのは、API取得に失敗しても処理全体を止めないことである。
API連携は、さまざまな理由で失敗する。
- OAuth認証ファイルがない
- Google Cloud側でAPIが有効化されていない
- Search Consoleの権限がない
- siteUrlの指定が違う
- ネットワークエラーが発生する
- トークンが無効になる
こうしたエラーがあるたびにブログ自動化全体が止まると、運用しにくい。
そこで、API取得に失敗した場合は、従来の手動CSVを使えるようにした。
API版CSVがある
→ data/search_console_queries_api.csv を使う
API版CSVがない
→ data/search_console_queries.csv を使う
このように、手動インポートへの逃げ道を残した。
自動化では、成功ルートだけでなく、失敗したときの逃げ道を考慮しておくのも重要である。
siteUrlの指定で少し迷った
Search Console APIでは、対象サイトを siteUrl として指定する。
筆者のサイトでは、Search ConsoleのプロパティがURLプレフィックスだったため、次の形式で指定した。
https://syanaise3wariup.com/
ここは少し注意が必要である。
Search Consoleには、URLプレフィックスプロパティとドメインプロパティがある。
URLプレフィックスなら https://example.com/ のような形式になる。
一方、ドメインプロパティなら sc-domain:example.com のような形式になる。
この指定がSearch Console上のプロパティと合っていないと、API取得に失敗する。
そのため、siteUrl は固定値としてコードに埋め込まず、.env から読み込むようにした。
SEARCH_CONSOLE_SITE_URL=https://syanaise3wariup.com/
このようにしておけば、環境やサイトを変えたときにも修正しやすい。
rowLimitとページングにも対応した
Search Console APIでは、一度に取得する行数に上限がある。
そのため、取得件数を増やす場合は rowLimit を指定し、必要に応じて startRow を使ってページングする設計にした。
今回の設定では、.env に以下のような項目を持たせた。
SEARCH_CONSOLE_ROW_LIMIT=25000
この値もコードに直接書かず、設定で変えられるようにした。
小規模なブログであれば、それほど大量の行数にはならないかもしれない。
しかし、後から記事数が増えた場合や、query×page単位で取得する場合に備えて、ページングできる設計にしておく方が安全である。
取得したデータをどう記事候補に変えるか
Search Console APIでデータを取得しただけでは、まだ記事候補にはならない。
取得したデータを、次のような観点で見ていく必要がある。
表示回数はあるか
クリック率は低くないか
平均掲載順位は改善余地があるか
既存記事と関連しているか
既存記事で十分に扱えているか
たとえば、表示回数が多く、掲載順位が8〜30位あたりにある検索語句は、改善余地があるかもしれない。
CTRが低い場合は、タイトルやメタディスクリプションの改善候補になる。
query×pageで見ると、どの記事がその検索語句に反応しているかも分かる。
つまり、取得したデータは次の工程で使う材料である。
Search Console API取得
↓
既存記事との照合
↓
新規記事・リライト・追記候補に分類
この3本目の記事ではAPI取得までを扱っているが、本当に重要なのは次工程である。
Search Consoleのデータを既存記事と照合して初めて、具体的な改善アクションに変えられる。
実装して感じた注意点
Search Console API連携を作って感じた注意点は、以下である。
認証情報をGitHubに上げない
Google OAuthのクライアント情報やトークンは、secrets に置くようにした。
これらはGitHubに上げない。
.gitignore で除外し、.env.example にはダミー値だけを置く方針にした。
API取得だけで完結させない
Search Console APIでデータを取ること自体が目的ではない。
目的は、ブログの記事テーマ候補を見つけることである。
そのため、CSV出力後に既存記事照合やスコアリングへつなげる前提で作った。
手動CSVの逃げ道を残す
APIは便利だが、認証や権限で止まることがある。
そのため、手動でエクスポートしたCSVを使えるようにしておくと安心である。
完全自動化よりも、止まらない運用を優先した。
query×pageを取る
query単位だけでは、検索語句と記事の関係が見えにくい。
query×pageを取得することで、どの記事を直すべきか判断しやすくなる。
これは今回かなり重要な設計ポイントだった。
まとめ
筆者は、ブログ記事テーマの収集を効率化するために、Search Console APIから検索パフォーマンスデータを取得する仕組みを作った。
取得したのは、検索クエリ、表示ページ、クリック数、表示回数、CTR、平均掲載順位などである。
特に、query単位とquery×page単位の2種類を取得するようにした点が重要である。
query単位では、どの検索語句で表示されているかが分かる。
query×page単位では、その検索語句でどの記事が表示されているかが分かる。
このデータを使うことで、AIの思いつきではなく、実際の検索行動に近いテーマ候補を集められる。
ただし、Search Console APIでデータを取るだけでは不十分である。
次に必要なのは、取得した検索クエリをWordPress既存記事と照合し、新規記事、リライト、追記候補に分けることである。
次回は、このSearch Consoleデータと既存記事を照合し、記事テーマ候補を分類する仕組みについて紹介する予定である。
コメント