この記事は、記事数が増えたサイトで「どの記事からリライトするか」を決める記事です。AIに全文リライトを任せるのではなく、Search Consoleの表示・クリック・順位と記事の役割を整理して候補を絞ります。数値の読み方はSearch Consoleの使い方、表示自体がない場合はインデックス未登録の確認、CTR課題ならSEOタイトルとmeta descriptionへ分けて確認します。AIとSEOを組み合わせた運用記事はAI×SEO・AIOにまとめています。
SEO全体の順番： まずSEO改善ロードマップで改善段階を確認します。AIで記事改善を一連の流れにする場合は、検索意図を整理 → リライト項目を確認 → 内部リンク候補を整理 → 公開前チェックの順に進めます。Search Consoleで技術的な問題が出ている場合は、リライト前にインデックス未登録の確認、サイトマップ取得エラー、canonicalの確認を先に切り分けます。長期間流入がない記事は、残す・更新・統合・削除の判断手順で役割まで確認します。
確認する順番
- 直近のSearch ConsoleデータをURL単位で整理
- 表示回数・クリック・CTR・平均掲載順位を確認
- AIに状態別の改善候補を分類させる
- 実際の検索クエリと本文を人が確認
- 変更日を記録し、後で再評価する
AI検索で表示されている記事は、通常検索と同じ基準だけで直さず、「触る・保護・待つ」4条件でも確認します。独自情報が弱い場合は一次情報7点チェックで、追加すべき実体験・比較・更新記録を整理できます。
「現状維持」も正しい判断に含める
初心者は全記事を直そうとせず、まずSearch Consoleで変化が見えるページだけを候補にします。運営に慣れてきたら、AIには「直す記事」だけでなく「今は触らない記事」も分類させます。データが少ないページ、伸びているページ、季節変動中のページまで一括修正しないことで、作業時間と判断コストを減らせます。
- リライト前に、根拠と範囲を確認する
- リライト判断｜根拠から次の作業を選ぶ
- 1．Search Consoleの数字をURL単位で整理する
- 2．AIには「分類」をさせる
- 3．検索クエリと記事の役割を照合する
- 4．一度に全部変えない
- 関連記事
- リライト候補を、根拠と次の作業で分ける。
- AIへ数値を渡すときの使い方
- 変更後は同じ指標で比較する
- 数字が動いた日にすぐ全面リライトしない
- よくある質問
- リライト候補は、数値・検索語・本文の根拠で絞る
- 状態別に『何を変えるか』を分ける
- 実務で使う優先順位シート｜まず3候補だけ残す
- 優先順位が高くても触らない方がよいケース
- AIへ渡す指示文の例
- 変更履歴を残して再評価する
- リライトは「変更前→変更内容→結果」で残す
- 実例｜表示回数が減っても「全面リライト」を選ばなかった
- 今回の実例で使ったAI環境
- 参考情報
リライト前に、根拠と範囲を確認する
- 比較できる検索データがあるか。未取得と0件を分ける。
- どの指標が変わったか。クリック・表示・CTR・順位を合わせて見る。
- 誤った事実、技術的な不具合、検索語への回答不足のどれを確認したか。
- 変更する箇所を具体的に示せるか。
確認済みの誤情報・不具合は、順位評価とは分けて修正します。低順位や少数の表示だけを理由に、記事全体を書き直したり内部リンクを追加したりしません。
リライト判断｜根拠から次の作業を選ぶ
対象ページを1つ決め、確認できた状態を選びます。自動でサイトやSearch Consoleを取得する機能ではありません。判断できない項目は「未取得・未確認」を選べます。
YOHAKU SELECTの作業整理用です。Googleの評価基準や順位予測ではありません。履歴を保存する場合はこのブラウザ内の最新5件に入り、別端末には同期されません。完了操作と結果の種類をアクセス解析へ記録する場合があります。対象URLや顧客情報の入力は不要です。
JavaScriptが無効のため自動整理は動作しません。確認済みの不具合・誤りは修正し、比較できるデータがない場合は検索評価を保留します。手動の記録手順で進められます。
判断手順・操作の見直し：2026年10月15日
1．Search Consoleの数字をURL単位で整理する
比較期間・検索タイプをそろえ、対象URL、表示回数、クリック、CTR、平均掲載順位を記録します。ページ合計だけでなく、主要クエリと本文の答えを照合してください。「表示あり・クリック少ない」と「表示自体がない」では、最初の作業が違います。
- 表示がない：検索への登録状態を先に確認する。
- 表示はある：順位と検索語を確認し、タイトル・冒頭・リンクのうち問題がある箇所だけ候補にする。
- 最新データが取れない：流入が少ない記事と決めつけず、誤情報・リンク切れ・表示崩れなど確認できる問題を直す。順位・CTRをAIに推定させない。
2．AIには「分類」をさせる
AIに順位改善を断定させるのではなく、「CTR改善候補」「本文強化候補」「内部リンク候補」「技術確認候補」のように分類させます。
3．検索クエリと記事の役割を照合する
数字だけでは検索意図のズレは分かりません。実際に表示されているクエリと記事タイトル・主要見出しを見比べ、狙っている内容と一致しているか確認します。
4．一度に全部変えない
タイトル、本文、内部リンク、構造を同時に変更すると改善理由を追いにくくなります。優先順位の高い変更から記録を残して実施します。
関連記事
リライト候補を、根拠と次の作業で分ける。
- 登録状態に疑問がある：インデックスの確認を先に行う。本文を書き直す前に、公開URLとGoogleの確認結果を照合。
- 表示はあるがCTRが気になる：順位・検索意図・タイトルの3分類。対象クエリと順位をそろえ、変える理由を言えるタイトルだけ候補にする。
- 本文の答えが不足する：不足する質問・出典・手順を特定して補足。出典はURLと到着先の見出しを確認する例のように確かめる。
- 読後の次の手順がない：内部リンクの文言と到着先を見直す。
- 好調・公開直後・データ不足：維持または再確認待ちに分類する。技術的な誤りやリンク切れは別に扱い、順位・CTRをAIで補わない。
AIに渡す記録：対象URL／比較期間／実測値（未取得なら未取得）／確認した検索語／不足する答え／変える1点／維持する情報。根拠がそろわない候補は保留し、変更後は変更履歴で比較条件を残します。
AIへ数値を渡すときの使い方
AIに「順位を上げる方法を決めて」と丸投げせず、URLごとの表示回数・クリック・CTR・平均掲載順位と記事の役割を渡し、「改善候補を理由付きで分類」させます。最終判断はSearch Consoleの実データと公開ページを人が確認して行います。
変更後は同じ指標で比較する
タイトル、本文、内部リンクを一度に大きく変えると何が効いたか分かりにくくなります。変更日と変更内容を記録し、一定期間後に同じ指標で比較します。
数字が動いた日にすぐ全面リライトしない
- 平均掲載順位だけで削除・統合を決める
- AIの改善案を確認せず一括反映する
- 変更日を残さず何度も修正する
よくある質問
順位が低い記事から直せばよいですか？
必ずしもそうではありません。表示回数が多くCTRが低い記事や、11〜30位付近で伸びしろがある記事の方が優先度が高い場合があります。
AIだけで優先順位を決められますか？
AIは整理役として使い、最終判断はSearch Consoleの実データ、記事内容、検索意図を確認して決めます。
リライト候補は、数値・検索語・本文の根拠で絞る
候補ごとに確認した数値／対象クエリ／公開本文とのずれ／次の1操作を並べます。平均順位や低CTRに点数を足すだけで決めず、同じ条件のデータと本文を照合します。データが取得できない欄は「未取得」と残し、リンク切れ・古い事実・文言と行き先の不一致など、公開ページで確かめられる問題を別に扱います。
| 状態 | 先に確認する根拠 | 次の1操作 |
|---|---|---|
| 表示はあるがCTRが低い | 対象ページ・検索語・端末・期間をそろえ、順位も確認 | タイトルが検索語の疑問に答えるか照合 |
| 検索語と本文の答えがずれる | 読者の疑問に対する不足箇所を具体的に特定 | 対象者・疑問・次の行動を整理 |
| 関連ページへ進みにくい | どの段落で、何の判断材料が足りないか確認 | その疑問を解決するリンクを検討 |
| 急な表示減少・順位低下 | サイト変更や登録状態の問題を切り分け | 技術確認から始める |
| 最新データが未取得 | 未取得と記録し、数値で順位付けしない | 公開本文の事実・リンク・行き先を確認 |
記入例（架空）：「最新GSC値は未取得。本文の料金条件が公式資料と不一致なので、その段落を修正。順位・CTRの評価は未判定。」のように、内容を直す根拠と検索効果の判断を分けます。数値が取得できたら同じ比較条件で確認し、変更理由は変更履歴6項目へ残します。
状態別に『何を変えるか』を分ける
- 表示回数多・CTR低：タイトル、ディスクリプション、検索意図の一致を確認
- 11〜30位付近：不足している答え、具体例、内部リンク、一次情報を確認
- 表示回数が少ない：需要、インデックス、記事の役割重複を確認
- 順位が急落：サイト変更、noindex、技術エラー、検索意図変化を先に確認
実務で使う優先順位シート｜まず3候補だけ残す
表示・CTRだけで全記事に点数を付ける前に、1件ずつ確認できる3候補へ絞ります。各候補は、次の7行を手元のメモへコピーして埋めます。
対象クエリ・検索タイプ・国・端末：
比較する2期間・日数・曜日構成：
両期間のクリック・表示・CTR・順位（欠測は未取得）：
公開本文で確認できた不足と根拠URL：
次に変える1か所／今回は保留する理由：
変更日・検索側の更新期間・再確認する条件：
架空例：「候補A／最新数値は未取得／公式の無料モデル条件と本文が不一致／無料条件の段落を直す／順位・CTR評価は保留」。検索数値がなくても事実の訂正はできますが、その訂正を検索順位改善の実績とはしません。
- 確認済みの誤り：公式条件・リンク先との不一致を、該当箇所だけ修正。
- 比較できる数値と本文不足：対象クエリの疑問に答える1か所を選ぶ。
- 根拠不足・条件不一致：「保留」と残し、AIに数値や理由を補わせない。
検索側の更新期間は公式履歴の記録例と照合します。3件すべてを一度に全面修正せず、確かめられる1件の1目的から始めます。これは当サイトの作業手順で、Googleの公式な順位付け基準ではありません。
優先順位が高くても触らない方がよいケース
数値上は改善候補に見えても、すぐにリライトしない方がよい場合があります。
- 公開直後でデータがまだ少ない
- 季節要因や一時的なニュースで検索需要が動いている
- サイト全体の技術障害やnoindexなど、記事以外の原因が疑われる
- 検索意図が異なる複数クエリが1ページに混ざっている
この場合は本文を直す前に、期間を延ばして確認するか、技術要因・記事役割の整理を先に行います。
AIへ渡す指示文の例
先に3候補の記録を埋め、対象期間と公開本文の抜粋を添えます。外部の更新期間は観察用の注記で、順位低下の原因として決めつけないよう指示します。
以下は、同一期間・同じ検索タイプで確認したURL別データと主要クエリです。各URLを「タイトル・説明文の確認」「本文の答えを補う」「内部リンクを確認」「技術確認」「保護・待機」に分類してください。使った数値、クエリと本文のずれ、提案する変更箇所をそれぞれ1行で示してください。
欠測は0で埋めず、判断材料が足りなければ未判定としてください。伸びているページは大幅変更の候補から外し、誤った事実が確認できた箇所だけ別に挙げてください。平均順位や低CTRだけで削除・統合を提案せず、順位・クリック増を予測しないでください。
人が公開本文と根拠を照合し、1ページの1目的に絞って実行します。比較条件と未計測の扱いはKPI4指標、変更した内容は変更履歴6項目へ残します。
AIの分類後は、SEOタイトルの決め方、内部リンクの貼り方、カニバリゼーションの確認方法を使い、実際の改善内容を決めます。
変更履歴を残して再評価する
リライト日、変更した箇所、対象クエリ、変更前の表示回数・CTR・平均掲載順位を記録します。一定期間後に同じ指標で比較すれば、次回の優先順位を決める材料になります。複数項目を一度に大きく変えた場合は、どの変更が影響したか切り分けにくい点にも注意してください。
変更履歴の最低限テンプレート
- 変更日
- 対象URL
- 対象クエリ
- 変更した箇所
- 変更前の表示回数・CTR・平均掲載順位
- 次回確認日
タイトル変更と本文変更を同日に行う場合は、何を変えたかを分けて記録します。次回の見直しでは、数値だけでなく検索クエリと記事の役割が改善後も一致しているか確認してください。
YOHAKU REWRITE LOG
リライトは「変更前→変更内容→結果」で残す
| 記録 | 例 |
|---|---|
| 変更前 | 表示・クリック・CTR・順位 |
| 変更内容 | titleだけ / 導入だけ / 内部リンクだけ |
| 確認日 | 反映を見る日 |
| 結果 | 上がった・変わらない・下がった |
一度に本文・title・URL・内部リンクを全部変えると、何が効いたか分かりません。変更単位を小さくして比較します。
YOHAKU LIVE GSC CASE｜データ確認 2026-09-19
実例｜表示回数が減っても「全面リライト」を選ばなかった
YOHAKU SELECTの「ホームページ公開のお知らせ」記事は、2026年9月13〜15日に67表示・5クリックを記録しました。その後は表示回数が減りましたが、平均掲載順位はおおむね3〜6位を維持していました。
次のSearch Consoleデータを「需要減の可能性」「順位低下の可能性」「CTR課題」「内容課題」に分けてください。
断定せず、追加で確認すべき数字も書いてください。
表示：67（9/13〜15に確認）
クリック：5
その後：表示回数は減少
平均掲載順位：おおむね3〜6位を維持
順位まで大きく落ちた証拠がないため、「表示が減った＝記事が悪くなった」とは決めません。検索される機会の減少、期間の短さ、検索語の変化を先に確認し、大幅なタイトル・本文変更は保留します。
短期間のスナップショットであり、将来の流入を予測するデータではありません。元の公開実例はSearch Consoleの使い方に残しています。
TEST ENVIRONMENT｜2026-09-24
今回の実例で使ったAI環境
| AI | ChatGPT / GPT-5.6 Sol |
|---|---|
| 入力 | Search Consoleの短期実例、既存記事本文、記事の役割 |
| AIへ任せたこと | 状態の整理、リライト候補の分類、重複候補の抽出 |
| 人・運営側で確認 | 実際の検索クエリ、公開日、事実誤り、変更する理由、最終公開内容 |
モデル更新で出力傾向は変わるため、これは2026年9月24日の実験記録です。「このモデルなら必ずSEOが改善する」という意味ではありません。
実際の本文修正はAIで古い記事をリライトする手順へ進みます。一方、検索意図がほぼ同じ記事が複数あるなら、書き直す前に残す・統合・削除の判断を先に行います。
