GSCとGA4を使って改善候補ページを見つける自動レポート設計

GSCとGA4を別々に見るだけでは、次に直すべきページが見えにくくなります。GSCは検索結果での表示、クリック、CTR、平均掲載順位を見せてくれますが、記事を読んだ後にCTAを押したか、外部リンクへ進んだかまでは分かりません。

GA4はページ閲覧、イベント、流入経路、エンゲージメントを見られます。そこで、自動レポートではGSCを「検索面の機会」、GA4を「サイト内の反応」として扱い、同じURL単位で並べます。

最初に必要なのは、GSCのpage/queryデータと、GA4のpagePath別ビュー・ユーザー・イベントです。いきなり複雑なダッシュボードを作るより、CSVやJSONを日次で保存し、前回との差分を見られる状態にするほうが運用は安定します。

URLの正規化も重要です。末尾スラッシュ、言語prefix、canonicalの違いが残ったままだと、同じページが別行として扱われます。L-001のように /ja/ai-automation/ を範囲に固定している場合は、最初にURL prefixで絞り込みます。

1つ目は、表示回数はあるのにCTRが低いページです。タイトル、description、検索意図とのズレ、FAQの有無を見直します。2つ目は、平均掲載順位が11位から30位付近で、少しの追記や内部リンクで上がる可能性があるページです。

3つ目は、GA4で閲覧はあるのにCTAクリックが少ないページです。比較表、次に読む記事、チェックリスト、外部リンクの位置を見直します。4つ目は、GSCには出ていないが記事として空または薄いページです。初期運用ではこの品質ギャップを先に埋めるほうが、将来の計測対象を増やせます。

改善候補に点数を付けるなら、まずは3軸で十分です。表示機会はimpressions、改善余地はCTRやposition、収益導線はCTAクリックや関連ツール比較への接続で見ます。

たとえば、impressionsが増えていてpositionが15位前後なら本文追加や内部リンクの優先度を上げます。viewsはあるのにCTAが少ないなら、導入文ではなく記事末尾と中盤の導線を見直します。数字を増やしすぎると毎日の判断が遅くなるため、最初は少数の指標に絞ります。

実装では、GSCとGA4のAPI取得を1つのスクリプトにまとめ、出力を latest-* と履歴ファイルに分けます。次に、対象URL範囲で絞り込み、改善候補を「CTR改善」「順位改善」「CTA改善」「品質ギャップ」のように分類します。

最後に、提案された改善をそのまま公開せず、記事データやテンプレートに反映してからtypecheck、build、deploy、smokeを通します。自動化の役割は、更新を勝手に量産することではなく、毎日同じ判断材料をそろえて改善漏れを減らすことです。

最初の運用は「ダッシュボード」より「出力ファイルの安定化」を優先します。最低限、GA4のページ別と、GSCのページ別、そして要約JSONを毎朝更新できれば、改善判断は回せます。

例: latest-ga4-pages.csv（pagePath別 views/activeUsers/sessions）と latest-gsc-pages.csv（page別 clicks/impressions/ctr/position）を同じ日に出力し、latest-growth-snapshot.json に全体要約（ユーザー数、views、上位ページ、RGLイベント）を残します。

差分は難しく考えず、(1) 前回より impressions が増えたページ、(2) CTR が低いページ、(3) views はあるのに CTA が弱いページ、の3種類だけを抽出して、直すURLを1つ決めます。

毎朝の運用で迷う最大の原因は、候補ページが増えたときに“どれから直すか”が毎回ぶれることです。先に判断表を決めておくと、出力が多少荒くても意思決定は安定します。

最小の優先順位表（例）:

L-001 の初期段階では、GSCの表示がまだ少ない日があります。その場合は“品質ギャップ”を優先し、比較表、チェックリスト、FAQ、同一ループ内リンクを増やして、次にデータが出たときの受け皿を先に作ります。

改善候補は「ページ単位」で並べるだけで十分です。最初から複雑なスコアリングにせず、毎日判断できる最小カラムに絞ります。

おすすめの列:

「impressionsが伸びているのにctrが低い」→タイトル/description/FAQ、「viewsはあるのにctaが弱い」→比較表/次に読む導線、「positionが11〜30」→追記/内部リンク、のようにルール化すると迷いません。

現実の運用では、OAuth refresh の invalid_grant、権限切れ、クォータ、API障害などで GSC/GA4 export が止まる日があります。そのたびに改善自体を止めると、日次ループが切れます。

止めないための最小ルール:

• latest-growth-snapshot.json の generatedAt を見て、最終成功日を明記する
• 最新exportが壊れていても、直近成功スナップショットを“暫定シグナル”として使う
• stale data の日は、新規流入最適化より品質ギャップ（表、FAQ、内部リンク、比較軸）を優先する
• run log に「export失敗理由」と「代替シグナル」を必ず残す
• OAuth/計測修復は別タスクで追い、当日の記事改善は1件完了させる

特に invalid_grant は“記事を直すかどうか”の判断とは分けて扱うのが重要です。計測修復は必要ですが、コンテンツ改善まで止める理由にはしません。L-001 のような立ち上げ期は、stale snapshotでも「どの記事が薄いか」「どの内部リンクが足りないか」は十分判断できます。

日次運用では、どの数字を見て、なぜそのページを直したのかを必ず記録します。たとえば「L-001のGSC表示はまだ0、A003が空本文だったため品質ギャップを優先」のように書くと、翌日の担当者や自動化エージェントが同じ判断を繰り返さずに済みます。

GA4のcustom dimensionで loop_id と article_slug を登録しておくと、RGLイベントをループ別・記事別に追えます。登録直後は過去イベントが (not set) になることがありますが、新規イベントから記事単位の反応が見えるようになります。

ログには最低でも「analytics snapshot日時」「見た指標」「選んだURL」「実施した改善」「検証結果」「deploy結果」を残します。日報の粒度を固定すると、どの改善が効いたかを後から比較しやすくなります。