Search ConsoleとGA4を毎週確認しても、「結局どの記事を直せばよいのか」が決まらなければ改善にはつながりません。そこで、WordPressの公開記事を基準にデータをまとめ、AIが確認すべき記事を絞り込む流れを作ります。
この記事では、初心者でも全体像をつかめるように、確認する指標、3期間の比較、公開直後・データ不足の保留、候補が出た後の判断まで順番に解説します。最初は手動で試し、必要になった段階でAPIによる週次取得へ移行できます。
自動化するのは収集と候補抽出までです。記事の修正や公開は自動化しません。
この記事でできるようになること
- Search Console、GA4、WordPressの役割を分けて確認できる
- 毎週同じ期間と指標で記事を比較できる
- 公開直後やデータ不足の記事を誤って修正候補にしない
- 表示回数、CTR、セッションなどから次に確認する記事を絞り込める
- 候補0件の週は、無理にリライトせず次の観測を待てる
Google Analyticsの管理画面でSearch Consoleをリンクする標準機能もありますが、本記事の方法はそれだけで完結するものではありません。WordPressの公開記事一覧を母集団にして、Search ConsoleとGA4のデータをURL単位で別々に取得・照合します。
自動化するのはデータ収集と改善候補の抽出まで
週次分析では、次の5段階に分けると誤修正を避けやすくなります。
- WordPressから公開記事一覧と公開日を取得する
- Search ConsoleとGA4から記事別データを取得する
- 直近28日、前の28日、直近90日を同じ形式で集計する
- 公開直後やデータ不足の記事を保留する
- 条件を満たした記事だけを人間の確認候補にする
AIに任せるのは、数値の整理、期間比較、候補理由の文章化です。タイトル変更、リライト、記事統合などは、対象クエリと本文を確認してから決めます。
Search Consoleのデータを手動で出力し、AIへ渡して分析する方法は「Search ConsoleをAIに分析させる方法」で解説しています。この記事では、その前段となる週次取得とデータ不足の判定に絞ります。
最初は手動で同じ流れを試せる
最初からAPIや定期実行を組む必要はありません。まずは次の手順で1回分の分析を作ると、必要な項目と判断基準を確認できます。
- WordPressから公開記事のURLと公開日を一覧にする
- Search Consoleからページ別のクリック、表示回数、CTR、平均掲載順位を出す
- GA4からランディングページ別のセッションとエンゲージメント指標を出す
- URL表記をそろえて一つの表へまとめる
- 公開直後・データ不足の記事を除外し、残った記事だけを確認する
この手順を毎週繰り返す負担が大きくなったら、取得と集計をAPIへ置き換えます。先に手動版を試すことで、不要な指標まで自動化することを避けられます。
記事数を増やすだけでは改善点が分からなかった
サイト運営を始めた頃は、まず記事数を増やすことが重要だと考えていました。しかし、運営期間が長くなると、記事を追加するだけでなく、公開後の数字を見て改善するサイクルが必要だと感じるようになりました。
そこでSearch ConsoleとGA4を手動で確認しようとしましたが、そもそも何をどう分析すればよいのか分かりませんでした。数字を開いても、表示回数、CTR、掲載順位、セッションのどれを優先するのか、データが少ない記事を変更してよいのか判断できなかったためです。
この問題を解決するため、毎週同じ期間と基準でデータを集め、判断材料が足りない記事には結論を出さない仕組みを作りました。
これは一つのサイトでの運用経験です。自動化による順位上昇やアクセス増加を示す実績ではありません。
Search ConsoleとGA4では分かることが違う
Search ConsoleとGA4は、同じ記事を見ていても測定対象が異なります。片方の数字だけで記事の状態を決めず、役割を分けて扱います。
| データ | 主に確認する項目 | 分かること | 単独では分からないこと |
|---|---|---|---|
| Search Console | クリック、表示回数、CTR、平均掲載順位、クエリ | Google検索での表示とクリック | 記事を開いた後の行動 |
| GA4 | セッション、アクティブユーザー、エンゲージメント率、平均セッション時間 | 記事へ到達した後の利用状況 | Google検索で表示された回数や順位 |
| WordPress | 投稿ID、URL、公開日、更新日、公開状態 | 分析対象となる公開記事と経過日数 | 検索結果や訪問後の行動 |
Googleは、Search ConsoleとGoogle Analyticsでは集計方法、タイムゾーン、プライバシー処理などが異なるため、数値が完全には一致しないと説明しています。両者を無理に同じ数字へ合わせるのではなく、検索上の露出と訪問後の行動を別の信号として使います。
参考（2026年8月19日確認）: Search Consoleのデータについて、GA4 Data APIの指標定義
週次分析の全体像
実際の処理では、先にWordPressの公開記事一覧を取得します。その後、Search ConsoleとGA4の結果をURL単位で照合します。
この順番にする理由は、アクセスがない記事も分析対象から消さないためです。Search ConsoleやGA4の取得結果だけを母集団にすると、データが0件の記事が一覧に現れない場合があります。
出力する記事別データの例は次のとおりです。
{
"page_path": "/sample-article/",
"published_days": 35,
"recent_28d": {
"gsc": {
"clicks": 3,
"impressions": 120,
"ctr": 0.025,
"average_position": 14.2
},
"ga4": {
"sessions": 8,
"engagement_rate": 0.62
}
},
"signals": ["insufficient_data"]
}この例のURLと数値は説明用です。実際の認証情報、プロパティID、サービスアカウント、非公開クエリは出力例に含めません。
データ不足で誤判定しない3つの仕組み
公開直後の記事はtoo_newにする
公開直後の記事は、同じ「直近28日」を指定しても、実際には数日分しかデータがありません。古い記事と同じ基準でCTRやセッションを比較すると、少数データから修正を決めることになります。
そこで、公開から一定日数に達していない記事には too_new を付け、改善候補から外します。ZenoPlusの初期設定では21日未満を公開直後として扱っています。この21日はGoogleの公式基準ではなく、運用上の初期設定です。サイトの更新頻度やデータ量に合わせて見直します。
少数データはinsufficient_dataにする
公開から日数が経っていても、表示回数とセッションが少なければ良否を判断できません。その場合は insufficient_data を付けます。
ZenoPlusでは、直近28日のSearch Console表示回数が30未満かつGA4セッションが10未満なら、データ不足として保留する設定から始めました。これも普遍的なSEO基準ではなく、小規模サイトで少数データによる誤判定を避けるための初期値です。
{
"too_new_days": 21,
"min_gsc_impressions": 30,
"min_ga4_sessions": 10,
"candidate_minimum": 0,
"candidate_maximum": 3
}閾値は固定の正解ではありません。データが蓄積したら、候補になった記事と実際に修正した記事を記録し、厳しすぎるか緩すぎるかを見直します。
改善候補0件を正常な結果として扱う
自動分析で避けたいのは、毎週必ずリライト対象を作ることです。条件を満たす記事がなければ、改善候補は0件で構いません。
候補の最小件数を0にし、最大件数だけを3件などに制限します。これにより、データが少ない週は変更せず、次回の観測を待てます。
候補0件は、順位改善に成功したという意味ではありません。「現時点の条件では、変更対象を決めるだけの材料がなかった」という分析結果です。
取得期間は直近28日だけにしない
直近28日だけを見ると、一時的な増減なのか、以前から続く傾向なのかを区別しにくくなります。週次分析では、次の3期間を保存します。
| 期間 | 用途 |
|---|---|
| 直近28日 | 現在の状態を確認する |
| 前の28日 | 直近期間との変化を見る |
| 直近90日 | より長い範囲で表示・流入の有無を見る |
前期間比が増えたという理由だけで改善成功とは判定しません。元の件数が少なければ、1クリックの差でも増加率は大きくなるためです。件数、記事の公開日、対象クエリを合わせて確認します。
候補が出たら数値と次の確認を結び付ける
AIには「良い・悪い」を断定させるのではなく、数値から次に人間が確認する項目を出させます。判断の入口は次のように整理できます。
| 観測した状態 | 最初に確認すること | すぐに変更しない条件 |
|---|---|---|
| 表示回数はあるがCTRが低い | 対象クエリ、検索意図、タイトル、説明文 | 表示回数が少ない、掲載順位が低すぎる |
| クリックはあるがGA4セッションが少ない | URL集計、計測設定、期間・タイムゾーン | GSCとGA4の数値差だけで記事不良と決めない |
| セッションはあるがエンゲージメントが弱い | 導入文、見出し、内部リンク、読者の目的との一致 | 計測定義や母数が不明なまま本文を変えない |
| 前の28日よりクリックが減った | クエリ別変化、順位、季節性、競合ページ | 1～2件程度の差や短期変動だけでリライトしない |
too_new / insufficient_data |
公開日、表示回数、セッション | 判断材料がたまるまで保留する |
この表は自動修正ルールではありません。改善候補を開いた後に、どこから確認するかをそろえるためのチェックリストです。
Search ConsoleとGA4をAPIで取得するときの注意点
Search Consoleは全行取得を保証しない
Search Analytics APIの公式仕様（2026年8月19日確認）では、結果は上位行に制限され、すべてのデータ行が返ることは保証されていません。1回のリクエストで指定できる rowLimit は最大25,000です。さらに取得する場合は、startRow を使ってページ送りします。
ZenoPlusの現行処理は1回25,000行までで、ページ送りは実装していません。現在の小規模なデータ量では上限に達していませんが、規模が大きくなった場合は追加対応が必要です。「Search Consoleの全データを完全取得する仕組み」とは表現できません。
また、Search Consoleでは匿名化されたクエリが表から省かれることがあります。行に存在しないクエリを「検索されていない」と断定しないでください。
確定データだけを使い、直近数日を外す
Search Consoleのデータは通常、利用可能になるまで2～3日かかります。Googleの全データ取得ガイド（2026年8月19日確認）でも、データは一般に2～3日後に利用できると説明されています。
週次処理では dataState を final にし、実行日の3日前までを対象にしています。これにより、遅延している可能性がある直近データを比較対象に含めにくくしています。ただし、3日前までにすればすべてのデータが完全に確定することを保証するものではありません。
Search Console APIの日付はPacific Time基準です。GA4はプロパティ側の設定も関係するため、両者の日別数値が完全に同じ時間境界になるとは限りません。記事単位の28日傾向を見る用途に限定します。
GA4も行数と割り当てを確認する
GA4 Data APIの基本仕様（2026年8月19日確認）では、runReport の既定行数は10,000、limit は最大250,000です。ZenoPlusの現行設定は100,000行で、これを超える場合のページ送りは実装していません。
GA4 Data APIには、リクエストの複雑さや期間などに応じた割り当てもあります。記事数や取得頻度を増やす場合は、Data APIの割り当てを確認してください。
認証情報をコードや分析結果へ入れない
定期実行では、Search ConsoleとGA4を読み取れる認証情報が必要です。しかし、サービスアカウントの秘密鍵をコード、Gitリポジトリ、記事用の画像、分析JSONへ入れてはいけません。
Googleは、可能ならユーザー管理のサービスアカウント鍵を避け、使用する場合もソースコードのリポジトリへ保存しないよう案内しています。
参考（2026年8月19日確認）: サービスアカウント鍵の管理に関するベストプラクティス
記事や画面例を公開するときは、少なくとも次を削除・置換します。
- サービスアカウントのメールアドレス
- 秘密鍵と認証JSONの保存場所
- GA4プロパティID
- Search Consoleの非公開プロパティ情報
- 顧客名、社名、未公開URL、非公開クエリ
- ローカルPCのユーザー名とフォルダ構成
匿名化後も、画像の背景、エラーログ、コマンド履歴に識別情報が残っていないか確認します。
初回の週次分析は改善候補0件だった
2026年8月19日に作成されたZenoPlusの週次分析結果では、WordPressの公開記事7件を対象に、2026年7月20日から8月16日までの直近28日を確認しました。
| 項目 | 初回確認値 |
|---|---|
| 公開記事 | 7件 |
| Search Consoleクリック | 1 |
| Search Console表示回数 | 58 |
| GA4セッション | 7 |
| too_new | 4件 |
| insufficient_data | 3件 |
| 改善候補 | 0件 |
全7記事が too_new または insufficient_data となったため、修正対象は選びませんでした。数字が少ない状態で「クリックがないからタイトルを変更する」と結論を出さず、次回以降のデータを待つ判断です。
この表は一回分の実行結果です。次回以降も同じ条件で記録し、候補が出た時点で記事内容を確認します。
投稿・分析・修正・再分析のサイクルを作る
定期分析は、レポートを保存するだけでは改善につながりません。候補が出たときは、次の流れで扱います。
- 記事を公開する
- 週次で同じ期間・指標を収集する
too_newとinsufficient_dataを除外する- 残った確認候補のクエリと本文を読む
- 修正する記事、修正内容、実施日を記録する
- 一定期間後に同じ条件で再分析する
複数記事を同時に大きく変更すると、どの変更と数値変化が関係したのか追いにくくなります。候補が複数あっても最大件数を決め、変更理由を残します。
AIが出した修正文についても、公開前に事実と出典を確認します。具体的な確認項目は「AIで作った記事のファクトチェック手順」を参照してください。
まとめ
Search ConsoleとGA4の週次分析で重要なのは、毎週必ず改善案を出すことではありません。公開記事を母集団にし、同じ期間でデータを集め、材料が足りない記事を保留できる状態を作ることです。
- WordPress、Search Console、GA4を記事URL単位でまとめる
- 直近28日、前の28日、直近90日を保存する
- 公開直後は
too_new、少数データはinsufficient_dataにする - 改善候補の最小件数を0にする
- AIは候補抽出までにし、修正と公開は人間が確認する
初回結果が0件でも、無理に記事を変更する必要はありません。次のデータが蓄積されるまで待ち、候補が出たときだけ検索意図と本文を確認するサイクルにします。
