301リダイレクト: それは何か、そして設定方法（2026年版）

このガイドでは、301の役割、302やcanonicalタグの代わりに使うべき場面、一般的な環境での設定方法、そして正しく動作して順位を維持しているかの確認方法を解説します。

301リダイレクトとは？#

301はHTTPステータスコードです。誰かが古いURLにアクセスすると、サーバーはページ本体を返しません。代わりに「恒久的に移動しました」という短い応答と、新しいアドレスを含むLocationヘッダーを返し、ブラウザはそのアドレスへすぐに再リクエストします。訪問者には新しいページが読み込まれるだけに見えます。

httpHTTP/1.1 301 Moved Permanently
Location: https://mybrand.com/about

重要なのは permanent（恒久的）という言葉です。Googleのドキュメントによると、恒久的なリダイレクトはインデックス処理に対してリダイレクト先を正規URLとすべき^[1]ことを示すため、新しいアドレスが時間とともに検索結果で古いアドレスに置き換わります。ブラウザも301をキャッシュする場合があるため、再訪問ユーザーは古いURLを完全にスキップできます。

また、実際にはほぼ毎回選ばれるリダイレクトでもあります。RedirHubで設定されたリダイレクトの約100件中96件は301で、302を設定したことがあるアカウントは約7件に1件にとどまります（RedirHubプラットフォームデータ、2026年10月）。

恒久的か一時的か迷っていますか？完全な比較については、301 と 302 のリダイレクトをご覧ください。

301リダイレクトはいつ使うべきですか？#

• URLを変更した場合。たとえば、新しいスラッグ、新しいフォルダー構造、または商品ページ名の変更などです。
• ブランド変更や合併後に新しいドメインへ移行した場合。古い各URLを、それに対応する新しいページへリダイレクトします。
• URLを標準化した場合。http:// を https:// に、また www ありを www なしに（またはその逆に）統一します。
• ページを統合または削除した場合。 古いURLはホームページではなく、最も近い代替ページに送ります。
• タイプミスのドメインや廃止した商品名など、追加のドメインを所有している場合。それらはメインサイトを指すようにします。

元に戻す予定がある場合は 302 を使用し、ページの重複版を引き続きアクセス可能にする必要がある場合は canonical タグを使用します（詳細は後述）。

301リダイレクトの設定方法#

リダイレクトを追加する場所は、現在古いURLへのリクエストに応答しているものによって異なります：

Apache（.htaccess）#

単一ページの場合は、Apache の Redirect ディレクティブで十分です。旧パスはスラッシュで始める必要があり、permanent または 301 は 301 ステータスを返します^[2]。ドメイン全体を移行して各パスを維持するには、mod_rewrite を使用します:

apache# 1ページ
Redirect 301 /old-page https://www.example.com/new-page

# ドメイン全体、パスを保持
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?oldbrand\.com$ [NC]
RewriteRule ^(.*)$ https://mybrand.com/$1 [R=301,L]

Nginx#

Nginxでは、return 301 により恒久的なリダイレクトを送信します^[3]。$request_uri はパスとクエリ文字列を保持します。nginx -t で設定をテストしてから、再読み込みしてください。

nginx# 1ページ
location = /old-page {
    return 301 https://www.example.com/new-page;
}

# ドメイン全体、パスを保持
server {
    listen 80;
    listen 443 ssl;
    server_name oldbrand.com www.oldbrand.com;
    # ssl_certificate lines for oldbrand.com go here
    return 301 https://mybrand.com$request_uri;
}

古いドメインの https:// 版は、そのサーバーにまだ有効な証明書がある場合にのみリダイレクトされます。証明書がない場合、リダイレクトが行われる前に訪問者に証明書警告が表示されます。

WordPress#

よく使われる選択肢は、無料の Redirection プラグイン^[4]で、200万件以上の有効インストールがあります。古いパスをソース、新しい URL をターゲットとして追加し、HTTP コードが 301 になっていることを確認してください。プラグインを使わない方法を含む手順は、WordPress で URL をリダイレクトする方法 にあります。

ドメインレジストラで#

古いドメインにウェブサイトがない場合、レジストラの転送機能だけで十分かもしれません。GoDaddy のドメイン転送、Cloudflare、Namecheap のガイドがあります。案内がある場合は恒久的な（301）オプションを選び、古いパスが保持されるのか、それともすべて1つのページに送られるのかを確認してください。

RedirHub で（サーバー不要）#

RedirHubは古いドメイン自体に応答するため、そのドメイン用のホスティング、サーバーアクセス、証明書は必要ありません。変更するのはドメインのルートとwwwのDNSレコードだけです。

1. RedirHubのダッシュボードで、Domain Redirectを選択します。
2. Redirect from に古いドメインまたはURLを、Redirect to に新しいアドレスを入力します。
3. Redirect type で、301 · Permanent を選択します。
4. Paths では、Keep the path を選ぶと /about は新しい /about に遷移し、Everything to one URL を選ぶと1つのURLにまとめられます。What happens パネルでは、サンプルアドレスの遷移先が表示されます。
5. Create redirect をクリックします。すぐに保存され、DNSがRedirHubを指すと公開されます。
6. Hostnames を開き、ドメインを選択して Connect DNS をクリックします。Manual タブで、表示されるレコードを追加します。@ 用の A レコード（3.33.236.10）、ドメイン確認用の TXT レコード、そして www 用の CNAME です。
7. I've made the changes をクリックします。ドメインが Connected と表示されたら、301 が有効になり、ルートと www の HTTPS も自動的に発行されます。

301リダイレクトの確認方法#

curl に -I を付けて実行し、レスポンスヘッダーだけを表示します。正しいリダイレクトでは 301 が表示され、location: に新しいアドレスが表示されます。

bashcurl -sI https://oldbrand.com/about

HTTP/2 301
location: https://mybrand.com/about

• ステータスコードは、移転が恒久的であれば302ではなく301（または308）です。
• Location は最終URLなので、連鎖ではなく1回の遷移で済みます。
• 移転先 は200を返し、404や別のリダイレクトではありません。
• すべてのバリエーションが機能します: http:// と https://、www ありとなし、さらにホームページだけでなく下位ページも。

ブラウザ派ですか？ リダイレクトチェッカー はステータスコード付きで全遷移を一覧表示し、リダイレクト速度テスト では HTTPS が有効かどうかと、リダイレクトの応答速度も表示します。手動で試すときはプライベートウィンドウを使ってください。ブラウザは301をキャッシュするためです。

301リダイレクトはリンクエクイティを引き継ぐのか？#

はい。GoogleのGary Illyes氏は2016年に、30xリダイレクトではもはやPageRankを失わない^[5]と述べており、Googleのドキュメントでも恒久的なリダイレクトは新しいURLが正規URLであることを示すシグナルとして扱われています。旧URLへのバックリンクは、新しいURLに対して引き続きカウントされます。

それでも順位に影響する要因は3つあります。チェーン：Googleは最終目的地へ直接リダイレクトする^[6]よう推奨しています。無関係な転送先：古いページをホームページや関係のないページに送ると、ソフト404として扱われることがあります。リダイレクトを早く外しすぎること：Googleはできるだけ長く、一般的には少なくとも1年間^[6]維持するよう推奨しています。

301リダイレクトとカノニカルタグ、どちらを使う？#

どちらも重複URLに対処しますが、動作は異なります。301は訪問者とクローラーを新しいURLへ送ります。古いURLはアクセスできなくなります。canonicalタグ（rel="canonical"）はすべてのバージョンを公開したままにし、検索エンジンにどれをインデックスするかだけを伝えます。

• ページが恒久的に移動した場合は301を使います。これには、新しいURL構造、ドメイン変更やリブランディング、統合・終了したページ、終了したイベントのような期限切れコンテンツが含まれます。
• 訪問者が複数のバージョンを利用できる必要がある場合はcanonicalタグを使います。たとえば印刷用バージョン、並べ替えやフィルターのパラメータ付きURL、ほぼ同じ内容を持つ地域別ページなどです。
• 同じURLでこの2つを併用しないでください。古いURLがリダイレクトされると、クローラーはそのcanonicalタグを見ることはできません。

よくある301リダイレクトのミス#

• チェーンとループ。 A → B → C では、訪問のたびに1回余計に処理が必要になります。A → B → A は読み込まれません。古いURLはそれぞれ直接最終ページへ向けましょう。
• すべてをホームページへ送る。 手早い方法ですが、訪問者は文脈を失い、検索エンジンはソフト404として扱うことがあります。
• 301 にすべきところを 302 にしている。 一時的なものをデフォルトにしているツールもあります。移動が恒久的なら、ステータスコードを確認してください。
• リダイレクトしているのがルートだけ。 パスが保持されない、またはマッピングされていないと、/blog/post-name のような深いリンクは壊れます。
• http または www のバリエーションが不足している。 旧ドメインでの HTTPS に加え、4 通りの組み合わせをすべてテストしてください。
• リダイレクトを早く消しすぎる。 旧 URL にまだアクセスがある、または被リンクがある間は、残しておいてください。

それでもリダイレクトがうまく動かない場合は、301 リダイレクトが機能しない？ 6 つのよくある原因と解決策 を参照してください。

サーバー設定 vs RedirHub#

サーバーのルールとリダイレクトサービスはどちらも本物の 301 を返します。違いは、その周辺で何を運用し、管理し続ける必要があるかです：

RedirHub は、ドメインの背後にサイトがもう存在しない場合に最適です。たとえば、リブランディング、終了した製品、あるいは ウェブサイトの移行 のように、数百もの古い URL それぞれに個別の転送先が必要なケースです。これらは 一括 CSV インポート で読み込めます。接続したすべてのドメインには 自動 HTTPS が適用されるため、旧ドメインへの https:// リンクも証明書の警告なしにリダイレクトされます。

古いURLがすでに運用しているサーバー上にあり、その設定を編集することに抵抗がないなら、.htaccess や Nginx に数行書くだけで無料でうまく機能します。リダイレクトサービスが価値を発揮するのは、保持しておくサーバーがもうない場合、多数のドメインを扱う場合、またはリダイレクト専用のドメインの証明書を管理したくない場合です。