301リダイレクトの使いどころ・設定方法・確認方法

要点: 301リダイレクトは、URLが恒久的に移転したことをブラウザと検索エンジンに伝えます。Googleは301と308を、リダイレクト先を正規URLにすべきという強いシグナルとして扱います。302と307は一時的なもので、元のURLが残ります。すべてのサイトは1つのアドレスだけで応答する必要があります。http://、https://、wwwあり、wwwなしのすべてが、1ホップで同じ最終URLにリダイレクトされなければなりません。リダイレクトは少なくとも1年間は維持し、内部リンクは最終アドレスに更新し、到達先だけでなくチェーン全体を確認してください。

リダイレクトは正常に動いている間は目に見えません。問題が起きても、症状は曖昧です。wwwありとなしで順位が分散する、移行後に何か月もトラフィックが落ちる、トップページが3つのアドレスを経由するため表示に余計に1秒かかる、といった具合です。こうした問題の多くは、自分のアドレスの各バージョンを最後までたどれば1分で見つかります。

このガイドでは、リダイレクトの種類とGoogleの扱い、すべてのサイトが統合すべきホストバージョン、チェーンとループ、主要なサーバーでの設定、無料のリダイレクトチェッカーの仕組み、報告される各問題の解決方法を解説します。

リダイレクトとは

リダイレクトとは、「このリソースは別の場所にあります」と伝え、新しいアドレスをLocationヘッダーで示すレスポンスです。ブラウザは新しいアドレスへ自動的にリクエストします。サーバーサイドのリダイレクトは、通信上では次のようになります。

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

ステータスコードは、移転をクライアントがどう扱うべきかを示します。MDNでは、リダイレクトを恒久的なもの(クローラーが「元のURLを更新する」)と一時的なもの(クローラーが「記憶しない」)に分けています。

Googleのリダイレクトに関するドキュメントでは、即時のmeta refresh(0秒)とJavaScriptのlocation変更も恒久的なものに分類し、遅延のあるmeta refreshは一時的なものとしています。可能な限りサーバーサイドの恒久リダイレクトを推奨しており、レンダリングが失敗することがあるため、「サーバーサイドやmeta refreshのリダイレクトが使えない場合にのみJavaScriptリダイレクトを使う」よう述べています。

リダイレクトがSEOで重要な理由

重複を統合します。 Googleの正規化ガイドは、リダイレクトを「リダイレクト先が正規になるべきという強いシグナル」として挙げています。リダイレクトがないと、同じコンテンツに対するリンクなどのシグナルが複数のURLに分散することがあります。

移行時にページを引き継ぎます。 URLが変わるとき、旧URLからそれぞれ対応する新URLへ301を設定すると、Googleにインデックス内の入れ替えを伝えられ、古いリンクからの訪問者を正しいページへ送れます。

HTTPSを守ります。 Googleは「同等のHTTPページよりHTTPSページを正規として優先」し、同じガイドでHTTPからHTTPSへのリダイレクトをそれを補強する方法の1つとして挙げています。

時間がかかります。 ホップのたびに、ページの読み込みが始まる前にラウンドトリップが1回増えます。モバイル回線では、3回のリダイレクトチェーンは何も表示されない時間として体感できる遅延になります。

1サイト、1アドレス

クローラーにとって、次の4つは同じページを表示していても別々のサイトです。

http://example.com/
http://www.example.com/
https://example.com/
https://www.example.com/

1つ(通常はwwwありまたはなしのHTTPS版)を選び、残りの3つが1回の301でそこへ直接転送されるようにします。wwwありかなしかは好みの問題です。重要なのは、200で応答するバージョンが1つだけであることです。また、TLS証明書がexample.comとwww.example.comの両方をカバーしていることも確認してください。そうでないと、https://wwwのリダイレクトは実行される前に失敗します。

同じルールはサイト内にも当てはまります。/pricingと/pricing/の両方が200で応答するなら、一方の形式を選び、もう一方をリダイレクトしてください。

チェーンとループ

チェーンとは、リダイレクトが別のリダイレクトにつながっている状態です。最も多いのは、プロトコルとホストを別々のステップで処理しているケースです。

http://www.example.com/  301 →  https://www.example.com/  301 →  https://example.com/

Googleのクローラーは「最大10回のリダイレクトホップをたどり」ます(HTTPステータスコードとGoogle検索)。そのため、2ホップのチェーンでページが失われることはありません。しかしGoogleのサイト移転ガイドは、「リダイレクトのチェーンを避け」、「最終的な移転先へ直接」リダイレクトするよう述べており、それが難しい場合はチェーンを短く、「3回以内が理想で、5回未満」に抑えるよう示しています。どちらにしても、ホップごとのコストは訪問者が負担します。

ループは終わらないチェーンです。AがBに、BがAにリダイレクトされる状態で、サーバーのHTTPSルールとCDNの別のルールが食い違っていることがよくあります。MDNによると、ブラウザはループを検出してエラーを表示するため、ページには到達できなくなります。

301リダイレクトの設定方法

Apache(.htaccessまたはバーチャルホスト)で、すべてのバージョンをhttps://www.example.comに統合する例:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

単一ページならRedirect 301 /old-page https://www.example.com/new-pageで十分です。MDNによると、コードを指定しないRedirectは、デフォルトで302を返します。

Nginxでは、1つのserverブロックでそれ以外のすべてのバージョンを受け止めます。

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    # ssl_certificate lines here for the 443 listener
    if ($host = example.com) { return 301 https://www.example.com$request_uri; }
    if ($scheme = http)      { return 301 https://www.example.com$request_uri; }
    # ... the site itself
}

別々のserverブロックに分ける構成も多く、各バージョンが1ステップで最終アドレスに到達するなら、どちらでも問題ありません。

Next.jsでは、next.config.jsに記述します。

module.exports = {
  async redirects() {
    return [
      { source: '/old-blog/:slug', destination: '/blog/:slug', permanent: true },
    ]
  },
}

Next.jsのドキュメントによると、リクエストメソッドを保持するため、permanent: trueは308、permanent: falseは307を返します。Googleは308を恒久的なものとして扱うので、問題ありません。

CDNとホスティング。 多くのCDNやホスティングの管理画面には、リダイレクトルールや「常にHTTPSを使用」のスイッチがあります。役割ごとに1つのレイヤーを使いましょう。CDNがHTTPをHTTPSに引き上げ、オリジンサーバーもホストをリダイレクトすると、2ホップのチェーンになり、両者が食い違うとループになります。

WordPress。 「設定」›「一般」のサイトアドレスが正規ホストを決め、WordPressは他のホストをそこへリダイレクトします。ページ単位のリダイレクトにはリダイレクトプラグインやSEOプラグインのリダイレクト管理機能を使い、ホストの統合にはサーバールールを優先してください。

Searviaのリダイレクトチェッカーの仕組み

リダイレクトチェッカーは、ウェブサイトSEOチェッカーと同じエンジンを使っています。ドメインを入力すると、トップページとその周辺のファイルを38項目のチェックで約20秒で監査し、このツールの主題である3つのチェックを最初に表示します。それぞれの内容は次のとおりです。

リダイレクトと重複バージョン(中優先度)。 チェッカーは入力されたドメインからwww.を取り除き、4つのアドレス(http://とhttps://、それぞれwwwありとなし)を開きます。それぞれを最大6回のリダイレクトまでたどり、到達先と各ホップのステータスコードを記録します。トップページの最終アドレスと同じスキームとホストに、恒久的な(301または308)リダイレクトだけで到達すれば、そのバージョンは合格です。結果は次のとおりです。

• 不合格:いずれかのバージョンが別の場所に到達する場合。たとえば、https://www.example.comがメインサイトなのにhttps://example.comが独自のページで応答する場合や、あるバージョンがリダイレクトループに入る場合、6回を超えるリダイレクトが必要な場合です。
• 警告:いずれかのバージョンが一時的なリダイレクト(302、303、307)を使っている場合、または入力したアドレスが応答するまでに、https://と入力ホストを起点に数えて1回を超えるリダイレクトホップが必要な場合です。
• 合格:すべてのバージョンが恒久的なリダイレクトで同じサイトに到達し、メインアドレスが1ホップ以内で済む場合です。

レポートには4つのバージョンそれぞれについて、最終URL、途中のリダイレクトコード(例:301 › 301)、チェックマークまたはバツ印が表示されます。名前解決できない、または到達できないバージョン(たとえばDNSレコードのないwwwホスト)は、不合格にはならず対象から除外されます。

HTTPS(高優先度)。 リダイレクトをたどらずに、http://とホスト名でリクエストします。サイトがHTTPSで動作し、HTTPリクエストに対してLocationがhttps://で始まる3xxが返れば合格です。「HTTP does not redirect to HTTPS」または「The site does not work over HTTPS」で不合格になります。プレーンHTTPがまったく応答しない場合はリダイレクトをテストできないため、合否ではなくメモが表示されます。

ページのステータス(高優先度)。 最終ページは2xxのステータスで応答する必要があります。4xxまたは5xxは不合格です。

テストしないもの

• meta refreshとJavaScriptのリダイレクト。 たどるのはHTTPリダイレクトだけです。metaタグでリダイレクトするバージョンは、自分自身に到達したものとして表示されます。
• 下層ページ。 テストするのはトップページのアドレスだけです。移行後のページ単位のリダイレクトは、旧URLのリストをクロールして確認してください。
• バージョンごとのホップ数。 ホップ数の警告はメインアドレスのホップだけを数えます。http://wwwでの2ホップの恒久チェーンは、表にコード(301 › 301)が表示されますが、結果は下がりません。各ホップのURLを確認するにはcurlを使ってください。

各ホップのURLとコードをすべて確認するには:

curl -sIL http://www.example.com/ | grep -iE '^(HTTP|location)'

結果の読み方

総合評価は38項目すべてを対象に、優先度で重み付けされています(高10、中5、低2。警告は半分)。「まず修正すべき項目」のリストと、共有できるレポートリンクも付きます。

チェッカーが報告するすべての問題の解決方法

1. 一部のバージョンがメインアドレスにリダイレクトされない

1. 最終アドレスを決めます:https://www.example.comまたはhttps://example.com。
2. レポートの表で、誤ったURLに到達しているバージョンを確認します。
3. それぞれから最終アドレスへ、パスを維持したまま直接301を追加します(Nginxでは$request_uri、Apacheでは$1)。
4. 外れたバージョンがまったく別のホストに到達する場合は、DNSを確認します。wwwの古いAレコードが、パーキングページや以前のホストを指している可能性があります。
5. canonicalタグ、サイトマップ、内部リンクもすべて最終アドレスを使っていることを確認します。canonicalと矛盾するリダイレクトは、シグナルを混乱させます。
6. リダイレクトチェッカーを再実行します。

2. アドレスが複数回リダイレクトされる

1. 入力したアドレスに対してcurl -sILコマンドを実行し、チェーンを確認します。
2. ステップを統合します。上のApacheとNginxの例のように、最終URL以外のすべてのバージョンを最終URLへ直接送る1つのルールにします。
3. CDNとオリジンの両方がリダイレクトしているなら、どちらか一方に任せます。通常は、CDNがHTTPからHTTPSを処理してオリジンは何もしないか、オリジンが両方を処理してCDNはリクエストを通過させます。
4. 自分で管理しているリンクを更新します。ロゴのリンク、ナビゲーション、メールの署名、ソーシャルのプロフィール、広告の遷移先は、最終アドレスを指すようにします。

3. HTTPがHTTPSにリダイレクトされない

1. 有効な証明書が、ネイキッドドメインとwwwの両方をカバーしたうえでHTTPSが動作していることを確認します。
2. すべてのhttp://のURLから、対応するhttps://のURLへ、パスを維持したまま恒久的なリダイレクトを追加します。
3. すべてがHTTPSで動作するようになったら、HSTS(Strict-Transport-Security: max-age=31536000; includeSubDomains)を検討してください。ブラウザがHTTPリクエストを完全に省略するようになります。GoogleはHSTSを、HTTPSを正規として補強するもう1つの方法として挙げています。セキュリティヘッダーチェッカーで確認できます。

4. サイトがHTTPSで動作しない

証明書をインストールし(Let's Encryptは無料で、多くのホスティングが自動化しています)、使用するすべてのホスト名をカバーしていることを確認してから、ステップ3のHTTPからHTTPSへのリダイレクトを追加します。次に片付けるべきはミックスコンテンツ、つまりまだhttp://で読み込まれているスクリプトや画像です。

5. トップページが200で応答しない

5xxはサーバーの問題なので、エラーログを確認してください。403は、ファイアウォールやボット対策が自動リクエストを拒否していることが多く、検索クローラーも拒否している可能性があります。トップページの404は、通常、リダイレクトが存在しなくなったパスへ訪問者を送っていることを意味します。リダイレクト先を修正し、再チェックしてください。

6. 一時的なリダイレクト、ループ、長いチェーン

1. バツ印の付いた行を見つけ、そのコードを確認します。ホストのバージョン間にある302、303、307は301または308に変更すべきです。一時的なものはデフォルト設定であることが多い(コードなしのApacheのRedirectは302を返す)ため、サーバー、CDN、プラグインを確認してください。
2. ループは通常、2つのレイヤーが食い違っていることを意味します。たとえば、CDNがHTTPSをHTTPへ送り、オリジンがHTTPをHTTPSへ送るケースです。どちらか一方をオフにします。
3. 6ホップを超えるチェーンは、ステップ2のように最終アドレスへ直接向かう1つのルールに置き換えます。

移行時のリダイレクト

URLが変わるとき、上記のホストレベルのルールは出発点にすぎません。Googleのサイト移転ガイドは、次の点を加えています。

1. すべての旧URLを対応する新URLにマッピングします。 サイトマップ、サーバーログ、アナリティクス、CMSを使います。すべてをトップページにリダイレクトするのは、マッピングとは言えません。
2. 最終的な移転先へ直接リダイレクトします。 再度リダイレクトするURLには転送しないでください。
3. 各新URLに自己参照のcanonicalを設定し、内部リンクを更新して、すべてのサイトマップに新URLを載せます。
4. リダイレクトは可能な限り長く、一般的には少なくとも1年間維持します。

多言語サイトについては、Googleからもう1つルールがあります。訪問者の所在地やブラウザの言語に基づいて言語バージョン間で自動的にリダイレクトするのは避けてください。「Googlebotクローラーは通常、米国から来る」ため、他のバージョンを見られないことがあるからです(多地域サイト)。代替策はhreflangガイドで解説しています。

実例(架空)

以下は架空の例であり、実際のデータではありません。架空の家具店Bramble & Coが、新しいプラットフォームに移行しました。リダイレクトチェッカーの結果は次のとおりです。

https://のネイキッドドメインは、リダイレクトされずにサイト全体で応答していました。新しいプラットフォームが両方のホストを配信しており、ホストのルールがあったのは旧サーバーだけだったのです。また、コードから、http://bramble.example/は2ホップで、最初が302だったこともわかりました。チームはCDNに、最終バージョン以外のすべてに適用する301ルールを1つ追加し、チェーンを避けるためプラットフォーム側のHTTPSリダイレクトを削除して再チェックしました。4つのバージョンすべてが、1ホップでhttps://www.bramble.example/に到達するようになりました。

15分でできるリダイレクトチェックリスト

1. 自分のドメインで無料のリダイレクトチェッカーを実行します。
2. 4つのバージョンすべてが1つのアドレスに到達していることを確認します。
3. レポート(またはcurl -sIL)で各バージョンのコードを確認します。1ホップで、ステータスは301または308であること。
4. canonical、サイトマップ、内部リンクが最終アドレスを使っていることを確認します。
5. 証明書がネイキッドドメインとwwwの両方をカバーしていることを確認します。
6. 移行後は旧URLのサンプルをテストし、リダイレクトを少なくとも1年間維持します。

Searviaでできること

無料のリダイレクトチェッカーは、アドレスのすべてのバージョンをたどり、HTTPSとトップページのステータスを、共有できる1つのレポートにまとめます。Searviaのアカウントでは、サイト監査が毎週サイト全体をクロールし、リダイレクトを指す内部リンク、サイトマップ内のリダイレクトまたは壊れたURL、エラーを返すページを検出するので、あらゆる場所で最終アドレスに直接リンクできます。稼働監視は24時間体制でサイトを監視し、ダウンしたときや証明書の期限が近づいたとき(HTTPSリダイレクトが最も壊れやすいタイミング)に通知します。技術的なチェックの全体的な順序は、テクニカルSEO監査ガイドをご覧ください。