WordPressのリダイレクト設定｜301・302の使い分けと確認手順

WordPress
保守管理・運用

最終更新日：2026年10月10日

この記事の監修者

齊藤真也

株式会社ファーストネットジャパン代表取締役

1998 年創業時からアプリ開発・Web マーケティング・フルリモート SES・ホームページ制作・翻訳・グラフィックデザインなど幅広い IT／クリエイティブ領域を手がけ、4,000 件超のプロジェクトを統括。セキュリティ対策・SEO・システム開発から中小企業のWeb戦略支援まで、技術とデザインの両面でクライアントの課題解決を27年以上にわたり支援してきた。
大阪本社・東京オフィスの2拠点体制で、全国の企業のデジタル化をサポート。
高松市出身。座右の銘は「圧倒的努力」。

WordPressのリダイレクトは、移転したページの旧URLから新URLへ訪問者を案内する仕組みです。恒久的な変更なら301、一時的な変更なら302を基本に、設定する場所と転送先を決めます。管理画面でURLを変えるだけでは、古いリンクへの対応が十分とは限りません。この記事では、ページ単位のURL変更を中心に、設定方法の選び方・転送表・公開前後の確認手順を解説します。

WordPressで
お困りではありませんか？

WordPressのあれこれならお任せください。
ファーストネットジャパンでは、
1998年の創業から培ってきた知見・経験を基に
WordPressのお悩みを解決いたします。

実績豊富な
WordPressの制作・構築・管理なら
こちらからご相談ください

301と302はページ移転が恒久的か一時的かで選ぶ

種類	主な用途	確認すること
301：恒久的な転送	スラッグ変更、ページ統合、恒久的な移転	転送先が旧ページの内容や目的を引き継ぐか
302：一時的な転送	期限のある代替ページへの案内	戻す予定日と、元ページの復旧条件
転送しない	適切な代替ページがない削除	404・410など対象状態と案内内容

Googleは、恒久的なリダイレクトを転送先が正規URLになる強いシグナル、一時的なものを弱いシグナルとして扱うと説明しています。301にしただけで順位や流入が維持されるとは限らず、内容の対応とクロールの確認が必要です。詳しくはGoogleのリダイレクトと検索に関する公式資料をご覧ください。

削除した全ページをトップページへまとめて転送すると、利用者が探していた情報に到達できません。代替ページがない場合は、無理に301を作らず削除ページとしての適切な扱いを検討します。

実務で使える資料

ホームページリニューアル

要件整理シート

リニューアルの目的や現サイトの課題、新サイトに必要な内容を整理できる実務用シートにまとめました。

リニューアルの目的
必要な機能・CMS
現在のサイトの課題
予算・スケジュール
必要なページ・コンテンツ
制作会社へ伝える要件

リニューアル要件整理シートをダウンロード

フォーム入力後、メールでダウンロードURLをご案内します（PDF資料・無料）

WordPressのリダイレクト設定方法を選ぶ

方法	向いている範囲	担当者が確認すること
管理用プラグイン	少数〜複数ページの転送を運用担当が管理	更新状況、権限、条件、転送ログ、他の設定との重複
サーバー・CDN側の設定	ドメイン全体や大量の共通パターン	環境の種類、適用順、バックアップ、復旧方法
テーマ・独自コード	機能やログイン状態に応じた転送	開発担当による検証、許可する転送先、保守体制

Apache・Nginx・CDNなどで設定場所や書式が異なります。環境を確認せず別サイトの設定を貼り付けないでください。既存設定を保存し、検証環境で動作を確かめてから本番へ適用します。URL変更とドメイン・サーバー移行を同時に行う場合は、担当者と移行計画をまとめます。

プラグイン、サーバー、CDNで同じURLを別々に転送すると、ループや連続転送の原因になります。転送ルールの管理元を決め、誰が変更を承認するかも記録しましょう。

設定前に旧URLと新URLの対応表を作る

公開済みページ、検索流入、広告・メール・QRコード、被リンクなどから使われている旧URLを確認します。転送先は似たURLではなく、読者の目的を引き継ぐページを選びます。次の表は設定作業前の管理例です。実際のサイトURLと判断内容に置き換えて使ってください。

旧URLの例	新URLの例	理由・確認事項
/blog/old-guide/	/blog/new-guide/	記事移転。新ページが200で表示され、内容を引き継ぐ
/service/old-name/	/service/new-name/	サービス名称変更。広告・フォーム・計測も更新
/blog/duplicate-a/	/blog/main-guide/	記事統合。旧記事の必要情報を統合先で確認

転送の種類、対象URL、転送先、実施日、担当者を記録する
クエリ文字列を残すか、予約・計測に必要な値を確認する
末尾スラッシュ、http/https、www有無の既存ルールと揃える
転送先自体が別のURLへ転送されていないか確認する

パターン指定は便利ですが、対象外のページまで巻き込む可能性があります。まず個別URLで確認し、共通ルールを使う場合は「転送されるURL」と「転送されないURL」の両方を試験します。

公開前後はステータス・転送先・フォームを確認する

ブラウザで新ページが開くことだけでは、301か302か、何回転送されたかは分かりません。開発担当にHTTPステータスとLocationヘッダー、最終到達URLを確認してもらいます。転送先が正常な200レスポンスで表示され、意図したページになっているかをチェックします。

確認項目	完了条件
旧URLへのアクセス	予定した301/302と正しい転送先になる
転送先	200で表示され、不要な再転送やエラーがない
ループ・連続転送	旧URLへ戻らず、可能な範囲で最終URLへ直接転送する
対象外のページ	ログイン、フォーム、管理画面などを巻き込まない
訪問条件	スマートフォン・PC、ログイン有無、必要なクエリで確認
キャッシュ	変更前の転送が残っていないか条件を分けて確認

フォーム送信先や会員機能を含む場合は、通常の閲覧URLとは別に扱います。転送によって送信方法や入力内容が失われないかを開発担当が確認し、業務のテストまで実施してください。

内部リンク・サイトマップ・正規URLも新URLへ揃える

転送を設定した後も、サイト内のリンクが旧URLのままだと不要な転送が残ります。メニュー、本文、関連記事、パンくず、画像のリンク、広告のリンク先を確認し、新URLへ更新します。サイトマップとcanonical（正規URLの指定）も現在の公開URLと整合させます。

Search Consoleで新URLを検査し、取得・正規URL・登録状況を確認します。申請受付と実際の登録は別なので、旧URLと新URLの検索表示・クリックを継続して確認してください。旧URLがすぐ検索結果から消えない場合も、転送が正しく機能しているかを先に確かめます。

リニューアルでは「公開日に転送して終わり」ではなく、流入の多かった旧URLを点検リストへ残すことが重要です。転送の維持期間とサーバー契約の継続も、移転計画の段階で確認します。

ループや意図しない転送は管理元と変更履歴から調べる

https化の設定、WordPressのサイトURL、サーバー側ルール、プラグイン、CDNが同時に作用していないかを確認します。見つけた設定を一度に削除せず、担当者が検証環境や復旧可能な手順で切り分けます。ログインできない場合も、認証やキャッシュの症状と分けて調べてください。

独自開発では、WordPressのwp_safe_redirectの公式仕様などを確認して、許可する転送先と処理終了を検討します。関数を選ぶだけで運用上の安全が完成するわけではありません。身に覚えのない外部転送は、設定ミスと決めつけず改ざんの疑いも含めて保守担当へ連絡します。

URLを変える前に、変える理由と影響する導線を確認する

WordPressの記事タイトルを修正したからといって、公開済みのスラッグまで変更する必要があるとは限りません。URLが社内の資料、メール、名刺のQRコード、広告、外部の記事に使われていれば、変更後も旧URLへのアクセスが続きます。見た目をそろえるだけの変更なのか、サイト構造やサービス名の変更で必要なのかを先に整理してください。変更の理由が説明できれば、対象と確認範囲を絞りやすくなります。

例えば、サービスの名称変更でページを移す場合は、旧サービスの説明を新ページが引き継ぎ、問い合わせ先や契約案内も整合しているかを確認します。別のサービスへ誘導する目的で似たURLへ転送するだけでは、訪問者が求める情報を引き継げません。記事統合では旧記事の重要な論点を統合先に含めてから、転送を判断します。URLだけを先に変えると、公開内容と転送表の対応が崩れるため注意してください。

アクセスが少ないURLも利用経路を確認する

アクセス解析で閲覧が少ないページでも、契約者へ案内した手順書や、毎年使う募集要項へのリンクが存在することがあります。検索データだけでは、メール、PDF、QRコード、ブックマークからの利用をすべて把握できません。管理部署へリンクの使用状況を確認し、変更によって問い合わせや申込の作業が止まらないようにします。対象の見落としを減らすため、サイト内のリンク一覧と部署からの申告を組み合わせてください。

旧URLと新URLの対応表を、実装できる情報へ落とし込む

対応表には旧URLと新URLだけでなく、判断理由、転送種別、対象の条件、検証結果、設定場所を記載します。相対パスだけで管理すると、ドメイン変更やhttpからhttpsへの統一を含むケースで、担当者によって解釈が変わる場合があります。対象に合わせて完全なURLとパスを使い分け、プロトコル、ホスト名、末尾スラッシュ、クエリの扱いまで確認してください。

対応表の項目	記載する内容	確認の目的
旧URL	実際に利用されている変更前のURL	旧ページのアクセス経路を追う
新URL	最終的に公開する転送先のURL	途中のURLを転送先にしない
変更の理由	名称変更、構成変更、内容の統合など	転送先との内容の対応を説明する
対象条件	個別一致か共通パターンか、クエリの扱い	対象外のURLを巻き込まない
設定場所	プラグイン、サーバー、CDNなど	重複設定と変更担当を把握する
検証・履歴	応答、到達先、確認日、担当者	公開前後の状態と戻し方を追う

表を埋める段階で、転送先がまだ公開されていない、似た記事が複数ある、担当部門が決まっていないといった課題が見つかることがあります。未確定の行を実装対象へ混ぜず、確認待ちとして分けてください。制作会社へ渡す表と社内で承認した表が別版にならないように、版、承認日、変更点を記録します。公開直前に追加したURLも、同じルールで承認と検証を行います。

クエリ付きURLは値の用途から判断する

URLの末尾に付く値には、広告の流入識別だけでなく、予約条件、検索条件、資料の種類などを表すものがあります。すべて残す、すべて削除するという一律の方針では、業務の条件を失ったり、不要な値を引き継いだりする可能性があります。新しいページが何を受け付けるかを確認し、必要な値と不要な値を整理してください。顧客情報を含むURLがある場合は、計測やログへの記録範囲も開発担当と確認します。

WordPressで
お困りではありませんか？

実績豊富な
WordPressの制作・構築・管理なら
こちらからご相談ください

プラグインとサーバー設定の使い分けを具体化する

運用担当がページ単位で転送を追加するなら、管理画面から条件と履歴を確認できる仕組みが候補になります。一方、ホスト名の統一や大きなディレクトリの移転など、WordPressが動作する前に処理したい転送は、サーバーやCDN側を含めて検討します。扱うURLの数だけで選ばず、誰が管理し、どの層で実行され、どこで検証できるかを比較してください。

既存のSEOプラグインに転送機能がある場合、別のプラグインを増やす前に現在の機能と契約条件を確認します。製品によって利用できる範囲や管理方法は異なるため、名称だけで対応可能と判断しないことが大切です。導入前に検証環境で試し、既存の正規化ルールや会員機能との競合を確認します。使わなくなった設定を削除するときも、現在参照される旧URLがないかを点検してください。

正規表現によるまとめ設定は対象外の試験も行う

共通のURLパターンを転送する設定は、個別登録の手間を減らせる反面、意図しないURLに一致することがあります。たとえばブログ用の規則が管理画面や画像のパスまで対象にすると、記事以外の動作へ影響します。設定したい範囲を説明できる担当者が、代表的な一致例、不一致例、境界の例を試験してください。大量のURLをまとめる前に、例外が必要なページを対応表で分けます。

サーバー設定を変更する場合は、現在の構成、設定を読み込む順番、他の規則との関係を確認します。Apache向けの設定をNginxへ貼り付けるように、環境が違う例をそのまま使うことはできません。設定ファイルを保存し、変更を戻す手順と操作権限を確保してから実施します。本番で試しながら規則を増やすのではなく、事前に試験できる範囲と公開後の確認項目を決めることが重要です。

公開日の作業を、URL変更・転送・確認の順に組み立てる

公開日には、新しいページの内容と公開状態、旧URLの転送、内部リンク、検索向け設定が整合するタイミングを計画します。新URLが未公開のまま旧URLだけを転送すると、訪問者がエラーや認証画面へ到達することがあります。担当者が別々に作業する場合は、誰の完了連絡を受けて次へ進むかを決めてください。公開直前の確認と、利用者の環境から行う公開後確認も分けます。

確認の段階	担当者が試すこと	記録する結果
新ページの公開前	内容、フォーム、画像、リンク、公開範囲	転送先として使える準備ができたか
転送設定の反映後	旧URLの応答とLocation、最終到達URL	予定した種別で正しいページへ届くか
対象外の確認	管理画面、画像、申込、既存ページ	余分な転送やエラーが発生していないか
リンク更新後	メニュー、関連記事、サイトマップ、canonical	新URLの指定へそろっているか
公開後の利用確認	PCとスマートフォン、外部の案内リンク	利用者の操作で業務が完了するか

公開後に不具合が見つかったときは、どの変更を戻すかを事前に決めた記録と照らして判断します。転送だけを解除しても新URLへ内部リンクを書き換えている場合は、サイト全体が以前の状態へ戻るとは限りません。本文、メニュー、設定、転送表、サイトマップなど変更した対象を分けて保存し、担当者が戻す範囲を把握できるようにしてください。復旧時にも、戻した後のフォームと主要ページを確認します。

よくある転送エラーを、応答の順番から調べる

新旧URLが互いに転送されるループ

旧URLから新URLへ転送し、新URL側の別設定が旧URLへ戻すと、ページへ到達できないループになります。画面にエラーが出たときは、最後に見えるURLだけで判断せず、各段階の応答と転送先を開発担当へ確認してもらいます。プラグイン、サーバー、CDN、https化などの管理元を順に整理し、どの規則が動いているかを特定してください。一度にすべてを解除すると、原因の確認と復旧が難しくなります。

途中のURLが増える連続転送

過去の変更を重ねると、最初の旧URLから中間URLをいくつも経由して現在のページへ進む状態になることがあります。対応表では最終公開URLを転送先として確認し、可能な範囲で不要な中継を減らします。中間URL自体を使うリンクがある場合は、そのURLへの対応も必要です。古い設定を削除することだけを目的にせず、どの入口からでも正しいページへ到達できるかを試験してください。

ブラウザのキャッシュで結果が違って見える

転送結果が環境によって違う場合は、サーバーの設定が反映されていないのか、ブラウザやCDNに以前の結果が残っているのかを切り分けます。通常の閲覧と新しいセッション、公開ページの応答を比較し、確認条件を記録してください。キャッシュを削除した一台で動いたことだけを成功条件にせず、利用者が実際に使う状態でも確認します。キャッシュの一括削除が別の機能へ影響する場合は、担当者と範囲を相談します。

公開後の検索データと旧URLの利用を継続して確認する

公開直後は、転送が動くことと、検索結果に新URLが表示されることを分けて記録します。Search Consoleで旧URLと新URLを確認し、選択された正規URLや取得状態、検索クエリ、表示とクリックの変化を追います。平均掲載順位だけを比較する場合も、対象クエリ、国、端末、期間が変わっていないかを確認してください。公開日を境に指標が変化しても、転送だけを原因と断定しないことが重要です。

転送ログやアクセス解析で旧URLへのアクセスが続いていれば、サイト内に残ったリンク、広告、外部資料を点検します。リンクを変更できるものは新URLへそろえ、変更できない案内は旧URLから到達できる状態を維持します。ドメイン移転を伴う場合は、旧ドメインの契約と証明書を終了すると旧URLへのアクセス自体が機能しなくなるため、維持する条件を移行計画で確認してください。

転送設定の管理表は公開後も残します。新しい担当者が以前の規則を不要と判断して削除すると、古い案内からの流入が止まる場合があります。設定理由、確認済みURL、例外、最終確認日を引き継ぎ、次のリニューアル時にも参照してください。URLを変更する際に内容、導線、運用記録を一緒に整えることで、利用者と社内担当の両方が迷いにくいサイトへ改善できます。