301リダイレクトとは？設定の基本とサイト移行・リニューアル時の注意点

URL変更を伴うサイト移行では、旧URLを新URLへ転送する設定だけでは十分ではありません。ページごとに「恒久的に移すのか」「一時的に切り替えるのか」「維持・廃止するのか」を判断しなければ、利用者が意図しないページへ到達したり、重要な導線を失ったりするおそれがあります。

この記事では、301リダイレクトの基本から、301・302・廃止の選び方、URL対応表の作り方、実装依頼とHTTP検収、公開後の確認までを解説します。旧URLごとの移行方針を決め、実装担当へ依頼・検収できる状態を目指しましょう。

301リダイレクトは設定だけで完結しません。URLごとの方針決定、対応表による管理、HTTP応答の確認、公開後の監視を一連の工程として進めます。

01Section301リダイレクトとは：恒久的なURL移転を伝えるHTTP応答

301リダイレクトとは、あるURLのコンテンツが別のURLへ恒久的に移ったことを、ブラウザや検索エンジンへ伝えるHTTP応答です。HTTPステータスコードは、URLへアクセスした際にサーバーが返す処理結果の番号であり、301は「Moved Permanently」を意味します。

リダイレクトでは、転送先を示すLocationヘッダーも確認します。たとえば旧URLが301を返していても、Locationに意図しないURLが指定されていれば、正しい移行とはいえません。301、Location、404、410のHTTP上の意味は、RFC 9110: HTTP Semantics（IETF）で定義されています。

301を検討しやすいURL変更

戻す予定がなく、新URLを今後の正式な到達先にする場合、301を検討します。代表的には次のようなケースです。

• ドメイン変更に伴い、各ページのURLが恒久的に変わる
• HTTPからHTTPSへ恒久的に移行する
• サイトリニューアルやCMS移行でURLパスが変わる
• wwwの有無や末尾スラッシュの表記を統一する
• 内容・利用目的が近いページへ恒久的に統合する

Googleは、URL変更を伴うサイト移転では、対応する新URLへサーバー側リダイレクトを設定し、確認する手順を案内しています。詳しくはURL の変更を伴うサイト移転を確認してください。

ただし、301はすべてのURL変更に機械的に適用するものではありません。一時的な切替、移転先が未確定のページ、代替先のない廃止ページは、別の方針を検討する必要があります。

02Section301と302、維持・廃止をどう選ぶか

転送方法はURLごとに判断します。戻す予定の有無と、利用者にとって関連する移転先があるかを基準に、301・302・維持・廃止方針を選びます。

元のURLへ戻す予定と、利用者にとって関連する移転先があるかを起点に、実際の移転内容に合わせてURLごとの処理方針を決めます。

301は恒久移転、302は一時的な移転を表します。リダイレクトと Google 検索では、恒久的リダイレクトを転送先のURLを正規URLとして扱うためのシグナルとして説明しています。一方、一時的なリダイレクトは、恒久的な移転を示すものではありません。

URL単位で処理方針を決めるフロー

1. 1旧URLを今後も同じURLで公開するかを確認します。継続公開するなら維持し、不要な転送は追加しません。
2. 2公開しない場合は、利用者にとって同等または近い内容・目的の新ページがあるかを確認します。
3. 3移転先があり、恒久的な変更なら301、一時的な切替なら302などを検討します。複数の旧ページを1ページへ統合する場合も、統合先との関連性を確認します。
4. 4移転先がない場合、一時的な非公開か、恒久的な廃止かを確認します。一時的なら復帰条件を残し、恒久廃止なら404または410を含む応答方針を決めます。

代替先のない廃止URLを、無関係なページやトップページへ一律に301転送することは避けましょう。利用者が求めた情報にたどり着けず、検索エンジンにも適切な移転として解釈されにくくなるためです。404と410のどちらを使うかは、削除の確実性、利用者への案内、運用上の制約を踏まえ、URL対応表に判断理由を残します。

03Sectionサイト移行・リニューアルの301設計はURL対応表から始める

URL対応表は転送先の一覧ではなく、判断理由、テスト結果、修正状況を一元管理し、実装と検収の認識をそろえる台帳です。

サイト移行で重要なのは、ルールを一括設定する前に、旧URLごとの行き先を決めることです。URL対応表は、実装指示書であると同時に、テスト結果、検収、公開後の修正状況を管理する台帳になります。

旧URLの候補は、XMLサイトマップ、CMSのページ一覧、アクセス解析、Search Console、サーバーログなどから収集します。加えて、広告、メール、営業資料、外部リンクで使われているURLも確認対象に含めると、公開後の導線切れを見つけやすくなります。

URL対応表に残す主要項目

すべての情報を別々の表で管理すると、実装時や検収時に対応関係を追いにくくなります。最低限、次の項目を1つのURL対応表で管理します。

ページ固有の判断と共通正規化ルールを分ける

「この旧URLはどの新URLへ移すか」はページ固有の判断であり、URL対応表で管理します。一方、HTTP/HTTPS、wwwの有無、末尾スラッシュといったサイト全体に共通する条件は、共通正規化ルールとして別管理する方が適しています。

両方を分ける理由は、共通ルールの変更とページ固有の例外を混同しないためです。たとえばHTTPS統一のルールを変えた場合、影響する重要URLをまとめて再テストできます。個別のページ統合や廃止は、対応表だけを確認すれば判断経緯を追えます。

URL対応表、責任分界、検収条件は、サイトのデザインやコンテンツを確定する前から整理しておくと、公開直前の判断漏れを減らせます。リニューアル全体の進行は、Webサイトリニューアルの進め方も参考にしながら、移行要件と合わせて整理してください。

04Section301を実装するまでの共通工程と依頼内容

301の設定場所は、Webサーバー、CMS、CDN、アプリケーションなど、サイト構成によって異なります。特定の仕組みを先に選ぶより、どの場所が最終的なHTTP応答を制御するか、誰が変更できるか、問題時に誰が切り戻すかを先に確定することが重要です。

Googleのサイト移転ガイドでも、移転前の準備、リダイレクトのテスト、移転後の確認が案内されています。実装と確認は次の順序で進めます。

実装担当へ依頼する際は、「301を設定してほしい」とだけ伝えるのでは不十分です。URLごとの期待値と、検証結果の提出形式まで含めて依頼します。

工数や期間は、URL数だけでは決まりません。URL変更率、実装箇所の数、既存台帳の有無、手動・自動テストの範囲、クエリパラメータ、多言語URLの有無などで変わります。見積もりでは、棚卸し、URL別判断、ルール策定、実装、テスト、本番反映、公開後の是正を作業単位として分けて確認すると、前提の抜け漏れを抑えられます。

05Section設定後の確認方法：HTTPテスト記録で検収する

検収では最終ページの表示だけでなく、旧URLの初回応答、Location、最終URLの応答を分けて記録し、対応表と照合します。

HTTPレスポンスとは、URLへアクセスした際にサーバーから返る応答全体です。検収では、ブラウザで新ページが表示されるかだけでなく、旧URLが何を返し、どのURLへ転送し、最終的にどの状態で到達したかを確認します。

初回応答と最終応答を分けて確認する

確認の要点は、最初の応答と、リダイレクト後に到達した最終応答を分けることです。curlを使える場合は、次のように確認できます。コマンド実行は必須ではなく、実装担当から同等のテスト記録を受け取る方法でもかまいません。

# 最初の応答のステータスとLocationを確認する
curl -I https://example.com/old-page/

# リダイレクトを追い、最終応答まで確認する
curl -I -L https://example.com/old-page/

curl -Iでは、旧URLが最初に返したステータスとLocationを確認します。curl -I -Lではリダイレクト経路を追えるため、最初の301と最後の200などを分けて記録できます。HTTP/...の応答が想定より多ければチェーン、同じURLへの遷移が繰り返されるならループが疑われます。

テスト記録には、少なくとも「旧URL、期待ステータス、実測ステータス、実測Location、最終URL、最終ステータス、確認日、確認者、合否、修正状況」を含めます。URL数や認証の有無によって全件手動テストが難しい場合は、全件・自動テスト・重要URLの手動確認をどのように組み合わせるか、公開前に合意しておきます。

検収での合格・修正対象

恒久移転対象なのに301以外が返る、Locationが不一致、最終URLが4xx・5xx、ループがある、移転先に意図しないnoindexがある場合は、原則として修正対象です。不要なチェーンも、旧URLから最終URLへ直接到達できるよう改善を検討します。

06Section301は検索・利用者への影響をどう抑えるか

2026年3月時点で、Googleは301などの恒久的リダイレクトを、転送先を正規URLとして扱うための重要なシグナルとして説明しています。URL変更を伴う移転での具体的な注意点は、リダイレクトと Google 検索およびURL の変更を伴うサイト移転で確認できます。リダイレクトが検索評価に関わるのは、検索エンジンがクロール・インデックス・評価という流れでページを扱っているためです。この前提となる仕組みはSEO対策とは何かで整理しています。

移転後の確認は、リダイレクトだけで終えず、新URLが検索・利用者の双方にとって利用可能な状態かを分けて確認します。

内部リンクも新URLへ更新し、旧URLへの依存を減らします。ドメインまたはサブドメインの変更を伴う場合は、Search Consoleのアドレス変更ツールを使えるか、移転範囲、所有権、プロパティの要件をアドレス変更ツールで確認してください。HTTPからHTTPSへの移行や同一サイト内のパス変更では、同ツールを使わず、リダイレクトと移転後の確認を行う案内です。

07Section公開後の監視と不具合の優先順位

公開後は、すべての不具合を同じ優先度で扱うのではなく、事業影響が大きいURLから確認します。主要CTA・フォームの停止、リダイレクトループ、重要URLの最終5xxは緊急度が高い問題です。検索流入、被リンク、広告、メール、営業資料、主要なコンバージョン導線に使われるURLも、公開直後の重点確認対象にします。

異常を見つけたら、次の順に切り分けます。まず旧URLのステータスとLocationを対応表と照合し、次に最終URLのステータスと表示を確認します。その後、チェーン・ループ、canonical・noindex・robots.txt、内部リンク・サイトマップ、CTA・フォーム・計測、Search Consoleや検索流入の順に確認すると、リダイレクトの問題と周辺設定・計測の問題を分けやすくなります。

監視期間、確認頻度、404・5xxや流入変動の調査開始条件は、サイト規模や通常時の変動により異なります。公開前に、担当者、確認期限、修正窓口、監視を終える条件を決めておきましょう。

サイト移行時のリダイレクト設計や検索影響を相談したい場合

URL対応表の作成、移行方針の判断、公開後の検索影響の確認まで、自社で対応する範囲と外部へ依頼する範囲を整理し、必要な支援先を比較できます。

SEO対策3980社掲載

SEO対策の相談先を探す