
外注先から「この記事をリライトしました」と報告が来る。順位が上がったかどうか、しばらく経ってからサーチコンソール(Googleが提供している、自社サイトの検索順位やクリック数を確認できる無料ツール。通称「サチコ」)を見る。なんとなく上がった気がする。でも、リライト前の順位って何位だったっけ……?
こういうこと、ありませんか。
もう一つ。3ヶ月前にもリライトしたはずなのに、また同じ記事のリライト提案が来ている。前回の施策って何をやったんだっけ。効果はあったのか、なかったのか。スプレッドシートを探してみるけど、数値は最新のもので上書きされていて、過去のデータはどこにもない。
これ、うちでも起きていた問題だった。
順位やクリック数のような「日々変わる数字」を、記事の基本情報と同じ場所に置いていたのが原因だ。新しい数字を入れるたびに古い数字が消える。当たり前といえば当たり前なのだが、これでは「3ヶ月前と比べてどうなったか」を誰にも説明できない。
そこで、Notionを使って「記事の情報」と「施策・計測の記録」を分けて管理するシステムを作った。この記事では、その仕組みと使い方を説明する。
全体像 ── データベースは2つ
このSEOリライト管理システムは、2つのNotionデータベース(以下「DB」)で成り立っている。
1つ目:記事管理DB
記事ごとの「プロフィール」にあたるDB。記事のURL、狙っているキーワード、月間の検索ボリューム(そのキーワードが月に何回Googleで検索されているか)、目標順位など、基本的に変わらない情報を置く場所。
2つ目:施策ログDB
記事ごとの「施策レポート」にあたるDB。「いつ、何をして、結果どうなったか」を1件ずつ記録していく場所。リライトした記録も、月次で順位を計測した記録も、全部ここに時系列で溜まっていく。
なぜ分けるのか。
たとえば、ある記事のプロフィールは1枚あれば十分だ。URLもキーワードも、そうそう変わるものじゃない。でも、施策レポートは違う。8月にリライトした記録、9月に順位を測った記録、10月にまた別の施策をした記録……と、どんどん増えていく。
この「増えていくデータ」をプロフィールの中に押し込もうとするから、上書きが起きる。施策レポートとして別に記録すれば、過去のデータは消えない。半年分、1年分と積み上がっていくほど、「この記事にはどんな施策が効いて、何が効かなかったか」が見えるようになる。
2つのDBは「リレーション」という機能でつながっている。リレーションとは、DB同士を紐づける仕組みのことで、記事管理DBの各レコード(行)から、その記事に関する施策ログを一覧で見ることができる。逆に、施策ログ側からも「どの記事に対する施策か」をたどれる。
記事管理DB ── 記事の「プロフィール」

記事管理DBに並んでいる主な項目を、実務で使う場面とセットで紹介する。
メインKW(メインキーワード)
その記事が狙っている検索キーワード。たとえば「サービス名 地域名」とか「サービスA 効果」とか。外注先とのやり取りや、サチコで効果を確認するときに使う。
月間検索Vol(月間検索ボリューム)
そのキーワードが月に何回くらいGoogleで検索されているかの数字。大きいほど「その記事の順位が上がったときのインパクトが大きい」ということ。リライトの優先順位を決めるときの判断材料になる。
ファネル(TOFU / MOFU / BOFU)
ちょっと聞き慣れない言葉だと思う。これは「読者がどの段階にいるか」を表す分類。
- TOFU(トーフ):まだ漠然と情報を探している段階。「○○とは」「○○ 原因」のような検索をしている人向けの記事。
- MOFU(モーフ):解決策を比較・検討している段階。「サービスA サービスB 違い」のような記事。
- BOFU(ボーフ):もう行動(問い合わせ・来店)に近い段階。「サービス名 地域名 費用」のような記事。
記事の役割がどこにあるかを把握しておくと、「認知系の記事が足りないな」「行動系の記事を強化しよう」といった戦略が立てやすくなる。
ステータス
「リライト待ち」→「執筆中」→「公開済み」→「効果測定中」という流れで、今その記事がどの段階にあるかを示す。
目標順位 / 想定流入数
リライト後に狙う検索順位と、その順位を達成した場合に見込める月間のアクセス数。検索ボリュームと順位ごとのクリック率(CTR=検索結果に表示されたとき、何%の人が実際にクリックするか)から算出している。
施策ログを追加(ボタン)
ここが今回の目玉。各記事の行に「施策ログを追加」というボタンが付いている。これを押すと、その記事に紐づいた施策ログの新しいレコードが自動で作られて、そのまま記入画面に移動する。わざわざ施策ログDBを別に開いて、記事を手動で紐づけて……という手間がない。ワンクリックで記録を始められる。
施策ログDB ── 記事の「施策レポート」

施策ログDBに記録するデータは、大きく分けて2種類ある。
施策記録
記事に対して「何かを変えた」ときの記録。リライト、内部リンクの追加、meta情報の修正、カニバリ対策(※後述)など。いつ、何をして、どこを変えたかを残す。ビフォー・アフターのスクリーンショットも貼れる。
定期計測
月に1回、各記事の順位・CTR・クリック数を記録するスナップショット。施策をしていなくても、数字は勝手に動く。それを定点観測するためのもの。
3つの日付で「いつの数字か」を明確にする
施策ログには「3つの日付」がある。ここが少しだけ複雑だが、大事なポイントなので説明しておく。
実施日:施策を実行した日。リライトを公開した日とか、計測をした日とか。
施策前_計測日:施策をやる直前に、サチコでデータを取った日。「この施策をやる前の状態」を記録するための日付。
施策後_計測日:施策のあと、効果を確認するためにサチコでデータを取った日。通常、施策から2〜4週間後に設定する。
なぜ3つも必要なのか。「いつ時点の数字なのか」が曖昧だと、あとから見返したとき比較ができないからだ。「順位5位」と書いてあっても、それが施策前の数字なのか施策後の数字なのか、いつ取ったデータなのか分からなければ、施策レポートとしての意味がない。
効果判定もつける。◎(大幅改善)、○(改善)、△(微改善)、→(変化なし)、×(悪化)、未計測の6段階。施策の結果を一目で把握するためのもので、これが溜まると「リライトは効くけどCTA変更は効かない」といった傾向が見えてくる。
ちなみに「カニバリ」という言葉がさっき出てきたが、これは「カニバリゼーション(共食い)」の略。同じサイト内の複数ページが同じキーワードで競合してしまい、Googleがどのページを上位に出すか迷って、結果的にどちらの順位も下がる現象のこと。備考欄に「カニバリ発生中:/topics/○○/と競合」のように書いておくと、対策の優先判断に使える。
ボタン1つで記録が始まる

このシステムで一番こだわったのが、「記録を始めるまでの手間をゼロに近づける」ことだった。
管理ツールが使われなくなる最大の原因は、入力が面倒なこと。別のDBを開いて、新規行を作って、リレーションで記事を選んで……というステップが3つ4つあると、「あとでやろう」が「結局やらない」に変わる。
そこで、記事管理DBのテーブルに「施策ログを追加」というボタン型のプロパティ(列)を追加した。
操作はこれだけ。
- 記事管理DBを開く
- 対象の記事の行にある「施策ログを追加」ボタンをクリック
- 施策ログの記入ページが開くので、そのまま書く
対象記事との紐づけは自動。ページ遷移も自動。ボタンを押した瞬間に記録が始まる。
このボタンはプロパティ(列)として追加しているので、新しい記事が増えても自動的にボタンが付く。個別にボタンを設定する必要はない。
日常の使い方 ── 5つの場面
場面1:外注先からリライト提案が来たとき
記事管理DBを開いて、対象記事の行を確認する。月間検索ボリュームや目標順位を見て、その記事にどれくらいの価値があるかを把握する。次に、施策ログを見て、過去に何をやったかを確認。
前回リライトしたのに効果が出ていなかったら、「同じやり方でいいのか? 別のアプローチを検討してほしい」と外注先にフィードバックできる。感覚ではなく、記録に基づいた判断。
場面2:リライトを実施したとき
対象記事の「施策ログを追加」ボタンをクリック。遷移先のページで施策の内容を記入する。
- 施策種別(本リライト、局所リライト、テクニカル修正など)
- 何をどう変えたか
- 施策前のデータ(順位・CTR・クリック数をサチコから取得)
- 効果判定は「未計測」にしておく
施策後の計測日は「実施日+4週間後」あたりを仮で入れておくと、計測忘れを防げる。
場面3:効果を計測するとき(実施後2〜4週間)
施策ログの「未計測一覧」ビューを開く。計測日を過ぎているレコードが並んでいるので、サチコからデータを取って、施策後の数値を埋める。施策前と比較して、効果判定をつける。
場面4:月次の定期計測
毎月決まったタイミング(たとえば毎月15日)に、主要記事の現在の順位・CTR・クリック数を記録する。
記事管理DBを開いて、各記事の「施策ログを追加」ボタンをクリック。施策種別を「定期計測」にして、今月の数値を入れる。前月の数値も記録しておけば、月ごとの変化が一目で分かる。
これを3ヶ月、半年と続けると、「この記事はじわじわ順位が下がり続けている」「リライト後に一時的に上がったけど戻った」といったトレンドが見えてくる。問題の早期発見に直結する。
場面5:月次レビュー
月末に施策ログを実施日ソートで振り返る。今月やった施策の効果判定を俯瞰して、「○や◎が多いなら今のやり方を継続」「×や→が多いなら方向転換を検討」という判断をする。定期計測のデータも合わせて、翌月にどの記事を優先的に手を入れるかを決める。
うまく運用するコツ
記録は当日中に。「あとで書こう」は危険。施策の内容も、施策前の数値も、翌日には記憶が曖昧になる。ボタンを押して30秒で書き始められる仕組みにしてあるので、施策を終えたその場で書くのがベスト。
定期計測の日付は揃える。「今月は5日に測って、来月は20日に測った」だと、期間がバラバラで比較しにくい。毎月15日なら15日、と決めておく。
効果判定は数値で決める。「なんとなく良くなった気がする」ではなく、施策前後の順位・CTR・クリック数の差で機械的に判定する。感覚を排除するのが、このシステムの価値。
このシステムで何が変わるか
導入前は、施策の記録がバラバラに散らばっていて、数値は上書きで消え、効果検証は感覚頼みだった。
導入後は、1記事1ボタンで記録が始まり、時系列で数値の変化を追えて、効果判定で次の打ち手が見える状態になった。
ログが溜まるほど価値が上がるシステムなので、最初の数ヶ月は「まだデータが少ないな」と感じるかもしれない。でも、半年後に振り返ったとき、「あのとき記録しておいてよかった」と思えるはず。
使いながら育てていくもの、くらいの気持ちで始めてもらえればと思う。








