記事が増えるほど「どの記事から直すか」が難しくなります。AIはリライトそのものを丸投げするより、Search Consoleの数値と記事の役割を整理し、優先順位の候補を作る用途で使うと効率的です。
SEO全体の順番： まずSEO改善ロードマップで改善段階を確認します。AIで記事改善を一連の流れにする場合は、検索意図を整理 → リライト項目を確認 → 内部リンク候補を整理 → 公開前チェックの順に進めます。
確認する順番
- 直近のSearch ConsoleデータをURL単位で整理
- 表示回数・クリック・CTR・平均掲載順位を確認
- AIに状態別の改善候補を分類させる
- 実際の検索クエリと本文を人が確認
- 変更日を記録し、後で再評価する
「現状維持」も正しい判断に含める
初心者は全記事を直そうとせず、まずSearch Consoleで変化が見えるページだけを候補にします。運営に慣れてきたら、AIには「直す記事」だけでなく「今は触らない記事」も分類させます。データが少ないページ、伸びているページ、季節変動中のページまで一括修正しないことで、作業時間と判断コストを減らせます。
1．Search Consoleの数字をURL単位で整理する
まずページごとに表示回数、クリック、CTR、平均掲載順位を並べます。期間を混ぜると比較しにくいため、同じ期間で揃えます。
2．AIには「分類」をさせる
AIに順位改善を断定させるのではなく、「CTR改善候補」「本文強化候補」「内部リンク候補」「技術確認候補」のように分類させます。
3．検索クエリと記事の役割を照合する
数字だけでは検索意図のズレは分かりません。実際に表示されているクエリと記事タイトル・主要見出しを見比べ、狙っている内容と一致しているか確認します。
4．一度に全部変えない
タイトル、本文、内部リンク、構造を同時に変更すると改善理由を追いにくくなります。優先順位の高い変更から記録を残して実施します。
関連記事
AIでリライト優先順位を決める4分類
| 状態 | 考える改善 |
|---|---|
| 表示回数多・CTR低 | タイトル・ディスクリプション・検索意図 |
| 順位11〜30位付近 | 本文不足・内部リンク・専門性 |
| 表示回数がほぼない | テーマ需要・インデックス・記事役割 |
| 順位低下が急 | 技術問題・検索意図変化・サイト変更 |
AIへ数値を渡すときの使い方
AIに「順位を上げる方法を決めて」と丸投げせず、URLごとの表示回数・クリック・CTR・平均掲載順位と記事の役割を渡し、「改善候補を理由付きで分類」させます。最終判断はSearch Consoleの実データと公開ページを人が確認して行います。
変更後は同じ指標で比較する
タイトル、本文、内部リンクを一度に大きく変えると何が効いたか分かりにくくなります。変更日と変更内容を記録し、一定期間後に同じ指標で比較します。
やらない方がよいこと
- 平均掲載順位だけで削除・統合を決める
- AIの改善案を確認せず一括反映する
- 変更日を残さず何度も修正する
よくある質問
順位が低い記事から直せばよいですか？
必ずしもそうではありません。表示回数が多くCTRが低い記事や、11〜30位付近で伸びしろがある記事の方が優先度が高い場合があります。
AIだけで優先順位を決められますか？
AIは整理役として使い、最終判断はSearch Consoleの実データ、記事内容、検索意図を確認して決めます。
リライト候補を点数化する簡易スコア
記事数が多いと、感覚だけでは優先順位を決めにくくなります。次のスコアはYOHAKU SELECTで候補を絞るための作業用の目安です。Googleの評価指標や順位保証の方法ではありません。
| 状態 | 加点の目安 | 考える理由 |
|---|---|---|
| 表示回数が多いのにCTRが低い | +3 | 検索結果で改善余地がある可能性 |
| 平均掲載順位が8〜30位付近 | +2 | 本文・内部リンク・検索意図を見直す候補 |
| クエリと記事内容にズレがある | +3 | タイトルだけでなく本文役割の見直しが必要 |
| 関連する強い記事から内部リンクが少ない | +1 | サイト内の導線改善候補 |
| 急な順位低下・表示減少 | 別枠 | 先に技術要因や検索意図変化を確認 |
合計点が高い記事から自動的に直すのではなく、最後に検索クエリと公開ページを人が確認して優先順位を決めます。
状態別に『何を変えるか』を分ける
- 表示回数多・CTR低：タイトル、ディスクリプション、検索意図の一致を確認
- 11〜30位付近：不足している答え、具体例、内部リンク、一次情報を確認
- 表示回数が少ない：需要、インデックス、記事の役割重複を確認
- 順位が急落：サイト変更、noindex、技術エラー、検索意図変化を先に確認
実務で使う優先順位シート
候補記事を並べるときは、数値だけでなく記事の役割も一緒に記録します。これにより「CTR改善だけでよい記事」と「本文から作り直す記事」を分けやすくなります。
| 項目 | 記録する内容 |
|---|---|
| URL | 対象ページのURL |
| 主なクエリ | 実際に表示されている検索語 |
| 表示回数・CTR・順位 | 同じ期間で揃えたSearch Console値 |
| 記事の役割 | 基礎・比較・トラブル解決・行動記事など |
| 改善候補 | タイトル / 本文 / 内部リンク / 技術確認 |
| 変更日 | 再評価の基準日 |
優先順位が高くても触らない方がよいケース
数値上は改善候補に見えても、すぐにリライトしない方がよい場合があります。
- 公開直後でデータがまだ少ない
- 季節要因や一時的なニュースで検索需要が動いている
- サイト全体の技術障害やnoindexなど、記事以外の原因が疑われる
- 検索意図が異なる複数クエリが1ページに混ざっている
この場合は本文を直す前に、期間を延ばして確認するか、技術要因・記事役割の整理を先に行います。
AIへ渡す指示文の例
以下はSearch Consoleから同一期間で取得したURL別データです。各URLを、①CTR改善候補、②本文強化候補、③内部リンク候補、④技術確認候補、⑤現状維持に分類してください。理由を数値と検索意図の両方から説明し、順位改善を断定しないでください。
AIの分類後は、SEOタイトルの決め方、内部リンクの貼り方、カニバリゼーションの確認方法を使い、実際の改善内容を決めます。
変更履歴を残して再評価する
リライト日、変更した箇所、対象クエリ、変更前の表示回数・CTR・平均掲載順位を記録します。一定期間後に同じ指標で比較すれば、次回の優先順位を決める材料になります。複数項目を一度に大きく変えた場合は、どの変更が影響したか切り分けにくい点にも注意してください。
変更履歴の最低限テンプレート
- 変更日
- 対象URL
- 対象クエリ
- 変更した箇所
- 変更前の表示回数・CTR・平均掲載順位
- 次回確認日
タイトル変更と本文変更を同日に行う場合は、何を変えたかを分けて記録します。次回の見直しでは、数値だけでなく検索クエリと記事の役割が改善後も一致しているか確認してください。
