こんにちは。バナナデスクです。
古い記事URLを開いて、新しい記事が表示された。これだけなら転送は成功したように見えます。でも、その途中で二つの古いURLを経由していたり、条件によって同じ場所を往復したりしていないでしょうか。
301リダイレクトは、古いURLから恒久的な移転先へ案内するために使います。ここで分けたいのは、設定欄に301を選んだこと、画面が移動したこと、実際に301が返ったことです。この三つは、同じ確認ではありません。
まず移転先を対応表で決め、その後に応答と本文を確かめましょう。この記事では、自作の検証サーバーで取得した正常・連鎖・ループの例と、隔離したWordPressでの操作例を分けて説明します。ご自身のサイトでは、どの設定を変え、何を記録すればよいかまで整理していきます。
301は、URLが恒久的に移るときの候補
Googleのリダイレクトの説明では、301や308を永続的な移転に用い、元に戻す予定のない変更で使う方法として説明しています。一時的な案内なら302や307など、変更の性質に合う方式を選びます。
301を設定しただけで、検索順位や評価がそのまま保たれると保証できるわけではありません。また、消した記事と関係のないトップページへ全件を送ると、元の記事を探している読者の用事が終わらないことがあります。まず内容に対応する移転先があるかを判断してください。
設定より先に、旧URL5件の行き先を決める
次は架空サイトの対応表です。講座案内が/courseへ、一般記事が/articleへ移る設定にしています。パスは説明用で、あなたのサイトへそのまま追加する設定ではありません。
| 旧パス | 移転先 | 判断 | この例の確認状況 |
|---|---|---|---|
| /old-course | /course | 講座案内の移転 | 301→200 |
| /old-article | /article | 記事の移転 | 設計上の対応。今回の個別ログには未収録 |
| /chain | /course | 中間URLを挟まず案内へ | 修正後301→200を取得 |
| /loop-a | /course | 往復をやめて案内へ | 修正後301→200を取得 |
| /loop-b | /course | 往復をやめて案内へ | 修正後301→200を取得 |
URLの書き方は、httpとhttps、ホスト名、末尾のスラッシュ、パラメーターを含めて照合します。似た名前のページがあるだけで転送先にせず、元の記事が答えていた疑問を、新しいページでも解決できるかを確認します。
設定する場所を一つに決め、変更前の状態を残す
転送の設定場所は、サーバーの管理機能、Webサーバーの設定、WordPressの機能やプラグインなど、利用環境によって違います。Googleの資料も、実装がホスティングやバックエンドの環境に依存すると説明しています。Apache向けの設定を、別の仕組みへそのまま貼らないでください。
変更前に、対象の旧URLが既に転送されていないかを確認します。サーバー、CDN、WordPress側へ同じ規則を重ねて入れると、どの設定で動いているか分かりにくくなります。今回変える場所、変更前の設定、戻す方法を記録してから、一つのURLで確かめます。
WordPressでは、ルールの保存と動作を分けて確かめる
編集時の検証では、本番と切り離したWordPress Playgroundに、架空の持ち物案内ページを用意しました。2026年10月2日の記録で、WordPressは7.1.2、テーマはTwenty Twenty-Five、プラグインはSafe Redirect Manager 2.3.0です。PHPの版はこの試験では記録していません。
旧パスは/n002-old-guide/、新パスは/n002-new-guide/。新ページには「ノートと、見直したい案内文を1つ用意する」という架空講座の本文を置きました。着地先のページ名だけでなく、この本文が読めるかを確かめるためです。
Safe Redirect Managerの公式説明では、管理画面の「ツール」から転送元、転送先、HTTPコードを設定します。転送元はWordPressを置いた場所からの相対パスです。たとえばhttps://example.com/wp/aboutを移す場合、WordPressが/wp/にあれば入力例は/aboutになります。Safe Redirect Manager公式説明
| 設定欄 | 隔離環境で保存した内容 |
|---|---|
| Redirect From | /n002-old-guide/ |
| Redirect To | 検証サイトの/n002-new-guide/を指す絶対URL |
| HTTP Status Code | 301 |
| 正規表現 | 使用しない |
最初の1件は、似たURLをまとめて扱う正規表現より、旧URL一つと新URL一つの組み合わせで確かめます。読者が自分のサイトへ置き換えるのは、この二つのURLです。例のパスをそのまま登録せず、先に新URLを直接開いて、公開した本文を確認してください。
下書きに戻したのは、移転先の記事ではなく転送ルール
保存画面とブラウザーで確認できたのは、次の変化です。ここでは画面上の観測を記録し、未取得のHTTP応答コードを補っていません。
| 転送ルールの状態 | 旧URLを開いた結果 | この記録で分かること |
|---|---|---|
| 公開 | 新URLへ移り、架空の持ち物案内を表示 | 意図した着地先と本文を確認 |
| 下書きへ変更して保存 | 旧URLのまま「Page not found」を表示 | ルールの状態変更に伴う画面差を確認 |
| ルールを再公開 | 再び新URLと持ち物案内を表示 | 再公開後の画面を再確認 |
「Page not found」と表示されたことだけで、HTTP 404が返ったと断定はできません。同様に、設定欄の301は保存値です。このWordPress試験の記録は設定と画面の観測であり、応答ヘッダーの測定結果を含みません。301→200の実測例とは分けて読んでください。
この区別は、転送がおかしいときにも役立ちます。新しい記事を下書きへ戻すと、着地先の公開状態まで変わってしまいます。ルールを点検する試験と移転先の記事を非公開にする操作を混ぜず、何を変えたかを記録してください。今回の隔離試験は、最後にプラグインを無効化して元のホーム表示を確認しました。
なお、別の隔離環境で先に試したRedirection 5.10.1では、ルールを保存しても旧URLのHTTP応答は404で、原因を特定できていません。別プラグインで着地先を表示できたことから、Redirectionの失敗原因や本番サーバーでの動作まで推測しないようにします。
301とLocation、その先の本文を確認する
この節の数値例は、127.0.0.1のみで動く自作Pythonサーバーで観測したものです。ルートと転送先の対応をJSONファイルへ保存して読み込む構成で、WordPress、Apache、nginxの設定が同じように動くことを検証したものではありません。
検証で/old-courseをGETすると、301と転送先を示すLocation: /courseが返り、移動先は200で講座案内を返しました。ブラウザーでも最後のURLが/courseになり、案内文を表示することを確認しました。
/old-course 301 Location: /course
/course 200 講座案内を表示単に転送先が200であることだけでなく、そこで意図した記事が読めるかを見ます。ログイン画面やトップページも200を返すことがあるためです。ログイン済みの管理者として見た結果だけでなく、一般読者が読む条件でも確認してください。
Chromeで確認するのは、最後のページだけでなく旧URLの応答
Chromeの開発者ツールでは、次の順に確認します。項目名は表示言語によって異なります。Chrome公式：Networkパネルの説明
- Network（ネットワーク）を開き、Preserve log（ログを保持）を有効にする。
- 確認したい旧URLを開く。
- 一覧で旧URLのリクエストを選び、Headers（ヘッダー）のGeneral（全般）でステータスを、Response Headers（レスポンス ヘッダー）でLocationを読む。
- Locationが示す次のURLの応答を確認し、最終ページに目的の本文があるかを照合する。
最後の200の行だけを見ると、途中の転送を見落とします。旧URL、中間URL、最終URLを順に対応表へ写してください。
設定を直しても以前と同じ場所へ移る場合は、ブラウザーに残った転送結果も確認対象です。Safe Redirect Managerの公式説明でも、301のキャッシュに注意を促しています。NetworkのDisable cache（キャッシュを無効にする）を有効にして旧URLを開き直し、ヘッダーを再確認します。この操作はブラウザーのキャッシュを対象にしており、サーバーやCDNの設定を削除する操作ではありません。比較できるよう、キャッシュを無効にしたかどうかも記録してください。
| 確認した結果 | 次に見る場所 |
|---|---|
| 旧URLは301だが、Locationが意図した新URLと違う | 対応表と保存した転送先を照合。別の転送規則やURL統一が関係するかを確認 |
| 新URLは200だが、トップやログイン画面が出る | 一般読者が目的の本文を読める公開状態かを確認 |
| 新URLへ到達する前に、複数の3xxを通る | 各Locationを順に記録し、不要な中間URLを減らせるか判断 |
| 同じURLへ戻る | 往復している二つの規則を特定。別の規則を足す前に戻し方を確認 |
自分のサイトでは、まず変更する旧URL一つだけで、この記録を完成させてください。対応表の行き先と実際のLocationが同じで、最終ページに目的の本文がある。その組み合わせを確認してから対象を広げると、途中で食い違いが出たときも原因を追いやすくなります。
連鎖は、古いURLから最終の行き先へ整理する
検証の/chainは、最初に/old-courseへ、その後/courseへと二段階で転送しました。ルートの対応を最終の/courseへ直すと、一回の301の後に200へ到達しました。
変更前：/chain → 301 /old-course → 301 /course → 200
変更後：/chain → 301 /course → 200途中の転送を減らす際も、httpsへの統一など他の設定が関係していないかを確認します。目に付いた規則だけを削って、別の旧URLが到達できなくならないよう、対応表のURLを一つずつ再確認します。
ループは、同じURLへ戻る箇所を探す
別の例では、/loop-aが/loop-bへ301を返し、/loop-bが/loop-aへ301を返しました。検証用の取得処理は同じパスへ戻った時点でループとして停止しました。この例に200で終わる本文はありません。
二つの行き先をともに/courseへ変更すると、それぞれ301の後に200を返しました。さらに変更前の設定ファイルを戻し、連鎖とループの状態が再現されることも確認しました。これはデモの復元確認であり、本番サイトを意図的に不具合へ戻した操作ではありません。
転送後は、内部リンクと掲載URLもそろえる
転送が動いたら、自分の記事内のリンクを適切な新URLへ更新します。サイトマップや正規URLの指定も、公開するページと一致しているかを確認します。転送だけに頼って旧URLを新しく掲載し続ける必要はありません。
最後に、旧URL、途中の応答、最終URL、最終の本文、確認日を対応表へ残してください。検索エンジン側の処理は別に時間がかかる場合があるため、ブラウザーで転送が動いたことを、インデックスの移行や順位維持の完了と混同しないようにします。