この記事の結論
カニバリの解消で僕が選んだのは、重なった記事を301で統合先へまとめる方法でした。2026年10月16日、Claude Codeの点検で出た4組を統合し、このメディアの3組では内部リンク24か所を張り替えています。
目次9項目
【無料・メールだけ】Claude Code 2daysセミナー（第二の脳構築講座）の次回開催の案内を受け取る →
カニバリの解消で僕がとった方法は、同じ問いに答えている記事を1本に寄せ、古いURLを301で統合先へ転送することでした。canonicalやnoindexという道もありますが、古い記事を読者に見せ続ける理由がなかったので、転送とリンクの張り替えで終わらせています。
2026年10月16日、僕の会社では重なった記事4組を301で統合しました。候補を出したのは、前日にClaude Codeで回した記事の点検です。このメディアの3組では、節の移植と本文のリンク24か所の張り替えも同じ日に済ませました。
AIの点検で重なりをどう見つけたか、統合しないと決めた組、301の書き方とリンクの張り替えの手順を、記録の順に書きます。「記事が食い合っている気がするけれど、どれを消せばいいの？」と迷っている方は、最初の章から読んでください。
カニバリの解消で301の統合を選んだ理由：canonical・noindexとの違い
カニバリの解消には、301で1本にまとめる、canonicalで正規のURLを示す、noindexで片方を外す、の3つの道があります。僕の会社では、古い記事をもう読ませる必要がなかったので301を選びました。
ここでいうカニバリとは、同じサイトの複数の記事が、同じ検索の問いに答えてしまっている状態です。どちらを検索結果に出すかをGoogleが決めかね、評価やリンクも2本に分かれます。
Googleの公式文書では、恒久的なリダイレクトは、転送先を正規のURLにする強いシグナルとされています。canonicalのlink要素も強いシグナルで、サイトマップに載せるのは弱いシグナルとされています。
一方でnoindexは、同じサイトの中で正規のURLを選ぶ目的には勧められていません。ページが検索から完全に外れるためで、Googleは代わりにcanonicalを案内しています。
3つの方法の比べ方
何を残して何を外すかで、使う方法が決まります。公式文書の扱いと、僕の会社での使い分けを並べます。
| 方法 | 古い記事は読める？ | Googleの扱い（公式文書） | 僕の会社での使いどころ |
|---|---|---|---|
| 301で統合 | 読めない（転送される） | 転送先を正規にする強いシグナル | 中身を統合先へ移せる重なり（4組） |
| canonical | 読める | 強いシグナル | 両方を残す理由があるとき（今回は使わず） |
| noindex | 読めるが検索に出ない | 正規のURLを選ぶ目的には非推奨 | 重なりの解消には使わなかった |
僕なら、まず「統合元の記事を、読者に見せ続ける理由があるか」を聞きます。理由がなければ301、あればcanonicalです。
Claude Codeのエージェントで64本を点検し、統合の候補を出した
統合の候補は、2026年10月15日にClaude Codeで回した記事の点検から出ました。記事の品質を見る担当のエージェントが、このメディアの64本すべてを、残す・改稿・統合・noindexなどに分けています。
この点検は、7つの観点を並列で調べ、全部のレポートを別のエージェントが反証する形でした。合わせて14のエージェントが動き、記事の品質を見る担当は18時40分から19時10分に書き上げています。
判定は「残す43・改稿16・統合3」
64本の判定は、残す43本、改稿16本、301での統合3本、noindex 1本、公開しない下書き1本でした。もう一つのメディアの14本からも、統合が1本出ています。
統合の4組のうち、この記事で例に出すのはAIツールの記事どうしの2組です。残りの2組は、ほかの分野の記事と、もう一つのメディアの記事でした。
重なりは、見出しの対応で示されていた
点検のレポートは、重なりを「どの見出しとどの見出しが同じことを言っているか」で示していました。Claude Codeの入門の組では、次のような対応です。
- 第二の脳のガイド記事の「導入5ステップ」「毎日の運用」が、使い方の記事の「最初の1週間」「1週間のあと」と重なる
- 業務効率化の事例の記事の7事例が、できることの記事の部門別の実例と重なる
数字も添えられていました。第二の脳のガイド記事は12,087字・被リンク18、事例の記事は9,198字・被リンク8です。事例の記事は、8月の公開から更新が止まっていました。
実測していないことも、レポートに書いてあった
レポートの末尾には、確かめていないことの一覧がありました。検索上位10件に同じURLが並ぶかは実測しておらず、重なりの判定は本文の重なりと、Search Consoleの検索語の重なりから出したとあります。
統合しても順位がどうなるかは保証できない、とも書かれていました。統合の根拠は、順位の予測ではなく、点検が示した本文と検索語の重なりです。
統合しないと決めた組もある：役割を分けてリンクでつなぐ
点検は、重なりを見つけた組を全部統合しろとは言っていませんでした。統合は301・内部リンク・サイトマップが一度に動くので、残す組は役割を分けてリンクでつなぐ扱いにしています。
たとえばClaude Codeのプラグインの2本は、同じ導入の記録を扱っていました。それでも「何ができるか」と「反映されないときの直し方」で役割が違うので、冒頭で役割を書き分け、相互にリンクする判定です。
プラグインの2本には、11月になってもどちらかが検索に登録されないままなら統合する、という見直しの条件も付いています。ブラウザまわりの4本は、一部が重なる程度だったので、相互リンクだけで残しました。
AIエージェントの2本は、11月30日まで統合しない
AIエージェントの作り方の記事と、総合ガイドの記事の組も、統合の候補に挙がっていました。こちらは11月2日の判断で、11月30日までは統合せず、それぞれに一次情報を足すことにしています。
統合は転送・リンク・サイトマップが一度に動くので、急がなくてよい組は判断の日を先に決めました。Googleも、恒久的なリダイレクトは元に戻さないと確信できるときだけ使うよう書いています。
2026年10月16日、4組を301で統合した手順
統合は、10月16日の昼に僕が承認し、同じ日に本番へ反映しました。昼に承認待ちの件を推奨どおり進めてよいと返し、もう一つのメディアの1組は12時22分に反映しています。
このメディアの3組は、19時45分から20時8分までに、移植・張り替え・転送・会社サイトの差し替えが終わっています。
手順は、次の6つです。Claude Codeが作業し、最後に別のエージェントが独立に検品して、合格を確かめました。
- 統合元の事実を、統合先の記事へ節として移す
- 統合元を指していた本文のリンクを、統合先へ張り替える（このメディアの3組で24か所）
- 301を書いた.htaccessを、メディアごとに新しく置く
- 統合元の原稿は下書きとして残し、再び公開されないようにする
- 統合元のURLを、サイトマップと検索エンジンへの通知で外す
- 会社サイトのメディア紹介の区画も、統合先の記事に差し替える
統合先は凍結中だったので、節を足すだけにした
統合先の2本は、タイトルの改善を試している途中で、タイトル・説明文・冒頭の段落を変えない期間でした。そこで、統合元の中身は節として足すだけにしています。
使い方の記事には、第二の脳の5ステップと毎日の型を、育て方の章の中の1節として移しました。できることの記事には、事例の比較表を「何がどれだけ変わったか」の章へ移しています。
どちらの節の末尾にも、旧記事の公開日と、10月16日にこの記事へまとめ直した旨を1行入れました。読者が旧記事のURLから転送されてきても、経緯が分かるようにするためです。
移した先はClaude Codeの使い方の第二の脳の節と、Claude Codeでできることの比較表です。
リンク24か所は、対応表から機械で張り替えた
張り替えは、手で1本ずつ直す形にしませんでした。旧記事と統合先の組を1つの対応表に書き、記事を組み立てる処理がその表を読んで、本文のリンクを統合先へ書き換えます。
同じ表を、公開前の機械チェックも読みます。旧記事のURLがサイトマップから消えても、表にある統合元なら意図した除外として止めずに通す作りです。
.htaccessの転送は表とは別のファイルなので、表と同じ日に同じ中身へそろえる決まりにしました。表に組を足すときは、.htaccessにも同じ行を足します。
301で転送されるなら、リンクは古いままでもよいように見えます。ただGoogleは、サイト内のリンクは正規のURLへ張るよう書いているので、転送と張り替えを同じ日にそろえました。
統合元の原稿は消さずに、下書きに戻した
統合元の原稿は削除せず、公開しない下書きの名前に変えて残しました。組み立ての処理は、対応表にある旧記事が公開側に戻ってくると止まります。
統合元のHTMLも、本番のサーバーには残してあります。転送を外せば元のページがそのまま出るので、判断を戻したくなったときの逃げ道になります。
.htaccessはmod_aliasのRedirect 301だけにした
301は、統合した記事のフォルダに置く.htaccessに、ApacheのRedirectの行だけで書きました。僕の会社では、RewriteEngineを使わないことを決めています。
理由は、サイトのいちばん上の.htaccessに、すでにHTTPSとwwwをそろえる書き換えと、特定のファイルを拒否する設定があるからです。そこに手を入れず、記事のフォルダの中だけで転送を完結させました。
書いた形を、URLを一般化して並べます。1行に1組で、旧記事のパスと統合先の完全なURLを書きます。
# 統合元 → 統合先（1行に1組）
Redirect 301 /column/旧記事A.html https://example.com/column/新記事A.html
Redirect 301 /column/旧記事B.html https://example.com/column/新記事B.html外すときは、このファイルを本番から消すだけで済みます。いちばん上の.htaccessに混ぜなかったので、戻すときにほかの設定を触らずに済みます。
Redirectで気をつける3つの仕様
Apacheの公式文書には、Redirectを統合に使う前に知っておきたい仕様がいくつかあります。僕がとくに大事だと考えたのは、次の3つです。
- 状態を書かないと302になる：Redirectは、状態を省くと一時的な302で返します。統合では301かpermanentを必ず書く
- 前方一致で効く：書いたパスで始まるURLはすべて転送され、残りのパスは転送先の後ろに付く。フォルダごと転送したいとき以外は、ファイル名まで書く
- .htaccessで使うにはFileInfoの許可が要る：許されていないサーバーでは効かないので、置いた後に転送されるかを確かめる
1番は、Googleの扱いにも直結します。公式文書では、302などの一時的な転送は、転送先を正規にするシグナルになりません。統合のつもりで302を出すと、Googleが転送先を正規に選ぶ根拠が1つ減ります。
.htaccessの置き場所やパスの書き方でつまずいたときは、.htaccessのBasic認証で500エラーが出たときの直し方も参考になります。
統合のあとに見ていること、分かっていないこと
統合したからといって、順位が上がったとは書けません。僕の会社の記録では、統合先の使い方の記事が狙う「claude code 使い方」は、統合より前の10月9日から表示が0のままでした。
11月2日の判定では、この下がり方は公開直後の一時的な上位表示が終わったのではなく、品質の評価で落とされている、が本線になっています。統合の効果は、ほかの変化と切り分けて確かめていません。
表示の急落の原因をどう切り分けたかは、SEOハネムーンか事故かを切り分けた記録にまとめています。
旧記事の4つのURLは、統合の当日に検索エンジンへの更新の通知も送りました。Search ConsoleのURL検査から読み直しを頼むときの上限の話は、インデックス登録リクエストが上限で止まる時の対処に書いています。
重なりを増やさないための関所
統合よりも効くのは、重なる記事を新しく作らないことだと考えています。僕の会社では、新しい記事を公開する前に、公開済みの全記事との重なりを機械で測っています。
型の言い回しを除いた重なりが12%以上か、同じ文字が120字以上続くか、見出しの半分以上が同じなら、その記事は出しません。同じ社内の出来事を主役にしてよいのも、1記事だけです。
メディアが2つあるので、同じ検索の問いの記事は両方で作らないことも決めています。すでにある側を直し、もう一方からはリンクする決まりです。
Claude Codeに記事の統合を任せるときの注意
AIに任せたのは、点検・移植・張り替え・転送の作業で、統合するかどうかの判断ではありません。統合は301・内部リンク・サイトマップが一度に動くので、僕の会社では人の判断が要るものに分けています。
点検のレポートも、統合の候補は「提案」として出し、承認を待つ扱いでした。承認したのは僕で、その後の作業はClaude Codeが進め、別のエージェントが検品しています。
任せる前に決めておきたい4つ
10月16日の作業から、AIに統合を任せるなら、僕は次の4つを先に決めます。
- 統合するかは人が決める。AIの点検は候補の一覧までにする
- 旧記事と統合先の対応表を1つ作り、リンクの張り替えはその表から機械で行う。.htaccessは同じ日に同じ中身へそろえる
- 統合元の原稿とHTMLは消さずに残し、戻し方を先に書いておく
- 作業した担当とは別のエージェントに、転送・リンク・サイトマップを検品させる
2番は、取りこぼしを防ぐ決まりです。張り替えを表から機械で行えば、24か所のうち1か所だけ古いまま、という見落としを手で探さずに済みます。
まとめ
- カニバリの解消は、古い記事を見せ続ける理由がなければ301で統合、残す理由があればcanonical。noindexは正規のURLを選ぶ目的には使わない
- 僕の会社では2026年10月15日にClaude Codeで64本を点検し、16日に4組を301で統合した。このメディアの3組では本文のリンク24か所を張り替えた
- .htaccessはmod_aliasのRedirect 301だけにした。状態を書かないと302になるので、301は必ず書く
- 統合しない組は役割を分けて相互リンクにし、判断の日を先に決めた
- 僕なら最初に、重なっている記事どうしの見出しを並べて、同じことを言っている見出しの組を数えるところから始めます
よくある質問
カニバリの解消は、301とcanonicalのどちらを使えばいいですか？
古い記事をもう読ませる必要がないなら301です。Googleは恒久的なリダイレクトを、転送先を正規のURLにする強いシグナルとしています。両方の記事を残したいときはcanonicalを使います。僕の会社では、統合元を読者に見せ続ける理由がなかったので301にしました。
重なった記事をnoindexにして片方だけ残すのはだめですか？
同じサイトの中で正規のURLを選ぶ目的なら、Googleはnoindexを勧めていません。ページが検索から完全に外れるためで、代わりにcanonicalを案内しています。僕の会社でも、重なりの解消にはnoindexを使わず、301とリンクの張り替えで済ませました。
301を設定したら、内部リンクはそのままでもいいですか？
転送はされますが、張り替えたほうがよいです。Googleは、サイト内でリンクするときは正規のURLへ張るよう書いています。僕の会社では、301の新設と同じ日に、このメディアの統合3組で統合元を指していた本文のリンク24か所を統合先へ張り替えました。
.htaccessのRedirectで、301と書かないとどうなりますか？
Apacheの公式文書では、Redirectで状態を書かないと302（一時的）になります。一時的な転送は、転送先を正規のURLにするシグナルになりません。統合で使うなら、301かpermanentを必ず書いてください。