リライトは、直す理由を特定してから選ぶ
順位が低い記事をすべて直すのではなく、事業に必要な問いへ答えているか、内容に誤りがあるか、どこに改善余地があるかを確認します。誤情報や利用者を困らせる不備は、検索流入の大きさと別に修正対象へ置きます。
対象リストに必要な前提
URLとcanonical、記事の役割、対象クエリ、比較期間、端末・国・検索タイプ、変更履歴を揃えます。Search ConsoleのクリックとGA4のセッションは異なる計測なので、同じ数になる前提にしません。アクセスが少ない記事でも、既存顧客の支援など役割があれば価値があります。
数字と本文を合わせて候補を分ける
| 状況 | 先にすること |
|---|---|
| 内容に誤り・古い手順 | 公式情報と実画面を確認し修正 |
| 表示はあるがクリックが少ない | クエリ・順位・検索結果・タイトルの約束を確認 |
| クリックはあるが目的の行動が少ない | 意図と内容、次の導線、計測を確認 |
| 急な流入減 | 技術・需要・変更履歴を切り分ける |
| 似た記事が複数ある | 役割と検索意図を比較し、整理の要否を検討 |
Googleの検索流入減の調査ガイドを参照し、小さな順位変動だけで全面変更を決めないようにします。
候補を選ぶ手順
- 事業上重要な記事と、誤りのある記事を抽出する。
- 同じ比較条件でクエリ・ページ単位の変化を見る。
- 本文を読み、意図に答えていない箇所を特定する。
- 技術的な問題と本文の問題を分ける。
- 修正範囲・根拠・期待する変化・確認日を決める。
- 工数と依存作業を含めて、実施・調査・保留に分ける。
架空例：記事Aは表示10,000・クリック100でCTR1％、記事Bは表示1,000・クリック50で5％。Aを自動的に優先するのではなく、対象クエリ・順位・記事の役割を確認します。Aが広い情報探索、Bが重要な比較検討の問いなら、必要な変更は異なります。
公開前と公開後の記録
変更前の本文、タイトル、指標、条件を残します。URL変更・統合・削除は本文追記より影響が広いので、内部リンクや転送の設計も必要です。日付だけ更新したり、根拠なく文章量を増やしたりする作業を改善と呼びません。
リライト選定票に修正理由と見送る理由を書きます。完了条件は、候補ごとに何を変え、何を見て判断するかが決まることです。公開直後の小さな変動だけで成功・失敗を確定せず、事前に決めた期間とデータ量で確認します。
AIに候補比較を依頼する
目的：記事の役割と観測からリライト候補を選ぶ。
入力：URL、役割、対象クエリ、期間、表示・クリック・順位、本文の問題、変更履歴。
出力：実施／追加調査／保留、理由、修正範囲、確認指標。
制約：低CTRだけで順位付けしない。未提供の検索結果や本文を見たと装わない。
削除・統合・URL変更は、影響確認が必要な別案として示す。
AIが引用した本文と数値を原資料へ照合します。実装前のチェックはSEOガイド、順序に迷ったら優先順位へ進みます。
AI支援で制作。資料確認日：2026年10月6日。次回確認予定：2027年1月6日。実務者監修・取材、第三者再現、実運用の効果測定は未実施です。ケースは架空の教材であり、実案件の経験談ではありません。記入例・数値例は架空の教材です。改善効果を保証するものではありません。
