AIで古いSEO記事の更新箇所を洗い出す方法

古いSEO記事を更新するときは、全文をAIに渡して「最新化して」と頼むより、まず何が古くなったのかを分解した方が安全です。更新対象は大きく、Fact、検索意図、Evidence、実績データ、構成、内部リンク、Commercial条件に分けられます。変わっていない部分まで書き換える必要はありません。

この記事では、既存記事と現行情報を比較してRefresh Gap Tableを作り、更新優先度を付け、必要な箇所だけ修正する方法を整理します。公開日だけを新しくするのではなく、「何が変わったから何を直したのか」を残せる状態をゴールにします。

最初に記事の役割がまだ有効か確認する

本文を直す前に、Target QueryとReader Jobが現在も同じか確認します。検索者が求めるものが変わっているなら、Factの更新だけでは足りません。

たとえば以前は「機能紹介」が中心だったQueryが、現在は「料金・比較・使い方」を求めるSERPに変わっている場合、記事の役割自体を見直す必要があります。一方、Intentが変わっていなければ、古いFactや不足Evidenceだけ直す方が効率的です。

Refresh Gap Tableを作る

更新対象を一つの表へまとめます。

表は横にスクロールできます

Area	Current	Current Evidence	Gap	Action
Product Fact	旧料金	公式料金ページ	価格変更	Replace
Feature	旧UI前提	公式Help	操作手順が古い	Rewrite section
Intent	旧Reader Job	現行SERP/GSC	大きな変化なし	Keep
Evidence	旧Source	新しい公式Doc	Source更新	Replace citation
Performance	CTR低下	GSC	Title/Intent要確認	Investigate
Internal Link	旧導線	Site map	新記事へ不足	Add link

「Gapなし」はKeepにします。全部を更新対象にしないことが重要です。

Time-sensitive Claimを先に抽出する

料金、Plan、Free/Trial、機能、API、利用上限、商用利用、Privacy、権利、製品名、UI名など、時間で変わりやすいClaimを本文から先に抽出します。

AIには「変動し得るFactだけを列挙し、原文位置と確認すべき公式Source種別を出す」と依頼します。ここで新しいFactを生成させず、確認対象の棚卸しに使います。

同じ記事でも、背景説明や一般的な手順は変わっていないことがあります。変動Factだけを切り出すと、確認コストを重要な箇所へ集中できます。

公式Sourceと旧本文をClaim単位で比較する

更新は「Sourceを読んで全文を書き直す」より、Claimごとの差分を見る方が追いやすくなります。

表は横にスクロールできます

Claim	旧本文	現行Source	判定
Free上限	旧条件	新条件	CHANGE
商用利用	条件付き可	同じ	KEEP
API	未対応と記載	現在対応	CHANGE
保存期間	記載なし	公式条件あり	ADD

この形式なら、誤更新や不要な言い換えを減らせます。

GSCは「順位が下がったから全文リライト」ではなく原因候補を見る

Search Consoleではclick、impression、CTR、query、pageを期間比較します。

たとえばimpressionは同じでCTRだけ落ちたなら、TitleやSERP競合の変化を疑えます。impression自体が落ちたなら、需要、順位、Index、Intent、競合など別の原因候補があります。新しいQueryが増えているなら、記事が拾い始めたIntentを確認します。

数字だけで原因を断定せず、「何を追加で確認すべきか」を決める材料にします。

Queryの変化をReader Jobへ変換する

GSCで新しいQueryが増えても、全部を本文へ足す必要はありません。同じReader Jobへ答えるQueryか、別Intentかを分けます。

たとえば記事が「AI PDF 要約」で、最近「AI PDF 表 読み取り」が増えた場合、PDFの視覚処理がReader Jobへ直結するならsection追加候補です。一方「PDF OCR アプリ 無料」が別Intentなら別記事の方がよいこともあります。

SERPの変化はPage TypeとQuestionで見る

更新時には現行SERPも確認します。上位が比較記事中心から公式・How-to中心へ変わった、動画やForumが増えたなど、page typeの変化を見ます。

さらに上位ページがどんなReader Questionへ答えているかを整理します。自記事が未回答で、Reader Jobにも必要ならGap候補です。競合見出しをそのまま追加するのではなく、自記事の役割へ合わせます。

Content GapはEvidenceと具体例も見る

古い記事の弱点は、Factが古いだけとは限りません。旧基準で書かれた短い記事では、具体例、Failure Case、Decision、Next Actionが不足していることがあります。

更新時に「正しいが薄い」sectionを見つけたら、単に文章量を増やさず、Input/Output、比較条件、検証手順、失敗時の切り分けなどReader Jobを完了するArtifactを追加します。

削除・統合候補もRefresh Gapに含める

更新は追加だけではありません。重複section、現在不要なFeature説明、別記事と役割が重なる部分、古いCTAなどは削除候補です。

同じQueryへ複数記事が答えている場合は、カニバリやIntent Ownerも確認します。単純に記事を長くせず、サイト全体でどこが答えるかを整理します。

更新しない判断も残す

監査した結果、主要FactもReader Jobも変わっていない記事は、無理に書き換えなくて構いません。更新作業そのものをKPIにすると、意味のない言い換えが増えます。

この場合は「Reviewed / No material change」と記録し、checkedAtだけをEvidence確認日として残します。本文の更新日を変えるかどうかは、実際の変更内容とサイト運用ルールに合わせて判断します。

更新優先度をRiskとImpactで決める

すべてのGapを同じ優先度で直す必要はありません。

P0候補：誤った料金・契約条件・権利・安全性など、読者判断を誤らせるFact。

P1候補：主要Intent未回答、重要Feature変更、Reader Job未完了。

P2候補：具体例不足、内部リンク不足、読みやすさ改善。

P3候補：軽微な表現・表記。

このPriorityを付けると、大量記事のRefreshでも重要な誤情報から直せます。

AIへの依頼文は差分抽出に寄せる

依頼例：

旧記事と現行Evidenceを比較してください。

出力：

• Claim / Section

• 旧内容

• 現行Evidence

• CHANGE / KEEP / ADD / REMOVE / INVESTIGATE

• Reader Jobへの影響

• 更新Priority

• 必要Artifact

ルール：

• Evidenceにない新Factを補完しない

• 全文リライト案はまだ出さない

• 変わっていない箇所はKEEPにする

• 公開日変更だけを更新扱いにしない

差分表を人が確認してから、必要なsectionだけ書き換えます。

更新後はChange Logを残す

少なくとも変更日、変更箇所、理由、Source、checkedAtを記録します。大量運用では「なぜ変えたか」が残っていないと、次回また全体確認から始まります。

価格変更で更新したのか、Intent変化で構成を変えたのか、品質基準の変更で深掘りしたのかを分けると、次のRefresh判断がしやすくなります。

更新日を変える条件を決める

実質的な変更があったときに更新日を変えます。誤字修正や句読点変更だけで、記事全体が新しくなったように見せる運用は避けます。

更新日を出すなら、読者が「何が最新なのか」を理解できるよう、重要なFactのcheckedAtも持つ方が透明性があります。

Before / Afterで更新量を確認する

たとえば旧記事が「料金表＋簡単な特徴」だけで、現行Reader Jobが「自分に必要なPlanを判断する」なら、料金数字だけ直してもTask Completionは不足します。この場合は、無料で足りる条件、追加費用、利用量別の判断、契約前チェックまで追加する大幅Refreshが必要です。

逆に、料金条件が1箇所だけ変わり、構成・判断材料・Evidenceが十分なら、その箇所と関連する結論だけ直せば足ります。更新量は記事の古さではなく、Reader Jobへの影響で決めます。

公開前のRefresh QA

更新後は次を確認します。

• 変動Factを公式Sourceで再確認した

• checkedAtを更新した

• Reader Jobが現行Intentと一致している

• GSCの変化を原因と断定していない

• 追加したsectionにEvidenceがある

• 不要な旧sectionを削除した

• 内部リンク先が現行URL

• CTAやCommercial Destinationが現行contractに従う

• 変更箇所と理由を記録した

• Titleだけ新しくして本文を放置していない

AIものさしの判断

古いSEO記事の更新は「全文を新しく書き直す作業」ではなく、現在との差分を見つけて必要な箇所だけ修正する作業です。Fact、Intent、Performance、Evidence、Navigationを別々に確認すると、変更理由を説明できます。

まず既存記事からTime-sensitive Claimを抽出し、公式Sourceとの差分表を作ってください。次にGSCとSERPでReader Jobの変化を確認し、P0/P1から修正する。最後にChange Logを残せば、次回Refreshもゼロからやり直さずに済みます。