一時的なURL変更は302と307の送信対象を分け恒久移転を301と混同しない

期間限定の案内page、A/Bテスト、ログイン前の案内のように、一時的に利用者を別URLへ送るなら、恒久移転を示す301ではなく、302または307を使います。通常の閲覧のようにGET requestを別URLへ案内するだけなら302で足ります。form送信のようにrequest methodを変えずに引き継ぐ必要があるなら307を検討します。どちらを使うかは、移転の期間ではなく、移動後に何を送るかで決めます。

redirectは、URLを変えるための便利な設定に見えます。しかし利用者、browser、検索engine、serverは、同じredirectを同じ意味で受け取るわけではありません。古いURLを今後も検索結果の入口として残すのか、formに入力された内容を別のURLへ送ってよいのか、移転が終わったあとに元のURLへ戻すのかを先に決めなければ、status codeだけを変えても運用は整いません。

RFC 7231は、302を対象resourceが一時的に別のURIにあることを示すstatus codeとしています。一方307は、一時的な移動を示したうえで、browserが自動redirectするときrequest methodを変えてはならないと定めます。この違いは、表示するpageを移す場合より、送信を伴う処理を移す場合に重要になります。

恒久移転と一時的な案内は目的が違う

301は、元のURLにあった内容が新しいURLへ移り、元へ戻す予定がないときに使います。会社siteのdomain移転、page構成の整理、URLの変更では、旧URLごとに対応する新URLを決め、301で案内します。ここで必要なのは、利用者をどこかへ飛ばすことではなく、元URLの内容がどこへ移ったかを明確にすることです。

一時的なredirectでは、元URLが本来の入口のままです。たとえば、短い期間だけ予約受付を別serviceのpageへ案内する場合、受付終了後は元の案内pageへ戻すか、別の案内へ差し替えます。A/Bテストで元pageとvariationを比べる場合も、testが終われば元pageを通常の入口として使います。このようなケースへ301を使うと、「ずっと移転した」という意味を送ることになります。

GoogleのA/Bテストに関する公式案内も、元URLからvariation URLへ利用者を送るテストでは301ではなく302を使うよう示しています。これはテストの間だけredirectを置き、元のURLを検索の入口として扱い続けるためです。テストpageを作ったことと、本番URLを移転したことは別です。

302と307はrequest methodの扱いを分ける

302と307は、どちらも一時的なredirectです。ただし、送るrequestがGETなのかPOSTなのかで、確認すべきことが変わります。GETはpageやfileを取得するために使われるrequestです。利用者が案内pageを開き、別の告知pageへ移るだけなら、通常はGET requestを扱います。この場合は、移動先のpageが正しい内容を返し、元のURLへ戻せることを確認すればよいでしょう。

POSTはformの送信など、serverへdataを渡すrequestで使われます。見積り依頼formを送信した直後に別URLへ移動させる場合、302を返したbrowserは、実装や慣行により後続requestをGETへ変えることがあります。入力dataを同じmethodで次のURLへ渡す設計なら、302が意図どおりに働くとは限りません。

307では、browserが自動でredirectするならrequest methodを変えません。したがって、送信先を一時的に切り替え、同じPOSTを別のURLで受ける必要がある場面では、307の意味を検討します。ただし、307を返せばform処理が安全になるわけではありません。移動先が同じ入力項目を受け取れるか、二重送信にならないか、利用者へ何を表示するか、送信内容を誰が保存するかを別に確認します。

説明用の仮例として、/contact/submit/へ送られた問い合わせを、一時的な保守用systemへ渡す場合を考えます。最初に決めるのはstatus codeではありません。元のformと移動先が同じfieldを受けるのか、送信後の確認画面はどちらが出すのか、返信先を誰が確認するのかを決めます。入力を保持したまま移動先で処理するなら、methodの扱いが変わらない307を候補にします。保守期間中だけ受付を止め、説明pageを見せるなら、formを送らせず302で案内する方が分かりやすい場合があります。

検索engineへの説明と利用者への案内をそろえる

一時的なredirectを置くときも、利用者が何を見て、次に何をするかを曖昧にしません。予約受付が休止中なら、移動先のpageに休止期間、代わりの連絡方法、通常の受付へ戻る予定を示します。login pageへ送るなら、login後に元の目的のpageへ戻れるかを確認します。top pageへ送れば表示だけはできますが、利用者が開こうとした商品や記事を失う場合があります。

検索engineへ向けても、temporary redirectを恒久移転の代わりに使い続けるべきではありません。予定がなくなり本当に新URLへ移すなら、対応する新URLを決めて301へ切り替えます。反対に、一時的な案内のまま何か月も設定を残すなら、終了日、管理者、見直す日を記録します。temporaryという言葉だけでは、いつ元へ戻すかは決まりません。

mobileの利用者だけを関係のないtop pageや広告pageへ送るredirectも避けます。利用者が検索で選んだURLと、browserにより見せるpageの内容が大きく違えば、必要な情報へ着けません。device別の案内が必要でも、できるだけ対応するpageへ送り、同じ情報へ到達できる状態を保ちます。

responseを見てからredirect ruleを増やす

redirectの確認は、設定画面のruleを読むだけでは足りません。実際のURLへrequestし、status codeとLocation headerを確認します。さらに、redirectの終点が200で目的のcontentを返すか、途中でloopしていないか、query stringや必要なpathが落ちていないかを確認します。

1. 元URL、移動先URL、redirectを置く理由、終了日を一組で書く。
2. browserで元URLを開き、利用者が必要なpageまたは案内へ進めるかを見る。
3. HTTP responseのstatus codeとLocation headerを確認し、意図した302、307、301のどれが返るかを見る。
4. POSTを扱う場合は、送信先、request method、入力data、二重送信時の動きをtest environmentで確認する。
5. 終了日になったらruleを外すか、恒久移転なら301へ変更し、元URLと検索結果を確認する。

redirectを外部の制作者やserver管理者へ頼む場合は、URLの一覧だけを渡しません。temporaryかpermanentか、いつまで使うか、form送信を通すか、戻す担当は誰かを一緒に残します。設定を入れる作業と、設定を終わらせる責任を分けないことが、古いredirectを残さないための条件です。最初の一手は、一時的に送っているURLを一つ選び、元へ戻す日と、送るrequestがGETかPOSTかを書くことです。