Search ConsoleとGA4でSEO改善を自動化した

Google Search Console と Google Analytics 4 のデータを集め、AIが既存ページを直して公開するSEO改善ループを組んだ。最初に考えたのは、毎日データを取り、そのまま毎日AIに改善させる構成だった。しかし実装では、観測は毎日、編集は週1件、変更したページは35日間触らない形に分けた。データ取得の頻度と、サイトを変更する頻度は同じでなくてよい。

観測は毎日、編集は週1件に分けた

日次処理が見るのは、公開サイトが壊れていないかだ。トップとブログ、robots.txt、sitemap.xmlの応答を直接確認し、noindexや全体クロール拒否も検査する。さらに、Google Search Console のURL検査と検索流入、Google Analytics 4 のページビューを前期間と比較する。この経路はレポートを保存するだけで、ページを変更しない。

一方、既存ページの編集は週1件に絞った。検索データは日ごとの揺れがあり、変更直後には再クロールと再評価も入る。毎日別の箇所を直すと、どの変更が結果に効いたのか切り分けられない。そこで変更時点の指標と仮説を実験記録に残し、同じページを35日間候補から外すことにした。

サイト停止、クロール拒否、canonical の不一致のような技術障害は、週次の実験枠を待たずに別系統で扱う。逆に、タイトルや見出しを変えるだけの案件は急がない。この分離によって「異常への即応」と「効果を測れる変更」を両立させた。

候補はコードで選び、AIには探させない

捨てた案のひとつが、Google Search Console とGoogle Analytics 4の生データをAIへ渡し、改善対象から自由に選ばせる構成だった。採用しなかった理由は、同じ入力でも候補や優先順位が揺れ、あとから「なぜこのページだったのか」を追いにくくなるからだ。

候補抽出は score.pyに固定した。検索結果には出ているがクリック率が低いページ、上位へ届きそうなページ、表示が落ちたページ、インデックスやcanonicalに問題があるページを規則で点数化する。同じページに複数の理由があれば最も高いものだけを残し、凍結中のページを除いて並べる。Google Analytics 4 の閲覧やエンゲージメントは補助証拠として候補へ添えるが、流入判断の主指標はGoogle Search Consoleのままにした。

AIが担当するのは、選ばれた後だ。ページ本文と検索意図を照合し、タイトル、description、見出し、説明、内部リンクのうち、仮説を検証する最小の変更を作る。根拠が薄ければ変更せずに終了できる。初回実行も、対象ページと仮説、変更範囲を実験ファイルへ保存するところまで通した。

検索クエリは分析材料だが、同時に外部入力でもある。そのためプロンプトでは、クエリ内の命令、URL、依頼を実行しない不信データとして扱う。検索欄に書かれた文字列から、AIの動作権限へ経路を作らないためだ。

AIの判断を、AIの外側で検査する

AIへの禁止事項をプロンプトに書くだけでは、自動公開の境界として弱い。週次処理は最新のmainから一時クローンを作り、作業ツリーが空であることを確認してからAIを起動する。日次処理との重複は排他ロックで防ぐ。AI自身にはcommit、push、デプロイを許可していない。

編集後は別の検査コードが、選ばれた候補ページに属する既存ファイルだけが変更されたかを確認する。新規ページ、URLの削除や変更、日付だけの更新、法務ページ、広告・計測・クロール・依存関係・ビルド・デプロイの設定は通常の改善対象から外した。実体験にない説明の追加も禁止している。

範囲検査を通過した後、lintとproduction buildが成功した場合だけ、申告された変更ファイルと実験記録を明示的にstageしてmainへpushする。AIは変更案を作れるが、公開条件は変更できない。初回の自動改善も、ひとつの既存記事にひとつの変更だけを加え、この経路で記録された。

Google Analytics 4 の設定も同じ考え方にした。宣言ファイルと現在値を照合し、自動で扱うのはカスタムディメンション、キーイベント、データ保持期間の追加と安全な更新に限定する。既存設定の削除やアーカイブ、データストリームの作成、外部サービス連携は行わない。

長期JSON鍵を採用せず、1時間だけ権限を借りる

自動実行の認証には、サービスアカウントの長期JSON鍵を置く案もあった。運用は単純になるが、漏えいした鍵は失効させるまで使われ続ける。今回はGoogle Cloud CLIのユーザー認証からサービスアカウントの権限を借り、実行時に1時間のアクセストークンを発行する方式にした。リポジトリにもcronの設定にも、長期鍵を保存しない。

権限も処理ごとに分けた。通常のGoogle Search ConsoleとGoogle Analytics 4 の収集には読み取り専用スコープを使い、Google Analytics 4 の宣言的な設定照合だけ編集スコープの別トークンを発行する。設定変更が失敗しても、検索データの収集と分析は継続する。編集権限を持つ経路の障害を、サイト改善全体の停止へ広げないためだ。

まとめ

この改善ループで重要だったのは、AIに何を考えさせるかより、どこから先を考えさせないかだった。日次観測は状態を知る。決定論的コードは候補を絞る。AIは選ばれたページに対する小さな仮説を形にする。外側の検査が公開可否を決める。それぞれを別の責務にした。

自動化の速度は、編集回数だけでは測れない。結果を原因へ結び付けられ、事故時に止める場所があり、認証情報が長く残らないことも速度の一部だ。データ取得の頻度と編集頻度を分けると、AIを毎日動かさなくても、改善ループは毎日進められる。