n8nでGSC/GA4からリライト候補を自動抽出するフローを作った

n8nでAI記事生成フローを作り、記事を自動投稿できるようになったとき、次の問題に気づきました。「記事を作る仕組みはできたが、どの記事を直すべきか、次に何を書くべきかが分からない」という問題です。

Search ConsoleやGA4の管理画面を見れば数字は分かります。ただ、膨大なクエリや指標を眺めるだけでは、具体的なアクションに変換しにくい。そこでフロー0として、週次でGSC/GA4データを取得し、既存記事台帳と照合してリライト候補と新規キーワード候補を自動で出す仕組みを作りました。

この記事でわかること：

• n8nでGSC/GA4データを取得する構成
• Pythonスクリプトとn8nを組み合わせる設計判断
• summary_cache.jsonと照合して既存記事か新規候補かを分ける方法
• リライト候補・新規キーワード候補のスコアリング設計
• Slack通知の分け方とCloudflare対策の詰まり

GSC/GA4を見ても「次に何をすべきか」が決まらなかった

Search ConsoleとGA4にはSEO改善に使えるデータが揃っています。どのクエリで表示されているか、クリック率はどうか、ページに来た後の滞在時間はどうか。こうしたデータは管理画面から確認できます。

ただ、週次で確認しようとすると問題が出てきました。記事が増えるほど、確認すべき記事数も増えます。10本なら手動でも回せますが、30本・50本になると管理画面を見ているだけでは「どれを直すか」の判断がついてきません。

AI記事生成パイプラインでは、記事を作るだけでなく、作った記事を改善する仕組みが必要です。フロー0は、その改善ループの起点として設計しました。

今回作ったフロー0の全体像

フロー0は記事生成（フロー1・2）とは独立した、週次の分析フローです。

GSC/GA4データ取得（Pythonスクリプト）
↓
performance_cache.jsonとしてVPSに保存
↓
n8nでperformance_cacheを読み込み
↓
summary_cache.json（既存記事台帳）を読み込み
↓
スコアリング（既存記事 × GSC/GA4指標）
↓
リライト候補 / 新規キーワード候補に分岐
↓
Slack通知（別々のメッセージで送信）
↓
必要に応じてkeyword_queue.csvへ候補を追加

フロー1・2の記事生成フローとの関係については、n8nでWebhook後にデータが消える問題をsession.jsonで解決した記事で書いたフロー構成を参照してください。フロー0はそれらの前段にあたる分析フローで、何を書くかを決めるための入力を作ります。

実際のn8nノード構成はこのようになっています。

Schedule Trigger（週次）
↓
Execute Command（fetch_metrics_json.py実行）
↓
performance_cache.json読み込み
↓
Extract from File（JSONパース）
↓
Google Driveからsummary_cache.json取得
↓
Codeノード（URLと照合・スコアリング）
↓
IFノード：リライト候補あり？
  → Slack通知（リライト候補）
IFノード：新規候補あり？
  → Slack通知（新規キーワード候補）
  → keyword_queue.csvへ追加（承認後）

Execute CommandノードでPythonを実行してからJSONを読み込む流れは、n8nのMergeノードでデータが取れない原因と直接参照で解決した記事で触れたExtract from Fileノードの扱いと同じ注意点があります。バイナリとして読み込まれる場合があるため、JSONパースのステップを忘れずに挟みます。

データ取得はPythonスクリプトに分離した

n8nだけでGSC/GA4の認証・取得を組むことも技術的には可能です。ただし、Google APIの認証フロー・スコープ設定・レート制限への対応を全部n8nのHTTPノードで組むと、フロー自体が複雑になりすぎます。

今回は fetch_metrics_json.py を作成してVPSの /root/metrics/ に配置し、n8nのExecute Commandノードから実行する構成にしました。

cd /root/metrics && python3 fetch_metrics_json.py

Pythonスクリプトが実行されると、取得結果が /root/metrics/performance_cache.json として保存されます。n8nはその後でperformance_cache.jsonを読み込んで分析に使います。

performance_cache.jsonの構造はこのようになっています。

{
  "generated_at": "2026-05-10T00:00:00+09:00",
  "pages": [
    {
      "url": "https://bizinets.life/n8n-webhook-session-json/",
      "gsc": {
        "impressions": 1200,
        "clicks": 18,
        "ctr": 0.015,
        "position": 14.8,
        "queries": [
          {
            "query": "n8n session.json 状態保持",
            "impressions": 300,
            "clicks": 4,
            "position": 16.2
          }
        ]
      },
      "ga4": {
        "users": 85,
        "avg_duration": 42,
        "engagement_rate": 0.51,
        "scroll_50": 0.38,
        "scroll_75": 0.21,
        "scroll_90": 0.08
      }
    }
  ]
}

この構造にすることで、ページ単位でGSCとGA4の指標を一元管理できます。n8n側で読み込んだときに、urlをキーとしてsummary_cache.jsonと照合する設計にしています。

この設計の狙いは役割分担です。n8nはオーケストレーター（処理の順序管理・通知・ファイル更新）、Pythonはデータ取得担当として分離しました。Pythonスクリプト側はn8nを意識せず、取得→保存だけに集中できます。

取得したGSCデータ：表示回数・クリック・順位・クエリ

Search Console APIから取得したデータは以下のとおりです。

取得期間：過去30日

取得件数：上位100件の検索クエリ

取得項目：

• impressions：表示回数
• clicks：クリック数
• ctr：クリック率
• position：平均掲載順位
• query：検索クエリ
• page：対応するページURL

GSCデータで特に注目したのは「表示はあるがクリックされていない」「掲載順位が11〜30位で伸びしろがある」という組み合わせです。表示回数が多く順位が20位前後の記事は、タイトルや構成を改善することでクリック率が上がる可能性があります。

また、想定していなかったクエリで表示されている記事も候補になります。そのクエリに合わせた内容を追記・修正することで、既存記事の射程を広げられます。

取得したGA4データ：滞在・エンゲージメント・スクロール

GA4からは、記事に流入した後の読まれ方を取得しました。

取得項目：

• users：ユーザー数
• avg_duration：平均エンゲージメント時間
• engagement_rate：エンゲージメント率
• scroll_50：50%スクロール率
• scroll_75：75%スクロール率
• scroll_90：90%スクロール率（GTMでカスタムイベントとして計測）

GSCが「検索からページへの入口データ」だとすれば、GA4は「ページに来た後の読まれ方データ」です。

流入はあるが avg_duration が極端に短い記事、scroll_50 が低い記事は、期待した読者に届いていないか、内容が読者の意図に合っていない可能性があります。これらはリライト候補として優先度が上がります。

summary_cache.jsonと照合して「既存記事か新規候補か」を分ける

フロー0の中心設計がここです。

GSCには検索クエリが出てきますが、そのクエリに対応する既存記事があるかどうかはGSCだけでは判断できません。そこで summary_cache.json と照合します。

summary_cache.json は公開済み記事の台帳で、以下の情報が入っています。

{
  "slug": "n8n-webhook-session-json",
  "url": "https://bizinets.life/n8n-webhook-session-json/",
  "wp_title": "n8nでWebhook後にデータが消える問題をsession.jsonで解決した",
  "target_keyword": "n8n session.json Webhook 状態保持",
  "summary": "記事の要約テキスト",
  "primary_topic": "practice-log",
  "related_topics": ["n8n", "Webhook", "session管理"]
}

照合の流れ：