リダイレクトとはHTTPレスポンスだ。301または302のステータスに、ブラウザへ代わりにどこへ行くべきかを伝えるLocationヘッダーが付いている。通信上ではそれがすべてであり、つまり本当の問いは「URLをどうリダイレクトするか」ではなく、サイトの手前にあるどの層が応答すべきかということになる。
この役割を果たせる層は6つあり、それらは互いに交換可能ではない。誰がレスポンスを返すか、パスとクエリ文字列が旅の途中で生き残るか、どれだけ速く方針を変えられるか、そして設定のどこまでを自分で所有するかが異なる。本稿ではこの6つすべてと、それらを選び分けるための表、そして機能するリダイレクトとキャンペーンパラメータを静かに食い尽くすリダイレクトを分ける2つの確認方法を順に見ていく。ステータスコードそのものについては、リダイレクトの種類が本稿の土台となるリファレンスだ。
リダイレクトは実際どこに存在するのか
まずは誤解から片付けよう。これはほかのどんな誤解よりも多くの午後を無駄にしてきたからだ。**DNSはURLをリダイレクトできない。**DNSレコードはホスト名をアドレスへマッピングするだけだ。パスを目にすることは決してなく、クエリ文字列を目にすることも決してなく、「代わりにどこかへ行け」と言う仕組みも持たない。AレコードやCNAMEレコードは指し示すだけであり、転送はしない。
だから、レジストラが「URL転送」を提供しているとき、実際に行っているのはホスト名を彼らが運用する小さなWebサーバーへ向けることであり、そのサーバーが代わりにHTTPリダイレクトを返している。便利であり、まったく正当な方法でもあるが、仕事をしているのはDNSではなくWebサーバーだ。そう見えてしまえば、以下の6つの方法はもはや選択肢の羅列ではなく、たった1つの問いに見えてくる。リクエストの経路上のどのマシンに応答させたいのか、という問いだ。
リダイレクトを置ける6つの場所
このいずれも、通信上では同じレスポンスに行き着く。異なるのは設定コスト、誰がそれを管理するか、そしてドメイン名より後ろのすべてに何が起こるかだ。
レジストラでのドメイン転送
最も速く、そして最も大雑把な選択肢だ。レジストラのコントロールパネルでドメインを遷移先へ向け、恒久か一時的かを選ぶ。防衛的に購入したドメイン、古い名前が単純に引き継げばよいだけのリブランド、あるいは短期のキャンペーンドメインに向いている。
落とし穴はURLの残りの部分に何が起こるかだ。ほとんどのレジストラ転送は、あらゆるリクエストを設定した単一の遷移先へ平坦化してしまうため、深いリンクもホームページに着地する。パスを保持するモードを提供しているものもあるが、それに頼る前に確認しておこう。
Webサーバーのルール
nginxやApacheを運用しているなら、リダイレクトはここに置くのが筋だ。マッチングと保持の両方を正確に制御できるからだ。Apacheの書き換えルールによるURL再マッピングのドキュメントがパターンを網羅しており、nginxのrewriteモジュールリファレンスはreturn 301とrewrite ... permanentを扱っている。単純な移動であればこちらが近道だ。
サーバールールは、正規ホストの強制やHTTPSの強制、再構成後のパス書き換え、そして条件付きのあらゆる処理に適したツールだ。また、リダイレクトルールが何年もかけて静かに積み重なっていく場所でもあるため、そのファイルは追記するだけの対象ではなく、刈り込む対象として扱おう。
ホスティングプラットフォームのルール
現代的なホストの多くはオリジンの手前に位置し、独自のリダイレクト層を提供している。_redirectsファイル、設定ブロック、ダッシュボード上のルールUIなどだ。これらはアプリケーションが実行される前に評価されるため速く安全であり、プロジェクトの他の部分と一緒にバージョン管理下に置けることから、サイト移行後の一括リダイレクトを置く場所として通常は最適だ。
CMSのプラグインや設定
本格的なCMSにはどれもリダイレクトマネージャーが備わっており、コンテンツチームにとってはこれが正解だ。デプロイ不要、サーバーアクセス不要、監査履歴があり、コンテンツを理解している人がマッピングを決められる。トレードオフは、リダイレクトが発行される前にリクエストがアプリケーションへ到達しなければならないことで、そのため上記の層より遅く、アプリケーションが落ちていれば機能しなくなる。
ページ内のmeta refreshやJavaScript
サーバーサイドで何も手を加えられないときの最後の手段だ。ページが読み込まれた後、<meta http-equiv="refresh">タグかスクリプトによって訪問者をさらに送り出す。機能はするが、フルページロードのコストがかかり、クライアントが実行してくれるかどうかに依存し、検索エンジンはサーバーレスポンスよりも弱いシグナルとして扱う。ほかに手段がないときに使おう。
管理された短縮リンク
リダイレクトされる対象が、自分が所有するページではなく公開したリンクであるなら、リダイレクトはリンクマネージャーに置くべきだ。遷移先はDNSにもサーバーにもデプロイパイプラインにも触れずに変更できる保存された値であり、すべてのホップが記録され、印刷や共有の後もそのリンクは動作し続ける。これこそがURL短縮サービスとは何かの背後にあるメカニズムのすべてであり、印刷されたキャンペーンリンクがランディングページへ直接向いてはいけない理由でもある。
30秒で1つを選ぶ
この判断のほとんどは2つの軸に集約される。誰がアクセス権を持っているか、そして何が生き残らなければならないかだ。
| 方法 | 誰が処理するか | パスとクエリの保持 | 最適な用途 |
|---|---|---|---|
| レジストラ転送 | レジストラのサーバー | 多くの場合されない、要確認 | ドメイン全体の譲渡 |
| Webサーバールール | 自分のオリジン | そう書けばされる | 正規ホスト、再構成 |
| プラットフォームルール | 手前のホスト | される | 一括移行のリダイレクト |
| CMSプラグイン | 自分のアプリケーション | される | コンテンツチーム、デプロイ不要 |
| meta refreshやJS | ブラウザ | されるが遅い | サーバーアクセスが皆無な場合 |
| 管理された短縮リンク | リンクサービス | 保存されたURLからされる | 公開・印刷されたリンク |
パスとクエリ文字列を保持する
**これはテストをすり抜けてしまう失敗だ。**誰もがドメインのルートをテストし、ルートは常にうまくいくからだ。
oldsite.comを単純なドメイン転送でnewsite.comへ向け、それから実際の受信リンクであるoldsite.com/pricing?utm_source=newsletterをたどってみよう。平坦化するリダイレクトでは、その訪問者は新しいホームページに着地し、パスは消え、キャンペーンパラメータもろとも消えてしまう。エラーは何も出ない。アナリティクスはただホームページへの直接トラフィックを示すだけで、そのニュースレターは何の効果もなかったように見えてしまう。
これを防ぐ習慣は2つある。裸のドメインではなく、クエリ文字列を伴う深いURLでテストすること。そして2つのサイトの構造が異なる場合は、すべてをルートへ送るのではなく重要なパスを明示的にマッピングすること。これは古いURLが持っていたSEO価値を最も近い新しいページへつなぎ止めることにもなる。同じ規律は他人のリンクを引き継ぐときにも当てはまり、だからこそ短縮リンクを壊さずに移行することは技術的な作業である前にマッピングの作業なのだ。
問題のリンクが自分で公開したものであるなら、遷移先を編集可能な状態に保つことがこれらすべてよりも価値がある。自分のドメインにリンクを置けば、マッピングはデプロイする設定ファイルではなく、変更するだけのフィールドになる。
公開する前に確認する
1つのコマンドで決着がつく。
curl -sIL "https://oldsite.com/pricing?utm_source=newsletter" | grep -E '^HTTP|^[Ll]ocation'
出力からは3つのことを読み取ろう。ステータスコードは意図したとおりのものであるべきで、恒久的なら301、まだ動いている最中なら302だ。301 vs 302は、この選択が見た目以上に重要である理由を扱っている。Locationヘッダーは裸のドメインではなく、フルパスとクエリ文字列を運んでいるべきだ。そしてリダイレクトはちょうど1回であるべきだ。3回や4回の連鎖でも解決はするが、各ホップはレイテンシであり、パラメータを落とすもう1つの機会でもある。ホスト名が繰り返し現れる場合は、リダイレクトではなくリダイレクトループを作ってしまったということだ。
ターミナルを開きたくないなら、私たちのリンクチェッカーがチェーンを追跡し、すべてのホップでステータスを表示してくれる。
検索エンジンはそれをどう扱うか
正しく行われたリダイレクトはSEOのリスクではなく、この点についてのガイダンスは珍しいほど明確だ。Googleのリダイレクトと検索に関するドキュメントは、恒久的なサーバーサイドリダイレクトをURLをその置き換え先へ集約する最も強いシグナルとして扱い、クライアントサイドのリダイレクトはそれより下位に位置づけ、チェーンを短く保つよう求めている。
実際に代償を払うことになる2つの間違いは、多数の古いURLをホームページへまとめてしまい、それぞれが持っていた固有の関連性を捨ててしまうことと、何度かの移行の後に過去のホップの連鎖をそのまま残してしまうことだ。どちらもリダイレクトを避ける理由にはならず、どちらも監査する理由になる。その監査はリンク切れ防止と同じ週次の習慣であり、リダイレクトがカスタムの短縮ドメイン上にあるなら、短縮リンクのカスタムドメインが設定のうちDNSと証明書の半分を扱っている。
変更を所有する人物に合った層を選び、パスを保持し、1ホップにとどめれば、リダイレクトは心配する対象ではなくなる。
コーナーストーン記事を読む
本稿はtutorialsクラスターに属する。ステータスコードとその意味についてはリダイレクトの種類が地図となり、URL短縮サービスの仕組みがリダイレクトの対象がページではなくリンクである場合に何が起こるかを扱っている。
ブログ内の関連記事
よくある質問
URLを別のURLへリダイレクトするにはどうすればよいですか。
リクエストに応答する側が、新しいアドレスを指す Location ヘッダー付きの301または302を返すようにすればよい。実際には層を選ぶという話になる。レジストラでのドメイン転送、Webサーバーやホスティングプラットフォームでのルール、CMSのプラグイン、あるいは管理された短縮リンクだ。方法が変えるのは誰がレスポンスを返すか、そしてパスとクエリ文字列が残るかどうかであって、ブラウザが受け取るものそのものではない。
DNSでURLをリダイレクトできますか。
できない。そしてこれがこのテーマ全体における最も多い誤解だ。DNSはホスト名をアドレスへ解決するだけであり、どのパスがリクエストされたのかを知る術がなく、リダイレクトを返すこともできない。レジストラがURL転送を提供している場合、実際にはそのホスト名を彼ら自身の小さなWebサーバーへ向けており、そのサーバーが代わりにHTTPリダイレクトを発行しているにすぎない。
リダイレクトはパスとクエリ文字列を保持しますか。
どの方法を選んだかに完全に依存する。レジストラのドメイン転送は多くの場合すべてを1つの遷移先へ平坦化してしまうため、/pricing?utm_source=emailはパラメータが消えたままホームページに着地する。サーバーやプラットフォームのルールはそう書けば両方を保持でき、管理された短縮リンクは保存された遷移先をクエリ文字列も含めて転送する。ドメインのルートだけでなく、深いURLでテストすること。
301と302のどちらのリダイレクトを使うべきですか。
移動が恒久的で、検索エンジンに新しいURLへシグナルを集約させたいなら301を、まだ何かが流動的なうちは302を使おう。実務上の落とし穴は、ブラウザが301を強くキャッシュすることだ。そのためあとで後悔する恒久的なリダイレクトは、サーバー側を変更してからずっと後まで、再訪問者に対して発動し続けてしまう。まず302でテストし、遷移先が確定してから301へ昇格させよう。
リダイレクトが機能しているかどうかはどう確認すればよいですか。
そのURLに対して curl -sIL を実行し、ステータス行と Location ヘッダーを読もう。求めるのは、1回のリダイレクト、正しいステータスコード、そして意図した遷移先が、パスとクエリを保ったまま返ってくることだ。数ホップの連鎖でも動作はするがレイテンシを無駄にし、ホスト名が繰り返し現れる場合はリダイレクトではなくループを作ってしまったということだ。
リダイレクトはSEOに悪影響を及ぼしますか。
正しく実装されたリダイレクトは悪影響を及ぼさない。Googleは301を、ランキングを遷移先へ集約する強いシグナルとして扱っており、問題を引き起こすのはリダイレクトそのものではなく長いチェーンだ。ホップは1つにとどめ、すべてをホームページへ投げ込むのではなく古いURLを最も近い新しいページへ向け、サーバーサイドのリダイレクトが可能な場合はクライアントサイドのリダイレクトを避けよう。
Elidoを試す
URLを貼り付けて短縮リンクを取得
登録不要。リンクは30日間有効。永久に保存するには登録してください。
Free、登録不要 · 1日あたり2件