サイトリニューアルで検索評価を失う原因 — 302 と 301 の違い

リニューアルしたのに、順位が戻らない

サイトをリニューアルしたあと、検索順位が以前の水準に戻らないことがあります。デザインも情報量も良くなっているのに順位だけが落ちる、という状態です。

原因はいくつも考えられますが、実際に調べてみるとリダイレクトの種類が違うだけというケースが少なくありません。旧ページから新ページへの転送自体は動いていて、ブラウザで開けば正しく新しいページに着きます。人間の目には何も問題がないので、見落とされたまま数ヶ月が過ぎます。

本記事では、この見落としがなぜ起きるのかと、公開後に自分で確かめる手順を整理します。

302 は「一時的な移動」と伝えている

HTTP のリダイレクトには種類があり、返すステータスコードによって検索エンジンへの意味が変わります。

302 は「いまは別の場所にあるが、そのうち元に戻る」という宣言です。検索エンジンはその宣言を尊重して、評価の持ち主を旧 URL のままにしておきます。新しいページはゼロから評価を積み直すことになります。

リニューアルは恒久的な移設なので、正しいのは 301 です。

302 が正しい場面もある

302 が常に悪いわけではありません。メンテナンス中に一時的な案内ページへ飛ばす、キャンペーン期間だけ特設ページへ送る、といった「あとで元に戻す」場合は 302 が正しい選択です。

判断の軸は 1 つで、元の URL に戻す予定があるかどうかです。戻さないなら 301、戻すなら 302 になります。迷ったときは、半年後にその URL をどう扱っているかを想像してみてください。

なぜ意図せず 302 になるのか

設定した側が 302 を選んだつもりがないのに、302 が返っていることがあります。構造的な理由が 2 つあります。

1 つ目は、管理画面にステータスコードの選択肢がないことです。CMS のリダイレクト設定に「転送元 URL」と「転送先 URL」の欄しかない場合、どちらのコードで返すかは実装側の既定に委ねられます。その既定が 302 になっていると、設定した人の意図とは無関係に一時的な移動として扱われます。

2 つ目は、フレームワークのリダイレクト関数の既定です。多くのフレームワークは、引数でコードを明示しない限り一時的な転送を返します。恒久的な移設のつもりで書いたコードが、一時的な転送になっている構図です。

いずれも「設定したから大丈夫」という前提が崩れる形なので、公開後の確認でしか気づけません。設定した本人に落ち度があるわけではなく、選択肢が提示されていないことが原因です。

確認は数分で終わる

コマンドラインから旧 URL に対してヘッダーだけを取得します。

curl -I https://example.com/old-page/

返ってきた 1 行目を見ます。

HTTP/2 301
location: https://example.com/new-page/

ここが 301 なら恒久的な移設として扱われています。302 になっていれば直す対象です。

リダイレクトが多段になっている場合は、最終的な到達先まで追いかけます。

curl -IL https://example.com/old-page/

ブラウザの開発者ツールでも同じ確認ができます。ネットワークタブを開いて旧 URL にアクセスし、最初のリクエストのステータスを見てください。

多段のリダイレクトを畳む

確認していると、転送が何度も連鎖しているケースが見つかることがあります。旧 URL から中間の URL へ、そこからさらに新 URL へ、という形です。

原因はたいてい積み重ねです。過去のリニューアルで設定した転送が残っていて、その上に今回の転送が乗ります。1 回ごとに時間がかかるうえ、途中に 302 が混ざっていれば、そこで意味が変わります。

対処は単純で、最初の URL から最終的な到達先へ 1 回で飛ばす ように書き直します。中間の設定は消さずに残しておいて構いませんが、新しく増える転送は最終地点を直接指すようにしてください。

www と https の正規化も同じ話

見落としやすいのが、ドメイン側の転送です。www ありとなし、http と https。これらも同じ内容のページが複数の URL で開ける状態になります。

どれか 1 つを正とし、残りは 301 で寄せるのが基本です。ここが揃っていないと、評価が分散します。リニューアルのタイミングは、この整理を一緒に済ませる好機です。 別々に手を入れるより手戻りがありません。

旧ページは消すより残して飛ばす

リニューアルの際、対応する新ページがない旧ページをどう扱うか迷うことがあります。判断の目安は次のとおりです。

避けたいのは、対応先がないからといって全部をトップページへ飛ばすことです。内容の関連しないページへの一括リダイレクトは、検索エンジンから実質的な 404 と見なされることがあり、訪問者にとっても求めていた情報に辿り着けない体験になります。

対応先が無いページを 404 にする場合も、そのままにせず 404 の画面に次の行き先を置いてください。 検索から来た人がそこで止まらずに済みます。一覧ページへのリンクと、サイト内を探せる手段があれば十分です。

なお、内容が完全一致しなくても、近いテーマの新ページがあるならそちらへ寄せて構いません。判断の基準は、その人が探していた情報に近づくかどうか です。厳密な対応を求めて時間をかけるより、近いページへ寄せてしまうほうが実務的です。

FIXIT

ちゃんと転送されてるのに、なんでダメなの？

Shiori

整理すると、人には見えていて、検索エンジンには別の意味で伝わっているんです。

FIXIT

じゃあ見た目で確認しても意味ないってこと？

Shiori

はい。分かれ目はステータスコードなので、そこだけ直接見てください。

すでに 302 で運用してしまっている場合

気づいた時点で 301 に直します。検索エンジンが再クロールしたタイミングから評価の移転が進みますが、反映には時間がかかります。302 の期間が長いほど回復にも時間を要するので、放置した分だけ機会損失が積み上がる形です。

直したあとに合わせて確認しておきたい点が 2 つあります。

1 つ目は、サイトマップの内容が新しい URL になっているかです。旧 URL が残っていると、検索エンジンに混乱した情報を送り続けることになります。

2 つ目は、Search Console からのインデックス登録のリクエストです。新しい URL のクロールを促せます。数が多い場合は主要なページから順に処理してください。

直したあと、どのくらいで戻るか

301 に直したあと「いつ戻るのか」を聞かれることがあります。正直なところ、日数は約束できません。決まるのは検索エンジンの再クロールのタイミングであり、こちらから制御できないためです。

ただし、進み方は確認できます。見るのは次の 2 点です。

1. 旧 URL が新 URL に置き換わっているか。検索結果に出てくる URL が変わっていくかを見ます
2. 新 URL の表示回数が伸びているか。管理画面で、対象ページの推移を追います

先に動くのは 1 番です。 URL の置き換えが進んでから、表示回数が追いついてきます。順位だけを毎日見ていると変化が見えず、直っていないように感じます。

促進のためにできることもあります。サイトマップを新 URL の内容に更新すること、主要なページのクロールを個別に依頼すること、そして新しいページ同士を内部リンクでつないでおくことです。どれも直接の効果より、見つけてもらう速さに効きます。

なお、待っているあいだに他の要因まで一緒に触ると、何が効いたのか分からなくなります。リダイレクトを直したら、しばらくはそこだけを見てください。

対応表は公開前に作る

リダイレクトの設定漏れは、公開の直前に慌てて作業することから生まれます。防ぐには、旧 URL と新 URL の対応表を設計の段階で作っておくのが確実です。

必要な列は 4 つで足ります。

3 列目まではリニューアルの設計時に埋まります。4 列目を空欄で残しておくのが要点です。 公開後にここを埋める作業が、そのまま確認の工程になります。

対象が多い場合は、優先順位をつけてください。流入のあるページから先に確認する のが順当です。アクセス解析や検索の管理画面で、直近に訪問のあった旧 URL を上から並べれば、その順番がそのまま優先度になります。全ページを一度に見る必要はありません。

発注時に握っておくこと

制作を外部に依頼する場合、リダイレクトの扱いは見積の前に決めておくべき項目です。あとから「その作業は含まれていない」となるのが、よくある行き違いです。

依頼の段階で確認しておくのは次の 3 点です。

2 行目が実務では重くなります。どのページをどこへ寄せるかは、内容を知っている側にしか決められません。 制作側は URL の一覧は作れますが、対応先の判断は業務の知識が要ります。ここを丸投げすると、機械的にトップページへ寄せられることになります。

3 行目も抜けやすい部分です。公開直後は双方が忙しく、確認が後回しになります。手順書に担当者名まで書いておく のが確実です。

順位が戻らない原因は他にもある

念のため補足すると、リダイレクトを直せば必ず戻るわけではありません。リニューアルで順位が落ちる原因はいくつかあり、リダイレクトはそのうちの 1 つです。

同時に確認しておきたいのは、次の点です。

• 本文の量が減っていないか。デザインを整理する過程で、説明文が削られていることがあります
• 見出しの構造が変わっていないか。何について書いたページかが伝わりにくくなる場合があります
• 内部リンクが切れていないか。他のページから辿れないページは、評価が伸びにくくなります
• クロールを拒否する設定が残っていないか。公開前の環境の設定がそのまま出ることがあります
• 正しい URL の指定が旧 URL のままになっていないか。新旧が混在すると扱いが定まりません

このうち 1 つ目が特に起きやすい部分です。見た目を整理すると、たいてい文字数は減ります。 リニューアル前後で本文量を比べておくと、原因の切り分けが早くなります。

4 つ目は数が少ないぶん見つけにくく、影響が大きい部類です。公開前の環境ではクロールを止めておくのが普通なので、その設定を戻し忘れると、新しいサイト全体が対象外になります。リダイレクトを直しても表示回数がまったく増えない場合は、ここを疑ってください。

順番としては、まずリダイレクトとクロールの設定を確認してください。どちらも設定の問題で、数分で確かめられ、直し方もはっきりしています。本文や構造の問題は、そのあとに見ても遅くありません。

見落としを仕組みで防ぐ

この種の問題は、知識の有無ではなく確認の有無で決まります。リニューアルの担当者がリダイレクトの違いを知っていても、確認の工程がなければ CMS の既定値をそのまま通してしまいます。

FIXIT では、リリース後の確認としてステータスコードのチェックを手順に含めています。数分で終わるうえ、見逃したときの損失が数ヶ月分の検索評価になるためです。

サイトの作り直しを検討している段階であれば、旧 URL の扱いを設計に含めておくと確実です。どのページをどこへ寄せるかの対応表を作っておけば、公開時に迷わず 301 を設定できます。移設そのものの進め方は リプレイス案件 (既存システム刷新) の見積の落とし穴 にも整理しました。

まとめ

• リニューアル後に順位が戻らない原因として、302 のままになっているケースが多い
• 302 は一時的な移動を意味し、評価の持ち主は旧 URL のまま残る
• 恒久的な移設なら 301。判断の軸は「元の URL に戻す予定があるか」だけ
• 管理画面やフレームワークの既定が 302 のことがあり、設定した側の意図とは無関係に決まる
• 確認は curl -I で数分。多段になっていれば curl -IL で経路ごと畳む
• 対応表は設計の段階で作り、確認欄を空けておく。埋める作業がそのまま検証になる
• 発注時は、旧 URL の扱いが作業範囲に入るか、誰が対応表を作るかを先に決める