SEOレポートの項目例と作り方|自動化ツール比較と週次運用の実例
制作内容
SEOレポートに何を入れるかは「読み手が次に何を決めるか」で決まる
SEOレポートの出来を左右するのは、グラフの見栄えではなく、読み手が次の一手を決められるかどうかです。ここでは、レポートに入れたい必須項目の一覧、週次・月次の使い分け、提出用の体裁、作成・自動化に使えるツールの比較、そのまま流用できるシート構成と本文の型までをまとめます。後半では、BENTEN Web Worksが自社サイトで週次レポートの自動生成を組んだときの判断と、手作業だったメタタグ更新を自動化した案件の進め方も紹介します。
SEOレポートに最低限入れたい6項目
順位や流入の数字を並べるだけでは、読み手は動けません。次の6項目を揃えると、レポートが報告書ではなく判断材料になります。
1. KPIサマリー(表示回数・クリック数・CTR・平均掲載順位)
Search Consoleの4指標を、対象期間と前期間を並べて出します。GA4が使える場合は、自然検索からの流入に絞ったセッション数と、対象のキーイベントを同じ表に足します。Search Consoleのクリック数とGA4のセッション数は別の指標なので、混ぜずに並べます。数字を並べて終わりにせず、増減の要因を一言添えるところまでを1セットにします。
2. 前期間・前年との比較
週次なら前週比、月次なら前月比と前年同月比です。単一期間の数字だけでは、季節変動なのか施策の効果なのかを切り分けられません。「比較対象を必ず並べる」と決めておくと、レポートの説得力が変わります。
3. 検索クエリの分析
流入し始めたクエリ、順位が上がったクエリ、落ちたクエリの3つに分類します。Search Consoleの検索パフォーマンスからCSVまたはAPIで取り、前回分と突き合わせて差分を見ます。伸びているクエリは、次に書く記事テーマの候補そのものです。
4. ページ別のパフォーマンス
流入上位のページ、コンバージョンに貢献しているページ、前回から落ちたページを並べます。Search Consoleはページ単位、GA4はランディングページ単位など、集計単位を揃えて突き合わせます。クリックが減ったページは、まず表示回数とCTRを分け、クエリ・端末・国など比較条件を揃えて確認します。表示回数が減っていれば需要や露出の変化、同じ条件でCTRが下がっていれば検索結果での見え方を疑い、その後にタイトルや説明文の修正を検討します。
5. インデックス・技術面の異常
登録状況と除外理由、クロールエラー、Core Web Vitalsの変化を確認します。新規の異常と、継続中の未解決事項は分けて書き、継続事項には対応状況を添えます。インデックスさせたいページが登録されているかを確認し、意図して登録させていないページは異常として扱いません。新規の異常がなければ「変化なし」の1行で足ります。毎回0件の表を貼るより、異常時だけ読まれる形にした方が読み手は助かります。
6. 次アクション(担当と期限つき)
レポートの中で一番読まれるのはここです。記事の追加、タイトル修正、内部リンクの追加といった作業単位に落とし込みます。「引き続き様子を見る」はアクションではありません。
週次・月次・四半期の使い分け
同じ項目をすべての頻度で出そうとすると、どのレポートも似た内容になります。読み手で切り分けるのが実際的です。
| 頻度 | 主な読み手 | 向いている内容 | 注意点 |
|---|---|---|---|
| 週次 | 現場担当・自分 | 順位やクエリの変化、今週やること | 数字が動かない週の報告は形骸化しやすい |
| 月次 | クライアント・上司 | KPIのまとめ、施策の結果、翌月の計画 | 提出後の打ち合わせまで含めて1セット |
| 四半期 | 経営・予算の判断者 | 方針と投資判断の材料 | 日々の作業リストは載せない |
提出の頻度と、日常の確認頻度は別に決めます。月次での報告でも、異常や施策の状況に応じて随時判断します。BENTEN Web Worksが自社で週次を選んだのは、判断が変わるタイミングに合わせた結果で、毎日配信は「毎日見ても判断材料は変わらない」として採りませんでした。
SEOレポートの作り方:取得から共有までの7ステップ
- 対象期間と比較条件(前期間・前年、クエリ、端末、国)を先に固定する
- Search Consoleから検索パフォーマンスとインデックス関連のデータを取得する
- GA4から自然検索に絞った流入とキーイベントを、ランディングページ単位で取得する
- 雛形シートに転記し、前回分との差分を出す
- 表示回数・CTR・順位に分けて、変化の理由を確認する
- 次アクションを担当と期限つきで記入する
- 読み手に合わせた形式で共有する
提出用の体裁:PDF・スプレッドシート・共有リンクの使い分け
| 形式 | 向いているケース | 注意点 |
|---|---|---|
| その時点の内容を確定版として残す。会議資料や印刷にしやすい | 更新のたびに作り直しが必要 | |
| スプレッドシート | 読み手が並べ替えや条件変更をして数字を触る。コメントでやり取りもできる | 最新版がどれか分かりにくくなる |
| 共有リンク(Looker Studioなど) | 常に最新を見せたい | 見に行く習慣がない相手には開かれない |
| チャット本文 | 自分や現場向け。要点と次アクションだけを本文に書く | 添付に逃がした時点で開かれなくなる |
迷ったら「読み手はその数字を見て何をするのか」で選びます。会議で説明するならPDF、読み手が自分で切り口を変えたいならスプレッドシート、常に最新を見てほしいなら共有リンクです。
作成・自動化に使えるツールの比較
| ツール | 役割 | 向いているケース | 注意点 |
|---|---|---|---|
| Google Search Console | 検索パフォーマンス・インデックスの一次データ | すべてのSEOレポートの土台 | 標準画面で期間比較は可能。変化の理由の検討や、担当・期限を含む次アクションの整理は別途行う |
| GA4 | 流入後の行動とコンバージョン | サイト内の成果まで見たい場合 | 探索レポートの操作に慣れが必要で、そのままでは提出物にならない |
| Looker Studio | GA4・Search Consoleを接続したダッシュボード | 複数人で常に最新を共有したい場合 | 定期メール配信も選べる。配信先・配信形式・文章要約の要否・保守負担で、要点と提案をチャット本文で届ける自前方式と比べる |
| スプレッドシート+GAS | 集計・成形・配信の自動化 | 自前で最小構成を組みたい場合 | 保守は自分の手元に残る。APIの仕様変更への追随が必要 |
| 有料SEOツール | 順位計測・競合分析 | 順位を定点で追いたい場合 | 契約前に、欲しい指標がそのツールで揃うかを確認する |
| AI(要約・提案) | 数値から要点と次アクションの文章化 | 読める文章に落とす手間を減らしたい場合 | 数値そのものの正しさは自分で検証する前提で使う |
ツールは1つで完結しません。取得(Search Console/GA4)→成形(スプレッドシートやGAS)→提出(PDF/共有リンク/チャット本文)の3層に分けて、どこを自動化すべきかを考えます。自動化するなら、GASの時刻トリガーで起動し、APIからデータを取得、AIに文章を生成させ、チャットへ通知、実行ログをシートに残す、という役割に分けます。
雛形として使えるシート構成と本文の型
次の5シート構成を土台にして、自分の運用に必要な列だけを足していくのが実際的です。
- KPI:期間/表示回数/クリック数/CTR/平均掲載順位/セッション(自然検索)/キーイベント
- クエリ:クエリ/クリック/表示回数/順位/前回順位/差分
- ページ:URL/クリック/表示回数/順位/キーイベント
- 技術:インデックス状況/エラー/確認日/対応状況
- アクション:やること/担当/期限/状態
レポート本文は、結論・根拠・次アクションの空欄を埋める形で書きます。
- 結論:今期の状態を1〜2文
- KPI:前回比の表と一言コメント
- 注目の変化:伸びたクエリ・落ちたページ
- 異常・リスク:新規の異常と継続中の未解決事項を分けて記載(なければ「なし」)
- 次アクション:箇条書きで担当と期限
雛形は完成品として配るより、自分の運用に合わせて育てる前提で作ると長く使えます。項目を増やすほど書くのが重くなり、続かなくなるためです。
BENTEN Web Works の対応事例から
SEO週次レポートを自前で自動生成した案件
この記事の元になった自社の週次レポート運用では、Search Console、WordPressの記事データ、自社で管理しているキーワードリストを集計し、AIで要点と提案キーワードだけに絞った文章を生成して、毎週土曜の朝にチャットへ届けています。確認が「数週間に1回、思い出したとき」だった状態からの置き換えです。
- 取得:Search Console/WordPressの記事データ/管理しているキーワードリスト
- 集計:GASの時刻トリガーで定期実行
- 生成:AIで要点と提案キーワードを文章化
- 通知:チャットへ配信し、実行ログをスプレッドシートに残す
判断として大きかったのは、最初からSEOダッシュボードSaaSを契約しなかったことです。標準ダッシュボードと欲しい指標がズレるたびに自分で集計し直す手間が残ること、SaaS側の仕様変更でレポート構成が変わることを避けたかった。代わりに、素のAPI+スプレッドシート+AIという最小構成を1本動かし、比較の物差しを自分の手元に置きました。
もう1つの判断は、BI風のダッシュボードを作らなかったことです。グラフを並べても自分は見に行かない、という経験が先にありました。本文として届く形に振り切った結果が下の表で、失敗時は実行ログをスプレッドシートに残して気づける形にしています。
「ダッシュボードは作らない。読まれない。本文として届くレポートに振り切る。」
| 項目 | Before | After |
|---|---|---|
| SEOデータの確認頻度 | 数週間に1回(思い出したとき) | 毎週土曜(自動配信) |
| 次に書くキーワードの判断 | 勘ベース | 提案キーワード付きで毎週届く |
| 記事公開後の効果確認 | 確認漏れが多発 | 翌週のレポートで自動補足 |
ツールを増やす前に「自分がどの頻度で、どの形なら読むか」を先に決める。この順序が、この事例から持ち帰れる点です。
手作業だったメタタグ更新を日次cronに置き換えた案件
MODX Evolution運営ECサイトのSEOメタタグ自動反映の案件では、管理画面から1ページずつtitle/meta descriptionを修正する運用を、SSH接続でのデータベース反映とGitHub Actionsの日次cronに置き換えました。
一括SQLの一発実行を採らなかったのは、想定外の不整合が起きたときの被害範囲が大きすぎるためで、完全バックアップと突合確認を先に固めて段階的に進める順序を選んでいます。レポート自動化との接点は、実行結果をDiscordに通知し、状況を都度確認できる状態を残した点です。集計や配信を自動にしても、確認できる場所がなければ「動いているのか分からない」状態になります。
よくある質問
SEOレポートは月次と週次、どちらで出せばいいですか?
固定のルールはなく、読み手に合わせて選びます。社外や上長への提出は月次、施策を動かす現場の判断は週次、というのが選択例です。週次は順位やクエリの変化と今週やることを短く、月次はKPIのまとめと施策の結果、翌月の計画までを含めます。提出頻度と日常の確認頻度は別に考えて構いません。
Looker Studioのダッシュボードがあれば、レポートは作らなくていいですか?
Looker Studioにはレポートを定期メールで配信する機能もあり、選び方の幅はあります。ただし配信されるのはダッシュボードで、要点と次アクションをチャット本文で届ける自前の方式とは配信先も形式も別物です。共有用のダッシュボードと、判断用の短いレポートを分けて持つのが現実的です。
レポート作成の自動化は何から手をつければいいですか?
取得・成形・配信の3層のうち、手作業が一番重いところから1つだけ置き換えます。多くの場合は、Search ConsoleやGA4から数字を集めて表にする成形の部分です。ここをスプレッドシートの関数やGASに置き換え、実行ログと失敗時の通知を先に用意しておきます。集計や配信を自動にしても、動いているかを確認できる場所がなければ運用は続きません。
関連サービス
「派手なSEOダッシュボードでなく、判断材料が手元に届く仕組みを相談したい」「外注ホームページの運用を継続できる形に整えたい」という方は、以下のサービスをご覧ください。
- 情シス代行サービス:WordPress運用や自動レポート基盤の整備・改修まで対応します → /services/it-outsourcing/
- 業務自動化・RPA:データ取得や集計、通知までの流れを組み替えたい場合はこちら → /services/automation/
どの頻度で、どの形式のレポートが必要かが固まっていない段階でも構いません。お問い合わせから30分のオンライン無料相談(Web会議)を受け付けています。相談では現在のお困りごとを伺います。
Others
その他の制作実績
制作会社が管理しているサイト、自分たちの手に戻せますか?公民連携プロジェクトのサーバー移管と常時SSL化を引き継いだ事例|サイト保守・運用
大阪市港区発の防災啓発プロジェ...