リダイレクトは訪問者を古いURLから新しいURLへ送り出す仕組みで、サイトを再構築する際にそこへ向かうすべてのリンクを壊さずに済む方法です。本ガイドでは、3種類のソース形式、301と302の使い分け、クエリ文字列、そして検証バッジの読み方について説明します。
KPanelでのリダイレクトの場所
- KPanelにサインインします。
- 左サイドバーのウェブサイトをクリックし、該当のサイトをクリックします。
- サイトの左メニューで設定を開き、続いてリダイレクトを開きます。
直接のアドレスは/websites/<site-id>/redirectsです。
ここでのリダイレクトはアプリケーションが実行される前に、Webサーバーによって適用されます。これにより、プラグインベースのリダイレクトよりも高速であり、アプリケーションがまったく認識しないURLに対しても機能します。
リダイレクトの追加
- リダイレクトを追加をクリックします。
- ソースパスを入力します。
- Destinationを入力します。
- 301 永続的または302 一時的を選択します。
- クエリ文字列を保持にチェックを入れたままにするかどうかを決めます。
- リダイレクトを追加をクリックします。
リダイレクトは適用された後、実際にサイトに対して確認が行われるため、表示されるステータスは推測ではなく実際の挙動を反映しています。
3種類のソース形式
| 形式 | 例 | 一致対象 |
|---|---|---|
| 完全一致 | /old-page | そのパスのみ |
| プレフィックス | /old-path/ | そのパスおよびその配下すべて |
| ワイルドカード | /blog/* | /blog/配下のすべて、残りの部分をキャプチャ |
ワイルドカードのソースは*に一致した部分をキャプチャし、宛先はそれを$1として参照できます。つまり、ソースを/blog/*、宛先を/news/$1とすると、/blog/hello-worldを/news/hello-worldへ送り、1つのルールで他のすべての投稿についても同様に処理します。
リダイレクトの作成後、ソースパスを変更することはできません。間違えた場合は、そのリダイレクトを削除して新しく追加してください。宛先、コード、クエリ設定はいずれも編集可能です。
宛先
宛先は次のいずれかになります。
- 相対パス:
/new-pageのように、同じサイト内の別の場所へ訪問者を送ります。 - 絶対パス:
https://example.com/newのように、まったく別のサイトへ訪問者を送ります。
絶対パスの宛先は、わかりやすい代替パスを作る方法です。たとえば、自分のドメイン上の/docsを、他の場所でホストされているドキュメントに向けるといった使い方です。
301か302か
301 永続的は、ブラウザと検索エンジンに対して、その移動が恒久的であることを伝えます。検索エンジンはランキング信号を新しいURLへ移し、古いURLへのリクエストを停止します。ブラウザはこのリダイレクトをキャッシュし、時には非常に長期間保持します。
302 一時的は、移動が元に戻る可能性があることを示します。何も移されず、長期間キャッシュされることもありません。
本当の再構築、つまりページを移動して戻ってくる予定がない場合は301を使用してください。期間限定キャンペーンやメンテナンス通知へのリンクなど、後で元に戻すと分かっている場合は302を使用してください。
誤った301は取り消すコストが高くつきます。ブラウザは恒久的なリダイレクトを積極的にキャッシュするため、誤ったルールに一度アクセスした訪問者は、そのルールを削除した後もそれに従い続ける可能性があり、あなたがその訪問者のキャッシュを消す手段はありません。確信が持てない場合は、まず302から始め、確信が持てた時点で301に昇格させてください。
クエリ文字列を保持
クエリ文字列を保持は既定でオンになっています。オンの場合、?utm_source=newsletterや他のすべてのパラメーターが宛先までそのまま引き継がれます。
ほとんどの場合、オンのままにしておいてください。クエリ文字列が失われると、キャンペーントラッキング、ページネーション、フィルター、そして状態を保持するリンクがすべて壊れます。リダイレクトの一覧では、この設定がオフになっているルールに(query stripped)という表示が付くため、どのルールがパラメーターを落としているかを一目で確認できます。
これをオフにするのは、宛先が古いパラメーターを決して受け取ってはならない場合だけです。たとえば、古いパラメーターが別の意味に解釈され、誤ったページが表示されてしまうような場合です。
ステータスバッジの読み方
保存するたびに、そのリダイレクトはキャッシュを経由せず実際にサイトに対してテストされ、その結果がStatus列のバッジとして表示されます。
| バッジ | 意味 |
|---|---|
| 未検証 | まだチェックが実行されていません。少し待ってから更新してください |
| コードと宛先付きで「検証済み」 | リダイレクトは有効で、設定どおりに動作しています |
| ステータス付きで「適用済みだが機能していません」 | ルールは書き込まれましたが、サイトは別の応答を返しました |
対応が必要なのは3つ目のバッジです。これは、設定自体は存在するもののリダイレクトが実際には機能していないことを意味し、表示されているステータスコードが代わりに何が起きたのかを教えてくれます。
保存後に、サーバー上の別の設定が同じドメインを使用していると警告が表示されることもあります。その場合、その競合が解決されるまでリダイレクトは適用されず、メッセージにはもう一方の設定名が示されます。これを見てどう対応すればよいか分からない場合は、サポートまでお問い合わせください。
編集と削除
各行には編集ボタンと削除ボタンがあります。
編集では、宛先、コード、クエリ設定を変更できます。ソースは固定です。
削除を行うと確認が求められ、何が起こるかが説明されます。そのパスへのリクエストはリダイレクトされなくなり、サイトがそのパスで通常返す内容(多くの場合404)が返されるようになります。
再構築を計画する
大量のURLを移動する前に、少し順序立てて考えることで多くの手間を省けます。
- 現在のURL一覧をエクスポートする:サイトマップやアナリティクスから取得し、実際にどこにトラフィックがあるかを把握します。
- 古いURLと新しいURLを対応付ける:1行につき1URLで、プレフィックスを共有するものはグループ化します。
- グループにはワイルドカードを使う:1つの
/blog/*ルールは200個の完全一致ルールに勝り、ずれが生じません。 - パターンに従わない例外には完全一致ルールを追加する。
- 各形式を一度ずつテストし、その後バッジを確認します。
- その後、Site Traffic Analyticsで4xxの件数を監視します。 404の割合が上昇している場合は、何かを見落としています。
見落としに備えて、安全策としてブランド化された404ページを追加してください。これにより、行き止まりがサイトへの戻り道に変わります。Custom Error Pagesを参照してください。
トラブルシューティング
リダイレクトが発動しない。 バッジを確認してください。「適用済みだが機能していません」と表示されている場合は、返されたステータスコードを確認してください。200の場合、通常は別の何か、多くの場合アプリケーション自体がリクエストに先に応答していることを意味します。
発動はするが、誤ったURLに到達する。 チェーンが発生していないか確認してください。あなたのルールが、別のルールやアプリケーションによって再度リダイレクトされるパスへトラフィックを送っている可能性があります。チェーンは速度が遅く、検索エンジンを混乱させます。最初のルールを最終的な宛先へ直接向けてください。
ワイルドカードがすべてを1つのページへ送ってしまう。 宛先に$1が欠けています。これがないと、すべてのキャプチャが同じターゲットに集約されてしまいます。
削除したはずのリダイレクトがブラウザでまだ発生する。 以前に301に従ったことがあり、ブラウザがそれをキャッシュしています。プライベートウィンドウでテストし、そのルールが本当に削除されたことを確認してください。
クエリパラメーターが消える。 そのルールでクエリ文字列を保持がオフになっています。編集して再度オンにしてください。
リダイレクトが多すぎる、またはループしている。 2つのルールが互いを指し合っているか、あるルールが自身のソースパターンに一致するパスを指しています。ループの片側を削除してください。
関連ページ
- Custom Error Pages:何にも一致しない場合に訪問者が目にする内容について。
- Site Traffic Analytics:再構築後に3xxと4xxの件数を監視するために。
- Password-Protecting a Site:移動ではなくパスをロックする方法について。