WordPressのリダイレクト設定で失敗しない方法｜301と302の違いも解説

WordPressのリダイレクト設定は、古いURLを新しいURLへ案内する重要な作業です。しかし301と302を目的に合わず選んだり、転送元と転送先を逆にしたりすると、検索評価の引き継ぎに時間がかかり、リダイレクトループでサイトへ入れなくなることがあります。

結論から言うと、ページ移転やURL変更が恒久的なら301、一時的なキャンペーン切り替えや短期メンテナンスなら302が基本です。設定前にURL対応表とバックアップを作り、設定後はブラウザ表示だけでなくHTTPステータスと転送回数まで確認してください。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・修正・復旧に携わっている、よこやま良平です。現場では、設定そのものよりも、古いルールの残存、キャッシュ、正規化設定との競合で転送が複雑になるケースを多く見てきました。

リダイレクトは見た目で成功しても、内部で複数回転送されることがあります。同じURLへ複数の方法を重ねず、管理する層を一つに決めてください。

この記事では初心者向けに判断順と設定例を示します。必ずバックアップを取り、サーバー仕様が分からない時は本番へ直接書き込まないでください。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressの301と302リダイレクトの違いを理解する

WordPressで301と302を選ぶ基準は、転送が恒久的か一時的かです。期間の長さだけでなく、元のURLへ戻す予定があるか、検索結果でどちらのURLを主役にしたいかまで決めると迷いません。

301は古いURLを今後使わない恒久的な転送

301は「このページは恒久的に移動した」という意味のHTTPステータスです。記事のスラッグ変更、サイト移転、重複ページの統合、常時SSL化でHTTPからHTTPSへ統一する場合など、旧URLへ戻さない変更に使います。

検索エンジンには、新しいURLを正規のページとして扱うよう伝えます。内容の対応関係、内部リンク、サイトマップ、canonicalなど他のシグナルも新URLへ統一する必要があります。

302は元のURLへ戻す予定がある一時的な転送

302は「一時的に別の場所へ案内している」という意味です。短期間のメンテナンス、在庫切れ中の代替案内、期間限定ページへの誘導、切り替え前の検証など、後で元URLを再び使う予定がある場面に向きます。

恒久移転なのに302を長期間使うと、検索エンジンへ意図が伝わりにくくなります。反対に、一時切り替えへ301を使うと、ブラウザやCDNに強くキャッシュされ、元へ戻した後も古い転送が残ったように見えることがあります。

転送コードは期間ではなく戻す予定と目的で決める

「一週間なら302、一か月なら301」のように日数だけで決めるのは危険です。数日でも旧URLを廃止するなら301が適切ですし、数か月でも元URLへ戻す計画が明確なら302を選ぶ余地があります。

WordPressサイト引越しのやり方｜初心者向け完全解説

WordPressのリダイレクト設定前に準備するもの

WordPressのリダイレクト設定で失敗を防ぐには、操作前に転送元・転送先・目的・解除条件を一覧化します。一行だけの変更でも、現在の設定と戻し方が分からなければ、障害時に原因を切り分けられません。

転送元と転送先を完全なURLで対応させる

URL対応表には、転送元、転送先、コード、設定理由、設定日、担当者を記録します。末尾のスラッシュ、wwwの有無、HTTPとHTTPS、クエリ文字列も確認してください。

転送先は必ず実際に開き、公開状態と内容を確認します。存在しない新URLへ転送すると、利用者は移動した直後に404へ到達します。内容が無関係なトップページへ大量転送するより、対応するページがなければ適切な404を返す方がよい場合もあります。

WordPressとサーバーのバックアップを取る

プラグインだけで設定する場合も、データベースのバックアップを取ります。.htaccessやNginx設定を変更する場合は、変更直前の設定ファイルを日時付きで保存し、管理画面へ入れない時にSFTPやサーバーパネルから戻せる状態にしてください。

バックアップは「ある」だけでは不十分です。保存場所、対象日時、復元担当者、復元手順を確認します。本番サイトで試す前にステージング環境を用意できるなら、同じURL構造と主要プラグインで競合を確認しておくと安全です。

既存の転送・SSL・キャッシュ設定を洗い出す

WordPressプラグイン、.htaccess、Nginx、レンタルサーバーの転送機能、CDN、WAF、ロードバランサーなど、転送を行える場所は複数あります。さらにWordPressアドレスとサイトアドレス、常時SSL化、www統一、末尾スラッシュ統一もURLを書き換えます。

同じ転送を複数箇所へ重ねると、片方を削除しても別の設定が残り、運用担当者が原因を見失います。現在どこが最初に応答しているかを確認し、原則として一つの管理方法へ集約してください。

内部リンクと外部連携の影響範囲を確認する

記事本文、メニュー、ボタン、画像、構造化データ、サイトマップに旧URLが残ると、閲覧のたびに転送が発生します。リダイレクトは保険として残しながら、管理できる内部リンクは新URLへ直接変更するのが基本です。

広告、メール、SNS、QRコード、アクセス解析、Webhook、決済、外部APIも確認します。転送後も開けるから大丈夫と判断せず、POST通信や計測パラメータが失われないか、外部サービス側でURL変更が必要かを確認してください。

1. 完全な転送元URLと転送先URLを対応表へ記録する
2. 301・302の理由と元へ戻す条件を決める
3. データベースと設定ファイルをバックアップする
4. 既存の転送・SSL・キャッシュ・正規化設定を確認する
5. 内部リンクと外部サービスへの影響を洗い出す

WordPress修正の依頼前チェックリスト｜原因を切り分ける方法

WordPressでリダイレクトを安全に設定する方法

WordPressのリダイレクトは、初心者なら履歴とテスト機能のある信頼できるプラグイン、サーバー管理に慣れているならWebサーバー設定で行うのが基本です。複数の方法を同じURLへ同時に使わないでください。

プラグインは転送元と転送先を一件ずつ登録する

リダイレクト管理プラグインでは、転送元の相対パス、転送先URL、HTTPコードを入力します。最初は正規表現や一括ルールを使わず、一件だけ登録してテストしてください。正常なら対象を少しずつ追加し、変更履歴を残します。

プラグインは管理画面で確認しやすい反面、停止・削除すると転送も消える場合があります。テーマ変更とは独立して管理できるものを選び、更新状況、対応WordPress版、権限、ログに個人情報が残らないかを確認します。

Apacheの.htaccessは既存ルールの位置を確認する

Apache環境では.htaccessへ転送ルールを書けます。ただしWordPressが自動生成する範囲へ直接混ぜると、パーマリンク設定の保存で書き換えられる可能性があります。変更前ファイルを保存し、サーバーの仕様書に従って管理してください。

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

この例は旧パスを新URLへ301転送する基本形です。実際にはサブディレクトリ、エスケープ、既存のRewriteRule、HTTPからHTTPSへの統一ルールとの順序で結果が変わります。コピーしたまま本番へ貼らず、自分のURL構造に合わせて一件ずつ検証します。

Nginxはサーバー設定を変更して再読み込みする

Nginxでは.htaccessを使いません。サーバー設定ファイルへreturnまたはrewriteを設定し、構文テスト後に設定を再読み込みします。共有サーバーでは利用者が直接変更できないことがあるため、管理画面の転送機能かサポート窓口を利用してください。

location = /old-page/ {
    return 301 https://example.com/new-page/;
}

Nginx設定を誤るとサイト全体が起動しない可能性があります。操作権限があることと、安全に変更できることは別です。設定ファイルの場所、構文テスト、再読み込み、ロールバック手順を説明できない場合は専門担当者へ依頼してください。

テーマのfunctions.phpへ直接書く方法は避ける

functions.phpでwp_redirectを実行する方法もありますが、テーマ変更やPHPエラーの影響を受け、管理画面まで巻き込む条件を書きやすいため、URL移転の恒久管理には向きません。アプリケーション処理として必要な場合も、条件、権限、nonce、送信前の処理を設計します。

単純なURL転送なら、専用プラグインまたはWebサーバー層へ集約する方が追跡しやすくなります。選んだ方法、ルールの保存場所、解除方法、担当者をURL対応表へ追記してください。

WordPressのSSL化後にログインできない？簡単に解決する方法

WordPressのリダイレクトで起きやすい失敗を防ぐ

WordPressのリダイレクト失敗は、コードの選択ミスより、条件の広げすぎ、転送先の再転送、キャッシュ、旧ルールの残存で起きやすいです。設定後に一度開けたことだけで完了とせず、経路全体を確認します。

転送元と転送先が同じ条件に入るとループする

旧URLから新URLへ転送した後、新URLも同じルールに一致して旧URLまたは自分自身へ戻ると、ブラウザは「リダイレクトが繰り返し行われました」と表示します。ドメイン統一、HTTPS化、末尾スラッシュ統一を別々に設定した時も発生します。

ループが起きたら新しいルールを追加して打ち消そうとせず、直前の変更を戻します。その後、ブラウザキャッシュ、CDN、プラグイン、サーバー設定を一層ずつ確認し、どの応答で元へ戻っているかを調べてください。

WordPressのリダイレクトループ・URLエラーの解決まとめ【初心者向け】

AからB、BからCの転送チェーンを残さない

URLを複数回変更すると、AからB、BからCという転送チェーンができます。利用者は最終ページへ着けても、応答時間が増え、途中のルールや証明書が壊れると到達できません。AからCへ直接転送し、内部リンクもCへ更新します。

複数ドメインの移転では、旧ドメインのSSL証明書が切れるとHTTPSの旧URLへアクセスした時点で警告が出て、転送まで進めないことがあります。リダイレクトを残す期間は、旧ドメインと証明書の維持計画も含めて決めてください。

正規表現とワイルドカードを広げすぎない

正規表現は多数URLをまとめられますが、管理画面、ログイン、画像、APIまで対象にするとサイト全体へ影響します。入力文字列の一部が意図せず一致し、関係のないページを同じ転送先へ送ることもあります。

最初は完全一致で一件を確認し、必要なURL群を具体的に列挙します。正規表現を使う場合は、一致する例と一致してはいけない例を用意し、ステージングで両方をテストします。

クエリ文字列と計測パラメータを落とさない

広告やメールのURLには、流入元を識別するクエリ文字列が付いていることがあります。転送設定によっては引き継がれず、アクセス解析でキャンペーン効果を測れなくなります。反対に、不要なパラメータをそのまま連結して重複URLを増やす場合もあります。

商品IDや検索条件など動作に必要な値、広告計測値、削除すべき値を分けてください。テストではパラメータなしだけでなく、代表的なパラメータ付きURLも開き、最終URLと計測結果を確認します。

キャッシュで古い転送が残っているように見える

301はブラウザ、CDN、キャッシュプラグインに保持されることがあります。設定を直しても同じ端末では古い転送が続き、修正が効いていないように見えるため、シークレットウィンドウや別端末、コマンドで応答を確認します。

キャッシュ削除はブラウザだけでなく、WordPressプラグイン、サーバー、CDNの順に対象を確認します。ただし障害中に全キャッシュを何度も消すと状況を追いにくくなるため、変更と削除の時刻を記録してください。

Webページがうまく表示されない？キャッシュ削除で解決！

WordPressのリダイレクト設定後に確認する手順

WordPressのリダイレクト設定後は、転送元・転送先・HTTPコード・転送回数・主要機能を順番に確認します。ブラウザの見た目、サーバー応答、検索エンジン向け設定を分けて検証することが重要です。

転送元URLを未ログイン状態で開く

まずシークレットウィンドウで転送元URLを直接入力し、目的のページへ着くか確認します。ログイン中だけ有効なCookieや管理者向けキャッシュが結果を変えることがあるため、未ログイン状態を基準にしてください。

パソコンとスマートフォン、wwwあり・なし、HTTP・HTTPS、末尾スラッシュあり・なしのうち、実際に利用される入口を確認します。すべてを別ルールで増やすのではなく、最終的に一つの正規URLへ直接到達することが目標です。

HTTPヘッダーでステータスとLocationを確認する

コマンドを使える場合は、ヘッダーだけを取得すると転送コードとLocationを確認できます。最初の応答が301か302か、Locationが予定した完全URLかを見ます。認証情報や個人情報を含むURLは外部チェックサービスへ入力しないでください。

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

一つ目は最初の応答、二つ目は転送をたどった結果を確認する例です。-Lで最終ページが表示されても、途中に不要な転送がないとは限りません。詳細出力やブラウザ開発者ツールで各応答を確認し、できるだけ一回の転送に整理します。

内部リンク・サイトマップ・canonicalを新URLへ統一する

リダイレクトが正常でも、サイト内リンクが旧URLのままでは毎回余分な転送が発生します。メニュー、本文、ボタン、パンくず、関連記事、画像リンク、構造化データを新URLへ更新します。

XMLサイトマップには新URLだけを載せ、canonicalも新URL自身を指すよう確認します。旧URLを検索エンジンから消したいからとrobots.txtで先に遮断すると、転送を確認しにくくなる場合があります。クロール可能な301を保ち、移行状況を監視してください。

フォーム・ログイン・決済・APIを操作して確認する

トップページと記事が開くだけでは、サイト全体の確認になりません。問い合わせ送信、ログイン、パスワード再設定、決済、会員ページ、REST API、Webhookなど、URLとHTTPメソッドに依存する機能をテストします。

異常があれば、エラーメッセージ、発生時刻、操作手順、転送前後URL、HTTPコードを記録します。推測でルールを追加せず、直前の変更を戻せる状態を保ったまま原因を一つずつ切り分けます。

数日から数週間は404と転送ログを監視する

公開直後に問題がなくても、検索結果、古いブックマーク、外部リンクから時間差でアクセスが来ます。404ログ、転送ヒット数、アクセス解析、Search Consoleのクロール状況を確認し、対応表に漏れた重要URLを見つけます。

ログにはIPアドレスやURLパラメータなどの情報が含まれる場合があります。保存期間と閲覧権限を決め、目的なく長期保存しないでください。追加したルールにも理由と確認結果を残します。

WordPressのリダイレクト設定に関するよくある質問

WordPressのリダイレクトを設定する時によくある疑問を、判断と運用の観点からまとめます。

WordPressの301・302リダイレクト設定まとめ

WordPressのリダイレクトは、恒久移転なら301、一時的な案内なら302が基本です。設定前にURL対応表、バックアップ、既存の転送・SSL・キャッシュ設定を確認し、一つの管理方法へ集約してください。

よこやま良平が実務で重視するのは、戻し方を用意してから一件ずつ設定し、HTTP応答と主要機能まで確認することです。転送は「目的ページが開いた」で終わりではありません。内部リンクを新URLへ直し、不要なチェーンをなくし、公開後の404とログを監視して完了です。

WordPressの転送トラブルを自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で