検索意図と記事の対応表を作る｜似たテーマの追加・改稿・統合を判断する

検索語の一覧に読者の作業を添える

最初の列には検索語、次の列には「誰が、何を決めたいか」を一文で書きます。「音声AI 料金」と「音声AI 商用利用」は同じ製品を扱っていても、予算決定と公開可否で必要な根拠が違います。検索量の数値が未取得なら空欄のまま残し、推測の需要を実績へ変えないでください。言語と対象地域も別列にし、英語検索語を日本語の意図へ自動でまとめないようにします。

既存ページを本文まで読んで対応させる

タイトルだけで既存記事があると判断せず、本文がどの質問に答えているかを確認します。料金の記事に商用利用への注意が一段落あるだけなら、公開条件を説明する記事の代わりにはなりません。一方、見出しの言い換えだけで追加した候補が既存の説明と同じ結論・手順になるなら、改稿へ回します。URL、主な質問、対象外の質問、現在不足している根拠を一行に記録すると、編集者が変わっても判断を追えます。

追加するページには独立した成果物を決める

新規候補には、読者が持ち帰れるものを指定します。例えば月間文字数から契約候補を絞る計算例、商用公開前の確認表、別サービスへ移る際の保存手順です。既存記事と違う製品名を並べただけでは十分ではありません。新しい根拠を調べる時間や、更新を続ける担当も確保できるかを確認します。一つの作業を細切れにして複数URLへ分けるより、途中で読み直せる見出しを同じページへ置く方が使いやすい場合もあります。

重なりは統合・役割分担・維持で整理する

重なった二記事は、すぐ削除せず、違いを説明できるかを検討します。役割を分けるなら、一方を費用の計算、もう一方を契約条件の確認に絞り、互いの目的が分かるリンクを置きます。実質的に同じ内容なら、残すURLへ根拠と有用な段落をまとめ、転送や内部リンクの変更を別の実装作業として準備します。canonicalは読者の質問の違いを代わりに設計する機能ではありません。

検索実績は対応表の仮説を確かめる材料にする

公開後はSearch Consoleでページと検索語を同じ期間で見ます。二つのURLが同じ語で表示されても、それだけで不具合とは決めません。対象国、端末、検索意図、掲載される本文が違う可能性があります。片方の記事に必要な情報が欠けるのか、見出しが広すぎるのかを本文へ戻って確認します。表示回数が少ない段階では、細かい比率の変化を優劣の根拠にせず、次に調べる候補として扱います。

台帳の一行を公開作業までつなぐ

対応表には「維持・改稿・追加・統合候補」の状態、担当、次の確認日を置きます。統合候補を承認済みの削除として扱わず、引き継ぐ本文とリンクの影響を確認する工程を残してください。公開したらURLと確認結果を追記し、候補だった行を完了へ変えます。古い計画書と公開済み一覧が別々に増える運用を避けるため、記事IDを共通の識別子にすると、日英版や後の改稿も追いやすくなります。

例：料金と利用条件を混ぜない

架空の編集例では「音声AIの選び方」が月額、音質、商用条件を広く説明しているとします。追加候補の「月10本のナレーション費用」は制作量と訂正量を計算する役割に絞り、「商用公開の確認」は契約の対象、出力の扱い、納品先の条件を調べる役割にします。選び方記事には詳しい計算や条件の全文を重ねず、該当箇所へ案内を置きます。実測も検索需要も確認していない例なので、そのまま勝てるキーワードと判断しません。

• キーワード調査ツールの選び方｜候補語を重複しない記事企画へ変える
• canonicalの競合を点検する｜内部リンク・転送・代表URLをそろえる
• 内部リンクの点検方法｜リンク切れ・孤立・不自然な関連記事を直す