SEO記事のカニバリを防ぐ方法｜担当URLの管理表と見直し手順

記事のカニバリを防ぐには、検索語の表記ごとに記事を増やす前に、読者の疑問をまとめ、答えの主担当となるURLを決めます。そのうえで、既存記事と新企画の「入力する材料」「本文の答え」「読後にできること」を照合し、役割が同じなら既存記事への追記を検討します。

「AI議事録の作り方」と「AIで議事録を作成する手順」は、タイトルが違っても同じ工程を説明しやすい企画です。一方、発言者を取り違えた文字起こしの修正には、別の入力例と確認手順が必要です。記事を分ける根拠は、言葉の違いだけでは決まりません。

この記事では、記事を継続制作するチーム向けに、担当URLの管理表、企画の重複を見つける手順、公開後の点検方法を説明します。MakeAIで実際に作成した記事計画の役割分担も使います。設計を行った記録であり、検索順位や流入が改善した実測事例ではありません。

カニバリの候補と、対応が必要な状態を分ける

SEOでいうキーワードカニバリゼーションは、同じサイトのページが似た検索語・意図で競い、全体の検索成果を損なう問題を指します。同じクエリで2ページが表示されたことだけでは、悪影響があるとは判断できません。Ahrefsの解説も、意図やサイト全体への影響を確かめる必要があると説明しています。

例えば、基本手順の記事とエラー解決の記事が、それぞれ別の具体的な質問から読まれている場合があります。一つの共通語を理由に統合すると、片方で解決していた疑問を薄める可能性があります。

見つけた状態	最初の扱い	次に確認すること
タイトルや検索語が似ている	企画重複の候補	読者の状況と本文の答えが同じか
同じクエリで2URLが表示される	検索データ上の候補	各URLが担う意図と、他の関連クエリからの流入
同じ目的の記事で表示先が入れ替わり、対象テーマの流入も弱い	優先して調べる候補	本文の重複、URLの変更、正規化、時期や検索需要の変化
検索データがまだ少ない	効果判定は保留	企画の範囲と公開ページへの導線を先に確認する

「Googleが混乱したから必ず順位が下がる」「似た記事は全て削除する」といった一律の判断をせず、変更前に何が起きているのかを記録します。

記事の管理表に、担当する疑問と扱わない範囲を書く

一つの行を一つの担当ページにします。主な検索語は探すためのラベルとして使い、表記違いや近い疑問は同じ行の補助語へまとめます。1ページで使えるキーワードを一つに制限する、という意味ではありません。

管理項目	記録する内容
担当URL・記事ID	既存ページか新企画か。記事名を変えても追える識別子
読者の状況と疑問	誰が、何を進められず、何を知りたいのか
主な検索語・補助語	調査した語、確認日、需要が未確認ならその状態
本文の答えと完成物	手順を選べる、入力表を作れる、誤りを直せるなど
独自の材料	検証記録、実際の入力と出力、比較条件、編集した教材
扱わない範囲	関連するが別の担当ページで詳しく答えること
親ページ・次に読むページ	全体像へ戻る先と、読後に必要になる作業
状態・更新担当・確認日	企画、下書き、予約、公開を分けて管理する

「扱わない範囲」は本文から関連語を消すための欄ではありません。読者に必要な短い説明は残し、別記事と同じ詳しい手順や事例を繰り返さないために使います。

記入例：議事録の基本と、話者の訂正を分ける

次の表は、MakeAIの記事計画で決めた分担を要約したものです。検索結果で両記事が競合していると観測した例ではありません。

担当する記事	読者が持ってくる材料	本文で完成させるもの	繰り返さない内容
AI議事録の基本手順	会議の記録、共有したい項目	記録から確認・共有までの作業手順	話者訂正だけの詳細な照合
文字起こしの話者ラベルを直す手順	発言者が混ざった文字起こしと照合材料	訂正できる箇所と未確認箇所を分けた記録	議事録全体の作成方法やツール比較

基本手順の実際の本文は、AIで議事録を作成し、確認・共有する手順で確認できます。詳細記事を独立させるなら、基本記事の小見出しを長く言い換えるだけでなく、固有の材料と作業を用意します。

新企画を追加するときの照合手順

1. 既存・予約・未執筆の企画を同じ表で検索する。公開済みだけを見ると、別の担当者が準備している記事と重なります。
2. 似た企画を2〜3件選び、本文の答えを比較する。タイトルだけでなく、冒頭の結論・主要見出し・具体例を読みます。
3. 対象の検索語で求められる形式を確認する。手順、比較、用語解説などの違いを見ます。上位ページの構成をそのまま写すためではありません。
4. 新記事にしかない完成物を一文で説明する。「既存記事と違うのはツール名だけ」なら、既存記事の更新で足りないか検討します。
5. 担当URLと判断理由を記録してから執筆する。担当者が変わっても、分けた理由が分かる状態にします。

「AI活用」と「生成AI活用」、「書き方」と「作り方」のような表記の差は、新しいURLを作る理由として十分ではありません。反対に、同じ製品の話でも、社内資料の登録と営業前の企業調査では、材料も検証することも変わります。

トピッククラスターは、基礎と詳細の仕事をつなぐ

トピッククラスターでは、テーマ全体を理解する入口となるページと、個別の疑問を解決する記事を関連付けます。MakeAIでは、事業ページ、実務テーマの入口、基礎記事、詳細記事の役割を分けて管理しています。

基礎記事からは「ここまで分かった読者が、次に困ること」へ案内し、詳細記事からは前提を確認できる基礎へ戻します。関連が薄い記事を数合わせでつなぐ必要はありません。

ページの役割	リンクで案内する理由
テーマの入口	何から読むかを選ぶため
基礎記事	全体の工程や前提を理解するため
詳細記事	特定の失敗や作業を解決するため
事業ページ	自社だけで進めにくい工程を相談するため

予約中の記事は、管理表に存在しても公開リンクには出しません。MakeAIのサイトも、リンク先が公開された段階で関連記事として案内する仕組みにしています。記事数が増えても基礎記事へ戻れる入口を残し、公開済みの記事が孤立しないよう確認します。

公開後は、Search ConsoleのクエリとURLを照合する

Search Consoleの検索パフォーマンスレポートでは、クエリやページごとのクリック数・表示回数・平均掲載順位などを確認できます。管理表の主な検索語だけでなく、各記事が実際に読まれている関連語も見ます。

1. 同じ期間・検索タイプ・国・デバイスの条件を揃える。
2. 確認するクエリを絞り、表示されたページを確認する。
3. 複数URLがある場合は、本文が同じ疑問へ同じ答えを返していないか読む。
4. それぞれのURLで、他に獲得しているクエリや流入も確認する。
5. 変更日と内容を残し、同じ長さの期間で推移を見直す。

MakeAIの運用では、原則として直近28日とその前の28日を週単位で確認する設計にしています。この期間は編集側の運用ルールで、Googleが定めた判定基準ではありません。公開直後でデータが少ないページは、無理に良否を決めません。

ページ別の表示回数を足した値と、サイト全体の表示回数は、集計方法の違いで一致しないことがあります。合計が合わないだけで異常と扱わず、同じ集計単位で比較します。

重複を見つけたら、統合・役割変更・維持を選ぶ

本文とデータを見た結果	検討する対応	変更前に残すもの
同じ疑問・答えで、独自の材料も重なる	必要な内容を一つにまとめる	残す内容、担当URL、旧URLの転送方針
目的は別だが、冒頭や見出しが同じに見える	対象と完成物を明確にし、重複説明を整理する	それぞれの読者と、リンクで補う範囲
役割が異なり、それぞれに必要な流入がある	維持し、必要な相互案内を整える	統合しない理由と次の確認日
同一内容が別URLでも表示される	正規化やURL生成の仕様を調べる	重複するURL、正規URLの指定、Googleの選択

統合する場合は、残すURLに必要な内容を移し、旧URLへのリンクや適切な転送を確認します。単に本文を消して終わらせず、旧ページを訪れる人が必要な情報へ到達できる状態を整えます。

canonicalは、重複・非常に似たページの正規URLに関する指定です。異なる目的の記事を同じテーマだからとまとめるための設定ではありません。Googleの正規化の説明では、運営者の指定と異なるURLが正規として選ばれる場合もあるとされています。担当URLを管理表に書くことと、Googleの正規URLの選択は別です。

同じ疑問と完成物を扱う二記事を、統合する仮の例

次は架空のサイトを使った編集判断の例です。MakeAIの実在する記事への統合提案や、検索順位が改善した実績ではありません。そのサイトに「AIで社内案内を作る手順」という記事Aと、「生成AIで案内文を書く方法」という記事Bがあり、どちらも開催条件から送信前の案内文を作る内容だったとします。

確認項目	記事A	記事B
読者と主な疑問	社内案内の担当者が、条件を漏らさず下書きを作りたい	同じ担当者が、条件を漏らさず下書きを作りたい
入力と完成物	日時・対象・参加条件から、確認前の案内文を作る	同じ条件から、確認前の案内文を作る
共通する内容	必要な入力項目、基本の依頼文、送信前の確認	ほぼ同じ入力項目、依頼文、送信前の確認
固有の材料	条件の記入例と、全文を示した完成案内	申込み期限を開催日と取り違えた失敗例と修正依頼
管理状態の仮定	担当者が決まり、関連ページからの入口として使っている	同じ担当者が管理。別の読者や用途は確認されていない

この場合、タイトルの言葉は違っても、読者の出発点と完成物は同じです。Bの失敗例は残す価値がありますが、別の作業を一から説明するための材料ではありません。そこで、AへBの失敗例を移し、一つの記事で基本手順と修正方法まで読める構成を検討します。Aを残す理由は、既存の入口と管理が整っているというこの例の条件です。古い記事や順位の高い記事を常に残すという規則ではありません。

統合後の節	残す材料	整理する重複
案内に必要な条件をそろえる	Aの記入例。日時と申込み期限を別項目にする	A・Bの入力項目の説明を一つにする
条件から下書きを作る	Aの依頼文と完成案内	同じ働きをするBの基本プロンプトは重ねない
日付を取り違えたときに直す	Bの誤った出力、修正依頼、直した後の照合	一般的な送信前チェックの重複を減らす

統合案を作ったら、Bにあった独自の回答や配布資料が抜けていないかを確認し、旧記事から来た読者も同じ疑問を解決できるかを読み直します。URLをまとめる場合の転送や内部リンクの変更は、内容の移行と合わせて担当者が計画します。この例から、公開中のURLをそのまま削除する判断はできません。

調査の途中で、Bが「社外向けの正式通知」など別の読者や判断条件を扱い、その用途で読まれていると分かったら、統合の前提は変わります。共通部分だけを整理し、役割を分ける案へ戻します。検索成果への悪影響を確認できていない段階では、統合による順位回復を約束せず、重複した答えと更新作業を整理する編集判断として記録します。

対応案は、変更するものと確かめることを一緒に書く

「統合する」「リライトする」という言葉だけでは、公開時に何を変えるかが決まりません。本文を読む人、URLを管理する人、検索データを見る人が同じ変更を確認できるよう、対応票を一枚作ります。転送や正規化の変更は本文の編集と別に扱い、根拠なく一括適用しないようにします。

対応票の記入欄
対象URLと現在の役割：
観察したクエリ・期間・検索条件：
似ている答えと、各ページに固有の材料：
採用する対応：維持／役割を明確化／統合／技術的な調査
残すURLと、その理由：
移す具体例・資料・リンク：
変更後に確認する読者の導線：
転送や正規化の変更が必要か：
公開後に同じ条件で確認する値：
統合しない場合の理由と、次の見直し条件：

同じ内容を別のURLでも表示している場合は、編集上の役割分担だけでは解決しないことがあります。Googleの正規化に関する説明を踏まえ、URL生成や正規URLの指定を確認します。自分で決めた担当URLがあることと、検索エンジンがそのURLを正規として扱うことは区別してください。

変更後は、残したテーマ全体の到達先を見る

統合後に旧URLのクリックが減ること自体は、想定どおりの場合があります。旧URLだけを見て失敗と判断せず、新しい到達先へ必要な内容が引き継がれ、読者が迷わず進めるかを確かめます。逆に新URLのクリックが増えても、元の詳細な疑問が解決できなくなったなら、記事の役割を失った可能性があります。

変更日を記録し、同じ長さの期間と同じ検索条件で、対象クエリと担当ページを確認します。検索数の季節変化や他の更新が同時に起きることもあるため、一度の前後差を統合の効果と断定しません。データが少ない場合は判定を保留し、まず転送先、内部リンク、本文の完成物が意図どおりかを確認します。

管理表は新規企画を止めるためだけのものではありません。既存記事では答えられない独立した疑問が見つかったとき、必要な入力と完成物を説明して新しい担当URLを置くためにも使います。分けた理由を残せることが、後から記事同士を整理し直す際の判断材料になります。

よくある質問

一つの検索意図に、必ず一つの記事しか作れませんか？

担当する中心ページを決める編集上の原則です。表記の違いだけで同じ答えを増やさないために使います。読者の状況や必要な材料が異なるなら詳細記事を設計できますが、分けた理由を本文で説明できることが条件です。

記事が増えるほど、トピッククラスターは強くなりますか？

本数だけでは判断できません。同じ説明が増えるより、必要な疑問に答え、既存記事と役割が分かれていることを優先します。独自の材料がない企画は、追記や統合で解決できないか検討します。

順位が落ちたら、似た記事をすぐ統合するべきですか？

まず対象期間・クエリ・URL・ページ変更を確認します。需要や競合、取得状態などの変化もあり、順位低下だけでは原因をカニバリに限定できません。根拠を残して、対応前後を比較できる状態にします。