301リダイレクトとは？.htaccessの書き方から設定方法・確認方法まで徹底解説

リダイレクト301 SEO対策
2026/08/13

サイトのURLを変更したら検索順位が下がってしまった、ドメイン移転をしたいけれど今までの評価が消えないか不安──Web担当者なら一度は感じる悩みではないでしょうか。その不安を解消する仕組みが「301リダイレクト」です。この記事では、301リダイレクトの意味と302リダイレクトとの違いから、.htaccessの具体的な書き方、WordPressプラグインでの設定方法、設定後の確認手順、そして「転送はいつまで維持すべきか」という疑問まで、実務で必要な知識を一通り解説します。

301リダイレクトとは

301リダイレクトとは、あるURLにアクセスがあったときに、サーバーが「このページは恒久的に別のURLへ移動しました」と伝え、自動的に新しいURLへ転送する処理のことです。ユーザーは古いURLをクリックしても自然に新しいページへたどり着き、検索エンジンは「このページの正式な場所は転送先である」と理解します。

重要なのは、301リダイレクトが単なる「ページの引っ越し案内」ではなく、検索エンジンに対する正規URLのシグナルとして機能する点です。Googleの公式ドキュメント「Redirects and Google Search」でも、恒久的なリダイレクトはインデックス処理において「転送先を正規（canonical）ページとして扱うべき」という信号になると明記されています。つまり、古いURLが積み上げてきた被リンクや評価を、新しいURLへ引き継ぐ役割を担っているわけです。

なお、リダイレクトの実現方法にはサーバー側で処理する方法（.htaccess、Nginxの設定ファイル、PHPなど）と、HTMLのmetaタグやJavaScriptで処理する方法があります。Googleは、検索エンジンに正しく解釈される可能性がもっとも高いのはサーバーサイドリダイレクトだとしており、実装可能であればサーバー側での設定が第一選択になります。

302リダイレクトとの違い

301と並んでよく使われるのが302リダイレクトです。両者の違いは一言でいえば「恒久的（permanent）か、一時的（temporary）か」です。

Googleは、恒久的リダイレクトを受け取ると転送先を検索結果に表示しようとし、一時的リダイレクトを受け取ると転送元のページを検索結果に残そうとします。この挙動の差が、SEO上の使い分けを決定づけます。

項目 301リダイレクト 302リダイレクト
ステータスコードの意味 Moved Permanently（恒久的に移動） Found（一時的に移動）
位置づけ 恒久的な転送 一時的な転送
検索結果に表示されるURL 転送先（新URL） 転送元（旧URL）
正規URLのシグナル 転送先を正規ページとして扱う信号になる 正規化の信号としては使われない
ブラウザのキャッシュ 強くキャッシュされやすい キャッシュされにくい
主な用途 URL変更、ドメイン移転、サイト統合、https化、URL正規化 期間限定キャンペーン、メンテナンス、A/Bテスト、一時的な代替ページへの誘導

たとえば「ECサイトで在庫切れ商品ページを一時的に別カテゴリへ飛ばす」ような場面では、元のページを検索結果に残しておきたいので302が適切です。逆に「旧サイトから新サイトへ完全移転する」なら、迷わず301を使います。

やってしまいがちな失敗が、恒久的な移転なのに302のまま放置してしまうケースです。この場合、Googleは旧URLをインデックスに残し続けようとするため、新URLがなかなか評価されないという事態が起こり得ます。逆に、数週間で元に戻す予定のページに301を設定してしまうと、ブラウザに強くキャッシュされて元のURLへ戻しづらくなります。元に戻す可能性があるなら302、二度と戻さないなら301、と覚えておくと判断しやすいでしょう。

ステータスコードの意味と3xx系の全体像

301や302は、HTTPステータスコードと呼ばれるサーバーからの応答コードの一種です。200番台は成功、300番台はリダイレクト、400番台はクライアント側のエラー（404 Not Foundなど）、500番台はサーバーエラーを表します。

転送に関わる3xx系のコードは、実務上は次の4つを押さえておけば十分です。

コード 名称 種別 特徴
301 Moved Permanently 恒久的 もっとも一般的な恒久リダイレクト。POSTがGETに変換される場合がある
302 Found 一時的 一時的な転送。古いクライアントではメソッドがGETに変わることがある
307 Temporary Redirect 一時的 リクエストメソッドとボディを維持したまま転送する
308 Permanent Redirect 恒久的 301のメソッド維持版。Googleも恒久リダイレクトとして扱う

307と308は、301・302で起こり得る「POSTリクエストがGETに変換されてしまう」問題を解決するために定義されたコードです。フォーム送信やAPIのように、リクエストメソッドを保持したまま転送したい場合は307・308が適しています。ただし一般的なWebページのSEO用途では、実績とツール対応の広さから301が今も標準的な選択肢です。Googleのドキュメントでも、301と308はいずれも「恒久的リダイレクト」として同じ扱いになると説明されています。

301リダイレクトが必要になる主なケース

301リダイレクトは「URLが変わるすべての場面」で必要になります。代表的なケースを整理しておきましょう。

URLやページ構成を変更するとき

カテゴリ構成の見直しやCMSの入れ替えで、/blog/2020/seo-tips.html から /column/seo-tips/ のようにURLが変わることがあります。何もしなければ、旧URLへのアクセスはすべて404エラーになります。

404が発生すると、ユーザーは目的の情報にたどり着けず離脱しますし、旧URLに貼られていた外部リンクの評価も宙に浮いたままです。301リダイレクトを設定しておけば、ユーザーは新URLへ自動的に案内され、検索エンジンも評価の移転先を正しく認識できます。

ドメイン移転・サイトリニューアルのとき

社名変更やブランド統合にともなうドメイン変更は、301リダイレクトがもっとも真価を発揮する場面です。旧ドメインの全ページを、対応する新ドメインのページへ1対1で転送するのが基本方針になります。

このとき絶対に避けたいのが、旧ドメインの全ページを新ドメインのトップページへまとめて転送する設定です。実装は楽ですが、Googleは転送元と転送先の内容が対応していないリダイレクトを「ソフト404」に近いものとして扱う可能性があり、ページごとの評価が引き継がれにくくなります。手間はかかっても、URLの対応表（マッピングリスト）を作り、ページ単位で転送先を指定しましょう。

www有無・http/httpsを統一する（URLの正規化）とき

http://example.com、http://www.example.com、https://example.com、https://www.example.com。この4つは人間の目には同じサイトに見えますが、検索エンジンにとっては別々のURLです。すべてでページが表示できる状態だと、評価が分散したり重複コンテンツとみなされたりする恐れがあります。

Googleも公式ドキュメントで、複数のURLでホームページに到達できる場合は、いずれか1つを正規URLとして選び、他のURLからリダイレクトで集約することを推奨しています。SSL化（https化）を行った際に、http側からhttps側への301リダイレクトを設定するのも同じ理由です。

複数ページを統合・削除するとき

内容が重複した記事を1本にまとめる、古いキャンペーンページを廃止する、といった整理の際にも301リダイレクトが役立ちます。統合する場合は、残す側のページへ301で転送すれば、削除するページが持っていた評価を引き継げます。

一方、転送先として適切なページが存在しないなら、無理にリダイレクトせず404（Not Found）または410（Gone）を返すほうが適切です。関連性のないページへ強引に飛ばすのは、ユーザー体験の観点からも検索エンジンの評価の観点からも逆効果になります。

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

設定方法はサーバー環境によって異なります。ここでは代表的な3つのパターンを見ていきます。

.htaccessでの設定（Apache）

もっとも一般的なのが、Apacheサーバーで.htaccessファイルに記述する方法です。多くのレンタルサーバーがApacheを採用しているため、この方法が使えるケースは非常に多くなっています。

手順は次のとおりです。

  1. FTPソフトやサーバーのファイルマネージャーで、サイトのドキュメントルート（public_htmlやwwwなど）にアクセスする
  2. 既存の.htaccessがあればダウンロードしてバックアップを取る
  3. リダイレクトの記述を追加する
  4. アップロードし、実際のURLにアクセスして動作を確認する

.htaccessは1文字の記述ミスでもサイト全体が表示されなくなったり、リダイレクトループを引き起こしたりする危険があります。編集前のバックアップは必須と考えてください。また、ファイル名がドットで始まるため、PC上では隠しファイル扱いになる点にも注意しましょう。

なお、.htaccessが使えるかどうかはサーバーの設定（AllowOverrideディレクティブ）に依存します。記述しても反映されない場合は、契約しているサーバーのマニュアルを確認してください。

WordPressのプラグインで設定する方法

WordPressサイトであれば、プラグインを使うのがもっとも手軽で安全です。サーバーの設定ファイルを直接触らずに済むため、リダイレクトループでサイトが落ちるリスクを大きく減らせます。

代表的なのが「Redirection」プラグインです。管理画面の「プラグイン」→「新規追加」から検索してインストール・有効化し、「ツール」→「Redirection」から設定画面を開きます。あとは「ソースURL」に転送元、「ターゲットURL」に転送先を入力して追加するだけで、301リダイレクトが有効になります。

Redirectionには次のような便利な機能もあります。

  • 転送されたアクセスのログ記録（どのURLが何回転送されたかを確認できる）
  • 404エラーが発生したURLの記録（リダイレクト漏れの発見に使える）
  • WordPressの投稿スラッグを変更した際の自動リダイレクト生成
  • 正規表現による一括リダイレクト設定
  • 設定内容のエクスポート・インポート

このほか、SEO系プラグイン「Yoast SEO」の有料版や「Rank Math」にもリダイレクト機能が搭載されています。すでにこれらを使っているなら、プラグインを増やさずに済むのがメリットです。

注意点として、プラグインによるリダイレクトはPHPが実行されてから処理されるため、サーバー設定ファイルによる転送よりもわずかに処理が重くなります。数千件規模の大量リダイレクトを扱う場合は、サーバー側の設定に寄せることも検討しましょう。

Nginx・PHPなど他のサーバー環境での設定

Nginxを使っている場合は、.htaccessは機能しません。サーバーの設定ファイル（nginx.confやサイトごとのconfファイル）に記述し、設定を再読み込みする必要があります。Googleの公式ドキュメントでも、Nginxではreturnディレクティブやrewriteディレクティブを使う例が紹介されています。

location = /service {
    return 301 https://example.com/about/service;
}

サイト全体を別ドメインへ転送する場合は、次のような書き方が使えます。

server {
    server_name old-example.com;
    return 301 https://new-example.com$request_uri;
}

PHPで動的にリダイレクトすることも可能です。Googleのドキュメントでもheader()関数を使う方法が示されています。

<?php
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();

PHPで実装する際の鉄則は、画面に何かを出力する前にヘッダーを送信することです。HTMLタグや空白が先に出力されていると、ヘッダーが送信できずエラーになります。また、exit()で処理を確実に終了させることも忘れないようにしましょう。

このほか、HTMLのmeta refresh（contentを0秒に設定）を使う方法もあり、Googleはこれを恒久的リダイレクトとして解釈するとしています。ただし、サーバーサイドの実装が可能なら、そちらを優先するのが公式の推奨です。JavaScriptによるリダイレクトはさらに優先度が低く、Googleは「サーバーサイドやmeta refreshが使えない場合にのみ使うように」と案内しています。レンダリングに失敗するとリダイレクトが認識されない可能性があるためです。

301リダイレクトの書き方例（.htaccess）

ここからは、Apacheの.htaccessにおける具体的な記述例を用途別に紹介します。実際に使う際は、ドメイン名やパスを自サイトのものに置き換えてください。

ページ単位のリダイレクト

もっともシンプルなのは、mod_aliasのRedirectディレクティブを使う方法です。

Redirect 301 /old-page.html https://example.com/new-page/

転送元は「サイトルートからの相対パス」、転送先は「絶対URL」で書くのが基本です。Googleの公式ドキュメントでは、ステータスコードの代わりにpermanentというキーワードを使う書き方も紹介されています。

Redirect permanent "/old" "https://example.com/new"

より柔軟な制御が必要なら、mod_rewriteのRewriteRuleを使います。

RewriteEngine On
RewriteRule ^old-page/?$ https://example.com/new-page/ [R=301,L]

[R=301,L]は「301でリダイレクトし（R=301）、ここで書き換え処理を終了する（L）」という意味のフラグです。Lを付けないと後続のルールが適用され、意図しない挙動になることがあります。

ディレクトリ単位のリダイレクト

配下のページをまとめて対応する新ディレクトリへ移したい場合は、RedirectMatchが便利です。

RedirectMatch 301 ^/old-directory/(.*)$ https://example.com/new-directory/$1

この記述により、/old-directory/page1.htmlは/new-directory/page1.htmlへ、/old-directory/sub/page2.htmlは/new-directory/sub/page2.htmlへと、階層構造を保ったまま転送されます。(.*)でマッチした部分が$1に入る仕組みです。

ドメイン単位のリダイレクト

ドメイン移転時に、全ページを新ドメインの同じパスへ転送する記述です。

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-example\.com$ [NC]
RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]

RewriteCondは条件指定で、「ホスト名がold-example.comのときだけ次のルールを適用する」という意味になります。[NC]は大文字小文字を区別しないフラグです。ドメイン名の中のドットは正規表現では任意の1文字を意味してしまうため、\.とエスケープしておくのが安全です。

www統一のリダイレクト

www無しをwww有りに統一する場合の記述です。

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

逆に、www有りをwww無しに統一したい場合は次のように書きます。

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

どちらを正規URLにするかに優劣はありません。すでに運用しているサイトなら、被リンクが多いほう・検索エンジンにインデックスされているほうに合わせるのが無難です。

https化のリダイレクト

SSL証明書を導入したあと、httpアクセスをhttpsへ転送する記述です。

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

なお、レンタルサーバーやロードバランサーの構成によっては%{HTTPS}が正しく判定されず、リダイレクトループを起こすことがあります。その場合は%{HTTP:X-Forwarded-Proto}を条件に使うなど、サーバーの仕様に合わせた記述が必要です。契約サーバーのマニュアルに推奨記述が載っていることも多いので、まずはそちらを確認しましょう。

設定後の確認方法

リダイレクトは「設定して終わり」ではありません。意図どおりに動いているか、必ず確認します。

ブラウザのシークレットモードで確認する

もっとも手軽な方法が、ブラウザで実際に旧URLへアクセスしてみることです。ただし通常のウィンドウでは、過去のリダイレクト結果や表示内容がキャッシュされていて、正しい検証にならない場合があります。シークレットモード（プライベートウィンドウ）を使い、キャッシュの影響を排除した状態でアクセスしましょう。

さらに正確に確認するなら、ブラウザの開発者ツール（F12キーで起動）の「ネットワーク」タブを開いた状態でアクセスします。旧URLのリクエストに対して「301」というステータスコードが表示され、レスポンスヘッダーのLocationに転送先URLが入っていれば成功です。ここが「302」になっていたら設定を見直してください。

コマンドラインが使える環境なら、以下のコマンドでヘッダーだけを確認する方法もあります。

curl -I https://example.com/old-page/

Google Search Consoleで確認する

検索エンジンから見てどう認識されているかを確かめるには、Google Search Console（GSC）の「URL検査」ツールが有効です。旧URLを入力して検査すると、Googleがそのページをどう処理したかが表示され、リダイレクトが認識されていれば「ページにリダイレクトがあります」といったステータスが確認できます。

このメッセージは一見エラーのようですが、転送先が正しくインデックスされていれば問題ないケースがほとんどです。一方、「リダイレクト エラー」と表示された場合は、リダイレクトループやチェーンが長すぎるなど、設定自体に不具合がある可能性が高いため調査が必要です。

新URLについては「インデックス登録をリクエスト」を実行しておくと、クロールが早まる場合があります。ドメイン移転の際は、GSCの「アドレス変更ツール」を使って新旧ドメインの関係をGoogleに伝えることも合わせて検討しましょう。

専用チェックツールを使う

転送が複数回連なっていないか（リダイレクトチェーン）を確認するには、リダイレクトの経路をすべて可視化してくれる外部のチェックツールが便利です。「redirect checker」「リダイレクトチェッカー」といったキーワードで検索すると、URLを入力するだけでステータスコードと転送経路を一覧表示してくれる無料ツールがいくつも見つかります。

サイト全体を一括で調べたい場合は、Screaming Frog SEO Spiderのようなクロールツールが有効です。全URLのステータスコードを取得できるため、404が残っているページやリダイレクトが連鎖しているページをまとめて洗い出せます。ページ数の多いサイトのリニューアル直後には、こうしたツールでの全体チェックを行っておくと安心です。

301リダイレクト設定時の注意点

最後に、実務でつまずきやすいポイントを整理します。

リダイレクトループ・リダイレクトチェーンを避ける

リダイレクトループは、AからBへ、BからAへと転送し合って処理が終わらなくなる状態です。ブラウザには「リダイレクトが多すぎます」というエラーが表示され、ページがまったく閲覧できなくなります。https化とwww統一のルールが競合したときなどに発生しがちです。

リダイレクトチェーンは、AからB、BからC、CからDと転送が数珠つなぎになる状態を指します。ページが表示されないわけではありませんが、転送のたびにサーバーへのリクエストが発生するため表示速度が落ち、ユーザー体験を損ないます。検索エンジンのクローラーが追跡できる転送回数にも限度があるため、チェーンが長いと最終的なページまでたどり着けない恐れもあります。

サイトを何度もリニューアルしていると、古いリダイレクト設定が積み重なってチェーンが生まれやすくなります。新しくリダイレクトを追加するときは、最終的な転送先を直接指定するように書き換えるのが鉄則です。

関連性の低いページへ転送しない

転送先は、転送元と内容が対応しているページを選びます。削除する製品ページなら同カテゴリの製品一覧へ、統合する記事なら統合先の記事へ、といった具合です。

関連性のないページへ転送しても、期待した評価の引き継ぎは起こりにくく、ユーザーも「探していた情報と違う」と感じて離脱します。対応する転送先が存在しないなら、無理に301を使わず404や410を返し、サイト内の関連ページへ誘導する404ページを用意するほうが誠実な対応です。

内部リンクやXMLサイトマップも更新する

リダイレクトを設定しても、サイト内のリンクが旧URLを指したままでは、ユーザーがクリックするたびに無駄な転送処理が発生します。記事本文、グローバルナビゲーション、フッター、バナーなど、旧URLを参照している箇所は新URLに書き換えましょう。

同様に、XMLサイトマップに旧URLが残っていると、検索エンジンに古い情報を送り続けることになります。サイトマップは新URLのみを記載した状態に更新し、Search Consoleから再送信してください。また、robots.txtで転送元URLをブロックしていると、クローラーがリダイレクトそのものを認識できません。移転作業の際は、robots.txtの記述も併せて確認しておきましょう。外部サービスに登録しているURLや、SNSプロフィールのリンクの更新も忘れずに行いたいところです。

転送設定はいつまで維持すべきか

「301リダイレクトはいつまで残せばいいのか」は、実務でもっともよく聞かれる疑問です。

Googleは、URLの変更を恒久的なものとしてシステムに記録するには、リダイレクトを複数回クロールする必要があるとしており、最低でも1年間はリダイレクトを維持することを推奨しています。1年間稼働させておけば、旧URLが持っていたシグナルは転送先へ引き継がれ、その後リダイレクトを解除しても評価は転送先に残るという考え方です。

ただしこれはあくまで「検索エンジンの評価」という観点での最低ラインです。実際には、旧URLがブックマークされていたり、他サイトからリンクされていたり、印刷物やメール本文に記載されていたりします。これらの流入は1年を過ぎても発生し続けるため、サーバー費用やドメイン維持費の負担が許すなら、可能な限り長く（できれば恒久的に）維持するのが理想です。

解除を検討する際は、まずSearch Consoleやアクセス解析ツールで旧URL経由の流入がほぼゼロになっているかを確認しましょう。ドメイン移転の場合は、旧ドメインの契約が切れると同時にリダイレクトも失われるため、ドメインの更新を止めるタイミングにも注意が必要です。

まとめ

301リダイレクトは、URLが変わってもユーザーと検索エンジンの評価を失わないための、Web運用に欠かせない基本技術です。本記事の要点を振り返ります。

  • 301は恒久的な転送、302は一時的な転送。恒久的リダイレクトは転送先を正規URLとして扱う信号になり、一時的リダイレクトでは転送元が検索結果に残る
  • URL変更、ドメイン移転、サイト統合、https化、www有無の統一（URLの正規化）といった場面で301を使う
  • 実装方法はApacheの.htaccess、WordPressのRedirectionなどのプラグイン、Nginxの設定ファイル、PHPのheader()関数など。Googleはサーバーサイドでの実装をもっとも推奨している
  • .htaccessではページ単位はRedirect 301、ディレクトリ単位はRedirectMatch、条件付きの転送はRewriteCondとRewriteRuleを使い分ける。編集前のバックアップは必須
  • 設定後はシークレットモードと開発者ツールでステータスコードが301になっているか確認し、Search ConsoleのURL検査や外部チェックツールで検索エンジン側の認識も確かめる
  • リダイレクトループとチェーンを避け、関連性の低いページへ転送しない。内部リンクとXMLサイトマップの更新も忘れない
  • Googleは301リダイレクトを最低1年間は維持することを推奨している。旧URLからの流入は長く続くため、可能なら恒久的に残しておくのが安全

URL変更をともなう作業では、事前にURLの対応表を作り、リダイレクト設定と確認までを一連の作業としてスケジュールに組み込んでおくことが、評価の下落を防ぐもっとも確実な方法です。

タイトルとURLをコピーしました