301と302の使い分けは検索結果に残すURLで決める

キャンペーンページを一時的に別のページへ回したい。リニューアルで古いURLを新しいURLへ寄せたい。どちらの作業でも最後に「301（恒久的な自動転送）と302（一時的な自動転送）のどちらを書くか」という一行の判断が来ます。

このとき多くの現場で持ち出されるのが「302だとSEOの評価が引き継がれないから、とりあえず全部301にしておこう」という説明です。ところがGoogle公式ドキュメントを開いて突き合わせると、そこに書かれているのは「評価がどれだけ引き継がれるか」ではなく「検索結果にどちらのURLが残るか」の話です。判断軸がずれているせいで、本来302で済む場面に301を張って戻せなくなる、という事故が起きます。

この記事は、自社サイトのリダイレクトを自分で設定するエンジニア／サイト運用担当の方に向けて、公式の記述を土台に選び方の軸を引き直し、設定前の5ステップと設定後の実測手順を1回通してみせます。読み終わったときに、いま手元の案件でどちらを書くべきかが決まっている状態を目指します。

公式が「一時的なリダイレクト」について書いていること

まず、Googleの「リダイレクトと Google 検索」のページにある一文を引きます。

ユーザーを別のページに一時的に誘導するには、一時的なリダイレクトを使用します。これにより、Google がリダイレクトの影響を受けなくなり、検索結果に古い URL が残る可能性が高まります。

続けて挙げられている例が具体的です。サイトのサービスが一時的に利用できなくなった場合、一時的なリダイレクトを設定すれば、検索結果にある元のURLに影響を与えずに、状況を説明するページへユーザーを誘導できる、と書かれています。

ここで語られているのは減点でも損失でもありません。「元のURLを検索結果に残したまま、人だけを別の場所に案内する」という機能の説明です。サービス停止のお知らせページを301で張ってしまえば、伝えたい内容は同じでも、Googleに対しては「元のページは恒久的にお知らせページへ移った」と言っていることになります。復旧後に元へ戻したい前提があるなら、それは意図と違います。

永続側について書かれていること

一方、永続的なリダイレクトについては別のページに明確な記述があります。「サイト移転（URL 変更あり）」のページには、リンククレジットについて要件を設けないという文脈で、次のように書かれています。

301 や その他の永続的なリダイレクト によって PageRank の損失が生じることはありません。

PageRankは、リンクを通じて他のページから送られる検索エンジン上の評価のことです。つまり「301を張ると評価が目減りする」という心配は、少なくとも公式の記述の上では否定されています。

もうひとつ、HTTPステータスコードの扱いをまとめたページには、301について「Google のシステムはリダイレクトを、リダイレクト先を処理する必要があることを示す強いシグナルとして使用します」と書かれています。重複したURLを1本に寄せる場面で永続的なリダイレクトが案内されるのは、この強さと関係があるように読めます。「重複した URL を統合する（正規化）」のページでは、既存の重複ページを取り除く場合はリダイレクトを使うようにと案内され、すべての永続的なリダイレクト方法はGoogle検索に対して同じ効果がある一方で、検索エンジンがリダイレクトを認識するまでの時間はそれぞれ異なり、最も早く効果が現れるのはHTTPリダイレクト（サーバーサイドリダイレクト）を使った場合だと書かれています。

整理すると、公式の記述から読み取れる軸はひとつです。元のURLを検索結果に残しておく必要がないなら永続、元のURLを検索結果に残したいなら一時。評価の目減りを気にして選ぶ問題ではありません。

選ぶ前に決める5ステップ

軸が決まれば、判断は設定ファイルを開く前に終わります。ここでは実際に2つのURLを通してみます。

• ケースA: example.com/campaign/summer（夏のキャンペーンページ。会期後は次年度に同じURLを使い回す予定）
• ケースB: example.com/service/plan（リニューアルで example.com/pricing に統合。旧URLは今後使わない）

1. 元のURLを将来また使うかを、書いて決める。 ケースAは来年また使うので「使う」。ケースBは統合先ができたので「使わない」。ここを口頭の合意で済ませると、あとから設定の意図が誰にも説明できなくなります。迷ったら、来期のサイト構成図に元のURLが載っているかで判断してください。
2. 検索結果に残したいURLをどちらか一方に決める。 ケースAは、会期外に検索されたときも campaign/summer が窓口であってほしいので元のURL。ケースBは pricing を出したいので新しいURL。この設問は手順1と必ず同じ側を向くはずで、向かない場合はURL設計そのものを見直す合図です。
3. 対応するステータスコードを選ぶ。 恒久的に移すなら301（または308）、一時的に案内するなら302（または307）。ケースAは302、ケースBは301です。
4. サーバー側で実装する。 公式ではサーバー側のリダイレクトの実装はホスティングとサーバーの環境、サイトのバックエンドのスクリプト言語によって異なると説明されています。たとえばPHPで永続的なリダイレクトを設定する場合は、画面にコンテンツを送信する前に header() 関数でヘッダーを設定します。Apacheの設定ファイル、nginxの return、CDNのルール、フレームワークのミドルウェアなど、実装場所は環境ごとに違うので、どこで転送しているかを対応表に書き添えておくと後任が追えます。
5. 実測して、意図と一致しているか確かめる。 設定した本人が「301で書いたから301が返っている」と思い込む状態を作らないための工程です。次の節でやります。

ケースAで302を選べたことが、この5ステップの実利です。「とりあえず301」で処理していたら、会期後に元のURLへ戻したくなった時点で、検索結果側の状態を元に戻す作業が別途必要になります。

場面ごとの判定表

手順1と2の答えを場面に当てはめた早見表です。判定の根拠はすべて「元のURLを将来また使うか」の一列に集約されます。

表の上3行と下3行の違いは、SEOの強弱ではなく元のURLの寿命だけです。判断に詰まったときは「半年後にこのURLでページを公開する予定があるか」と言い換えると答えが出ます。

実測する6ステップ

設定後の確認は、ブラウザで開いて転送されたことを見るだけでは足りません。見た目は同じでも、返っているコードが違えばGoogleへの伝わり方が変わります。

1. 転送元のURLに対してヘッダーだけを取る。 curl -sI https://example.com/campaign/summer のように、本文を取らずレスポンスヘッダーを見ます。1行目のステータスコードと Location ヘッダーの行き先が、意図した組み合わせになっているかを確認します。
2. 転送の連鎖（ホップ数）を数える。 curl -sIL のように追跡付きで実行すると、途中のレスポンスがすべて並びます。公式には、Googleのクローラーはデフォルトで最大10回のリダイレクトホップを追跡する（特定のプロダクトのクローラーでは制限が異なる場合がある）と書かれています。数えて2回以上あるなら、中間を飛ばして一手で最終URLへ着くように書き直すのが素直です。
3. 末尾スラッシュのあり／なし両方で叩く。 転送規則の書き方によっては片方だけ効いていることがあります。あわせて http:// と https://、www あり／なしも同じ手順で確認しておくと取りこぼしが減ります。
4. キャッシュを疑う。 恒久的な転送はブラウザ側にも記憶されることがあるため、以前の設定が残って正しく確認できない場合があります。curl で確認する、シークレットウィンドウを使う、といった形で、キャッシュの影響を受けない経路で見てください。
5. 転送元に置いた説明文が使われない前提で書く。 公式には、Googleがリダイレクト URL から受信したコンテンツはすべて無視され、代わりに最終的なターゲットURLのコンテンツが処理されると書かれています。転送元のHTMLに移転のお知らせを書き込んでも、検索側で扱われるのは到達先の内容です。
6. 対応表に実測結果の列を足す。 「意図したコード」と「実測したコード」を並べて書くと、差分がそのまま直すべき箇所の一覧になります。

つまずきやすい3点

1. 遅延つきの meta refresh は一時的なリダイレクトとして解釈される。 公式には、content 属性に秒数を設定して遅延させるリダイレクトは、Googleによって一時的なリダイレクトと解釈されると書かれています。恒久移転のつもりで数秒待たせる案内ページを挟むと、意図と違う種類のリダイレクトとして伝わることになります。

2. 307と308を「新しいから安全」と選ばない。 公式では307は302と同じ、308は301と同じと説明され、これらのステータスコードはGoogleによって同じように扱われるとしつつ、意味が大きく異なることに注意するよう書かれています。そのうえで、リダイレクトに適したステータスコードを使い、他のクライアント（電子書籍リーダーや他の検索エンジンなど）もその恩恵を受けられるようにしてほしい、と続きます。Googleでの扱いが同じでも、選ぶ理由を「意味」の側に置くのが公式の要請です。

3. JavaScriptによる転送を第一候補にしない。 公式には、サーバー側のリダイレクトまたは meta refresh リダイレクトを行えない場合にのみJavaScriptリダイレクトを使うようにと書かれています。理由も明示されていて、GoogleはクロールしたすべてのURLをレンダリングしようとするものの、さまざまな理由でレンダリングが失敗することがあり、その場合はリダイレクトを認識できない可能性があるためです。さらに、新しいページへのリンクと簡単な説明だけを置く方法（crypto リダイレクト）については、ほかに方法がない場合を除き、コンテンツを移転したことを検索エンジンに伝えるために使わないよう書かれています。

永続側を選んだ後に見えるもの

301を張った直後に検索結果が入れ替わるわけではありません。公式のサイト移転のページには、Googleがサイトを再クロールしてインデックスに登録し直す間にランキングが変動することがあり、原則として中規模のサイトでほとんどのページの移転がインデックスに反映されるのに数週間かかり、より大規模なサイトであればそれより長くかかると書かれています。速度は主にURLの数とサーバーの速度によって決まり、サイトマップを送信すると検出プロセスの時間を短縮できるとも案内されています。

もうひとつ、移転後はGoogleが一時的に通常より高い頻度で移転先のサイトをクロールするという記述があります。元のサイトへのクロールが新しいサイトへ転送され、そこに通常のクロールも重なるためです。転送の設定と同時に、受け側のサーバーに余裕があるかも見ておく価値があります。

公開前チェックリスト

Wemiroでは、登録したURLのリストに対して返ってきたHTTPステータスコードと転送の到達先を一覧で確認でき、意図した種類の転送になっていないURLや、転送が何段も連なっているURLを絞り込めます。移転や統合の直後に、対応表の「実測コード」の列を埋める作業をまとめて済ませる用途を想定しています。

URL変更を伴うリニューアル全体の進め方はサイト移転でURLが変わるときの301リダイレクト手順に、末尾スラッシュのような正規化の判断はURL末尾のスラッシュはSEOでどう扱われるかにまとめています。重複URLを1本に寄せる側の判断は重複コンテンツとcanonicalの考え方が対応します。