301リダイレクトとは、URLを恒久的に別のURLへ移したことを、ブラウザと検索エンジンに伝える転送設定です。
ドメイン変更、SSL化、URL整理、ページ統合の場面では、301リダイレクトを正しく設定できるかどうかで、ユーザーの導線と検索評価の引き継ぎやすさが大きく変わります。逆に、設定漏れや転送先の選び方を誤ると、404の増加、評価の分散、リダイレクトチェーンの発生につながります。
この記事では、301リダイレクトの基本、302との違い、具体的な設定例、確認方法、やってはいけない運用までを整理します。301リダイレクトを安全に実装したい方は、ここからはじめていきましょう。
この記事でわかること
301リダイレクトの意味と、まず押さえるべき役割
301リダイレクトの役割は、「古いURLはもう使わず、新しいURLを正規の行き先として扱ってほしい」と伝えることです。単なる転送ではなく、URL移行の意思表示として機能します。
たとえば、会社名変更でドメインが変わった場合、旧URLにアクセスしたユーザーを新ドメインへ送るだけでは不十分です。検索エンジンにも「今後はこちらを評価対象にしてほしい」と伝える必要があります。そのときに使うのが301です。
Googleは、301や308のような恒久的なリダイレクトを、移転先URLを正規版として扱う強いシグナルとして解釈します。URLを恒久的に変えるなら、サーバー側の301を優先するのが基本です。
(参照:GoogleのリダイレクトとGoogle検索の解説)
301リダイレクトが必要になる代表的な場面
301リダイレクトが必要になるのは、旧URLを今後も見せ続ける理由がなく、新URLへ評価と導線を寄せたい場面です。
- サイトをhttpからhttpsへ切り替え、SSL化後のURLへ統一したい
- 会社名変更やサービス統合でドメインを変更した
- 記事URLや商品URLを整理し、分かりやすいURLへ移した
- 重複ページを統合し、評価を1つのURLに集約したい
- 古いキャンペーンページを後継ページへ引き継ぎたい
ECで「/item?id=123」のような旧URLを「/shoes/running-blue/」へ変えるケースや、地域ごとに似た内容の店舗ページを整理するケースでもよく使われます。実務でよくあるのは、リニューアル時にデザインばかり注目され、URL移行表の作成が後回しになることです。移行後のトラブルは、この一覧不足から起きることが少なくありません。
301を設定しないと何が起きるか
301を入れないままURLを変えると、ユーザーは旧URLで404に当たり、検索エンジンは新旧URLの関係をつかみにくくなります。
その結果、次のような問題が起こりやすくなります。
- お気に入りや外部リンク経由の訪問者が目的ページに到達できない
- 被リンクや内部リンクの評価が新URLにまとまりにくい
- 旧URLが残り続け、新URLとの評価分散が起こる
- 削除済みURLへのアクセスが増え、保守確認の手間が増える
特にBtoBサイトでは、資料ページや導入事例ページのURL変更後に、営業資料や外部メディアからのリンクが旧URLのまま残ることがあります。こうした流入を取りこぼさないためにも、301は移行作業の中心に置くべきです。
301と302の違い
301と302の違いは、移転が恒久的か、一時的かです。戻す予定がないなら301、元のURLへ戻す可能性があるなら302を使います。
検索エンジンの解釈も異なります。301は移転先を正規版として扱う強いシグナル、302は一時的な移動として扱う弱いシグナルです。つまり、URL変更の意図に合わないステータスを返すと、検索結果上の扱いもぶれやすくなります。
| 301と302の違い | |
|---|---|
| 301 | 恒久的な移転。今後は新URLを使う前提で設定する |
| 302 | 一時的な移転。メンテナンス中や一時的な差し替えで使う |
301を使うべきケース
301を使うのは、新URLへ評価も導線も移したいときです。
たとえば以下のようなケースです。
- サイト全体の常時SSL化
- wwwあり・なしの統一
- 旧ドメインから新ドメインへの移転
- 記事統合による旧記事から新記事への集約
- 商品ページのURL変更後、旧URLを使わない運用
302を使うべきケース
302を使うのは、元のURLを将来的に復活させる前提があるときです。
たとえば、システム障害で一時的に案内ページへ送る場合や、短期間のキャンペーンで仮ページへ切り替える場合が該当します。期間限定の在庫切れ対応で別ページへ逃がす場面も、恒久移転でないなら302のほうが意図に合います。
一時対応なのに301を使うと、あとで元URLへ戻したいときに検索エンジン側の認識がずれやすくなります。逆に恒久移転なのに302のまま放置すると、新URLへの切り替えが進みにくくなります。
301リダイレクトを設定する主な理由
301リダイレクトを設定する理由は、ユーザーを迷わせず、URL変更後も評価を分散させないためです。実務では「転送できれば十分」と考えられがちですが、重要なのは転送の質です。
ユーザーを正しいページへ案内できる
最も分かりやすい効果は、旧URLに来た訪問者をそのまま新URLへ届けられることです。
ブックマーク、メール署名、営業資料、外部記事、X(旧Twitter)投稿など、URLは想像以上に長く残ります。公開後に自社側でリンクを直しても、外部に出たURLまではすぐに更新できません。301があれば、そうした古い導線も生かせます。
検索評価を新URLへ集約しやすい
301は、旧URLに向いていたシグナルを新URLへ寄せるための重要な手段です。
被リンク、内部リンク、過去のクロール履歴、正規URLの判断材料など、URLにはさまざまなシグナルが紐づきます。URLだけ変えて何もしないと、それらが分散しやすくなります。301を使うことで、新URLを評価対象として扱ってもらいやすくなります。
当社でもサイト移転やURL整理の改善では、順位変動そのものより先に「どのURLを評価してほしいのかが明確か」を確認します。ここが曖昧だと、コンテンツの良し悪し以前に、検索エンジンへ送るシグナルが散ってしまうためです。
重複URLの整理に役立つ
301は、同じ内容に近いURLが複数ある状態を整理する手段としても有効です。
たとえば次のような重複は珍しくありません。
- https://example.com と https://www.example.com
- /index.html あり・なし
- 旧カテゴリURLと新カテゴリURLが共存している
- 色違いだけで本文がほぼ同じ商品ページ
- 地域名だけ差し替えた紹介ページ
ただし、重複整理の手段は常に301とは限りません。ユーザーにとって別ページとして残す意味があるならcanonicalのほうが適切なこともあります。削除・統合してよいか、別URLとして残すべきかを先に判断することが大切です。
⇒canonicalの詳細は、canonical(カノニカル)とは?URLの正規化でSEO対策を進めようで詳しく解説しています。
301リダイレクトの設定方法
301リダイレクトは、できる限りサーバー側で設定するのが基本です。2026年時点でも、この原則は変わっていません。
CMSやサーバー環境によって書き方は異なりますが、考え方は共通しています。旧URLへのアクセスに対して、HTTPステータス301と転送先URLを返す、という構造です。
.htaccessで設定する場合の基本
Apache系サーバーでは、.htaccessで301を設定するケースが多くあります。代表的な記述要素は次の3つです。
- RewriteEngine On:書き換え機能を有効化する
- RewriteCond:どの条件で転送するかを指定する
- RewriteRule:どこへ転送するかを指定する
末尾の[R=301,L]は、301で転送し、そのルールで処理を終える指定です。Rだけで数値を書かないと302扱いになることがあるため、恒久移転では301を明示します。
⇒.htaccessの基本を整理したい場合は、.htaccessとは?基本的な役割や正しい記述方法、設置場所、注意点を解説も是非参照ください。
wwwあり・なしを統一する例
wwwありをなしへ寄せるなら、次のような考え方で設定します。
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
逆にwwwなしをありへ統一したいなら、条件と転送先を入れ替えます。大切なのは、サイト全体でどちらを正規URLにするかを先に決めることです。途中で方針が揺れると、内部リンクやcanonicalまで修正が必要になります。
httpからhttpsへ切り替える例
SSL化では、httpアクセスをhttpsへまとめます。
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
この設定自体はシンプルですが、実務では混在コンテンツやcanonical未更新のほうが問題になりやすいです。転送だけ成功しても、画像・CSS・JSの参照先がhttpのままだと表示や計測に不具合が出ることがあります。
⇒SSL化の詳細は、SSL化(HTTPS)のSEO対策における効果で詳しく解説しています。
ページ単位・ディレクトリ単位で移す例
記事統合やカテゴリ整理では、ページ単位またはディレクトリ単位で設定します。
Redirect 301 /old-page.html https://example.com/new-page.html
RedirectMatch 301 ^/old-category/(.*)$ https://example.com/new-category/$1
ページ単位は細かく制御しやすく、ディレクトリ単位は大量URLの移行に向いています。どちらを選ぶかは、旧URLと新URLの対応関係が規則的かどうかで決めると整理しやすいです。
ドメイン変更時の考え方
ドメイン変更では、トップページだけでなく、できる限り各ページを対応する新URLへ1対1で移すことが重要です。
旧ドメインの全ページを一律で新トップへ送る運用は、ユーザー体験も検索評価の引き継ぎも弱くなりやすいです。たとえば旧ブログ記事に来た人が新トップへ飛ばされると、目的ページに着けません。検索エンジンから見ても、対応関係が粗い移転になります。
サイト移転では、URLマッピング表を先に作り、旧URL・新URL・ステータス・担当者・確認結果まで一覧化しておくと事故を減らせます。規模が大きいほど、この準備が実装そのものより重要です。
WordPressで設定する方法
WordPressでは、プラグインで301リダイレクトを管理する方法もあります。代表例としてはRedirectionがよく使われます。


管理画面で旧URLと新URLを登録できるため、少数ページの移転には便利です。ただし、プラグイン任せにしすぎると、テーマ変更や他プラグインとの競合で意図しない挙動になることがあります。WordPressサイトで順位が伸びない原因として、本文より前に設定競合が見つかることは珍しくありません。大量移行やドメイン移転では、サーバー側設定のほうが安定しやすいです。
⇒WordPressでのSEO全体像を知りたい方は、WordPressでできるSEO対策11選!初心者でもできる方法をわかりやすく解説もあわせてご覧ください。
Googleが推奨する方法と、代替手段の考え方
301リダイレクトは、サーバー側の恒久的リダイレクトを優先するのが基本です。JavaScriptやmeta refreshは、サーバー側で実装できない場合の代替と考えるのが安全です。
Googleは複数のリダイレクト方式を認識できますが、可能なら301や308のようなサーバー側の恒久的HTTPリダイレクトを使うことを勧めています。
(参照:Googleのサイト移転ガイド)
JavaScriptリダイレクトは最終手段
JavaScriptで転送する方法はありますが、URL移行の主手段としては優先度が下がります。
理由は、HTTPレスポンスの段階で移転を伝えられないこと、実装や読み込み条件の影響を受けやすいこと、検証時に挙動が分かりにくいことです。特に移転規模が大きいと、JavaScriptベースの転送は保守しづらくなります。
- サーバー応答の時点で301を返せない
- 旧ページのHTMLやスクリプトが残る前提になる
- 実装漏れがあるとページごとに挙動がばらつく
meta refreshは使えても、第一候補ではない
meta refreshも代替策にはなりますが、恒久移転ならサーバー側301のほうが明快です。
即時のmeta refreshは恒久的な転送として解釈されることがありますが、HTMLの<head>内実装が前提で、サーバー側リダイレクトより設計が複雑になりやすいです。移転ルールを長期運用するなら、HTTPレベルで管理したほうが見通しがよくなります。
⇒meta refreshについては、meta refreshとは?リダイレクトの設定方法と設置の際の注意点も参考にしてみてください。
301リダイレクトが正しく動いているか確認する方法
301リダイレクトは、設定しただけで終わらせず、必ずHTTPステータスと最終到達URLを確認することが重要です。見た目でページが開いても、302になっていたり、途中でチェーンが発生していたりすることがあります。
ブラウザの開発者ツールで確認する
最も手軽なのは、Chromeなどの開発者ツールでNetworkを確認する方法です。
旧URLを開く前に開発者ツールを起動し、Networkタブでログ保持を有効にしてからアクセスします。最初のリクエストが301になっているか、その後にどのURLへ移動したかを見ます。HeadersでLocationヘッダーを確認すれば、転送先も把握できます。
見た目だけで確認すると、JavaScript転送とHTTP 301を混同しやすいです。HTTPレスポンスで301が返っているかまで見るのが実務では分かりやすいです。
コマンドで確認する
サーバー移行や大量URLの確認では、コマンドラインのほうが効率的です。
curl -I https://example.com/old-page
これでレスポンスヘッダーを確認できます。301 Moved Permanentlyが返り、Locationに想定の新URLが入っていれば基本は問題ありません。チェーンまで見たい場合は、追跡オプションを使って最終URLまで確認します。
curl -IL https://example.com/old-page
大量URLを扱う場合は、移行表をCSV化してスクリプトで一括チェックすると確認漏れを減らせます。
確認時に見るべきポイント
確認では、単に「飛ぶかどうか」ではなく、次の点まで見てください。
- 最初のレスポンスが301になっているか
- 最終到達URLが想定どおりか
- 302や307が混ざっていないか
- チェーンが長くなっていないか
- PCとスマホで挙動差がないか
当社でも移転確認では、PC表示だけでなくモバイルの実挙動を確認することがあります。特にテンプレート分岐があるサイトでは、スマホだけ別URLや別条件に飛んでしまうことがあるためです。
301リダイレクト設定時の注意点
301リダイレクトで失敗しやすいのは、転送ルールそのものより、周辺設定の更新漏れです。URL移行はリダイレクト単体では完結しません。
内部リンク・canonical・サイトマップを新URLへ更新する
301を入れても、サイト内が旧URLを参照したままだと、無駄な転送が増えます。
- 本文内リンクやナビゲーションのURL
- canonicalタグの参照先
- XMLサイトマップ
- 構造化データ内のURL
- OGPや共有URLの設定
特にcanonicalが旧URLのままだと、せっかく新URLへ寄せたシグナルを自分で曖昧にしてしまいます。移行後はHTMLソースまで含めて確認することがおすすめです。
⇒XMLサイトマップの詳細は、XMLサイトマップ(sitemap.xml)とは?SEO効果や作成、設置方法で詳しく解説しています。
無関係なページへまとめて飛ばさない
301は万能な評価移転装置ではありません。内容が近いページ同士をつなぐことが前提です。
たとえば、終了した採用ページを会社トップへ一律転送したり、古い商品ページを関係の薄いカテゴリトップへまとめたりすると、ユーザー満足度が下がります。検索エンジンにとっても、移転先の妥当性が弱くなります。
筆者の経験では、統合後に順位が不安定になるケースの多くは、転送先の関連性が薄いまま「とりあえず近そうなページ」に寄せている状態です。旧ページで満たしていた検索意図を、新ページでも受け止められるかを基準に選ぶと判断しやすくなります。
リダイレクトチェーンを短く保つ
A→B→Cのように複数回転送するチェーンは、ユーザー体験と保守性の両面で不利です。
Googleは複数ホップをたどれますが、最終URLへ直接送ることを推奨しています。実務では、旧http→旧https→新www→新最終URLのように、歴代ルールが積み上がって長くなることがよくあります。移行のたびに古いルールを棚卸しし、最終URLへ一本化するのが理想です。
リダイレクトループを起こさない
A→B、B→Aのようなループは、ページが開けなくなる典型的な障害です。
www統一、SSL化、末尾スラッシュ統一を別々に追加した結果、条件がぶつかってループすることがあります。設定後は代表URLだけでなく、wwwあり・なし、http・https、末尾スラッシュあり・なしなど複数パターンで確認すると見つけやすいです。
削除すべきページは404や410も検討する
すべてを301にすればよいわけではありません。対応する移転先がないページは、404や410のほうが適切なこともあります。
たとえば、短期キャンペーン終了後のページで、後継コンテンツも代替案内もない場合、無理にトップへ飛ばすより、終了を明示したうえで適切なステータスを返すほうが自然です。URL移行とページ削除は別の判断軸として考えると整理しやすくなります。
サイト移転・URL変更で失敗しにくい進め方
サイト移転で重要なのは、301の実装前にURL対応表を固め、実装後に検証までやり切ることです。設定方法より、進め方の設計で差がつきます。
1. 旧URLと新URLの対応表を作る
まず、全URLを洗い出して1対1の対応表を作ります。
最低限、旧URL、新URL、移転種別、優先度、確認結果の列は用意すると管理しやすいです。記事数が多いメディアや商品点数の多いECでは、この表がないと確認工程で抜け漏れが起きます。
2. 重要ページから先に検証する
全件一括で本番反映する前に、流入やCVに近いページから先に確認します。
- 自然検索流入が多い記事
- 被リンクを多く受けているページ
- 問い合わせや購入につながるページ
- 指名検索で見られる会社情報ページ
3. Search Consoleとサーバーログで移行後を監視する
移行後は、クロールエラー、インデックス状況、想定外の404、旧URLの残存を確認します。
大規模移転では、公開直後より数日から数週間後に問題が見つかることがあります。テンプレート差し替えや運用担当者の更新で、旧URLリンクが再発するためです。公開日だけでなく、移行後の監視期間まで含めて計画すると運用が安定します。
4. リダイレクトは短期間で外さない
301は、設定したらすぐ消してよいものではありません。
Googleのサイト移転ガイドでは、リダイレクトを一般的には1年以上維持することが案内されています。外部リンクや古いブックマークは長く残るため、短期間で外すとユーザーも検索エンジンも困ります。特に資料、プレスリリース、比較記事に掲載されたURLは想像以上に長寿命です。
よくある質問
301リダイレクトと308の違いは何ですか?
どちらも恒久的なリダイレクトです。検索エンジンに対しては、どちらも移転先を正規版として扱う強いシグナルになります。一般的なWeb運用では301のほうが広く使われています。
301リダイレクトを設定すると順位はすぐ戻りますか?
すぐに安定するとは限りません。クロール、再評価、インデックス更新の時間が必要です。特に大規模移転では、一時的に順位や流入が動くことがあります。
すべての旧URLをトップページへ飛ばしても問題ありませんか?
おすすめしません。内容が近いページへ個別に対応させるほうが、ユーザーにも検索エンジンにも分かりやすくなります。関連性の薄い一括転送は、移行品質が低くなりやすいです。
301リダイレクトとcanonicalはどちらを使えばよいですか?
旧URLを使わないなら301、類似ページを残したまま正規URLを示したいならcanonicalが基本です。削除・統合するのか、併存させるのかで使い分けます。
WordPressではプラグインだけで十分ですか?
少数ページの転送なら対応しやすいですが、大量URLの移転やドメイン変更ではサーバー側設定のほうが安定しやすいです。規模と保守性で選ぶとよいでしょう。
まとめ
301リダイレクトは、URLを恒久的に変更したときに、新URLへ導線と評価を集約するための基本設定です。特に、SSL化、URL整理、記事統合、ドメイン移転では、301の有無で移行後の安定性が大きく変わります。
重要なのは、転送できることではなく、適切なページへ、最短で、周辺設定まで含めて整えることです。内部リンクやcanonical、サイトマップまで更新し、チェーンやループがないか確認してはじめて、移行品質が担保されます。
301リダイレクトを実装する際は、まずURL対応表を作り、重要ページから検証し、移行後もしばらく監視を続けてください。内部対策全体もあわせて見直したい方は、以下のページも是非ご覧ください。

