リダイレクト

TL;DR — リダイレクトは、古い URL をリクエストした訪問者を新しい URL へ転送します。最も一般的なのは 301（「恒久的に移動」）で、古いページのランキングシグナルを新しい URL へ移すよう Google に伝えます。302 は「一時的」です。恒久か一時かを正しく選び、JavaScript ではなく実際のサーバーレベルのリダイレクトを使えば、重要事項の90%を押さえられます。

リダイレクトとは

HTTP リダイレクトは 3xx レスポンスと Location フィールドを使い、クライアントを別の URI へ誘導します。 この主張の根拠 Primary standard or official documentation supporting the adjacent article claim. 対象範囲： Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. 信頼度： 高 · 検証日： 2026-07-14 RFC 9110: Redirection Google は恒久リダイレクトを強いカノニカルシグナルとして扱いますが、転送先のインデックス登録を保証しません。 この主張の根拠 Primary standard or official documentation supporting the adjacent article claim. 対象範囲： Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. 信頼度： 高 · 検証日： 2026-07-14 Google: Redirects and Search

ページを移動したとき、訪問者や Google が古いアドレスで行き止まりになるのは避けたいものです。リダイレクトは、訪問者を新しいアドレスへ自動転送する指示です。古いリンクをクリックすると、サーバーが新しいページを返します。

内部的には、リダイレクトは特定のサーバーレスポンスにすぎません。300 番台（多くは 301 または 302）のステータスコードと、代わりの移動先を示す Location ヘッダーです。利用時にこの仕組みを意識する必要はありませんが、「このページは移動しました。ここをクリック」という案内より信頼できる理由はここにあります。

最も重要な2種類

• 301 — Moved Permanently。 移動が恒久的な場合に使います。ページの新しい所在を検索エンジンへ伝え、古いページの順位とリンクを新しい URL へ引き継ぎます。最もよく使う種類です。
• 302 — Found（一時的）。 短期キャンペーン、A/B テスト、後で戻すページなど、一時的な移動に使います。恒久的な変更ではないため、ランキングシグナルを移さないよう Google へ伝えます。

ほかにも 303、307、308 がありますが、多くのサイトでの実務的な判断は、恒久的な移動（301）か、一時的な移動（302）かです。

設定方法

• サーバーで設定 — Apache の .htaccess または nginx の設定ルール。古典的な方法です。
• CMS プラグインで設定 — WordPress のリダイレクトプラグインは通常、代わりに .htaccess を編集します。
• CDN／エッジで設定 — Cloudflare などでは、リクエストがサーバーへ到達する前にリダイレクトできます。

可能なら、スクリプトでブラウザを転送する JavaScript リダイレクトは避けてください。Google は対応できますが、ページのレンダリングに成功した後でしか処理できません。この追加段階は失敗することがあるため、本物のサーバーリダイレクトより遅く、信頼性も低くなります。

よくある間違い

リダイレクトとカノニカルタグは同じではありません。古い URL が存在しなくなり、全員を新しい URL へ送るべき場合はリダイレクトします。複数の URL を公開したまま、1つを「主要」版として Google に扱ってほしい場合（トラッキングパラメータ付き商品ページなど）はカノニカルタグを使います。リダイレクト＝1つの URL だけが残る。カノニカル＝複数が残り、1つを優先する、という違いです。

プロトコルレベルの詳細、301／302／303／307／308 の全体像、維持期間、チェーンやループの落とし穴は、Advanced タブで確認してください。

TL;DR — リダイレクトは 3xx ステータスコードと Location ヘッダーを持つ HTTP レスポンスです。SEO より先にプロトコルがあります。Google はコードを2つのカノニカル化区分にまとめます。恒久（301／308）＝強いシグナルでシグナルを転送先へ統合し、一時（302／303／307）＝弱いシグナルで通常は元に残しますが、長期間の一時リダイレクトは扱いが変わることがあります。307 と 308 は HTTP メソッドと本文を維持し、301 と 302 は維持しない場合があります。サーバー側、CDN／エッジ（私の推奨）、CMS プラグインで実装します。JS と遅延 meta refresh はレンダリングに依存するため弱い選択肢です。適切な単一リダイレクトで PageRank は失われません。実際のリスクはチェーン（避ける）とループ（検索エンジンが無視）です。少なくとも1年間維持してください。また、リダイレクトはカノニカルタグではありません。

プロトコルレベルで見たリダイレクトの実体

リダイレクトのステータスコードには、HTTP メソッドの扱いについて標準化された意味があります。 この主張の根拠 Primary standard or official documentation supporting the adjacent article claim. 対象範囲： Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. 信頼度： 高 · 検証日： 2026-07-14 RFC 9110: Redirection 検索向けガイダンスは恒久・一時のシグナルを区別し、移転には直接のサーバー側リダイレクトを推奨しています。 この主張の根拠 Primary standard or official documentation supporting the adjacent article claim. 対象範囲： Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. 信頼度： 高 · 検証日： 2026-07-14 Google: Redirects and Search

多くの SEO 記事は、リダイレクトの実体を説明せず「301 は恒久的」と言い始めます。しかし仕組みを理解すると、その後のすべてを説明できます。MDN は、“redirection is triggered by a server sending a special redirect response to a request. Redirect responses have status codes that start with 3, and a Location header holding the URL to redirect to.” (訳) 「リダイレクトは、サーバーがリクエストへ特別なリダイレクトレスポンスを送ることで発生します。レスポンスには 3 で始まるステータスコードと、転送先 URL を保持する Location ヘッダーがあります」と説明しています。

つまりリダイレクトは、301、302、303、307、308 などの 3xx ステータスコードと、転送先を示す Location ヘッダーの組み合わせです。ブラウザやクローラーはレスポンスを読み、Location の URL を再リクエストします。ステータスコードは恒久／一時、メソッド維持の有無という意味を表し、Location はアドレスです。SEO 上のすべての影響は、どの 3xx コードを送るかから生じます。

Ahrefs の 11 Types Of Redirects & Their SEO Impact では、SEO の観点から “A redirect is a way to send people and bots to a new URL when they request the old URL, but the page has changed locations.” (訳) 「ページの場所が変わったとき、古い URL をリクエストした人やボットを新しい URL へ送る方法」と説明しました。

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

Google のリダイレクト文書 は目的を明確に示します。“Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location.” (訳) 「URL のリダイレクトとは、既存 URL を別の URL に解決し、ページの場所が変わったことを訪問者と Google 検索へ実質的に伝えること」です。SEO 上の結果は恒久性で明確に分かれます。

• 恒久リダイレクトでは、検索結果に新しい転送先が表示されます。
• 一時リダイレクトでは、検索結果に転送元ページが残ります。

リンク価値の側面もあります。Google はリダイレクトの両端を追跡します。“When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent.” (訳) 「URL をリダイレクトすると、Google は転送元（古い URL）と転送先（新しい URL）の両方を追跡します。どちらかがカノニカルになり、その選択はリダイレクトが一時的か恒久的かなどのシグナルに依存します」。恒久リダイレクトはシグナルを新しい URL へ前向きに統合し、一時リダイレクトは通常、古い URL に残します。

リダイレクトの全体像：301、302、303、307、308

各コードにはこのサブクラスター内の詳しい解説があります（「次に進む場所」を参照）。概要は次のとおりです。

• 301（Moved Permanently） — 最も一般的な恒久リダイレクト。強いカノニカル化シグナルで、ランキングシグナルを転送先へ統合します。Google の文書では “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (訳) 「Google はリダイレクトをたどり、転送先を処理すべきという強いシグナルとして使用します」。
• 302（Found） — 標準的な一時リダイレクト。Google はたどり、“and Google systems use the redirect as a weak signal.” (訳) 「弱いシグナルとして使用します」。ゼロではなく弱いため、長期間残すと 301 のように扱われる場合があります。
• 303（See Other） — 例外的なコード。一時区分で、Post/Redirect/Get パターン（フォーム送信後、GET で結果ページへ転送）に使われます。SEO ではまれで、Google の扱いは本当に不明確です。機能によって 301 または 302 のように振る舞う可能性があります。
• 307（Temporary Redirect） — SEO 上は 302 と同じですが、HTTP メソッドと本文を維持します。Google は “equivalent to 302.” (訳) 「302 と同等」と説明します。HSTS を使う HTTPS サイトでは自動的に現れることもあります。
• 308（Permanent Redirect） — SEO 上は 301 と同じですが、メソッドと本文を維持します。Google は “equivalent to 301.” (訳) 「301 と同等」と説明します。

307／308 が元のメソッドと本文を維持し、301／302 ではクライアントが途中で POST を GET に変えられるという違いは、Google のランキングには影響しません。しかしフォーム送信や API 呼び出しのリダイレクトでは重要です。Google も不用意に選ばないよう、“While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (訳) 「Google はこれらを同様に扱いますが、意味は異なります。電子書籍リーダーや他の検索エンジンなどのクライアントにも有益となるよう、用途に適したコードを使ってください」と案内しています（Cheat Sheets タブに比較表があります）。

リダイレクトがクロール、インデックス登録、リンク価値へ与える影響

区分は2つで、違いは1つです。Google の文書では恒久リダイレクト（301、308、即時 meta refresh、JS の location）について、“the indexing pipeline uses the redirect as a signal that the redirect target should be canonical,” (訳) 「インデックス登録パイプラインは、転送先をカノニカルにすべきというシグナルとしてリダイレクトを使う」と説明します。一時リダイレクト（302、303、307、遅延 meta refresh）では、“the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (訳) 「転送先をカノニカルにすべきというシグナルとして使いません」。

PageRank が失われるという説は過去のものです。 リダイレクトで「リンク価値の10〜15%を失う」という古い説は、何年も前から正しくありません。Google の Gary Illyes は2016年に、“30x redirects don’t lose PageRank anymore,” (訳) 「30x リダイレクトで PageRank はもう失われない」と述べ、John Mueller は当時すでに新情報ではないと指摘しました。正しく実装した単一リダイレクトは、ページのシグナル価値をほぼすべて渡します。コストはリダイレクト自体ではなく、チェーンとループから生じます。

リダイレクトを維持する期間。 Google のサイト移転ガイダンスは、すべてのシグナルを新 URL へ移すため、“keep the redirects for as long as possible, generally at least 1 year” (訳) 「可能な限り長く、通常は少なくとも1年間維持」するよう案内しています。Gary Illyes は “after 1 y all signals had time to pass on from A to B.” (訳) 「1年後にはすべてのシグナルが A から B へ移る時間があった」と述べました。私は実際に検証しました。古いコンテンツから Ahrefs の4記事へ設定し1年以上経過した 301 を削除すると、“a clear drop in referring domains after I did this,” (訳) 「参照ドメインが明確に減少」しましたが、“not much drop in traffic to these posts.” (訳) 「記事へのトラフィックはあまり減少しません」でした。結論は、“I’m not willing to conclusively say that permanent redirects pass value even after one year, but what Gary said seems to mostly hold true.” (訳) 「恒久リダイレクトが1年後も価値を渡すとは断言できませんが、Gary の発言はおおむね正しいようです」。安全な既定方針は、古いリダイレクトを不用意に削除しないことです。

リダイレクトチェーンとリダイレクトループ

• リダイレクトチェーンは、リクエスト URL と最終転送先の間に複数のホップがある状態です（ページ1 → ページ2 → ページ3）。Google は最大10ホップをたどり （“By default, Google’s crawlers follow up to 10 redirect hops” (訳) 「既定で Google のクローラーは最大10のリダイレクトホップをたどる」）、現行のサイト移転ガイダンス ではチェーンを避け、不可避なら3以下、5未満にするよう案内しています。10はクローラーの上限、3〜5は実務ガイダンスで、矛盾する制限ではありません。チェーンは遅延を増やし、クロールバジェットを浪費し、分析を曖昧にします。
• リダイレクトループは自分の尾を食べるチェーンです。URL が自分自身やチェーン内の前の URL へ戻り、解決しません。ブラウザは「リダイレクトが多すぎます」とエラーを出し、検索エンジンは処理を諦めます。John Mueller は次のように述べました。 “a redirect loop is a URL that doesn’t work, so it’s essentially a broken link. We ignore these for search.” (訳) 「リダイレクトループは機能しない URL、つまり実質的に壊れたリンクです。検索では無視します」。ループはクローラーを閉じ込め、サーバー資源も浪費します。

よく知られる5ホップという数値には、過去の担当者ガイダンスもあります。2014年のウェブマスターハングアウトの46:03 で、John Mueller は Googlebot が1回のクロールで最大5つのリダイレクトをたどり、残りがあれば次回に続けると説明しました。2020年にも、1回のクロール試行で最大5ホップと説明しています。これらの歴史的発言は数値の背景を示しますが、現行文書を上書きせず、長いチェーンが特定のスケジュールで必ず再開される保証でもありません。

私の独立した実務観察では、Google は長いチェーンの処理を再開することが多く、私は約5ホップを修正優先度のしきい値にしています。これは観察に基づく運用判断であり、Google プラットフォームの上限ではありません。リダイレクトを管理できるなら、目標は常に直接の1ホップです。

どちらにも下記の専用記事があります。

リダイレクトの実装方法

リダイレクトを置く唯一の「正解」はありません。維持管理できる場所を選びます。

• サーバー側設定。 Apache の .htaccess、nginx ルール、サーバー側スクリプト。多くのサイトの既定で、最も信頼できます。WordPress では “most WordPress installs will be running Apache and the plugins used for redirecting will actually be editing a website’s .htaccess file” (訳) 「多くの WordPress 環境は Apache で動作し、リダイレクトプラグインは実際にはサイトの .htaccess を編集します」。プラグインは使いやすいフロントエンドです。
• CDN／エッジ。 Cloudflare ルールや edge worker は、リクエストがオリジンへ届く前に動きます。私の好みは “I typically prefer to have redirects on the edge (CDN-level) over having them on the server.” (訳) 「通常はサーバーよりエッジ（CDN レベル）にリダイレクトを置く」です。ただし多くの人には “always recommend going with what is easiest for you to implement. For many people that is server-level redirects.” (訳) 「最も実装しやすい方法を常に推奨し、多くの場合はサーバーレベル」と案内しています。
• クライアント側：meta refresh。 <meta http-equiv="refresh"> タグ。即時（0秒）は Google に恒久と解釈され、遅延は一時と解釈されます。サーバーリダイレクトより遅く不格好ですが、唯一の手段になる場合があります。
• クライアント側：JavaScript。 スクリプトが window.location を設定します。Google は対応できますが、独立して失敗し得るレンダリングが成功した場合だけです。Google は “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (訳) 「サーバー側または meta refresh を使えない場合にのみ JavaScript リダイレクトを使用」と案内しています。恒久リダイレクトの推奨順序は、308／301 → meta refresh 0 → JavaScript → crypto です。

リダイレクトとカノニカルタグの違い

両者は別の問題を解決しますが、常に混同されています。

• リダイレクト — 古い URL が独自コンテンツの提供を完全に停止すべき場合に使います。今後存在する URL は1つだけです。古いアドレスは転送し、独自ページを返しません。
• カノニカルタグ — 複数 URL を公開し、個別にアクセス可能なままにする必要がある一方、1つを優先版として Google に扱ってほしい場合に使います。ファセットナビゲーションの派生形、トラッキングパラメータ URL、印刷版などはすべてアクセス可能で、主要版へ rel=canonical を向けます。

Bing も2025年12月の重複コンテンツ記事 で、“Use 301 redirects to consolidate variants into a single preferred URL. Apply canonical tags when multiple versions must remain accessible.” (訳) 「派生版を1つの優先 URL へ統合するには 301 を使い、複数版をアクセス可能に保つ必要がある場合はカノニカルタグを使う」と明確に区別しています。カノニカルのヒントが無視され、本当に統合したいならリダイレクトへ強められますが、その重複 URL が独自コンテンツを提供し続ける必要がない場合に限ります。

Bing について

方向性として Bing は Google と一致し、恒久移転には 301、一時移転には 302 を使います。Bing の Fabrice Canel は次のように述べています。転送先が2日以内に変わる可能性があるなら “preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended,” (訳) 「302 が望ましく、それ以外は 301 を推奨」。同僚の Frédéric Dubut は「2日」は厳密なしきい値ではなく、“anytime a redirect is temporary… you should use 302s.” (訳) 「リダイレクトが一時的なら常に 302 を使う」と補足しました。転送先がどれほど早く変わるかに沿って表現した同じメンタルモデルです。

次に進む場所：リダイレクトのサブクラスター

このハブは全体地図です。以下の各トピックには、サイドバーに掲載された個別の詳しい解説があります。

個別のリダイレクトコード

• 301 Redirect — 恒久リダイレクトの標準。シグナルを転送先へ統合する仕組みと使用場面。
• 302 Redirect — 標準的な一時リダイレクト。ゼロではなく弱いシグナルである理由と、301 の扱いへ変化する場合。
• 303 Redirect（See Other） — Post/Redirect/Get 用途、SEO でまれな理由、Google の扱いが本当に未定義である理由。
• 307 Temporary Redirect — SEO 上は 302 と同じですが、HTTP メソッドを厳密に維持し、HSTS やフォーム／API で使われます。
• 308 Permanent Redirect — SEO 上は 301 と同じですが、HTTP メソッドと本文を厳密に維持します。

直接比較

• 301 vs. 302 Redirect — 恒久対一時、前向き対後ろ向きのシグナル統合、選び方。
• 301 vs. 308 Redirect — SEO 上は同じですが、308 は HTTP メソッドと本文を維持します。
• 302 vs. 307 Redirect — 一時側の同じ比較。SEO 上は同じですが、307 はフォームや API のメソッドと本文を維持します。

クライアント側実装

• JavaScript Redirects — 最も弱い選択肢である理由、Google のレンダリングパイプラインがサーバー側 301 と異なる扱いをする仕組み、最後の手段として許容できる場面。
• Meta Refresh Redirect — 即時と遅延、Google の優先順序でサーバー側と JavaScript の間に位置する理由、推奨されない理由。

落とし穴

• Redirect Chains — 最終 URL へ直接転送すべき理由、10ホップの上限、チェーンによるクロールバジェット浪費。
• Redirect Loops — 解決しないリダイレクト、検索エンジンが無視する理由、循環を断つ方法。

Google Search Console 内

• Page with Redirect — この Page Indexing ステータスの意味、エラーではなく正常である理由、対応が必要なまれな場合。
• Redirect Error — Google が挙げる4原因（チェーンが長すぎる、ループ、URL 最大長、不正／空 URL）と、正常な「Page with redirect」との違い。

このサブクラスターを含む HTTP ステータスコード全体（2xx／3xx／4xx／5xx の各系列とリダイレクト以外のコード）は、/technical-seo/http-status-codes/ のクラスター索引を参照してください。

AI 要約

Advanced 版の要点は次のとおりです。

• リダイレクト＝3xx ステータスコード＋Location ヘッダー。 コードは恒久／一時、メソッド維持の有無という意味を表し、Location は転送先です。SEO よりプロトコルが先です。
• カノニカル化の2区分： 恒久 301／308＝強いシグナル（新 URL へ前向きに統合）、一時 302／303／307＝弱いシグナル（通常は古い URL に残るが、長期化すると変わる場合あり）。
• 各区分内： 307／308 は HTTP メソッドと本文を維持し、301／302 は維持しない場合があります。ランキング差はありませんが、フォームと API では重要です。
• 303 は例外 — Post/Redirect/Get 用で SEO ではまれ、Google の扱いは本当に未定義です。
• PageRank が失われる説は過去のもの： 適切な単一リダイレクトで価値は失われません（Illyes、2016年）。コストはチェーン（Google は最大10ホップをたどるが回避を推奨）とループ（壊れたリンクとして無視）です。
• 1年以上維持。 Patrick が1年以上経過した 301 を削除した実験では、参照ドメインが減り、トラフィック減は小さく、“mostly holds true,” (訳) 「おおむね正しい」ため、不用意に削除しません。
• 実装場所はサーバー側（.htaccess／nginx）、CDN／エッジ（Patrick の推奨）、CMS プラグイン（通常は .htaccess を編集）。JS と遅延 meta refresh はレンダリング依存のため弱くなります。
• リダイレクト ≠ カノニカル： 今後1 URL だけを残すならリダイレクト、複数を公開したまま1つを優先するならカノニカルです。

公式ドキュメント

リダイレクトに関する一次情報です。

Google

• リダイレクトと Google 検索 — 恒久と一時、リダイレクト種類の表（301／308／302／303／307、meta refresh、JS、crypto）、代替 URL／リンク価値の概念を扱う主要文書。
• HTTP ステータスコードが Google クローラーへ与える影響 — 3xx の動作、10ホップの上限、301／302／307／308 の扱い。
• URL 変更を伴うサイト移転 — チェーンを避け、“keep the redirects… generally at least 1 year.” (訳) 「通常は少なくとも1年間維持」するガイダンス。
• 重複 URL の統合 — カノニカル設定が “a hint, not a rule,” (訳) 「ルールではなくヒント」である理由とリダイレクトとの関係。
• Search Off the Record — Google Search Relations チームによるリダイレクト種類（301 対 302、307／308 の用途、ドメイン統合）の回。

Bing / Microsoft

• 重複コンテンツは SEO と AI 検索での可視性を損なうか — Fabrice Canel と Krishna Madhavan による、派生版を 301 で統合する場合と、複数版を公開し続けるためカノニカルタグを使う場合の説明。

技術リファレンス

• HTTP のリダイレクト — MDN によるプロトコルレベルの定義（3xx ステータス＋Location ヘッダー）と、コードごとのメソッド／本文の扱い。

情報源からの引用

Google、Bing、MDN の公式発言です。各リンクは出典ページの引用箇所へ移動します。

Google — リダイレクトの目的、恒久と一時

• “Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location.” (訳) 「URL のリダイレクトとは、既存 URL を別の URL に解決し、ページの場所が変わったことを訪問者と Google 検索へ実質的に伝えることです」。 — Google Search Central ドキュメント。 引用箇所へ
• “we recommend that you use a permanent server-side redirect whenever possible.” (訳) 「可能な限り恒久的なサーバー側リダイレクトを使用することを推奨します」。 引用箇所へ
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL).” (訳) 「URL をリダイレクトすると、Google は転送元（古い URL）と転送先（新しい URL）の両方を追跡します」。 引用箇所へ
• “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (訳) 「サーバー側または meta refresh を使えない場合にのみ JavaScript リダイレクトを使用してください」。 引用箇所へ

Google — 各コードに対するクローラーの扱い

• “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (訳) 「Google はリダイレクトをたどり、転送先を処理すべきという強いシグナルとして使用します」（301）。 引用箇所へ
• “Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (訳) 「Google のクローラーはリダイレクトをたどり、転送先を処理すべきという弱いシグナルとして使用します」（302）。 引用箇所へ
• “While Google treats these status codes the same way, keep in mind that they’re semantically different.” (訳) 「Google は同様に扱いますが、意味が異なる点に注意してください」（307 ≈ 302、308 ≈ 301）。 引用箇所へ
• “By default, Google’s crawlers follow up to 10 redirect hops.” (訳) 「既定で Google のクローラーは最大10のリダイレクトホップをたどります」。 引用箇所へ

Google — チェーンと維持期間

• “Avoid chaining redirects.” (訳) 「リダイレクトチェーンを避けてください」。 引用箇所へ
• “ideally no more than 3 and fewer than 5.” (訳) 「理想的には3以下、5未満」。 引用箇所へ
• “Keep the redirects for as long as possible, generally at least 1 year.” (訳) 「リダイレクトは可能な限り長く、通常は少なくとも1年間維持してください」。 引用箇所へ

John Mueller（Google）— 過去の5ホップ発言

• 2014年のウェブマスターハングアウトで、Mueller は Googlebot が1回のクロールで最大5つのリダイレクトをたどり、残りを次回のクロールで続けると説明しました。 46:03から視聴
• “up to 5 hops in the chain per crawl attempt” (訳) 「1回のクロール試行につきチェーン内で最大5ホップ」。 （2020年の Reddit コメント。Search Engine Journal 経由。） 記事を読む

John Mueller（Google）— リダイレクトループ

• “In general, a redirect loop is a URL that doesn’t work, so it’s essentially a broken link. We ignore these for search.” (訳) 「一般に、リダイレクトループは機能しない URL、つまり実質的に壊れたリンクです。検索では無視します」。 引用箇所へ

Fabrice Canel（Microsoft Bing）— 301 と 302 の期間

• “When the future is uncertain… preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended.” (訳) 「先行きが不確かな場合、転送先 URL が2日以内に変わる可能性があれば 302 が望ましく、それ以外は 301 を推奨します」。 引用箇所へ

MDN — プロトコルレベルの定義

• “redirection is triggered by a server sending a special redirect response to a request. Redirect responses have status codes that start with 3, and a Location header holding the URL to redirect to.” (訳) 「リダイレクトは、サーバーがリクエストへ特別なレスポンスを送ることで発生します。レスポンスには 3 で始まるステータスコードと、転送先 URL を保持する Location ヘッダーがあります」。 文書を読む

リダイレクト実装チェックリスト

リダイレクトを公開する前後に確認します。

• 状況に合うコード — 恒久移転 → 301／308、一時移転 → 302／307、フォームの POST を維持 → 307／308。
• 最も近い同等 URL へ転送 — すべてをホームページへ一括転送しない（Google には soft 404 と解釈されます）。
• 最終転送先へ直接 — チェーンを作らず、転送先が後で移動したら転送元ルールを更新します。
• ループなし — 転送先がチェーンへ戻らないことを確認（古い URL に curl -IL を実行し、全ホップを確認）。
• 可能なら JavaScript ではなくサーバーまたはエッジ。
• 明らかな派生形を統一 — www の有無、HTTP／HTTPS、末尾スラッシュ、大文字小文字を1つのカノニカル形式へ。
• 内部リンクを更新し、新 URL を直接指すようにします。自サイトの移動でリダイレクトに依存しません。
• 1年以上維持（Google のガイダンス）。高価値ページはさらに長くし、不用意に削除しません。
• ロールバック経路を確保 — 公開前に以前の転送先（または廃止する旧ページのコンテンツ）を記録し、不適切な転送先や予期しない減少をすぐ戻せるようにします。
• デプロイ後に検証 — curl -IL、ブラウザの Network タブ、サイトクローラーでコードと最終転送先を確認し、チェーンとループを一括監視します。-I は HEAD リクエストです。サーバーが HEAD と GET を別扱いする疑いがあれば、通常の curl -L（GET）またはクローラーの GET モードでも確認します。

リダイレクト種類の比較

5つの 3xx リダイレクトコード早見表

実際の判断を決める2点

• 恒久か一時か → カノニカル化シグナル（強い／弱い）と、検索に新 URL／旧 URL のどちらを表示するかを決めます。
• メソッドを維持するか → 307／308 は元のメソッドと本文を維持し、301／302 は途中で POST を GET に変えることをクライアントへ許します（Fetch Standard によれば古いクライアントとの互換性の名残）。303 は常に GET を強制します。ランキングには無関係ですが、フォームと API では重要です。メソッドと本文を維持する必要があれば 307／308 を使います。

恒久リダイレクトの実装方法：強い順

要点

• 適切な単一リダイレクトで PageRank は失われません（Illyes、2016年）。
• Google は10ホップ上限を文書化していますが、チェーンが不可避なら3以下、5未満を推奨します。
• Mueller の2014年と2020年の発言は1回のクロールで約5ホップを説明し、2014年には残りを後で続けるとも述べています。現行スケジュールの保証ではなく、歴史的な担当者発言として扱います。
• リダイレクトは1年以上維持。
• Google にとって 307 ≈ 302、308 ≈ 301。違いはメソッド維持です。
• リダイレクト＝1 URL だけが残る。カノニカルタグ＝複数が残り、1つを優先。

時間を使う価値のある資料

私の記事

• 11 Types Of Redirects & Their SEO Impact — 301、302、303、307、308、meta refresh、JS、crypto、チェーン、ループをすべて扱う詳しい解説。このハブの基になった記事です。
• HTTP Status Codes & Their SEO Impact — 1xx〜5xx の全体でリダイレクトが占める位置。
• 1年後に 301 を削除してもよいか：検証結果 — 1年以上経過したリダイレクトを外す比較実験（参照ドメインは減少し、トラフィックはほぼ維持）。
• SEO のための 301 と 302：どちらを使うか — 302 によって Google が旧ドメインから新ドメインへ切り替えた実験を含む直接比較。
• サイト移転の成功にはチェックリスト以上のものが必要 — サイト全体の移転におけるリダイレクト。

業界の資料

• リダイレクトと Google 検索 （Google）— このハブの主張の多くを支える主要文書。
• HTTP ステータスコードが Google クローラーへ与える影響 （Google）— 3xx の扱いと10ホップ上限。
• 重複コンテンツは SEO と AI 検索での可視性を損なうか （Bing）— リダイレクト対カノニカルタグについての Microsoft の現行公式見解。
• HTTP のリダイレクト （MDN）— 3xx コードとメソッド／本文の扱いのプロトコルリファレンス。
• Google：301、302、30x で PageRank は希釈しない （Search Engine Land）— PageRank に関する誤解を訂正した発言の出典。
• Google 検索はリダイレクトループを無視 （Search Engine Roundtable）— ループは “essentially a broken link” (訳) 「実質的に壊れたリンク」という Mueller の発言。
• Bing：2日以内に変わる URL は 302、それ以外は 301 （Search Engine Roundtable）— Fabrice Canel の 301 対 302 の期間ガイダンス。
• SEO のためのリダイレクトガイド （Conductor Academy）— リダイレクト全体の堅実な競合解説。

リダイレクトかカノニカルか：存続テストを使う

2つのシグナルは同じ優先 URL を指すことがありますが、解決する問題は異なります。

転送元 URL が独自コンテンツの提供を停止すべきならリダイレクト

古い URL を要求したユーザーとクローラーを別の場所へ送るべき場合は、サーバー側リダイレクトを選びます。恒久移転には恒久コード（301 または 308）、転送元が戻る予定なら一時コード（302、303、307）を使います。

典型例： URL 変更、ページ統合、HTTP から HTTPS への移行、ドメイン移転。転送先は本当に同等でなければなりません。無関係な古い URL をホームページへ一括転送すると soft 404 と扱われる場合があります。

複数 URL をアクセス可能に保つならカノニカル化

重複またはほぼ重複する派生版が独自の 200 レスポンスを返し続ける必要がある一方、1 URL をインデックス登録の優先版として扱ってほしい場合は rel="canonical" を選びます。カノニカルはナビゲーションではなくヒントで、ユーザーはリクエストした URL に留まります。Google に対してもルールではなくヒントです。Google は、“indicating a canonical preference is a hint, not a rule,” (訳) 「カノニカルの優先指定はルールではなくヒント」と説明し、他のシグナルに基づいて別ページを選ぶ場合があります。

典型例： 有用な並べ替え／絞り込みの派生形、配信またはパラメータ付きの版、まだ削除できない重複。

関連する代替ページがない場合

送る場所を作るためだけに無関係なページへ転送しないでください。本当の後継がないコンテンツを一括転送したりホームページへ送ったりすると、Google には soft 404 と解釈されます。同等のページがないなら、転送先を捏造せず、意図的な 404／410 を選ぶべきというシグナルです。

矛盾する指示を送らない

URL A が B へリダイレクトするなら、B は A をカノニカルに指定してはいけません。内部リンクとサイトマップを存続する転送先に合わせます。フレームワークは単純です。1 URL が残る → リダイレクト。複数を公開し続ける → カノニカル。

プロンプト：弱い転送先があるリダイレクトマップを監査

旧 URL、提案転送先、理由、旧タイトル／トピック、転送先タイトル／トピック、意図する恒久性、利用可能ならトラフィック／リンクシグナルを含むリダイレクトマップ CSV を貼り付けます。

Review this proposed redirect map for relevance and implementation risk.

For each row:
1. Classify the destination as strong equivalent, plausible but needs review,
   irrelevant/catch-all, self-redirect, chain risk, loop risk, missing destination,
   or insufficient evidence.
2. Explain the classification using only the supplied old/destination topics and
   URL evidence.
3. Flag many-to-one mappings to a homepage or broad category for manual review.
4. Check whether the intended permanence matches the proposed 3xx code when a code
   column is present.
5. Do not invent a replacement URL. If no equivalent is supplied, recommend manual
   mapping or an intentional 404/410 decision.

Return a table with old URL, destination, verdict, evidence, recommended action, and
priority. End with a summary of repeated rule patterns that could create chains or
loops.

DATA:
[PASTE REDIRECT MAP HERE]

マップをデプロイする前に、コンテンツの同等性に関するすべての判断を人間がレビューしてください。

リダイレクトの計画と検証に使うツール

• Redirect Checker — デプロイ後、URL または小規模バッチの最終ステータス、全ホップ、転送先を素早く確認します。
• Redirect Chain Mapper — 複数ホップを診断し、各ホップの変化を確認し、一般的なサーバープラットフォーム向けの平坦化ルールをエクスポートします。
• Bulk HTTP Status Code Checker — 大規模なリダイレクト一覧を検証し、一時または複数ホップの結果を絞り込み、証拠をエクスポートします。
• Redirect Map Builder — 旧 URL から新 URL への対応を計画し、未対応 URL と 410 削除リストを明示し、プラットフォーム向けルールを出力します。提案には引き続きコンテンツ同等性のレビューが必要です。
• ブラウザ DevTools → Network — ブラウザ固有の動作を再現しながら、ドキュメントレスポンスの 3xx コードと Location ヘッダーを検証します。

理解度チェック：HTTP リダイレクト

リダイレクトの仕組みと検索エンジンによる扱いについての5問です。各問で回答を選び、結果を確認してください。

変更履歴