Search Consoleなどでカニバリ候補を見つけ、「この2記事は同じ検索意図を取り合っている」と判断したあとに残る難問があります。どちらのURLを残し、どちらを統合元にするのかです。現在順位が少し高い方、公開日が新しい方だけで決めると、被リンクや内部リンク、長く積み上げたURLの履歴まで捨てる可能性があります。
- カニバリした2記事のどちらを残すかを決める7つの判断軸
- 「順位が高い方を残す」だけでは危険な理由
- 統合先URLを決めた後の、内容移植→301/308→内部リンク更新の順序
- 301リダイレクト・canonical・役割分離・削除の使い分け
- URL A / Bを比較する「統合先URL選定確認ツール」の使い方
まず確認：この記事は「カニバリ判定の次工程」
この記事は、同じクエリに複数URLが出たかを調べる記事ではありません。まだ「本当にカニバリか」が確定していない場合は、先にSearch Consoleでキーワードカニバリを確認する方法で、検索意図・内容重複・主役URLの入れ替わりまで確認してください。
| 工程 | 中心の疑問 | 担当記事 |
|---|---|---|
| 発見・判定 | 同じクエリに複数URLが出る。これは問題か？ | 第06記事：Search Consoleでカニバリを確認 |
| 統合判断 | 統合すると決めた。どちらのURLを残すか？ | 本記事 |
| 実装・検証 | 内容をどう移し、旧URLをどう処理し、何を確認するか？ | 本記事 |
検索意図が明確に違う2ページなら、そもそも統合しない方がよいことがあります。この記事の手順は、「同じ、または非常に近い検索意図で、1ページへ集約する」と決めたケースを対象にします。
カニバリした記事はどちらを残す？7つの判断軸
統合先は1つの数字では決めません。次の7軸を並べると、「今たまたま順位が高いURL」ではなく、今後の代表ページとして最も筋がよいURLを選びやすくなります。
| 判断軸 | 確認すること | 優先の考え方 |
|---|---|---|
| 1. 検索意図との一致 | 残したい主キーワードで、読者が最後に欲しい答えをどちらがより正面から返しているか | 最優先。検索実績があっても意図がずれるURLを代表にしない |
| 2. 安定した検索実績 | 十分な期間でのクリック・表示回数・主要クエリの広がり。短期の順位だけに依存しない | 一時点ではなく期間で比較 |
| 3. 外部リンク・参照 | 被リンク、外部サイトからの引用・紹介、ブックマークされる価値 | 外部から積み上がったシグナルを無駄にしない |
| 4. 内部リンクと階層 | サイト内でどちらがハブ・代表ページとして多く参照されているか | 既存導線を活かせるURLを優先しやすい |
| 5. URLの継続性・明快さ | 短く意味が分かる、長く使える、すでに認知されているか | 新URLを作る利益が小さいなら既存URLを残す |
| 6. 独自情報・更新性 | どちらが再構成の土台にしやすく、今後も更新しやすいか | 「文章量」ではなく、有用な固有情報と保守性で見る |
| 7. 読者・事業上の役割 | 問い合わせ、資料請求、回遊、理解促進などサイト上の役割が明確か | データがなければUNKNOWNのままにする |
「現在順位が高い方を残す」だけでは足りない理由
順位は重要な観測値ですが、統合先URLの全価値を表すものではありません。検索結果は変動しますし、平均掲載順位はクエリ・デバイス・地域などをまたいだ集計として見る必要があります。
たとえばAが現在8位、Bが11位でも、Bの方が主題に合ったURLで、外部リンクが多く、サイト内の代表ページとして長く参照されているなら、Aの「3順位上」を理由にBを捨てるのは早計です。逆に、Aが長期間にわたって主要クエリのクリックを安定して獲得し、URLも分かりやすいなら、Aを残してBの独自内容をAへ移す方が自然です。
迷ったときの優先順位：意図 → 蓄積シグナル → 継続性
- まず検索意図を固定する
統合後の1ページが「誰の、どの疑問に、何を答えるか」を1文で決めます。 - その意図に合うURLを候補にする
タイトルだけではなく、本文の中心、既存流入クエリ、ページの役割まで見ます。 - 失いたくない蓄積を比較する
安定した検索実績、被リンク、内部リンク、外部からの参照を確認します。 - 今後の運用コストを比べる
URLの意味、更新しやすさ、サイト構造との整合を確認します。 - 新しい第3URLは最後の選択肢にする
既存2URLのどちらも主題に合わない場合だけ検討します。新URLを作ると移行対象が増えるため、「きれいだから」だけでは作りません。
具体例：古いAと新しいB、どちらを残す？
URL A：3年前から公開。文章はやや古いが、主要クエリから安定流入があり、複数の内部リンクと外部リンクがある。
URL B：半年前に公開。構成は新しく詳しいが、流入とリンクはまだ少ない。検索意図はAとほぼ同じ。
このケースでは、まずAを残す方向が有力です。Bの新しい説明・図表・具体例を棚卸しし、Aの構成を現在の検索意図に合わせて再設計して取り込みます。その後BをAへ恒久リダイレクトします。
ただしAのURLや中心テーマが現在狙う検索意図と大きくずれ、Bだけが明確に適合しているなら逆転します。「古いURLを必ず残す」「新しい記事を必ず残す」という固定ルールはありません。
統合先URLを比較して選ぶ｜統合先URL選定シート
URL AとURL Bについて、どちらが各項目で優位かを選んでください。これはSEOの自動採点ではなく、判断材料の偏りと未確認項目を可視化する補助ツールです。
※実データを自動取得しません。Google API・Search Console API・OpenAI APIは使用しません。
カニバリした記事を統合する方法：9ステップ
統合先を決めたら、「片方を消して終わり」ではありません。検索エンジンと読者の両方に、代表URLが変わったことを一貫して伝えます。
- 統合前の状態を保存する
両URLの主要クエリ、クリック、表示回数、被リンク、内部リンク、タイトル、主要見出しを記録します。統合後の効果測定の基準になります。 - 残すURLを確定する
7軸で比較し、統合後の検索意図と代表URLを1つに決めます。 - 統合元だけにある有用情報を棚卸しする
具体例、図表、FAQ、一次情報へのリンクなど、「消すと読者価値が下がる要素」を抽出します。 - 統合先を1本の記事として再構成する
2記事を上から順に貼り合わせるのではなく、重複を削り、検索意図に沿って見出し・結論・例を再設計します。 - 統合先を公開・更新する
タイトル、本文、内部導線、AIOSEOのSEOタイトル・Meta Descriptionを統合後の役割に合わせます。 - 旧URLから統合先へ恒久リダイレクトする
サーバー側で可能なら301または308などの恒久リダイレクトを使い、旧URL→最終URLへ直接つなぎます。不要な中継URLを挟まないようにします。 - 内部リンクを統合先へ張り替える
自サイト内で旧URLへ向くリンクを、リダイレクト任せにせず統合先へ更新します。 - canonical・サイトマップを整える
統合先は自分自身を代表URLとして扱える状態にし、サイトマップにも現行URLを載せます。通常記事ならAIOSEOの自動canonicalを基本とし、理由なく手動固定しません。 - URL検査とSearch Consoleで経過を見る
旧URLが正しく転送されるか、統合先が取得・インデックス可能か、Googleが選ぶcanonical、主要クエリの推移を確認します。
301リダイレクト・canonical・役割分離・削除の使い分け
| 方法 | 向いている状態 | 注意 |
|---|---|---|
| 統合＋301/308 | 2ページの中心検索意図が同じで、1ページへ内容を集約する | 本記事の中心。旧URLを関連する統合先へ直接転送 |
| 役割分離 | 似て見えるが、別の検索意図・別の読者課題として明確に分けられる | タイトル・導入・主要H2・内部リンクまで役割を分ける |
| rel=”canonical” | 同一または非常によく似た内容を、事情により複数URLで維持する | Googleへのシグナルの1つ。独立した2記事の設計問題を隠す用途にしない |
| 404 / 410 | ページが不要で、関連する代替ページもない | 無関係なトップページ等へ一律転送しない |
| noindex | 検索結果へ出さない明確な運用理由がある | 統合の代用品として安易に使わない。リンク・役割を先に整理 |
Google Search Centralは、URL変更時には可能ならサーバー側の恒久リダイレクトを推奨し、複数ページの内容を1ページへ統合した場合は古いURLを新しい統合ページへリダイレクトできると説明しています。また、301などの恒久リダイレクト自体によるPageRankの損失を心配する必要はないとしています。
canonicalだけで記事統合を済ませない
canonicalは「重複・非常に類似したURL群の代表」を伝えるための仕組みです。Google自身が代表URLを選ぶため、指定は絶対命令ではありません。2つの独立記事が同じ検索意図を競っていて、片方を廃止して内容を1本へまとめるなら、本文統合＋恒久リダイレクトの方が目的を明確に伝えやすいケースがあります。
逆に、印刷用URL、パラメータ違い、商品バリエーションなど、ユーザー向けには複数URLを維持する必要があり、内容が同一・非常に類似するケースではcanonicalが適します。記事同士の競合とURL重複を同じ問題として扱わないことが重要です。
統合後に必ず確認する5項目
- 旧URL：1回の恒久リダイレクトで統合先へ到達するか
- 統合先：200 OKで表示され、noindex等が誤って付いていないか
- 内部リンク：重要ページから旧URLへリンクが残っていないか
- canonical：統合先が意図した代表URLとして扱われる状態か
- Search Console：クリック・表示回数・主要クエリが時間とともにどのURLへ集約されるか
よくある失敗
流入が少ない方を即削除する
流入が少なくても、被リンク・独自情報・特定の重要クエリを持つ場合があります。削除前に「移す価値」を確認します。
統合元の記事を丸ごと末尾へ貼る
重複した説明を残すと、1ページになっても読者の理解は改善しません。検索意図を基準に1本の構成へ再編集します。
旧URLをトップページへ転送する
内容に対応する統合先があるなら、そこへ直接転送します。Googleは無関係な多数の旧URLを1つの無関係なページへ転送することを避けるよう案内しています。
リダイレクト後も内部リンクを放置する
内部リンクは統合先へ直接張り替えます。リダイレクトは移行の仕組みであり、古い内部構造を永久に放置する理由にはなりません。
リダイレクトをすぐ外す
GoogleはURL移行時のリダイレクトを可能な限り長く、一般に少なくとも1年維持することを勧めています。ユーザーが旧URLをブックマークしている可能性もあるため、運用上はさらに長く残す判断もあります。
既存記事とつなぐと「探索→分類→実測→判定→統合」まで進む
| 段階 | 記事 | 役割 |
|---|---|---|
| 1. 疑問を増やす | 1つのキーワードから知識を広げる方法 | 問いを増やす |
| 2. 候補を増やす | ChatGPTで関連キーワードを広げる方法 | 関連語・質問候補を生成 |
| 3. 公開前に分類 | ChatGPTでキーワードクラスタリングする方法 | 検索意図でまとめる・分ける |
| 4. 公開後に分類 | Search ConsoleクエリをChatGPTで分類する方法 | 実測クエリから役割を見直す |
| 5. 重複を判定 | Search Consoleでカニバリを確認する方法 | 同じクエリの複数URLを診断 |
| 6. 統合する | 本記事 | 残すURLを選び、内容とシグナルを集約 |
さらに考えてみる：統合で守るのは「記事」ではなく「問いへの答え」
記事統合では「Aを勝たせるかBを勝たせるか」と考えがちです。しかし本当に残したいのは、URLそのものではなく、検索者の問いに対する最もよい答えと、そこへ積み上がった信頼の経路です。
この視点に立つと、古い記事のURLを残しながら本文は大きく作り替えることも、新しい記事のURLへ旧記事の価値を移すことも、同じ目的のための選択肢になります。「どちらの記事が好きか」ではなく、「統合後にどのURLが代表として最も説明しやすいか」で判断できます。
次に生まれる疑問
- 記事を統合したあと、Search Consoleで効果をどう比較すればいい？
- 表示回数はあるのにCTRが低いクエリは、タイトルと本文のどこから直す？
- 内部リンクのアンカーテキストで代表ページを明確にするには？
- 301リダイレクト後に「Googleが選択した正規URL」が想定と違うときはどうする？
- 古い記事を残す・統合する・削除する判断をサイト全体で定期運用するには？
まとめ
カニバリした記事の統合先は、現在順位だけで決めません。まず統合後の検索意図を固定し、検索実績、外部リンク、内部リンク、URLの継続性、独自情報と更新性、読者・事業上の役割を比較します。
残すURLを決めたら、統合元の有用情報を再編集して統合先へ移し、旧URLから関連する統合先へ恒久リダイレクトします。その後、内部リンク、canonical、サイトマップ、URL検査、Search Consoleの推移まで確認して、初めて「1ページへ集約した」状態になります。
- 統合先URLは現在順位だけで決めず、検索意図との一致、既存評価、外部・内部リンク、URL継続価値、独自情報、更新しやすさを比較して決めます。
- 残さないURLの有用情報を統合先へ再構成し、恒久リダイレクトと内部リンク更新まで行います。
次に進むなら｜関連する後続記事
この記事の内容を次の工程へ進めるときは、次の記事がつながります。
- Search Consoleで記事統合後のSEO効果を測る方法｜前後比較で見る4指標 — 今の記事で整理した内容を、次の判断・分析・実装へ進めるときに確認します。
参考資料
- Google Search Central：URL変更を伴うサイト移転
恒久リダイレクト、リダイレクトチェーン回避、統合ページへの転送、内部リンク更新、移行後の監視、リダイレクト維持期間の確認に参照しました。 - Google Search Central：URLの正規化とは
canonicalが重複・非常に類似したURL群の代表URLを選ぶ仕組みであること、正規URL選択に複数のシグナルが使われることの確認に参照しました。 - Google Search Console ヘルプ：URL検査ツール
統合後のURL状態、Googleが選択した正規URL、クロール・インデックス状態を確認する実務手順の参考にしました。 - 知るを遊ぶ：Search Consoleでキーワードカニバリを確認する方法
本記事の前工程である「複数URLの発見とカニバリ判定」を分離し、同じ説明を重複させないために参照しました。
