URLを変更したのに旧リンクが検索結果に残り、訪問者が404ページへ迷い込む――そんな悩みはリダイレクトで一挙に解決できます。
本記事ではリダイレクトの意味と種類を初心者にもわかりやすく解説し、301・302の使い分けからApache・Nginx・WordPressでの設定手順、確認ツールまで網羅。読めばSEO評価を守りながら安全に転送を実装する方法がわかります。
リダイレクトとは?

リダイレクトとは、アクセスされたURLを別のURLへ自動転送する仕組みを指します。たとえば、旧サイトから新サイトへ引っ越した際に「訪問者と検索エンジンのどちらも迷わせない」よう導線を保つ役割を果たします。
仕組みとしては、サーバーやブラウザーがHTTPヘッダーに含まれるステータスコードを読み取り、転送先を案内します。これによりリンク評価(被リンクやPageRank)を無駄なく引き継ぎ、404エラーを防ぐことができます。
ただし、ステータスコードの選択を誤るとSEOパフォーマンスが低下し、転送ループやチェーンエラーといったトラブルが発生する場合があります。
適切な設定を行うためには、リダイレクトの種類や動作タイミングを理解したうえで、CMSやサーバー環境に合った手順を取ることが重要です。以下の表に代表的なリダイレクト方式と特徴をまとめました。
方式 | 主な利用シーン・ポイント |
---|---|
301(恒久転送) | ドメイン変更・HTTPS化など恒久的なURL移行で使用。リンク評価を損なわずに引き継げる |
302(⼀時転送) | キャンペーンページへの短期転送など、一時的な切り替えに適用。302 でもリンク評価は新 URL へ引き継がれます。 |
307(⼀時転送) | HTTP/1.1で導入。POSTデータを保持したまま安全に転送したいときに利用。 |
リダイレクトが必要になる代表的シーン
Web運営では「ページは残したいがURLを変えざるを得ない」シーンがたびたび発生します。典型例として、常時SSL化で http→https に統合する、ドメイン統合で www の有無を一本化する、季節キャンペーン終了後に通常ページへ戻す、ECサイトで商品整理に伴いURLを再構築する、などがあります。
放置すると旧URLが404エラーを返し、ユーザー離脱やクローラビリティ低下を招きます。リダイレクトを適切に配置すれば、アクセス損失を防ぎ、検索順位も維持しやすくなります。
- SSL化:常時httpsに統合する際、全ページで301転送を設定。
- ドメイン変更:旧ドメインを新ドメインへ丸ごと301転送。
- 一時キャンペーン:302で期間限定ページへ誘導し、終了後に元URLへ戻す。
- ページ構造の整理:古いカテゴリURLを新カテゴリに301統合し、内部リンクを更新。
- ユーザーの離脱防止と回遊性向上
- リンク評価の継承でSEOパフォーマンス維持
HTTPステータスコードと転送の流れ
リダイレクトはHTTPレスポンスで返される「3xx」系ステータスコードによって制御されます。ブラウザーはサーバーから 301 や 302 などのコードを受け取ると、レスポンスヘッダーの Location に記載された転送先URLへ自動アクセスを試みます。
この際、301は「恒久的に移転した」ことを意味し、検索エンジンもリンク評価を新URLに移行します。一方302や307は「一時的な移転」であるため、評価は旧URLに残ったままです。したがって、Googlebotは 301 と 302 を読み分け、評価をどちらへ与えるか決定します。
- クライアントが旧URLにアクセス
- サーバーが3xxコードとLocationヘッダーを返す
- クライアントが転送先URLへ再リクエスト
- 新URLのコンテンツが表示される
- デベロッパーツールのNetworkタブでステータスとLocationを確認
- リダイレクトチェッカーでチェーンやループがないか検証
初心者が混乱しやすい用語の整理
リダイレクト周辺には専門用語が多く、初心者は混乱しがちです。たとえば「301と302の違い」「カノニカルとの使い分け」「転送チェーンと転送ループ」などが代表的な迷いポイントです。
301は恒久転送、302は一時転送という大別を覚えたうえで、canonicalタグは「同一内容ページの正規URLを示すHTMLタグ」である点を押さえましょう。
また、転送チェーンは複数リダイレクトが連続する状態、転送ループはA→B→Aと無限に回る誤設定を指します。
- 301 vs 302:恒久か一時かでリンク評価の動きが異なる。
- canonical:HTML内タグで正規ページを宣言、リダイレクトとは併用可。
- 転送チェーン:301→302→301のように転送が多段化、速度低下の原因。
- 転送ループ:A→B→Aで無限転送、ページ表示が不能。
- 恒久なら301、一時なら302/307を選択
- 同一コンテンツならcanonicalで正規化
ステータスコード別リダイレクトの種類と使い分け

リダイレクトを正しく実装するには、HTTPステータスコードごとの役割を理解し、シーンに合わせて使い分けることが不可欠です。
とくに301・302・307は転送の頻度やSEOへの影響が大きく異なるため、「恒久なのか一時なのか」「POSTデータを保持する必要があるか」など、目的を明確にして選択しましょう。以下の表に主要ステータスコードの違いをまとめましたので、まずは全体像を把握してください。
コード | 特徴 | 主な利用シーン |
---|---|---|
301 | 恒久転送。リンク評価をほぼ100%引き継ぎ、キャッシュが強力に残る。 | ドメイン変更、常時SSL化、URL正規化 |
302 | 一時転送。検索評価は原則旧URLに残るが、短期施策に便利。 | キャンペーンページ、一時的なメンテナンス |
307 | 一時転送(HTTP/1.1)。POSTデータを保持して転送できる。 | フォーム送信を伴うシステム移行 |
301 vs 302 vs 307:SEO視点の選び方
検索エンジンは転送の意図をステータスコードから判断し、ページ評価の移動可否を決定します。そのため「301を一時的に使ったら評価が移り戻らない」といったミスが起こりやすいです。なお、恒久移転には 301 が推奨されるものの、302 を長期運用しても評価が分散するわけではないです。
基本原則として、URLを恒常的に変える場合は301、短期施策やテスト中のページは302または307を選択します。307は302と同じ一時転送ですが、フォームのPOST情報を保持できる点が特長で、ECサイトの決済導線などで重宝します。
- 恒久移転 → 301:評価を新URLに集中させ、旧URLを確実にアーカイブする。
- 短期キャンペーン → 302:終了後に旧URLへ評価を戻せる。
- フォーム付きページ一時移動 → 307:POSTデータを破棄せずに安全転送。
- URLが戻る可能性があるかどうかで恒久・一時を判断。
- SEO影響を最小限にしたい場合、301後は内部リンクとサイトマップも更新。
JavaScript・Meta Refreshのメリット・注意点
サーバーサイドの設定が難しい場合、HTMLヘッダにタグを入れたり、JavaScriptでwindow.locationを操作してリダイレクトを実現する方法もあります。
これらはサーバー権限が不要で、共有サーバーや静的ホスティングでも簡単に設置できる反面、検索エンジンが意図を正確に解釈できず、評価が分散したり遅延が発生するリスクがあります。
さらに、リダイレクト前にページが一瞬表示される「ちらつき」がユーザー体験を損ねる場合もあるため、本番環境では極力301/302へ置き換えることが推奨されます。
【クライアントサイド転送の主な特長】
- メリット:サーバー設定不要で導入が容易、A/Bテストなど動的制御に向く。
- デメリット:検索評価が正しく伝搬しにくい、転送実行までに表示遅延が生じる。
- タイミングを0秒に設定しても一瞬の遅れは避けられない。
- クローラーがJavaScriptを実行できない場合、転送が無視される恐れがある。
HTTPS移行・ドメイン変更に最適な設定例
常時SSL化やブランド変更によるドメイン移行は、サイト全体のURLが一斉に変わる大規模作業です。ここでは「旧URL→新URL」への301一括転送を用い、検索評価と被リンクを漏れなく引き継ぐことが鍵となります。
Apacheの場合は.htaccess、Nginxではserverブロックにリライトルールを書くことで、ディレクトリ単位やワイルドカードを用いた高効率の転送が可能です。
設定後はリダイレクトチェッカーでチェーン・ループがないか確認し、Search Consoleでクロールエラーを監視すると安全です。
環境 | 記述例 | ポイント |
---|---|---|
Apache(.htaccess) | RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://example.com/$1 [R=301,L] |
httpアクセスをhttpsへ完全転送 |
Nginx | server { listen 80; server_name old.com; return 301 https://new.com$request_uri; } |
旧ドメインから新ドメインへ一括301 |
WordPress | Redirectionプラグインで「正規表現転送」を設定 | 管理画面からGUI操作のみでOK |
- 新旧サイトマップをSearch Consoleに登録し、クロールを促進。
- 主要被リンク元に連絡し、アンカーテキストを新URLへ更新してもらう。
主要CMS・サーバーでのリダイレクト設定手順

リダイレクトは「どの環境で運営しているか」によって設定方法が大きく変わります。共有サーバーで動かすブログなら .htaccess が使える Apache 系が多く、Nginx を導入した高速サーバーでは設定ファイルを書き換える形になります。
WordPress ユーザーであれば、管理画面から操作できるプラグインを導入すれば専門知識がなくても安全に設定できます。
ここでは代表的な3方式を比較し、メリット・手順・注意点を整理しました。自社サイトの構成と運用体制に合わせて選べば、リンク評価を落とさずに URL を移行でき、転送ループなどの事故も防げます。
環境 | 主な設定手段 | 向いているケース |
---|---|---|
Apache | .htaccess に Rewrite ルールを記述 | 共有サーバー・レンタルサーバーでサイトを運営 |
Nginx | server ブロックに return や rewrite を追記 | 高速性を重視、root 権限でサーバーを管理 |
WordPress | Redirection などプラグインで GUI 設定 | 管理者が複数、コーディングに不慣れ |
.htaccess(Apache)で一括転送を設定する方法
Apache サーバーではルート直下の .htaccess にリダイレクトルールを書き込むだけで全ページを一括転送できます。まず RewriteEngine On を宣言したうえで、RewriteCond と RewriteRule を組み合わせます。
たとえば常時 SSL 化なら http でのアクセスを検知し、https へ 301 転送する形です。RewriteRule ^(.*)$ https://example.com/$1 [R=301,L] のようにワイルドカードを使えばディレクトリ構造を丸ごと保持できるため、個別設定より効率的です。
設定後はブラウザーのキャッシュをクリアしてから再読込し、Network タブで 301 と Location ヘッダーが出ているか確認しましょう。
- RewriteEngine On を最上部に記述し忘れるとルールが無効化される。
- 複数の RewriteRule が並ぶときは [L] フラグで処理を打ち切り、チェーンを防止。
- 日本語 URL はエンコードずれが起きやすいので、実際にクリックして動作確認が必須。
- 必ずテスト環境で動作確認し、500 エラーが出たらすぐ戻せるようバックアップを残す。
- RedirectMatch を使うと正規表現で細かいディレクトリ移行も一括記述できる。
Nginx設定ファイルで正規化/WWW統合を行う手順
Nginx では /etc/nginx/sites-available/ などの server ブロック内に return や rewrite を追記してリダイレクトを実装します。高速処理が特長のため、処理を簡潔に書くのがベストプラクティスです。
www あり・なしの統合なら、listen 80; server_name www.example.com; のブロックで return 301 https://example.com$request_uri; と一行書くだけで済みます。
同様に http→https も return 301 https://$host$request_uri; とすることで SSL 化を一括実現可能です。設定後は sudo nginx -t で構文テストを行い、service nginx reload で反映。curl -I 旧 URL で 301 と Location を確認したら完了です。
- rewrite ^/(.*)$ /$1 permanent; など古い書き方は新バージョンで推奨されない。
- if ディレクティブは条件が複雑だと遅延要因になるため、map と return の組み合わせが高速。
- HSTS を有効にするなら add_header Strict-Transport-Security を同時に設定し、ブラウザーに https を強制。
- 設定ファイルを誤ると全サイトがダウンするため、必ず構文テストを実施。
- letsencrypt の自動更新がある場合、80 番ポートのリダイレクトは一時的に無効化が必要。
WordPressプラグインでクリック操作だけのリダイレクト
WordPress を使っているなら、プラグイン「Redirection」や「Simple 301 Redirects」を入れると管理画面から URL 転送を GUI で設定できます。手順はプラグインを有効化し、転送元 URL と転送先 URL を入力するだけ。
301 か 302 かはドロップダウンで選択でき、正規表現にも対応しています。さらに 404 ログ機能があり、「ユーザーがどの壊れたリンクへアクセスしているか」を確認しながら即時転送を追加できる点も便利です。
プラグインは .htaccess を直接書き換えないため、誤設定でサイトが真っ白になるリスクが低いのが魅力ですが、転送数が数千件を超えると速度に影響することがあります。その場合はエクスポート機能でルールを .htaccess へ移行すると負荷を軽減できます。
- Redirection → 404 モニターを ON にして、壊れたリンクを可視化。
- Simple 301 Redirects → 数行のみの転送に向き、軽量で扱いやすい。
- Yoast SEO Premium → リダイレクト管理も兼ねるが有料プラグイン。
- 定期的にエクスポートし、サーバー移転時にルールを引き継ぐ。
- キャッシュ系プラグインと併用するときは優先順位を確認し、転送前にキャッシュが返らないように設定。
リダイレクト後の確認・トラブル対策とSEO維持

リダイレクト設定が完了したら作業は終わり……ではありません。転送が正しく機能しているか、検索エンジンが新URLに評価を引き継いでいるかを確認し、不具合があれば迅速に修正しなければSEOパフォーマンスやユーザー体験を大きく損ねます。
まずはブラウザーの開発者ツールや専用チェッカーで転送経路とステータスコードを検証し、チェーン(多段転送)やループ(無限転送)の有無を把握します。
次に、Google Search Console でクロールエラーやインデックス状況をモニタリングし、評価が分散していないかを確認することが重要です。
さらに、転送後に発生しやすいキャッシュ・Cookie 由来の表示崩れや、被リンクのリンク切れにも注意しましょう。定期的なテストとログ監視をルーティーン化すれば、サイトの安定性と検索順位を長期的に維持できます。
リダイレクトチェッカーで転送状態をテスト
リダイレクトチェッカーとは、URLを入力するだけでサーバーからブラウザーへ返されるステータスコードやLocationヘッダーの遷移を一覧表示してくれるツールです。代表的な「HTTP Status Checker」「Redirect Path」拡張機能を使えば、301・302・307などのコードと転送先URLが一目で確認できます。
これにより、意図しない302転送や多段チェーンが潜んでいないかをすばやく把握できます。また、cURLコマンド(curl -I URL)でヘッダーだけを取得し、開発環境でも同じ結果になるか確認すると、キャッシュの影響を受けず精度が上がります。
【活用ポイント】
- URLをランダム抽出し、一括でリダイレクトチェッカーに投入して網羅的に検証。
- ステータスコードが3xx以外(403・404など)の場合は.htaccessやプラグイン設定を見直す。
- Locationヘッダーが相対パスになっていると一部ブラウザーで誤動作するため、必ず絶対パスを指定。
- 初回検証はキャッシュを無効化しリアルタイム状態を確認。
- HTTP・HTTPS双方のURLでテストし、一貫して同じ転送結果か比較。
- 検証ログをCSVで保存し、次回比較用のベースラインにする。
ループ・チェーンエラーを解消するチェックポイント
リダイレクトループはA→B→Aのように無限転送が発生し、ブラウザーは「このページはリダイレクトループのため表示できません」とエラーを返します。チェーンはA→B→C→Dのように多段で転送が連なり、ユーザーの待ち時間が増加し、クローラのクロールバジェットも消費します。
いずれもサイト評価低下の原因になるため、設定ミスを早期に特定して修正しましょう。具体的には、リダイレクト元と先のパターンをスプレッドシートでマッピングし、「同じURLが複数ルールにマッチしていないか」「ワイルドカードが想定外のURLを巻き込んでいないか」を洗い出します。
また、プラグインとサーバールールが二重適用されている場合もループの温床となるため、優先順位を把握することが不可欠です。
- Apacheなら.htaccessの記述順を整理し、[L]フラグで早期打ち切りを徹底。
- Nginxではserverブロック間のreturn競合を避け、mapディレクティブで条件分岐を集約。
- WordPressプラグイン同士で重複ルールがある場合、不要なプラグインを停止して整理。
- 転送は最大2段以内を目標に設計する。
- 定期ログ解析で「3xx回数が急増」していないかチェック。
Search Consoleで評価を監視しリンク損失を防ぐ
Google Search Consoleは、リダイレクト後のクロール状況やインデックス状況を確認し、SEOパフォーマンスを維持するうえで欠かせないツールです。まず「カバレッジ」レポートで「送信されたURLにリダイレクトがあります」という項目が急増していないかを確認し、適切に301転送されているかを把握します。
次に「リンク」レポートで外部被リンクが旧URLに集中していないかチェックし、主要なリンク元には連絡を取って新URLへ修正してもらうと評価の漏れを防げます。
さらに「URL検査ツール」を活用し、検査ボタンから「ページをインデックス登録」リクエストを送ることでクロール再実行を促進できます。
- 「ページエクスペリエンス」指標でCore Web Vitalsが悪化していないか併せて監視。
- サイトマップは転送後すぐに新旧の両方を送信し、Googlebotに変更を周知。
- カバレッジの「除外」欄に旧URLが大量に出た場合は、転送ループやチェーンのサイン。
- 週1回ダッシュボードをチェックし、異常値はメール通知で即確認。
- 主要KPIは「クリック数」「合計表示回数」「平均掲載順位」を旧URL移行前後で比較。
まとめ
リダイレクトは旧URLから新URLへユーザーと検索評価を無駄なく引き継ぐ基本施策です。
301・302を状況に応じて選び、ApacheやNginxの設定ファイル、WordPressプラグインで正しく実装すればSEO低下や転送ループを防げます。最後にチェッカーで動作を確認し、Search Consoleで監視すれば、移転やHTTPS化も安心して進められます。