301リダイレクトは被リンクの評価を引き継ぐか？ チェーンと着地点の落とし穴（2026年8月時点）

01 いま最新版は何か — 301リダイレクトとGoogleの現在の説明

301リダイレクトの基本

301リダイレクトとは、あるURLへのアクセスを別のURLへ恒久的に転送するHTTPステータスコードです。サーバーが返すレスポンスヘッダーにHTTP/1.1 301 Moved PermanentlyとLocation: 新URLを含めることで、ブラウザと検索エンジンの両方に「このページは新しい場所に移動した」ことを伝えます。URLの変更・ドメインの移行・重複記事の統合など、既存のURLを維持できない場面で使われる、最も基本的なSEO対策のひとつです。

Googleは「評価は失われない」と明言している

リダイレクトが被リンクの評価をどこまで引き継ぐかを考えるうえで、まず確認すべき一次情報があります。Google Search Centralの公式ドキュメント(Site Moves and Migrations(訳: サイトの移転))は、サイト移行時の注意点として「301やその他の恒久リダイレクトによって、PageRankが失われることはない」と明記しています。同ドキュメントは2026年8月20日付で更新されており、この記述は現時点でのGoogleの公式見解です。

ただし「引き継ぐ」と「即座に完了する」は別の話

ここで注意したいのは、同ドキュメントが「評価は失われない」と述べている一方で、「代替名(alternate name)」という現象についても触れている点です。Googleはリダイレクトの転送元URLと転送先URLの両方を把握し続けており、どちらを検索結果に表示するかは複数のシグナルによって決まります。ユーザーが旧URLの方を信頼している可能性がある場合、リダイレクト後もしばらくは旧URLが検索結果に表示され続けることがあると説明されています。つまり「301を設定した」という事実だけでは、評価の移転が瞬時に完了するとは限りません。この記事では、公式ドキュメントの記述と、当サイトが実際に運用しているリダイレクトの実測を突き合わせて、この論点を整理します。

02 なぜ・背景 — 「成立」だけでは終わらない理由

リダイレクトチェーンという落とし穴

301を設定したこと自体は正しくても、旧URLから新URLまでの経路が複数回のリダイレクトを経由している場合があります。これをリダイレクトチェーンと呼びます。前掲のSite Moves and Migrationsドキュメントは、Googlebotは最大10ホップまでのチェーンを辿るとしながらも、「最終的な着地点へ直接リダイレクトすることを推奨する。それが不可能な場合でも、チェーンの数はできるだけ少なく、理想的には3ホップ以内、5ホップ未満に抑えるべきだ」と述べています。チェーンが長くなるほど、ユーザーの待ち時間が増えるだけでなく、一部のユーザーエージェントやブラウザが長いチェーンに対応していないという実務上のリスクも指摘されています。

「解決」に見えて、実は着地点が間違っているケース

もうひとつ見落としやすいのが、リダイレクトの着地点の妥当性です。同ドキュメントは「多数の旧URLを、無関係な単一のURL(たとえばトップページ)へまとめてリダイレクトしないこと。ユーザーを混乱させるだけでなく、ソフト404として扱われる可能性がある」と警告しています。一方で「複数ページに分散していたコンテンツを、統合した1つの新しいページへリダイレクトすることは問題ない」とも明記されており、統合を目的としたリダイレクトと、行き先のない記事を無理やりトップページへ逃がすリダイレクトは、Googleにとって別物として扱われることがわかります。

種類	代表的なステータス	Googleの扱い
恒久 リダイレクト	301・308	索引付けの仕組みが、転送先を正規URLにすべきというシグナルとして使う
一時 リダイレクト	302・303・307	Googlebotは辿るが、正規URLのシグナルとしては使わない(転送元が検索結果に残る)

「強いシグナル」と「弱いシグナル」という表現

この扱いの差を、Googleはさらに具体的な言葉で説明しています。クローラーの挙動を扱う公式ドキュメント(How HTTP status codes affect Google's crawlers(訳: HTTPステータスコードがGoogleのクローラーに与える影響))は、301について「Googleのシステムは、このリダイレクトを転送先を処理すべきだという強いシグナルとして使う」と述べる一方、302については「弱いシグナルとして使う」と、明確に強度の差を言葉にしています。308は301と、307は302と同等に扱われるとも補足されており、恒久・一時のどちらを選ぶかが評価の引き継ぎやすさに直結することが、この一文からも裏付けられます。

URL検査ツールはリダイレクトを追わない

同ドキュメントには、実務上見落としやすい注意点も書かれています。「GoogleのクローラーはデフォルトでURLを10ホップまで辿るが、製品によって上限が異なる。たとえばGoogle Inspection Toolsはリダイレクトを一切追わない」という記述です。つまりSearch ConsoleのURL Inspection tool(訳: URL検査ツール)で旧URLを検査しても、リダイレクトの先まで自動では確認してくれません。リダイレクトの検証は、URL検査ツールの結果を鵜呑みにせず、05章のチェックリストにあるとおり自分でステータスコードを1件ずつ確認する必要があります。

移行直後はクロール量が一時的に増える

Site Moves and Migrationsドキュメントは、移行直後の実務上の注意点として「移行後、Googleは新しいサイトを通常より多くクロールする。旧サイトへのクロールも新サイトへリダイレクトされるため、通常のクロールに加えてこの分の負荷が上乗せされる。サーバーに十分な処理能力があることを確認してほしい」とも述べています。リダイレクトの設定そのものは正しくても、サーバー側の準備が不足していると、この一時的な負荷増でエラーが発生し、結果的に評価の移転が遅れる可能性があります。

03 この記事で出てくる用語

リンクエクイティとは

リダイレクトチェーンとは

代替名(alternate name)とは

01章で触れた代替名は、リダイレクトの転送元URLが、転送先の正規URLとは別に、Googleの索引の中で保持され続ける状態を指します。前掲のドキュメントは「新しいドメイン名に移行した場合、新URLが既に索引に入っていても、Googleは古いURLを検索結果に時折表示し続けることがある。これは正常な挙動であり、ユーザーが新しいドメイン名に慣れるにつれて、代替名は自然に薄れていく」と説明しています。つまり移行直後に旧URLが検索結果に見えても、それ自体は失敗の証拠ではありません。

ソフト404とは

02章で触れたソフト404は、サーバーが200(正常)というステータスコードを返しているにもかかわらず、実際のページ内容が「見つかりません」に近い、ユーザーにとって価値のないページである状態を指します。無関係なURLへリダイレクトを大量に集約すると、着地点のページが元の検索意図と合わなくなり、Googleがこれをソフト404に近い状態として扱う可能性がある、というのが02章の警告の核心です。

04 型別 — 適用範囲・限界・手順

🅰 適用範囲 — このガイドが当てはまる場面

このガイドが特に役立つのは、記事の統合・URL構造の変更・ドメインやサブドメインの移行・HTTPからHTTPSへの切り替えなど、既存のURLを維持できない変更を行うすべての場面です。逆に、URLをまったく変更しない運用であれば、リダイレクトの設計自体が不要になります。まずは05章のチェックリストの最初の項目で、自分のサイトに現在いくつのリダイレクトが存在するかを数えるところから始めるのが妥当です。

🅱 301が保証しないこと

301リダイレクトを設定しても、それだけで解決しないことがあります。01章で触れたとおり、Googleにとって評価の移転は複数のシグナルに基づく判断であり、リダイレクトの設定はその中の重要な一要素にすぎません。canonicalタグの指定・内部リンクの向き先・サイトマップに載っているURLが、リダイレクトの意図と食い違っていると、Googleが判断に迷う余地が生まれます。canonicalタグの公式ドキュメント(Consolidate duplicate URLs(訳: 重複するURLを統合する))自身が、この指定を「示唆であり、絶対的な規則ではない」と明記しているとおり、301は「宣言する」ための仕組みであって、そこにあるすべてのシグナルを強制的に上書きする仕組みではない、という前提を持っておく必要があります。

🅲 手順 — URL統合の4段階

実際の作業は、次の4段階で進めると抜け漏れを防ぎやすくなります。第一に、URLを変更・統合する対象を洗い出す棚卸し。第二に、旧URLと新URLを1対1で対応づけた対応表を作る設計。第三に、301で1ホップのリダイレクトを設定する実装。第四に、ステータスコードとcanonicalタグの両方を確認する検証です。この4段階を、05章のチェックリストにそのまま落とし込んでいます。

よくある失敗パターン

実際の現場でよく見られる失敗が、記事を統合したはずなのに、統合先のURLのcanonicalタグが自分自身を指していない、というケースです。リダイレクトは正しく設定されていても、着地点のページのcanonicalが別のURLを指していると、Googleにとってどちらが本当の代表URLなのか判断材料が一貫せず、意図した統合が完全には伝わらないことがあります。03章で触れたとおり、301は「引き継がれる可能性を高める」仕組みであって、他のシグナルとの整合性が取れていて初めて機能するという前提を、常に意識しておく必要があります。

05 自分のサイトで確認するチェックリスト

チェックリストの3つの観点

ここまでの内容を、今日から手を動かせる作業に翻訳しました。観点は、リダイレクトの現状把握、チェーンと着地点の点検、canonicalとの整合性確認の3つに分かれます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• 自分のサイトで現在稼働しているリダイレクトの件数を、対応表またはサーバー設定から数える
• そのうち5件を選び、実際にブラウザまたはコマンドでアクセスして、何ホップで最終URLに到達するか数える
• 3ホップを超えるリダイレクトチェーンが無いか確認する(見つかったら旧URLから最終URLへ直接張り替える)
• リダイレクトの着地点が、統合元の内容と関連する具体的なページになっているか確認する(トップページへの一括転送になっていないか)
• 着地点のページの「ソースを表示」を開き、head内のrel="canonical"が着地点自身のURLを指しているか確認する
• リダイレクト設定に使っているステータスコードが301または308(恒久)か、302など(一時的)かを確認する
• 恒久的な統合の目的で302以下を使っている箇所が無いか確認する
• Search Consoleの「ページ」レポートを開き、旧URLが「重複しています。ユーザーにより指定された正規URLと異なる」等の扱いになっていないか確認する
• リダイレクトを設定してからの経過日数を数え、Google公式が目安とする「数週間程度」を超えているか確認する
• サイトマップに旧URLが残っていないか、新URLのみが記載されているか確認する
• 旧URLへの内部リンクが残っていないか、主要ページを3件開いて確認する(残っていれば新URLへ張り替える)
• 外部サイトから旧URLへリンクされている箇所が無いか、Search Consoleの「リンク」レポートで確認する(あれば連絡して更新を依頼するか、そのまま様子を見るかを判断する)
• リダイレクトの対応表(旧URL・新URL・設定日・理由)が社内に存在するか確認する(無ければ「無し」と記録する)

13項目の内訳と、かかる時間の目安

最初の4項目はリダイレクトの現状把握、5番目から7番目はチェーンとステータスコードの点検、8番目から9番目はGoogle側の反映状況の確認、10番目から13番目はcanonical・サイトマップ・内部リンク・対応表の整合性確認に対応しています。すべてに目を通す時間の目安は1サイトあたり25分程度です。10番目の項目でサイトマップを確認する際は、公式ドキュメント(Sitemaps overview(訳: サイトマップの概要))が「サイトマップはGoogleに新URLの存在を伝える手段のひとつであり、掲載したURLのクロールを保証するものではない」としている点も踏まえておくと、確認の精度が上がります。まずは自分のサイトで最近リダイレクトを設定した箇所から手を動かし始めることをおすすめします。

06 リダイレクト手段の比較

5つの手段、それぞれの向き不向き

URLを変更する際の手段は301だけではありません。前掲のRedirects and Google Searchドキュメントは、サーバー側リダイレクトを最も推奨しつつ、複数の手段を序列付きで紹介しています。以下は、それぞれの手段が「Googleにどう解釈されるか」を整理した表です。

手段	Googleの解釈	備考
301・308 サーバー側	恒久リダイレクト。転送先が正規URLとして扱われる	最も推奨される方式。解釈の確実性が最も高い
302・303・307 サーバー側	一時リダイレクト。転送元が検索結果に残る	恒久的な統合には不向き
meta refresh (0秒)	恒久リダイレクトとして解釈される	サーバー側の設定ができない場合の代替手段
meta refresh (数秒後)	一時リダイレクトとして解釈される	同上・遅延時間が意味を持つ
JavaScript Location	レンダリングが成功すれば解釈される	レンダリングに失敗すると、Googleが一度も認識しない可能性がある

サーバー側リダイレクトが最も確実

この表からわかるとおり、Googleが最も確実に解釈できるのはサーバー側の301・308です。JavaScriptによるリダイレクトは、Googleがページをクロールした後にレンダリングを試みて初めて認識されるため、レンダリングが何らかの理由で失敗すると、そのリダイレクト自体が一度も認識されない可能性があります。前掲のRedirects and Google Searchドキュメントも「サーバー側またはmeta refreshでのリダイレクトができない場合に限って、JavaScriptリダイレクトを使うこと」と明記しています。自分のサイトの実装がどの方式に該当するかを、当サイトの🔧 Google Search Console お助けツールと組み合わせて確認しておくと安心です。

07 当サイトの実測

重複記事の統合に使っている301リダイレクト

このガイドを書く過程で、自サイトが実際に運用しているリダイレクトも確認しました。当サイトでは、内容が重複していると判定した記事を1本に統合する作業を進めており、統合元のURLには301リダイレクトを設定しています。02章で触れた「複数ページに分散していたコンテンツを、統合した1つの新しいページへリダイレクトすることは問題ない」という公式ドキュメントの記述に沿った運用です。

5組を実際にHTTPで確認した

統合済みの組み合わせのうち5組を選び、実際にcurlコマンドでLocationヘッダーとcanonicalタグを直接確認しました。結果は、5組すべてが1ホップで最終URLに到達し、最終URLのステータスコードは200、canonicalタグは最終URL自身を自己参照していました。02章で触れたよくある失敗(着地点のcanonicalが統合先と食い違う)には該当していないことを、推測ではなく実測で確認できた形です。

チェーンが発生していないことも確認した

curlの--max-redirsオプションと-w "%{num_redirects}"を使って、それぞれの組み合わせが何ホップで最終URLに到達するかも計測しました。5組ともnum_redirects=1、つまり1回のリダイレクトで最終URLに到達しており、中継URLを経由するチェーンにはなっていませんでした。03章で触れたリダイレクトチェーンのリスクを、この5組については回避できていることになります。ただし、これは今回サンプルとして選んだ5組の結果であり、統合作業が進むにつれて対象は増えていきます。05章のチェックリストにあるとおり、この確認は一度きりで終わらせず、統合対象が増えるたびに継続する必要があります。

08 このテーマの、これまで

4層の整合性をcurlで確認した回

sitemap・canonical・内部リンク・末尾スラッシュという4つの要素が食い違っていないかを、curlコマンド3行で確認する方法を以前まとめたことがあります(archives/39)。本記事の04章🅱で触れた「301は他のシグナルとの整合性が取れて初めて機能する」という考え方は、この4層の一致を前提にしています。

内部リンク設計とトピカルマップを扱った回

記事同士を内部リンクでつなぎ、サイト全体の構造を設計する考え方を以前まとめたことがあります(archives/6)。本記事の05章のチェックリストで扱った「旧URLへの内部リンクが残っていないか」という点検は、この内部リンク設計の一部として継続的に行う作業です。

再クロール待ち行列547件を記録した回

URLを書き換えた際、Googleの再クロールが完了するまでに実際どれくらいの時間がかかるかを、547件の待ち行列とともに記録した回もあります(archives/108)。02章で触れた「移行完了までに数週間程度かかる」という公式の目安は、この記事で扱った再クロールの実測とも整合しています。

重複記事をタイトル一致と元記事一致の2通りで数えた回

自サイト内に同じ内容の記事が複数存在していないかを、タイトルの一致と元記事URLの一致という2つの異なる基準で数えたところ、45組と139組という3倍の差が出た事例を記録した回もあります(archives/129)。07章で扱った5組の統合リダイレクトは、この重複判定の結果を受けて実際に着手した作業の一部です。

sitemapの末尾スラッシュがGoogleから見えていなかった回

sitemap.xmlに記載したURLの末尾スラッシュの有無がページ実体と一致せず、Googleから見えていなかった事例を検証した回もあります(archives/38)。05章のチェックリストで扱った「サイトマップに旧URLが残っていないか」という点検は、URLの表記が1文字でもずれると同じ形で機能しなくなる、という教訓を踏まえたものです。