SEOデータを「毎週見にいかないと活用できない」状態を終わらせた話
「サーチコンソールを開かないとデータが分からない」「順位や流入の変化に気づけないままサイト運営が進んでしまう」。多くのサイト運営者が抱えるこの悩みを、BENTEN Web Worksでは 毎週土曜の朝、要点をまとめたSEOレポートが自動で手元に届く仕組み にして解決しました。
派手なSEOダッシュボードを導入する前に、自社施策として整えた地味で実用的な基盤の話です。記事更新を継続したい外注ホームページ運用や、社内SEO担当者が一人で回している現場でも応用が効く構成にしてあります。
システム概要
- 対象: 自社サイト bentenweb.com（ブログ＋サービスページ）
- 頻度: 毎週土曜 07:00〜08:00 JSTに自動実行
- 配信先: 社内連絡用のチャットチャンネル（要点と提案を本文に直接記載）
- 規模感: 個人事業（運用は私一人）
課題・依頼背景（Before）
リニューアル後しばらくは「とにかく書く」フェーズでよかったのですが、記事数が増えるほど次の悩みが顕在化しました。
- キーワード判断の手がかりがない: 次にどのテーマで書くか、勘で決めることが多かった
- 記事公開後の効果測定がない: 公開した記事が何位に乗ったのか、どのクエリで流入したのかを追えていない
- サーチコンソールを見にいく動機が湧かない: 開けば情報はあるが、能動的に開かないと見ない
- 複数ソースを横断する手間: サイト側の記事一覧と検索データを毎回突き合わせるのが重い
「判断材料が手元にない状態で、勘でSEO施策を回している」状態が続いていました。クライアント案件でも同じ課題は頻繁に出てくるので、まずは自社で解決策を回せる形にしておきたかった、というのも動機の一つです。
提案・解決アプローチ（思考プロセスを見せる）
「SEOダッシュボードSaaSを契約する」のは選択肢として検討しましたが、最初から外部ツールに依存せず、自前で最小構成を1本動かしてから判断する 方針にしました。
案A: 既製のSEO分析SaaSを導入
メリットは導入の早さ。一方デメリットは、本当に欲しい指標とSaaSの標準ダッシュボードがズレるたびに、画面を開いて自分で集計し直す手間が残る こと。SaaS側の仕様変更でレポート構成が変わるリスクもあります。
案B: 自前のスクリプトで「読まれるレポート」を生成（採用）
採用したのは、サーチコンソール／WordPress側の記事データ／自社で管理しているキーワードリストを集計し、AIで要点と提案だけに絞ったレポートを生成して、毎週土曜朝にチャットへ通知する 構成です。
- ダッシュボード型ではなく、本文として読める文章 で届く
- 「今週注目すべき動き」「次に書くべきキーワード候補」まで提案を含める
- 開きにいかなくても、通知を読むだけで現状が分かる
「ダッシュボードは見ない。届いた文章は読む」という、自分の行動特性に合わせて設計しました。
あえて採用しなかった選択肢
- 高機能SEO分析SaaSの導入: 自社規模に対して機能が過剰。月額費用に見合うか分からない段階で固定費を増やさない 判断
- ダッシュボード型のレポート: グラフを並べたBIっぽいレポートは見栄えはいいものの、自分が見にいかなくなる経験から却下
- 毎日通知: 毎日見ても判断材料は変わらないため、週次に絞った。頻度を上げるほどノイズになる
実装内容
技術スタック
- 実行基盤: Google Apps Script（時刻トリガーで毎週土曜朝に起動）
- データ取得: Search Console API、WordPress REST API
- キーワード管理: Google Sheets（メイン3軸＋サブKWを一元管理、順位は自動更新）
- 分析・本文生成: AIモデルで「要点」「変化点」「提案KW」を生成
- 配信: チャット通知（要点を本文に直接記載、添付PDFなどには逃がさない）
工夫した点
- データ取得は素のAPIで安定運用: 余計なミドルウェアを挟まず、APIの仕様変更に追随しやすい構成
- キーワードはスプレッドシート一元管理: 編集者が増えても運用が崩れない
- 生成プロンプトを社内資産化: 「読み手に届く要点」だけを返すよう、プロンプト側で抽出設計
- 失敗時の検知: 実行ログをスプレッドシートに残し、週次で実行失敗があれば気づける形に
派手な可視化や凝ったグラフは入れていません。「土曜の朝に読むだけで、今週の判断ができる」 ことだけが、このレポートの価値です。
成果
| 指標 | Before | After | 意味 |
|---|---|---|---|
| SEOデータの確認頻度 | 数週間に1回（思い出した時） | 毎週土曜（自動配信） | 判断材料が常に手元にある |
| 次に書くキーワード判断 | 勘ベース | 提案KW込みで毎週届く | 思考のスタートが軽い |
| 記事公開後の効果確認 | 確認漏れが多発 | 翌週のレポートで自動補足 | 公開しっぱなしを防止 |
| 実行時間 | （手動で1時間以上） | 約44秒（GAS 6分制限の余裕大） | 仕組み側のコストも軽い |
数値以上に大きいのは、「データを見にいく」習慣が「データが届く」習慣に変わった ことです。意思の力に頼らずSEOデータと付き合えるようになりました。
私の働き様
β：検討プロセス（一人称で振り返り）
エピソード1：SaaSを選ばなかった理由（→ ちょうどいい／ビジネスに寄り添う）
SEO分析SaaSは便利ですが、自社規模で固定費を増やすほどの価値が出せるかは、契約してみないと分からない という根本問題があります。先に自前で動く最小構成を持っておけば、SaaSを比較検討する基準にもなります。「SaaS導入ありきで考えない」という姿勢は、クライアントへの提案でも一貫させたいポイントでした。
エピソード2：ダッシュボードを作らなかった理由（→ ちゃんと動く／思考プロセス）
最初は「BIっぽい綺麗なダッシュボード」を作る案もありましたが、自分が見にいかない仕組みは、どれだけ綺麗でも価値がゼロ です。プッシュ型で本文として届くレポートに振り切りました。「数値は手段であって、行動を起こすための材料」 という視点を、この設計判断ではっきりさせました。
エピソード3：通知頻度を週次に絞った反省（→ 思考プロセス／ちゃんと動く）
設計初期は「毎日通知」も検討しましたが、毎日見ても判断材料が変わらず、ノイズで本来の判断が鈍る と気づき、週次に絞り直しました。「頻度を上げる＝価値が上がる」ではない、という当たり前を改めて確認できた判断です。
α：コミュニケーション抜粋（自分の発言だけ）
社内案件のため、判断時に自分宛に書き残したメモから引用します。
「ダッシュボードは作らない。読まれない。本文として届くレポートに振り切る。」
「SaaSを契約する前に自前で1本動かす。契約の判断材料を、まず仕組み側で作る。」
「数値は手段。今週の判断ができる材料が手元にある状態を、土曜の朝までに整える。それだけ。」
これらの判断軸は、SEO支援を求めるクライアント案件にもそのまま持ち込んでいます。派手で全部入りより、ちゃんと動いて、ビジネスに寄り添えて、ちょうどいい。
学び・横展開
このSEO週次レポート基盤から整理できた、BENTEN Web Worksとして他社案件にも適用している判断軸は3つです。
- 見にいかない仕組みは作らない: ダッシュボードよりプッシュ型。本文で要点が届く設計
- SaaS契約の前に最小構成を1本動かす: 比較の物差しを自分の手の中に持っておく
- 数値は手段、判断と行動が目的: 綺麗な可視化より、来週の動きが決まることが大事
社内SEO担当者が一人で回している現場や、外注ホームページの効果測定が止まっている案件でも、「週次の本文レポート」 という形は十分に効きます。同じ悩みをお持ちの方は、まず通知の届け方から一緒に設計するのがおすすめです。
関連サービス
「派手なSEOダッシュボードでなく、判断材料が手元に届く仕組みを相談したい」「外注ホームページの運用を継続できる形に整えたい」という方は、以下のサービスをご覧ください。
- 情シス代行サービス: WordPress運用・自動レポート基盤の整備・改修まで月額制でお任せいただけます → /services/it-outsourcing/
派手な分析SaaS導入でなく、ビジネスに寄り添う改修 を相談したい方は、まずは無料相談からお声がけください。
