記事を統合・削除するときのURL整理：リダイレクトと更新の手順

1. まず記事ごとに「残す・転送する・消す」を決める

Googleのリダイレクトに関するドキュメントでは、リダイレクトの用途として、複数URLの統合、サイトの統合、ユーザー体験を保ったままのページ削除が挙げられています。恒久的な変更だと確信できる場合に恒久リダイレクトを使う、という考え方です。一方、削除したページについては、404と410の説明で、どちらも「内容が存在しない」ものとして同じに扱われ、インデックス済みのURLは索引から外れると説明されています。

この二つを踏まえ、記事ごとの扱いを次の表で決めます（表の運用は編集上の提案です）。

• 内容を別記事に統合した、推奨する扱い：旧URL→統合先へ301、補足：統合先に旧記事の要点が実際に入っていること
• 同じテーマの新版に置き換えた、推奨する扱い：旧URL→新版へ301、補足：日付や前提が変わるなら本文で触れる
• 引き継ぐ先がない／役目を終えた、推奨する扱い：404または410、補足：関連の薄いページへ無理に飛ばさない
• 一時的に非公開にする、推奨する扱い：302など一時的な転送、または公開を維持、補足：恒久の判断が付くまで301にしない

関連の薄い転送先（トップページなど）に一律で飛ばすのが不利になるかどうかは、今回確認した公式ページには書かれていませんでした。ただ、読者にとっては探していた内容が見つからないので、近い記事がなければ404/410にするほうが誠実だと考えます。

2. 作業前：対応表を作る

最初に作るのは、旧URL・新URL・理由を並べた対応表です。GoogleのURL変更を伴うサイト移転のガイドも、旧URLから新URLへの対応づけを作り、サイトマップ、サーバーログ、アクセス解析から重要なURLを拾うよう勧めています。同ガイドはサイト移転向けですが、記事単位の統合にも同じ発想が使えます。

対応表の雛形

下は説明用の例です。実在のサイトや数値ではありません。

• 1、旧URL：/blog/tips-a/、新URL：/blog/guide-main/、処理：301、理由：内容が重複、本文の引き継ぎ：手順3を統合先の第2章へ、作業日：記入、確認日：記入、備考：内部リンク5件を修正
• 2、旧URL：/blog/tips-b/、新URL：/blog/guide-main/、処理：301、理由：旧版の更新、本文の引き継ぎ：全体を統合、作業日：記入、確認日：記入、備考：
• 3、旧URL：/blog/old-campaign/、新URL：なし、処理：410、理由：期間限定で終了、本文の引き継ぎ：引き継ぎなし、作業日：記入、確認日：記入、備考：外部からの被リンクを確認

列は最低限「旧URL」「新URL」「処理」「理由」があれば運用できます。「本文の引き継ぎ」を入れておくと、転送先に旧記事の内容が残っているかを後で見直せます。

作業前の確認項目

• 旧URLのリストは、サイトマップ、アクセス解析、検索パフォーマンスの上位URLなど複数の情報源から集めたか
• 統合先の記事に、旧記事で読者が探していた答えが入っているか
• 統合先のURLは最終形か（後でまた変えると転送が連鎖する）
• 統合先自体が200で表示され、noindexになっていないか
• 旧URLに外部サイトや社内資料からのリンクがないか

3. 実施：転送を設定し、サイト内の参照を直す

設定方法はGoogleの資料で、サーバー側のリダイレクトが最も確実で、メタリフレッシュは次善、JavaScriptによる転送は最後の手段とされています。恒久を示すのは301/308と、待ち時間0秒のメタリフレッシュです。可能ならサーバー側の301/308を選びます。

作業の順番は次の通りです。

1. 統合先の記事を先に更新して公開する（旧記事の要点を移す）
2. 対応表の「処理」列に従い、転送または404/410を設定する
3. 記事内、ナビゲーション、関連記事、カテゴリ一覧の内部リンクを新URLへ直す。転送に頼らず直接リンクにするためです
4. サイトマップから旧URLを外し、新URLを載せる
5. 統合先の canonical が自分自身のURLになっているか確認する

転送先がさらに転送される連鎖は避けます。サイト移転のガイドでは、連鎖は5ホップを超えないこと、できれば3未満が目安とされています。過去に何度もURLを変えた記事は、旧々URLを最終URLへ直接向け直します。

4. 作業後：公開直後と数週間後に確認する

公開直後

• 旧URLを実際に開き、新URLに移動するか確認する（ブラウザの表示だけでなく、ステータスが301/308か確認する）
• 削除したURLが404/410を返し、200でエラー文だけを表示していないか確認する。200のままエラー風の内容を出すと、Search Consoleで「ソフト404」として扱われる可能性があります
• 新URLが200で表示されるか、転送の連鎖がないか確認する
• サイトマップの内容が新URLに更新されているか確認する

数週間後

Googleは中規模サイトで新URLの反映に数週間以上かかることがあるとしています。すぐに結果が出なくても慌てず、Search Consoleで旧URLと新URLのインデックス状況を見ます。

転送を残す期間について、サイト移転のガイドは「可能な限り、一般に少なくとも1年」としています。記事単位の統合でも、まず1年を最短の目安にし、旧URLへのリンクや流入が残っているなら、その後も維持を検討するのが無理のない運用です。

5. AIに任せる範囲と、人が確認する範囲

AIに向くのは、URL一覧と記事タイトルから統合候補を整理し、対応表の下書きを作る作業です。次のような依頼文が使えます。入力には、アクセスログや個人情報を含むデータを貼らず、URLとタイトル、公開日だけにしてください。

次のブログ記事一覧から、統合・削除の候補を整理してください。
目的：旧URLの読者と検索流入を途切れさせないこと。
出力：Markdownの表（旧URL／新URL／処理（301・404・410・保留）／理由／本文で引き継ぐ要点）。
ルール：
- 内容が重なる記事は、最も網羅的な1本を統合先にする
- 引き継ぐ先が見つからない記事は、無理に転送せず「404または410」とし、理由を書く
- 判断に自信がない行は「保留」とし、何を確認すべきか書く
記事一覧：
（URL｜タイトル｜公開日 を1行ずつ）

人が決めるのは次の点です。

• 統合先の本文が、旧記事の検索意図を実際に満たしているか
• 「保留」の行の最終判断
• 設定後に旧URLのステータスを実際に開いて確かめること

AIの表はあくまで下書きです。URLの綴り間違いや、存在しない統合先が混ざることがあるため、設定前に全行を見直してください。

6. 記録を残して次の更新に備える

対応表は、作業が終わったら捨てずに保管します。数か月後に「なぜこのURLは410なのか」「どの記事に統合したのか」を追えるようになり、転送の連鎖やリンク切れの調査にも使えます。転送を外す時期を決めたときは、「処理」列に終了予定日を足しておくと管理しやすくなります。

なお、本文の表と確認項目は公式資料の内容を踏まえた編集上の運用案で、実際のサイトで動作検証したものではありません。サーバー設定やCMSの仕様は環境ごとに異なるため、必ずテスト用URLなどで一度試してから本番に反映してください。