URLを変更するときに必要なリダイレクトに関する基礎知識
最近はノーコードでウェブサイトの公開ができるようになっていますし、AIを使って簡単にウェブサイトも作成できるようになってきています。
その結果、コーダー・エンジニアが介入しなくても公開・運用できるケースが増えています。
簡単にできるようになったのは良いことですが、なにも考えずにパスの変更をしてしまい、その後リダイレクト設定をせずにそのままになっているなんてケースがあります（リダイレクト設定をしないままパスを変えているケースに、ここ最近で2回遭遇しました）。
今回はウェブサイトにおけるリダイレクト設定についてまとめます。
URLを変える = 引っ越し
URLはインターネット上の住所だとよく言われます。
住所を変えるということは、「引っ越し」です。
ドメイン全体を移転する場合も、サイト内の一部のページのURLを変える場合も、対応する新しいページがあれば旧URLからリダイレクトが必要です（ドメイン全体を移転する場合は、旧ドメインを手放してしまうとどうしようもありませんが）。
引っ越すときに引っ越し先の住所を教えていなかったら連絡が取れなくなる可能性がありますし、使っているサービスの住所登録も変更して回る必要があります。
実際の引っ越し手続きでも、郵便局で手続きをしておくと、前の住所に届いた郵便物を新しい住所に届けてくれるサービスがあります。
これと同じことをURLでも行うのがリダイレクト設定です。
リダイレクトは日本語で「転送」と訳されます。元のURLにアクセスが来たら、サーバーが転送先を返し、ブラウザがそのURLへ移動してくれます。
リダイレクト方法にはいくつか種類があり、転送が恒久的なのか一時的なのかによって設定を変える必要があります。
ステータスコードの使い分け
リダイレクト設定時にはステータスコードというものも一緒に指定するのですが、そのときに使うステータスコードは、大きく分けて「恒久的なもの（この先ずっと変わったまま）」と「一時的なもの」に分かれます。
リダイレクトに関連する代表的なステータスコードは下記の通りです。
| コード | 名称 | 区分 | 内容 |
|---|---|---|---|
| 301 | Moved Permanently | 恒久的 | 移転した。もう古いURLは使わない |
| 308 | Permanent Redirect | 恒久的 | 301と同じだが、リクエストのメソッドを変更しない |
| 302 | Found | 一時的 | 一時的に別の場所にある |
| 303 | See Other | 一時的 | 処理の結果を別のURLで見せる |
| 307 | Temporary Redirect | 一時的 | 302と同じだが、メソッドを変更しない |
URLを恒久的に変更したときは、301または308を使います（基本は301）。
そして301と302を間違えると、検索エンジン側での扱われ方が変わってしまいます。
Googleは301と308を、転送先を正規URLとして扱うための強いシグナルにします。ただし、設定した瞬間に検索結果が新URLへ切り替わるわけではありません。
一方、302・303・307は一時的な転送として扱われ、転送元のURLが検索結果に残る場合があります。
普通のウェブサイトのURL変更であれば、301を使うのが基本です。
301リダイレクト設定はキャッシュに注意
301リダイレクト設定はブラウザにキャッシュされることがあり、有効期限などを指定しないと長く残る場合があります。
一度間違った転送先を設定してしまうと、設定を直してもそのブラウザではしばらく直す前の転送先に飛んでしまいます。
自分の環境ならキャッシュを消せば済む話ですが、すでにアクセスしてしまった他ユーザーの環境には干渉できないので注意が必要です。
対策として、301のレスポンスにCache-Control: max-age=3600のような有効期限を付けておく方法があります。
リダイレクト設定はいつまで残す？
「リダイレクト設定はいつまで残せばいいの？」と思う人もいるでしょう。
別サイトからリンクしている可能性がありますし、できることならずっと残しておくのが理想です。
それが難しい場合でも、Googleのサイト移転ガイドでは「できるだけ長く、一般的には最低でも1年」維持するよう案内されています。
ただし、1年経てば古いリンクが無くなるわけではないので、新URLが使われている以上は旧URLもずっと残しておくのが理想だということは知っておきましょう。
リダイレクトの設定方法
リダイレクトの設定方法は、サーバーやホスティング環境によって書き方が変わります。
また、転送元と転送先を並べた表さえあれば、あとはそれを各サーバーの記法に直して設定するだけの作業になります。
ノーコードツール・CMSの場合
冒頭に書いた通り、最近はノーコードツールで作られたサイトも多いです。
たとえばStudioにはBusinessプラン以上だと「リダイレクトページ」、Shopifyには「URLリダイレクト」があります。
設定できる転送元やプランの条件はサービスごとに異なるので、利用中のサービスのヘルプを確認しましょう。
WordPressの場合は、Redirectionのようなプラグインを使うか、後述するサーバーの設定ファイルを使用する方法を利用します。
Apache（.htaccess）
Apacheで.htaccessによる書き換えが許可されている環境なら、下記のように設定できます。
なお、.htaccessは書き間違えるとサイト全体が500エラーになるので、編集前にバックアップを取ってから作業をしましょう。
サイトのルートにある.htaccessで、1ページを転送する例です。
既存のCMSのルールがある場合は、その前に置くなど、評価される順番も確認します。
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]R=301が返すステータスコード、Lはここでルールの処理を止める指定です。
Nginx
Nginxの場合は、対象サイトの既存のserverブロック内に書きます。
location = /old-page/ {
return 301 /new-page/$is_args$args;
}$is_args$argsはクエリ文字列を引き継ぐ指定です。
この例は/old-page/に一致する設定なので、末尾のスラッシュがない旧URLも使われていた場合は、その転送も確認します。
設定後は構文を確認し、成功した場合に再読み込みします。
下記はNginxを直接管理する環境の例で、コンテナや管理サービスではその環境の反映手順に従います。
sudo nginx -t && sudo nginx -s reloadNext.js
Next.jsのリダイレクトは、next.config.jsに設定できます。
下記はCommonJS形式の例です。
既存の設定オブジェクトがある場合は、そこへredirectsを追加します。
module.exports = {
async redirects() {
return [
{
source: '/old-page',
destination: '/new-page',
permanent: true,
},
]
},
}permanent: trueが308、falseが307になります。
301と308は、Googleにはどちらも恒久的な転送として扱われます。
ただし、308はPOSTなどのメソッドを維持しますが、301ではPOSTがGETに変わる場合がある点だけ注意が必要です。
どうしても301を返したい場合は、permanentの代わりにstatusCode: 301を指定できます（両方を同時に指定することはできません）。
設定を変更したら、再ビルド・再デプロイして反映します。
Vercelを使っている場合はvercel.jsonでも設定できますが、同じ転送を複数の場所で管理すると混乱のもとになるため、あらかじめ設定場所を決めておきましょう。
サーバーを触れない場合
何らかの理由でサーバーの設定を触れない環境では、旧URLのHTMLのhead内に、meta要素を書く方法があります。
<meta http-equiv="refresh" content="0; url=https://example.com/new-page/">この設定をしておくとGoogleは待ち時間が0秒のmeta refreshを恒久的な転送として扱ってくれます。
逆に、待ち時間を1秒でも入れると一時的な転送として扱われるので、ここは0秒で書きます。
しかし、HTMLを読み込ませてから移動させる方式なので転送開始までHTMLの読み込みが必要ですし、そもそもHTMLを返さないPDFや画像には使えません。
サーバー側で設定できるならそちらを使うようにしましょう。
他にもJavaScriptでlocation.hrefを書き換える方法もありますが、リダイレクト方法としてはさらに優先度の低い選択肢になります。
リダイレクトでやりがちな失敗
リダイレクトの設定はできているものの、失敗してしまっていたり理想的とは言えない設定になっている場合もあります。
全部トップページに飛ばしている
古いURLをまとめてトップページへ301でリダイレクトさせる設定を見かけますが、転送元と内容が対応しない場合、Googleからソフト404として扱われることがあります。
ユーザーからしても、読みたかった記事を開いたらトップページに飛ばされるのはイライラします。
面倒でも、ページごとに対応するリダイレクト先を決めます。
本当に該当するページが無くなった「削除」の場合は、リダイレクトではなく404または410を返しましょう。
リダイレクトが数珠つなぎになっている
リニューアルを何度か繰り返したサイトでよく起きますが、「A → B → C → D」のようにリダイレクトが数珠つなぎになっていると、そのぶん表示が遅くなります。
新しいリダイレクト設定をする場合は、古いリダイレクト設定も見直して、できるだけ1回で終わるようにしましょう。
リダイレクトループしている
AからBへ、BからAへリダイレクトする設定になっているパターンです。
「www」あり・なしの統一と「http」から「https」への転送を別々のルールで書いたときに起こりやすく、ブラウザには「リダイレクトが多すぎます」とだけ表示されます。
ルールを複数書いたら、実際にアクセスして必ず確認しましょう。
クエリ文字列を使っているURLは、その値が必要な形で引き継がれるかも見ます。
ドメインが変わるならアドレス変更ツールを使う
ドメインごと引っ越す場合は、Search Consoleの「アドレス変更ツール」を使いましょう（同じドメイン内のパス変更や、HTTPからHTTPSへの変更には使わないので注意）。
使うときは301リダイレクトを設定したうえで、新旧どちらのプロパティも同じアカウントで所有している必要があります。
このツールで送られるシグナルが続くのは180日間ですが、180日経ってもリダイレクト設定は残したままにしておくのが理想です。
まとめ
とりあえず最低限覚えておきたいのは、恒久的なURL変更なら301のリダイレクトを使うことです。
リダイレクトは、知っていれば設定自体はそこまで難しいものではありません。
しかし、ページを増やす作業や文言を直す作業と同じ感覚でURLが変更され、そもそもリダイレクトの話が出てこないまま公開されているケースが多いように感じます。
ノーコードツールでスラッグを1つ書き換えるのは数秒で終わりますが、それがどう影響するのかを知っておかないと気づきすらしません。
作業手順を整理して社内で共有し、作業時はそれに沿って行うなど、「誰かが気付かないとそのまま進んでしまう」状態にならないような工夫が必要です。
