記事のURLを変えたり、サイトを常時SSL化したりしたあと、転送が思いどおりに動いているか気になることがあります。
ブラウザーでは転送先のページがすぐに開くので、301なのか302なのか、何回転送されたのかは画面から分かりません。
この記事では、URLを入れて転送を1段ずつ追う方法と、curlやブラウザーの開発者ツールで確かめる方法を紹介します。
この記事で使うリダイレクトチェックは、当サイトと同じMOTOKI合同会社が作った「WEBツール箱」の1つです。
無料で、会員登録なしで使えます。
最終確認日：2026年9月28日
この記事で分かること
- 301と302の違いと、どちらを使うべきか
- 転送を1段ずつ追って確かめる手順
- WordPressで転送が2回に増える理由
- ツールを使わずに確かめる方法
先に結論｜恒久的な移動は301、転送は1回が理想
| 見るところ | 望ましい状態 | 理由 |
|---|---|---|
| 転送の種類 | URLを恒久的に変えたなら301 | 302のままだと、検索エンジンが旧URLを登録し続けることがある |
| 転送の回数 | 必要な転送を最小限にする。2回までなら安全という共通基準ではない | 転送のたびに通信の往復が増え、表示が遅くなる |
| 着地するURL | http・wwwの有無にかかわらず1つ | 同じ内容が2つのURLで見られると、検索エンジンの評価が分かれる |
ツールで確かめる手順
- リダイレクトチェックを開く
- 調べたいURLを入れて「転送を追う」を押す
- 「転送の道筋」に、1段ごとのURL・ステータスコード・かかった時間が出る
- 「アクセス方法ごとの着地点」に、http・httpsとwwwの有無の4通りの行き先が出る
ツールは自動の転送を止めた状態で1回ずつアクセスし、返ってきたステータスコードと転送先を追いかけます。
最大10段まで追い、同じURLに戻ってきた場合はループとして知らせます。
実際に調べた結果
記事を移した旧URL｜301で1回
このサイトには、別の区画から移してきた記事があります。
移す前のURLをリダイレクトチェックで調べた結果です。
旧URLは「HTTP 301（恒久的な転送）」を返し、1回で新しいURLに着地しました。
着地したページは「HTTP 200」で、canonicalも着地したURLと同じです。
これは転送状態の確認例です。目的の内容へ到達するか、クエリが必要に応じて保持されるか、内部リンクやサイトマップも更新済みかを確認します。
wwwありで開いたURL｜転送が2回に増える
同じサイトを、「www」を付け、末尾のスラッシュを付けずに開いた場合です。
1回目の転送で末尾にスラッシュが付き、2回目の転送で「www」が外れて、ようやく表示されました。
スラッシュを付ける転送と、wwwを外す転送が、別々に1回ずつ動いているためです。
転送回数だけで正常とは判断できません。各段の行き先・HTTPS・応答・クエリの保持を確認し、可能なら最終URLへ直接転送します。
http・wwwの4通り｜1つのURLに着地しているか
wp-cocoon.comの結果では、4通りのアクセス方法がすべて「https://wp-cocoon.com/」に着地しました。
httpで開いても、wwwを付けて開いても、1回の転送で同じURLに集まっています。
常時SSL化とwwwの統一ができている状態です。
どれか1つでも別のURLに着地していると、ツールは「wwwあり・なしで別々のURLとして表示されています」と知らせます。
WordPressで起きる転送
WordPressは、設定しなくても自分で転送をかける場面があります。
ツールの結果に覚えのない転送が出たときは、まずここを疑います。
| 場面 | 転送の種類 | 起きること |
|---|---|---|
| 末尾のスラッシュが無いURLを開いた | 301 | パーマリンクの形に合わせて、スラッシュ付きのURLへ転送する |
| 記事のスラッグを変えた | 301 | 旧スラッグ履歴から転送できる場合がある。全種類のURL変更を保証しないため実測する |
| コードで wp_redirect() を使った | 何も指定しないと302 | 恒久的な移動なら、2番目の引数に301を渡す |
| 「設定」の「一般」でサイトアドレスを変えた | サーバーの設定しだい | wwwの有無やhttpsは、サーバー側の転送と揃える |
自分でコードを書いて転送するときは、恒久的な移動かどうかを決めてから301か302を選びます。
プラグインで管理するなら「Redirectionを使ったリダイレクト設定まとめ」、.htaccessに書くなら「.htaccessを使ったリダイレクト方法」で手順を紹介しています。
転送が3回以上重なるとき
ツールは、転送が3回以上重なると注意を出します。
よくあるのは、httpからhttpsへの転送と、wwwの統一を別々のルールで書いている場合です。
各段のLocationと応答ヘッダーを読み、サーバー、WordPress、CDNなど、どの設定が転送を返しているかを調べます。
原因の設定を特定してから、可能なら最終URLへ直接転送する形に整理します。
ブラウザーが「リダイレクトが多すぎます」と表示する場合は、同じURLへ戻るループか、転送回数の上限を超えた長い経路を確認します。
エラー表示だけでループと断定せず、各段のURLを比較してください。
WordPressの特定のページだけで起きる場合は、「特定のページだけリダイレクトループが発生する時の対応方法」を参考にしてください。
ツールを使わずに確かめる方法
curlのコマンドで、転送を順に表示できます。
curl -sS -L --max-redirs 10 -D - -o /dev/null https://example.com/2026年9月28日に、wwwありで末尾のスラッシュなしのURLで実行した結果です。
| 順番 | HTTPの行 | Locationの行（転送先） |
|---|---|---|
| 1 | HTTP/1.1 301 Moved Permanently | https://www.motoki-design.co.jp/wordpress/ |
| 2 | HTTP/1.1 301 Moved Permanently | https://motoki-design.co.jp/wordpress/ |
| 3 | HTTP/1.1 200 OK | （なし） |
ツールの結果と同じく、2回の301のあとに200が返っています。
ブラウザーで確かめる場合は、開発者ツールを使います。
- F12キー（Macはcommand＋option＋I）で開発者ツールを開き、「Network」タブを選ぶ
- 「Preserve log」にチェックを入れる（転送の前のページの記録が消えないようにする）
- 調べたいURLを開き、一覧の「Status」の列で301や302を確かめる
ブラウザーのキャッシュやHSTSによって表示される経路が変わる場合があります。シークレットウィンドウだけで確実とはせず、Networkの記録とcurlのHTTP応答を比較します。
ツールでできないこと
| できないこと | 代わりの方法 |
|---|---|
| URLの「?」以降を付けて調べる | 「?」以降は外して調べる。付けたまま確かめたいときはcurlを使う |
| http:// から始めて道筋を追う | 道筋は常にhttpsから追う。httpからの行き先は「アクセス方法ごとの着地点」で見る |
| 下の階層のページで4通りを比べる | 4通りの比較はドメインのトップページだけで行う |
| 転送の途中のページのJavaScript転送を見つける | meta refreshやJavaScriptの転送は、最後に着いたページだけを調べる |
2026年9月28日に「?p=」を付けたURLを入れたところ、「?」以降を外したトップページが調べられました。
よくある質問
Q. 301と302を間違えると、どうなりますか？
恒久的な移動なのに302を使うと、検索エンジンが旧URLを検索結果に残し続けることがあります。
サイトのリニューアルやドメインの変更では、301を使ってください。
Q. 307や308と出ました
307は302と同じく一時的な転送、308は301と同じく恒久的な転送です。
307・308ではリクエストメソッドと本文を維持します。301・302はPOSTをGETへ変更する場合があります。認証や送信処理を別の宛先へ転送する際は、送信先と再送の影響を確認します。
Q. 転送のあとのページが表示されません
最後に着いたページがエラーを返していると、ツールは「最終的にエラーページに到達しました」と知らせます。
転送先のURLが消えていないか確かめ、サイト全体のリンク切れはリンク切れ・エラー診断で調べられます。
まとめ
- 転送の種類と回数はリダイレクトチェックにURLを入れれば分かる
- 恒久的な移動は301を使う
- 転送は必要な転送を最小限にする。2回までなら安全という共通基準ではない
- WordPressは末尾のスラッシュやスラッグの変更で自分から301をかける
- 手で確かめるなら、curlのGET要求によるヘッダー確認か、開発者ツールの「Preserve log」を使う
ほかの項目もまとめて点検するなら、「WordPressサイトを自分で点検する手順」で順番と使い分けを解説しています。
ツールの一覧はWEBツール箱にあります。
上のコマンドはmacOS/LinuxなどでGET応答のヘッダーを追います。Windowsではcurl.exeを使い、/dev/nullをNULに置き換えます。従来の-IはHEAD要求で、GETと応答が異なるサーバーがあります。HTTPヘッダーによる転送の確認であり、JavaScript転送は別途ブラウザーで確認します。
GET要求と転送上限を確認した結果
2026年10月3日、掲載のcurlによるGETコマンドで、隔離環境の301→302→200を順に取得できました。
同じURLへ戻る試験では、–max-redirs 10の上限に達し、curlは終了コード47を返しました。
47だけではループと長い転送列を区別できないため、保存したLocationを比較します。
GETでは200、HEADでは302を返す試験用URLも確認しました。
-Iだけの確認では通常のページ取得と経路が異なる場合があるため、記事のコマンドはGETでヘッダーを記録します。
同日のWAZA公開URL https://www.motoki-design.co.jp/wordpress でも、GETで301→301→200を確認しました。
最初は末尾スラッシュを追加し、次はwwwなしへ移動しています。
2026年9月28日の掲載例と同じ経路でした。
これはHTTP応答の確認であり、ブラウザーのキャッシュ・HSTS・JavaScript転送やツールの現行画面の確認は含みません。
