WordPressリダイレクトの設定方法完全ガイド|301・プラグイン・エラー対処まで解説
はじめに
WordPressサイトを運営していると、記事URLの変更、パーマリンク構造の見直し、HTTPS化、ドメイン移転などにより、古いURLから新しいURLへ訪問者を転送する必要が生じます。この転送処理が「リダイレクト」です。
適切なリダイレクトを設定すれば、ユーザーを目的のページへ案内できるだけでなく、旧URLが蓄積してきた被リンクや検索評価を新URLへ引き継ぐためのシグナルにもなります。反対に、設定を誤ると404エラーやリダイレクトループが発生し、ユーザー体験やSEOに悪影響を及ぼす可能性があります。
本記事では、WordPressリダイレクトの基本から、301・302の違い、プラグイン「Redirection」や.htaccessを使った設定方法、エラーの対処法、SEO上の注意点まで詳しく解説します。
1. WordPressのリダイレクトとは
1-1. リダイレクトの仕組み
リダイレクトとは、ユーザーや検索エンジンが特定のURLへアクセスしたときに、別のURLへ自動的に転送する仕組みです。
たとえば、次のように記事URLを変更したとします。
旧URL:
https://example.com/old-page/新URL:
https://example.com/new-page/旧URLにリダイレクトを設定すると、ユーザーがブックマークや検索結果から旧URLへアクセスしても、自動的に新URLへ移動します。
リダイレクトは、WebサーバーやWordPressがHTTPレスポンスとして「このページは別のURLへ移動した」というステータスコードと転送先URLを返すことで実行されます。
1-2. WordPressでリダイレクトが必要になるケース
WordPressでリダイレクトが必要になる代表的なケースは次のとおりです。
投稿や固定ページのスラッグを変更した
パーマリンク設定を変更した
複数の記事を1つの記事へ統合した
古い記事を削除し、代替ページへ案内したい
HTTPからHTTPSへ移行した
wwwあり・なしを統一した
サイトを別ドメインへ移転した
カテゴリーやディレクトリ構造を変更した
キャンペーンページを一時的に別ページへ転送したい
URLが変わるにもかかわらずリダイレクトを設定しないと、旧URLへアクセスしたユーザーには404エラーが表示されます。サイト内のURLを変更するときは、旧URLへのアクセスが残っていないか確認することが重要です。
1-3. リダイレクトを設定しない場合のSEO・ユーザーへの影響
リダイレクトを設定しない場合、旧URLが獲得していた被リンクや検索評価を新URLへ適切に引き継げない可能性があります。また、検索結果、外部サイト、SNS、ブックマークなどに旧URLが残っていると、訪問者は404ページへ到達します。
主な影響は次のとおりです。
検索流入が減少する
被リンクからの訪問者を失う
ユーザーが目的の情報を見つけられない
サイトの信頼性が低下する
クロール対象に不要な404 URLが増える
コンバージョンの機会を失う
Googleは、恒久的なリダイレクトを転送先URLが正規URLであることを示すシグナルとして利用します。URLを恒久的に変更した場合は、旧ページと内容が対応する新ページへ適切に転送しましょう。
2. WordPressで使われるリダイレクトの種類
2-1. 301リダイレクト:恒久的なURL変更
301リダイレクトは、ページやサイトが恒久的に移転したことを示すリダイレクトです。
次のようなケースで使用します。
記事URLを今後元に戻さない
古い記事を新しい記事へ統合した
ドメインを恒久的に変更した
HTTPからHTTPSへ完全移行した
wwwあり・なしを恒久的に統一した
SEOを目的としたURL変更では、基本的に301リダイレクトを使用します。検索エンジンは旧URLではなく、転送先の新URLを正規URLとして扱う方向で処理します。
2-2. 302リダイレクト:一時的なURL変更
302リダイレクトは、転送が一時的であることを示します。
利用例は次のとおりです。
ページのメンテナンス中だけ別ページへ案内する
短期間のキャンペーンページへ転送する
A/Bテストを実施する
一時的な在庫切れで代替ページを表示する
将来的に元のURLへ戻す予定がある場合は302を選択します。Googleも、A/Bテストのような一時的な転送では301ではなく302を使用するよう案内しています。
2-3. 307・308リダイレクトとの違い
307と308もHTTPリダイレクトのステータスコードです。
| ステータスコード | 意味 | 主な用途 |
|---|---|---|
| 301 | 恒久的な移転 | URL変更、サイト移転、HTTPS化 |
| 302 | 一時的な移転 | メンテナンス、テスト、一時転送 |
| 307 | 一時的な移転 | HTTPメソッドを維持した一時転送 |
| 308 | 恒久的な移転 | HTTPメソッドを維持した恒久転送 |
307と308は、POSTなどのHTTPメソッドとリクエスト内容を維持したまま転送することを明確に示します。一方、301や302は、ブラウザや実装によってPOSTがGETへ変換されることがあります。
一般的なWordPressの記事URL変更では301または302が広く使われます。フォーム送信やAPI通信を含む転送では、307・308の利用も検討します。
2-4. 301と302の使い分け方
301と302は、「元のURLへ戻す予定があるか」で判断すると分かりやすくなります。
恒久的な変更であれば301、一時的な変更であれば302です。
判断に迷う場合は、次の質問を確認してください。
今後も新URLを使い続けるか
元のページを再公開する予定があるか
検索結果を新URLへ置き換えたいか
一時的なテストやメンテナンスではないか
「検索順位を維持したいから、とりあえず301にする」のではなく、変更の実態に合ったステータスコードを選ぶことが重要です。
3. WordPressで301リダイレクトを設定する方法
3-1. プラグインを使って設定する
初心者に最も取り組みやすいのが、リダイレクト管理プラグインを使う方法です。
代表的なプラグインとして「Redirection」があります。管理画面から旧URLと新URLを入力するだけで301リダイレクトを設定でき、404エラーや転送ログも確認できます。正規表現を使った複数URLの一括転送にも対応しています。
コードを直接編集する必要がないため、数件から数百件程度のリダイレクトを管理したいサイトに適しています。
3-2. .htaccessを編集して設定する
Apacheサーバーを利用している場合は、WordPressのルートディレクトリにある「.htaccess」ファイルへ転送ルールを記述できます。
WordPressがページを生成する前のサーバーレベルで処理できる点がメリットです。ただし、記述を間違えるとサイト全体に500エラーが発生する可能性があります。
なお、Nginxでは.htaccessを使用しません。Nginx環境ではサーバー設定ファイルやホスティングサービスの管理画面から設定します。
3-3. functions.phpを使って設定する
テーマのfunctions.phpへコードを追加し、特定の条件でリダイレクトする方法もあります。
add_action( 'template_redirect', function () { if ( is_page( 'old-page' ) ) { wp_safe_redirect( home_url( '/new-page/' ), 301 ); exit; } });template_redirectは、WordPressが表示するテンプレートを決定する直前に実行されるため、ページの条件に応じたリダイレクトに利用できます。wp_safe_redirect()は、許可されたホストへの安全な転送を行う関数です。
リダイレクト関数を実行した後は、後続処理を停止するためにexit;を記述します。
functions.phpを直接編集すると、テーマ変更やアップデートで設定が失われる可能性があります。子テーマまたは自作プラグインへ記述する方法が安全です。
3-4. サーバーの管理画面から設定する
レンタルサーバーによっては、管理画面にURL転送やリダイレクト設定機能が用意されています。
画面上で次の項目を指定するだけで設定できる場合があります。
転送元URL
転送先URL
301または302
HTTPからHTTPSへの転送
wwwあり・なしの統一
サーバーごとに機能や名称が異なるため、利用中のサービスのマニュアルを確認してください。CDNやリバースプロキシを利用している場合は、サーバー側よりCDN側の転送機能を使ったほうが適切なこともあります。
3-5. 設定方法ごとのメリット・デメリット
| 設定方法 | メリット | デメリット |
| プラグイン | 操作しやすく、ログを管理できる | プラグインへの依存が増える |
| .htaccess | サーバーレベルで処理できる | 記述ミスでサイト障害が起こりやすい |
| functions.php | WordPressの条件分岐を利用できる | テーマ変更やPHPエラーの影響を受ける |
| サーバー管理画面 | コード編集が不要 | サーバーによって機能が異なる |
少数のURLを手軽に管理するならプラグイン、ドメイン全体やHTTPS化を処理するならサーバー機能や.htaccessが候補になります。
4. プラグイン「Redirection」でリダイレクトを設定する手順
4-1. Redirectionをインストール・有効化する
WordPress管理画面へログインし、次の手順でインストールします。
「プラグイン」から「新規プラグインを追加」を開く
検索欄に「Redirection」と入力する
Redirectionの「今すぐインストール」をクリックする
インストール後に「有効化」をクリックする
「ツール」から「Redirection」を開く
同名または類似名のプラグインがあるため、名称と開発者情報を確認してからインストールしましょう。
4-2. 初期設定を完了する
初回起動時には、セットアップ画面が表示されます。案内に従って初期設定を進めます。
設定項目には、投稿や固定ページのパーマリンク変更を監視する機能や、リダイレクト・404エラーのログ記録などがあります。
ログはトラブルの発見に役立ちますが、長期間保存するとデータベース容量が増える可能性があります。Redirectionでは、ログの保存期間を設定したり、ログを無効化したりできます。
IPアドレスを記録する設定を利用する場合は、必要性、保存期間、プライバシーポリシーも確認してください。
4-3. 個別ページに301リダイレクトを設定する
基本的な設定手順は次のとおりです。
「ツール」から「Redirection」を開く
リダイレクトの追加欄を表示する
「ソースURL」に旧URLのパスを入力する
「ターゲットURL」に新URLを入力する
HTTPコードで301を選択する
「転送ルールを追加」または追加ボタンをクリックする
設定例は次のとおりです。
ソースURL:
/old-page/ターゲットURL:
https://example.com/new-page/同一ドメイン内であれば、ターゲットURLを次のような相対パスで指定できる場合もあります。
/new-page/設定後は必ず旧URLへアクセスし、正しいページへ転送されるか確認してください。
4-4. 正規表現を使って複数URLを一括転送する
複数のURLに共通したパターンがある場合は、正規表現を使って一括転送できます。
たとえば、次の旧ディレクトリを新ディレクトリへ移動するとします。
/old-category/apple//old-category/orange//old-category/banana/転送先:
/new-category/apple//new-category/orange//new-category/banana/ソースURLに次のパターンを設定します。
^/old-category/(.*)$ターゲットURLには次のように入力します。
/new-category/$1正規表現のオプションを有効にすると、(.*)に一致した部分が$1へ引き継がれます。Redirectionは、正規表現による複数URLのマッチと、キャプチャした文字列の転送先への埋め込みに対応しています。
正規表現が広すぎると、意図しないURLまで転送したり、転送先が再び同じルールに一致してループしたりします。少数のURLでテストしてから本番運用してください。
4-5. 404エラーの発生状況を確認する
Redirectionでは、サイト内で発生した404エラーを確認できます。
管理画面の「404」または404ログを開き、次の項目を確認します。
404になったURL
発生日時
アクセス回数
参照元URL
ユーザーエージェント
アクセス回数が多いURLや、内部リンクからアクセスされているURLを優先的に調査します。
ただし、404ログに表示されたURLをすべてリダイレクトする必要はありません。存在したことがなく、代替ページもないURLには404が正しいレスポンスです。
4-6. リダイレクトのアクセスログを確認する
リダイレクトされたURLへのアクセスは、ログ画面から確認できます。Redirectionのログでは、アクセスされたURL、転送先、日時、参照元、HTTPメソッドなどを確認できます。
ログを確認することで、次のような問題を発見できます。
旧URLへのアクセスが長期間残っている
内部リンクが旧URLのままになっている
想定外のURLがルールに一致している
不要なボットアクセスが集中している
転送先のURLを再変更する必要がある
ログを無期限で保存する必要がなければ、保存期間を設定してデータベースの肥大化を防ぎましょう。
5. .htaccessで301リダイレクトを設定する方法
5-1. .htaccessを編集する前の準備とバックアップ
.htaccessは、Apacheサーバーの動作を制御する重要なファイルです。編集前に必ずバックアップしてください。
主な準備は次のとおりです。
FTPソフトまたはサーバーのファイルマネージャーを用意する
WordPressのルートディレクトリを開く
隠しファイルを表示する
.htaccessをダウンロードして保存する
サイトと管理画面が正常に開くことを確認する
WordPressの標準ルールには、通常次のようなコメントがあります。
# BEGIN WordPress...# END WordPress独自のリダイレクトルールは、原則として# BEGIN WordPressより前に記述します。WordPressの設定更新によって、BEGINからENDまでの内容が書き換えられることがあるためです。
5-2. 特定のページを別のページへ転送する記述例
特定の旧ページを新ページへ転送する基本例です。
Redirect 301 /old-page/ https://example.com/new-page/また、mod_rewriteを使う場合は次のように記述できます。
RewriteEngine OnRewriteRule ^old-page/?$ https://example.com/new-page/ [R=301,L]R=301は301リダイレクト、Lはそのルールに一致した時点で後続ルールの処理を終了する指定です。
5-3. ディレクトリ単位で転送する記述例
旧ディレクトリ以下のパスを維持したまま、新ディレクトリへ転送する例です。
RewriteEngine OnRewriteRule ^old-directory/(.*)$ /new-directory/$1 [R=301,L]たとえば、次のURLは、
https://example.com/old-directory/page-a/次のURLへ転送されます。
https://example.com/new-directory/page-a/5-4. ドメイン全体を新しいドメインへ転送する記述例
旧ドメインから新ドメインへ、パスを維持したまま転送する例です。
RewriteEngine OnRewriteCond %{HTTP_HOST} ^(?:www\.)?old-example\.com$ [NC]RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]旧URL:
https://old-example.com/category/page/新URL:
https://new-example.com/category/page/ドメイン移転では、旧ドメイン側のサーバーとSSL証明書を維持し、HTTPSの旧URLにもアクセスできる状態でリダイレクトを返す必要があります。
5-5. HTTPからHTTPSへリダイレクトする記述例
HTTPへのアクセスをHTTPSへ統一する例です。
RewriteEngine OnRewriteCond %{HTTPS} !=onRewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]ただし、ロードバランサー、CDN、リバースプロキシを利用している環境では、サーバーから常にHTTPアクセスとして認識されることがあります。その状態で上記ルールを使うとリダイレクトループが起きる可能性があります。
HTTPS化は、可能であればサーバーまたはCDNの管理画面で設定してください。
5-6. wwwあり・なしを統一する記述例
wwwなしへ統一する場合は、次のように記述します。
RewriteEngine OnRewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]wwwありへ統一する場合は、次のように記述します。
RewriteEngine OnRewriteCond %{HTTP_HOST} ^example\.com$ [NC]RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]HTTPS化とwww統一を別々のルールで処理すると、2回以上のリダイレクトが発生することがあります。可能であれば、アクセス元から最終URLへ1回で転送できるルールにまとめましょう。
5-7. .htaccess編集時の注意点
.htaccessを編集するときは、次の点に注意してください。
編集前に必ずバックアップする
WordPressの標準ルールより前に記述する
同じURLに複数のルールを設定しない
転送元と転送先を同一にしない
302でテストしてから301へ変更する方法も検討する
ブラウザやCDNのキャッシュを削除する
500エラーが出たら直前の変更を元に戻す
Nginx環境では使用しない
サーバー管理画面の転送設定と重複させない
301リダイレクトはブラウザにキャッシュされることがあります。検証中はシークレットモードや別ブラウザを利用すると確認しやすくなります。
6. ケース別のWordPressリダイレクト設定
6-1. 投稿・固定ページのURLを変更した場合
投稿や固定ページのスラッグを変更した場合は、旧URLから新URLへ1対1で301リダイレクトを設定します。
/old-service/ → /new-service/転送先は、旧ページと同じ内容または後継となるページにします。設定後は、メニュー、記事本文、パンくずリストなどの内部リンクも新URLへ変更してください。
6-2. パーマリンク構造を変更した場合
パーマリンクを次のように変更すると、サイト内の多くの投稿URLが一度に変わります。
変更前:
/2025/01/post-name/変更後:
/post-name/この場合は、正規表現やサーバールールを使って旧構造から新構造へ転送します。ただし、投稿名の重複、日付、カテゴリー情報などを新URLだけでは特定できない場合があります。
パーマリンク変更前に、旧URLと新URLの対応表を作成し、重複や転送漏れを確認しましょう。
6-3. サイトを別ドメインへ移転した場合
ドメイン移転では、原則として旧サイトの各ページから、対応する新サイトの各ページへ301リダイレクトします。
適切な例:
old-example.com/service-a/↓new-example.com/service-a/避けたい例:
old-example.com/service-a/↓new-example.com/すべてのページを新サイトのトップページへ転送するのではなく、ページ単位で対応させることが重要です。
Googleは、ドメイン移転後のリダイレクトをできる限り長く、一般的には少なくとも1年間維持するよう案内しています。また、新しいサイトマップの送信や、Search Consoleのアドレス変更手続きも行います。
6-4. HTTPからHTTPSへ移行した場合
HTTPS化では、次の4種類のURLが存在することがあります。
http://example.com/http://www.example.com/https://example.com/https://www.example.com/正規URLを1つ決め、残りのURLを正規URLへ301リダイレクトします。
あわせて、次の項目も更新してください。
WordPressアドレス
サイトアドレス
内部リンク
画像URL
canonicalタグ
XMLサイトマップ
構造化データ
Search Consoleとアクセス解析の設定
6-5. wwwあり・なしを統一する場合
wwwあり・なしは、どちらか一方へ統一します。
SEO上、どちらを選んだから有利になるというものではありません。重要なのは、リダイレクト、内部リンク、canonicalタグ、サイトマップで同じURL形式を使用することです。
Googleも、優先するURL形式を決め、内部リンクやサイトマップで一貫して使用し、重複するURLから優先URLへリダイレクトする方法を案内しています。
6-6. 複数の古いURLを1つのページへ転送する場合
複数の記事を1つの包括的な記事へ統合した場合は、それぞれの旧URLから統合先へ301リダイレクトします。
/old-page-a/ → /complete-guide//old-page-b/ → /complete-guide//old-page-c/ → /complete-guide/ただし、内容に関連性がないページを同じURLへまとめて転送するのは避けてください。旧ページの検索意図を新ページが十分に満たしているか確認します。
6-7. 404ページを関連ページへ転送する場合
過去に存在したページを削除し、明確な代替ページがある場合は、その関連ページへ301リダイレクトします。
代替ページがない場合は、無理にリダイレクトせず404または410を返すことも適切です。すべての404ページをトップページへ転送すると、ユーザーが探していた情報に到達できず、検索エンジンからソフト404と判断される可能性があります。
404ログは「すべて修正する作業一覧」ではありません。被リンク、内部リンク、アクセス数、代替コンテンツの有無を確認して対応を決めましょう。
6-8. 外部サイトへリダイレクトする場合
WordPressから外部サイトへ転送することも可能です。
https://example.com/old-campaign/↓https://external-example.net/new-campaign/外部転送では、次の点を確認してください。
転送先サイトを信頼できるか
転送先URLが将来も維持されるか
オープンリダイレクトの脆弱性がないか
ユーザーの意図に合っているか
アフィリエイトや広告に関する表記が必要でないか
ユーザーが入力したURLを検証せずに転送先へ使用すると、悪意のある外部サイトへの誘導に利用される可能性があります。
7. WordPressのリダイレクトができない原因と対処法
7-1. リダイレクトループが発生する
リダイレクトループとは、URLが相互に転送され続ける状態です。
URL A → URL B → URL Aまたは、同じURL自身へ転送している場合にも発生します。
確認するポイントは次のとおりです。
転送元と転送先が同じになっていないか
プラグインと.htaccessで同じ転送を設定していないか
HTTP・HTTPSの判定が正しいか
www統一ルールが反対方向に重複していないか
CDNとサーバーで異なる転送を設定していないか
正規表現が転送先にも一致していないか
正規表現では、^や$を使って一致範囲を限定することでループを防げる場合があります。
7-2. 「ERR_TOO_MANY_REDIRECTS」が表示される
「ERR_TOO_MANY_REDIRECTS」は、ブラウザが過剰なリダイレクトを検出したときに表示されます。
対処手順は次のとおりです。
ブラウザのCookieとキャッシュを削除する
WordPressのリダイレクトプラグインを一時停止する
.htaccessを初期状態へ戻す
WordPressアドレスとサイトアドレスを確認する
サーバーやCDNのHTTPS設定を確認する
転送経路をHTTPヘッダー確認ツールで調べる
管理画面へ入れない場合は、FTPやファイルマネージャーからプラグインのフォルダ名を変更し、プラグインを強制的に無効化できます。
7-3. リダイレクト先が404エラーになる
リダイレクト自体が動作していても、転送先URLが存在しなければ404エラーになります。
次の点を確認してください。
転送先URLに入力ミスがないか
投稿が公開状態になっているか
末尾のスラッシュが影響していないか
パーマリンク設定が正常か
転送先を再変更していないか
大文字と小文字が一致しているか
転送先URLをブラウザへ直接入力し、リダイレクトを経由せず正常に表示できるか確認しましょう。
7-4. .htaccessの記述が反映されない
.htaccessが反映されない場合は、次の原因が考えられます。
サーバーがNginxである
.htaccessの利用が許可されていない
編集しているファイルの場所が違う
ファイル名が
.htaccess.txtになっているWordPressの標準ルールより後ろに記述している
mod_rewriteが利用できない
サーバーやCDNのキャッシュが残っている
WordPress管理画面の「設定」から「パーマリンク」を開き、設定を変更せずに保存すると、標準のリライトルールが再生成される場合があります。実行前に現在の.htaccessをバックアップしてください。
7-5. プラグイン同士が競合している
SEOプラグイン、SSL化プラグイン、キャッシュプラグイン、セキュリティプラグインには、リダイレクト機能が含まれていることがあります。
複数のプラグインで同じURLを管理すると、競合やループの原因になります。
一時的にプラグインを停止し、問題が解消するか確認してください。本番サイトで停止するのが難しい場合は、ステージング環境で検証します。
7-6. キャッシュが残っている
正しい設定へ変更しても、古い301リダイレクトがキャッシュされていると、変更前の転送が続くことがあります。
削除対象は次のとおりです。
ブラウザキャッシュ
WordPressキャッシュ
サーバーキャッシュ
CDNキャッシュ
プロキシキャッシュ
シークレットモードだけでは、CDNやサーバー側のキャッシュは回避できません。それぞれの管理画面でキャッシュを削除してください。
7-7. WordPressアドレスとサイトアドレスが一致していない
「設定」の「一般」にある次の項目が不適切だと、管理画面やサイト全体でリダイレクトループが発生することがあります。
WordPressアドレス(URL)
サイトアドレス(URL)
通常は、HTTP・HTTPS、wwwあり・なしを含めて同じ形式にします。ただし、WordPress本体をサブディレクトリへ設置している場合は、2つのURLが異なる構成もあります。
管理画面へ入れない場合は、環境に合うことを確認したうえで、wp-config.phpへ次のように一時指定できます。
define( 'WP_HOME', 'https://example.com' );define( 'WP_SITEURL', 'https://example.com' );設定値を誤ると状況が悪化するため、事前にバックアップを取得してください。
7-8. SSL設定やサーバー設定に問題がある
HTTPS化後のループは、WordPressではなく、SSL、CDN、プロキシ、ロードバランサーの設定が原因であることもあります。
特に、CDNの接続モードが「ブラウザからCDNまではHTTPS、CDNからサーバーまではHTTP」となっている場合、WordPressやサーバーがHTTPアクセスと判断してHTTPSへ転送し続けることがあります。
次の設定を確認してください。
SSL証明書が有効か
CDNからオリジンサーバーまでHTTPSで接続されているか
サーバーが転送元プロトコルを正しく判定できるか
HTTPS強制設定が重複していないか
HSTSを設定しているか
旧ドメインにも有効な証明書があるか
8. リダイレクトの動作を確認する方法
8-1. ブラウザで転送先を確認する
最も簡単な方法は、ブラウザのアドレスバーへ旧URLを入力することです。
次の点を確認します。
最終的に正しいURLが表示されるか
ページ内容が正常に表示されるか
URLが何度も切り替わっていないか
末尾のスラッシュなどが想定どおりか
パラメーターが必要に応じて引き継がれるか
表示できるだけでは301か302かを判断できないため、HTTPステータスコードも確認してください。
8-2. HTTPステータスコードを確認する
パソコンのターミナルでcurlを使用できる場合は、次のコマンドでレスポンスヘッダーを確認できます。
curl -I https://example.com/old-page/複数のリダイレクトを追跡する場合は次のように実行します。
curl -IL https://example.com/old-page/確認する主な項目は次のとおりです。
HTTP/2 301location: https://example.com/new-page/最初のレスポンスが301で、Locationヘッダーが正しい転送先になっているか確認します。
8-3. シークレットモードでキャッシュの影響を避ける
通常のブラウザで古い転送結果が表示される場合は、シークレットモードやプライベートブラウズを利用します。
ただし、シークレットモードで避けられるのは主にブラウザ側のCookieやキャッシュです。サーバー、WordPress、CDNのキャッシュが原因の場合は、それぞれを削除する必要があります。
8-4. Google Search Consoleでエラーを確認する
Google Search Consoleでは、URL検査やインデックス登録に関するレポートを使って、旧URLと新URLの状態を確認できます。
確認項目は次のとおりです。
旧URLがリダイレクトとして認識されているか
新URLがインデックス登録可能か
新URLのcanonicalが正しいか
サイトマップに新URLが含まれているか
クロールエラーが増えていないか
ドメイン移転後の検索流入に異常がないか
XMLサイトマップには、検索エンジンへ重要なURLを伝える役割があります。URL変更後は旧URLを削除し、新URLだけを掲載したサイトマップを送信しましょう。
8-5. リダイレクトチェーンやループを調べる
リダイレクトチェーンとは、最終ページへ到達するまでに複数回の転送が発生する状態です。
URL A → URL B → URL Cこの場合、URL AからURL Cへ直接転送するよう修正します。
URL A → URL CURL B → URL Ccurl -IL、ブラウザの開発者ツール、HTTPヘッダー確認ツールなどを使い、各ステータスコードとLocationヘッダーを確認してください。
9. WordPressでリダイレクトを設定する際のSEO上の注意点
9-1. 原則として恒久的なURL変更には301を使う
元のURLへ戻す予定がない場合は、301リダイレクトを使用します。
302のまま長期間運用しても検索エンジンが転送先を処理することはありますが、サイト運営者の意図を明確に伝えるため、恒久的な移転には恒久リダイレクトを設定するのが基本です。
9-2. 関連性の高いページへ転送する
旧ページからは、内容や検索意図が最も近いページへ転送します。
たとえば、特定商品の解説ページを削除した場合、無関係なトップページではなく、後継商品や同じカテゴリーの案内ページが候補です。
適切な転送先がない場合は、404または410を返すほうが自然なこともあります。
9-3. リダイレクトチェーンを作らない
URLを何度も変更すると、次のような転送が残りやすくなります。
旧URL → 以前の新URL → 現在のURLすべての旧URLから現在のURLへ直接転送するよう整理します。リダイレクト回数を減らすことで、ユーザーが最終ページへ到達するまでの遅延や、途中ルールの不具合を抑えられます。
9-4. すべての404ページをトップページへ転送しない
404を一律にトップページへ転送すると、ユーザーは探していた情報を見つけられません。また、存在しない多数のURLが同じトップページへ転送される不自然な状態になります。
404をリダイレクトするのは、過去に存在したURLであり、明確な代替ページがある場合を中心にしましょう。
9-5. 内部リンクとサイトマップも新URLへ更新する
リダイレクトを設定した後も、サイト内のリンクが旧URLのままでは、ページを移動するたびに転送が発生します。
次の場所を確認してください。
記事本文
グローバルメニュー
フッター
サイドバー
パンくずリスト
関連記事
ボタンやバナー
XMLサイトマップ
構造化データ
OGP設定
内部リンクはリダイレクトを経由させず、新URLへ直接リンクします。
9-6. canonicalタグとの矛盾を避ける
リダイレクト先ページのcanonicalタグが旧URLを指していると、検索エンジンへ矛盾したシグナルを送ることになります。
次のような状態は避けてください。
旧URL → 301 → 新URL新URLのcanonical → 旧URL新URLのcanonicalは、原則として新URL自身を指定します。Googleは、リダイレクトやcanonicalなど複数のシグナルを用いて代表URLを選択します。
9-7. リダイレクト設定を長期間維持する
検索エンジンやユーザーが旧URLへアクセスする可能性が残っている間は、リダイレクトを維持します。
Googleはサイト移転時のリダイレクトについて、可能な限り長く、一般的には少なくとも1年間維持することを推奨しています。ユーザーのブックマークや外部リンクを考慮すると、問題がなければさらに長期間残す方法が現実的です。
10. WordPressリダイレクトに関するよくある質問
10-1. 301リダイレクトはいつまで残すべき?
少なくとも1年間を目安とし、可能であればそれ以降も維持します。
検索エンジンの処理が完了した後も、外部サイトのリンク、古いメール、SNS投稿、ユーザーのブックマークから旧URLへアクセスされる可能性があります。旧ドメインを手放すとリダイレクトも停止するため、ドメイン移転では旧ドメインの維持費も考慮してください。
10-2. リダイレクトすると検索順位は下がる?
適切な301リダイレクトを設定しても、検索順位が必ず維持されるとは限りません。URL変更後は、検索エンジンが新URLをクロールし、評価やインデックスを処理するまで順位や流入が変動することがあります。
影響を抑えるには、次の対応が重要です。
内容が対応するページへ1対1で転送する
転送先の内容を大幅に変えない
リダイレクトチェーンを避ける
内部リンクとサイトマップを更新する
新URLをクロール可能にする
canonicalやnoindexを確認する
10-3. プラグインなしでも設定できる?
プラグインなしでも設定できます。
Apache環境では.htaccess、Nginx環境ではサーバー設定、WordPress内ではfunctions.phpや自作プラグインを利用できます。レンタルサーバーの管理画面に転送機能が用意されている場合もあります。
コード編集に慣れていない場合は、管理しやすいリダイレクトプラグインを利用する方法が安全です。
10-4. リダイレクト設定後も旧URLは削除してよい?
旧ページのコンテンツ自体は削除しても構いませんが、旧URLへのリダイレクト設定は残します。
旧URLへアクセスした際に、削除済みページの404が先に返されるのではなく、サーバーまたはWordPressが301を返す状態にしてください。旧URLをrobots.txtでブロックすると、検索エンジンがリダイレクトを確認できない場合があるため注意が必要です。
10-5. 404エラーはすべてリダイレクトすべき?
すべてをリダイレクトする必要はありません。
次の場合はリダイレクトを検討します。
過去に存在した重要ページである
被リンクやアクセスがある
URL変更後の旧URLである
明確な代替ページがある
内部リンクの入力ミスで発生している
存在したことがなく、代替ページもないURLは404のままで問題ありません。不審な文字列を含むURLや、脆弱性を探すボットのアクセスへ転送を設定する必要もありません。
10-6. リダイレクトの設定数が多いと表示速度に影響する?
影響の大きさは、設定方法、プラグインの実装、ルール数、サーバー性能、ログ設定などによって異なります。
大量の正規表現を毎回評価したり、すべての404アクセスを長期間記録したりすると、処理やデータベース容量へ影響する可能性があります。
次の対策が有効です。
不要なルールを削除する
重複ルールを統合する
正規表現の対象を限定する
ログの保存期間を設定する
ドメイン全体の転送はサーバー側で処理する
リダイレクトチェーンを解消する
大規模サイトではステージング環境で負荷を検証する
10-7. WordPressにログインできない場合はどう対処する?
リダイレクト設定後に管理画面へログインできなくなった場合は、FTPまたはサーバーのファイルマネージャーを利用します。
プラグインが原因と考えられる場合は、次のように対象プラグインのフォルダ名を変更します。
/wp-content/plugins/redirection/変更例:
/wp-content/plugins/redirection-disabled/これによりプラグインが強制的に無効化されます。
.htaccessが原因の場合は、現在のファイルをバックアップしたうえで、追加したリダイレクトルールを削除します。WordPressアドレスの設定ミスが原因の場合は、wp-config.phpまたはデータベースのhomeとsiteurlを確認します。
復旧後は、原因となった設定を特定し、同じ転送をプラグイン、サーバー、CDNなど複数の場所へ重複して設定しないよう整理してください。
まとめ
WordPressのリダイレクトは、URL変更後もユーザーを正しいページへ案内し、検索エンジンへページの移転を伝えるための重要な設定です。
恒久的なURL変更では301、一時的な転送では302を使用します。個別ページを手軽に管理するなら「Redirection」などのプラグイン、ドメイン全体の移転やHTTPS化ではサーバー管理画面や.htaccessが有力な選択肢です。
設定後は、ページが表示されることだけでなく、HTTPステータスコード、転送先、リダイレクト回数まで確認してください。特に、リダイレクトループ、チェーン、404への転送、canonicalタグとの矛盾には注意が必要です。
また、リダイレクトを設定しただけで作業を終わらせず、内部リンク、XMLサイトマップ、Search Consoleの情報も新URLへ更新しましょう。旧URLと関連性の高い新URLを1対1で対応させ、リダイレクトを長期間維持することが、ユーザー体験とSEOの両面で重要です。

