SEOリダイレクト：2026年版 301、302、307、308リダイレクト完全ガイド

TL;DR: 301リダイレクトは、SEO評価（SEO equity）を新しいURLへ恒久的に転送します。302リダイレクトは一時的な転送であり、元のURLをインデックスに残し続けます。Googleのジョン・ミューラー氏が認めている通り、すべての3xxリダイレクトは現在、PageRankを同等に受け渡すため、適切なリダイレクトの選択はPageRankの最適化ではなく、技術的な正確性が重要となります。リダイレクトチェーンは、評価を希釈させ、読み込み速度を低下させます。本ガイドでは、すべてのリダイレクトタイプ、最も多い8つのミス、プラットフォーム別の実装手順、および適切なリダイレクト監査方法を解説します。

ウェブサイトのURLが変更されるたび（ページ名の変更、サイト移転、HTTPS化、コンテンツの統合など）、サイト運営者は「SEO上の資産（SEO equity）を保持するか、それとも長年かけて築いたランキングの権威性を失うか」という選択を迫られます。その選択肢こそがリダイレクトです。

正しく実装すれば、リダイレクトはユーザーからは見えず、検索エンジンにも最適に処理されます。しかし、誤った実装を行えば、インデックスの混乱、リンク評価の希釈、クロールバジェットの浪費を引き起こす「サイレントなランキング低下要因」となり、エラーレポートには現れないまま徐々に悪影響を及ぼします。

本ガイドでは、モダンSEOにおいて遭遇するすべてのリダイレクトタイプを網羅し、それぞれがGoogleのクローラーとどのように相互作用するか、最も一般的で致命的なミス、そしてプラットフォーム別の実装ガイダンスを解説します。

HTTPリダイレクトとは何か、その仕組み

HTTPリダイレクトとは、ウェブブラウザや検索エンジンのクローラーに対して、あるURLから別のURLへ移動するように指示するサーバーの命令です。技術的には、HTTPリダイレクトはサーバーから発行される「3xxステータスコード」です。ここで「3」はリダイレクト応答であることを意味します。

ユーザーがブラウザにURLを入力したとき（またはクローラーがページにアクセスしようとしたとき）、サーバーはHTTPステータスコードで応答します。リダイレクト応答の場合、このコードに加えて移動先URLを指定する「Location」ヘッダーが送信され、ブラウザやクローラーは自動的にその目的地へ移動します。

SEOにおける重要なポイントは、サーバーレベルのリダイレクトが、ブラウザがコンテンツをレンダリングするよりも先に発生することです。つまり、リダイレクト命令は、移動が恒久的なものか一時的なものかというコンテキストを保持した状態で検索エンジンのクローラーに伝わり、それがインデックスやランキング目的で元のURLと目的地URLがどのように扱われるかに直接影響します。

リダイレクトタイプの完全リファレンス

301リダイレクト — 恒久的な移転 (Permanent Move)

301リダイレクトは、SEOにおいて最も一般的に使用されるリダイレクトですが、それには正当な理由があります。これは、ブラウザと検索エンジンの両方に対して、URLが「恒久的に新しい場所へ移動した」ことを伝えます。検索エンジンのクローラーが301を検出すると、以下の3つを実行します。

1. リダイレクトに従い、目的地URLへ進む
2. 元のURLから目的地URLへランキングシグナル（リンク評価、PageRank）を転送する
3. 元のURLを目的地URLに置き換え、インデックスを更新する

SEOへの影響は甚大です。リンク資産のほとんど（多くの場合、元の価値の90〜99%）は301リダイレクトを通じて継承されます。つまり、旧URLに向けられたバックリンクは、リダイレクト設定後も目的地URLに対してランキングの恩恵を提供し続けます。

301を使用すべきケース:

• ドメインの移行（あるドメインから別のドメインへの移動）
• URLの構造変更（サイト全体のURLパターン変更）
• HTTPからHTTPSへの移行
• 重複コンテンツを単一の正規（Canonical）URLに統合する場合
• 関連する代替ページがある古いコンテンツの廃止
• ビジネスや製品のリブランディングに伴うドメイン変更

例: 製品のリブランディングに伴い mysite.com/old-product-name から mysite.com/new-product-name へ移動する。301を使用することで、旧URLへのすべてのバックリンク価値を新URLへ引き継ぎ、Googleはインデックスを正規の目的地へ更新します。

302リダイレクト — 一時的な移転 (Temporary Move)

302リダイレクトは、URLが「一時的に新しい場所へ移動」したことを意味します。301との大きな違いは、検索エンジンがこれを短期的な変更と解釈することです。検索エンジンは元のURLをインデックスに残し、評価を目的地URLへ転送せずに、元のURLに対してランキングシグナルの割り当てを継続します。

Googleのジョン・ミューラー氏が認めている通り、301と302の技術的な選択はPageRankの転送自体には大きな影響を与えません。重要なのは「インテント（意図）のシグナル」です。302はGoogleに対し、「元のURLは戻ってくるので、そのままランキングし続けてほしい」と伝え、301は「インデックスを更新し、権威性を新しい目的地へ移転してほしい」と伝えます。

302を使用すべきケース:

• 元のURLをインデックスに残したまま、新しいページデザインをA/Bテストする場合
• プロモーション用のランディングページや季節限定ページへ一時的にリダイレクトする場合
• メンテナンス中にユーザーをメンテナンスページへ誘導する場合
• URLの変更を恒久的にするかどうか検討中の間

やってはいけないこと: 恒久的な変更を意図しているにもかかわらず302を使用すること。これはテクニカルSEOにおいて最も一般的でコストのかかる失敗の一つであり、その結果、元のURLがインデックスに残ったまま、新しいURLがランキング評価を蓄積できないという事態を招きます。

307 リダイレクト — 一時的な転送（メソッド保持）

307 リダイレクトは、HTTP/1.1 における 302 の等価物ですが、重要な技術的違いが 1 点あります。それは、リダイレクトに従う際にリクエストメソッド（GET、POST、PUT など）が確実に保持されるという点です。302 は技術的にブラウザが元のリクエストタイプに関わらずメソッドを GET に変更することを許可する可能性がありますが、307 はこれを明示的に禁止します。

SEO において、302 と 307 の実用上の違いは最小限です。どちらも一時的な移動を示し、元の URL のインデックスステータスを保持します。307 は、フォーム送信、API、Web アプリケーションのリダイレクトなど、技術的な正当性のためにリクエストメソッドの保持が重要となるシナリオで一般的に使用されます。

307 の使用タイミング:

• リクエストメソッドの保持が必須となる、HTTPS 内部リダイレクトを処理する最新の Web サーバー
• フォーム送信や API 呼び出しを伴うアプリケーションレベルのリダイレクト
• 利用している Web フレームワークが一時的なリダイレクトに 307 を生成する場合

308 リダイレクト — 恒久的な転送（メソッド保持）

308 は 307 の恒久的なバージョンです。301 と同様に恒久的な移動を示唆し、SEO 評価（SEO エクイティ）を転送先 URL に引き継ぎます。307 と同様に、リダイレクト中も HTTP リクエストメソッドを保持します。308 は標準的な Web SEO ではあまり見かけませんが、HTTP/2 や現代のアプリケーションアーキテクチャの進化に伴い、関連性が高まっています。

308 の使用タイミング:

• 明示的にメソッドを保持する恒久的なリダイレクトを優先する最新のアプリケーションフレームワーク
• 複雑なリクエストルーティング要件を持つプログレッシブ・ウェブアプリ（PWA）
• アプリケーションロジック上で、技術的アーキテクチャが明示的に 301 ではなく 308 を必要とする場合

メタ・リフレッシュ（Meta Refresh）リダイレクト — SEO の文脈では回避すべき

メタ・リフレッシュは、サーバーサイドの HTTP ヘッダーではなく、HTML を通じて実装されるクライアントサイドのリダイレクトです。HTML の <meta http-equiv="refresh"> タグは、指定された遅延の後に新しい URL へ移動するようブラウザに指示します。サーバーサイドのリダイレクトとは異なり、メタ・リフレッシュはブラウザレベルのイベントであり、ページが部分的に読み込まれた後に発生します。

SEO の観点から見ると、メタ・リフレッシュは一般的に推奨されません。Google はこれらを追跡できますが、リンクエクイティの転送効率が低く、ユーザーエクスペリエンス（特に遅延タイマーがある場合）を低下させます。また、クローキングに悪用される可能性もあり、スパムパターンとして関連付けられることが多いため、Google の品質評価システムからより厳格な審査を受けるリスクがあります。

メタ・リフレッシュが必要となる場面:

• CMS が .htaccess ファイルを繰り返し上書きしてしまい、サーバーサイドでのリダイレクトが実用的でない場合
• サーバーサイドのリダイレクト機能が一切使用できず、他に代替手段がない場合

原則: 可能な限り常にサーバーサイドのリダイレクト（301, 302, 307, 308）を使用してください。メタ・リフレッシュは、サーバーサイドのオプションが利用できない、真に技術的な制約がある場合にのみ使用してください。

JavaScript リダイレクト — あくまで代替手段

JavaScript リダイレクトはクライアントサイドで実行され、ブラウザのスクリプトを使用してユーザーを新しい URL へとナビゲートします。一般的な実装には window.location.href = "newURL" や window.location.replace("newURL") があります。

検索エンジンのクローラーによる JavaScript リダイレクトの処理は、一貫性に欠ける場合があります。Google は JavaScript リダイレクトを追跡できますが、処理のために JavaScript レンダリング（追加のクロールステップ）が必要となり、遅延や不確実性を伴います。Bing などのクローラーでは、JavaScript リダイレクトの扱いが一貫しない可能性があります。また、JavaScript リダイレクトによるリンクエクイティの転送は、サーバーサイドのリダイレクトよりも信頼性が低くなります。

JavaScript リダイレクトが必要となる場面:

• サーバーサイドのルーティングが特定の遷移で利用できないシングルページアプリケーション（SPA）
• サーバー構成にアクセスできないサードパーティの埋め込みコンテンツ

原則: 常にサーバーサイドのリダイレクトを優先してください。JavaScript リダイレクトは、対象の URL に対してサーバーサイドのオプションが本当に利用できない場合にのみ使用してください。

ページランクとリダイレクト・エクイティ：決定的な答え

テクニカル SEO における最も根強い誤解の一つに、「リダイレクトの種類によって受け渡されるページランクの量が異なる」というものがあります。これは Google アルゴリズムの初期バージョンでは部分的に真実でしたが、現在は明確に修正されています。

2016 年、Google の Gary Illyes 氏は「30x リダイレクトでページランクが失われることは、もはやない」と明言しました。その後、John Mueller 氏も「302 か 301 か。最大限のページランクを得るにはどちらを選ぶべきか？幸いなことに、どちらでも構いません。技術的に適切なリダイレクトタイプを使用してください。それは 307 でも 308 リダイレクトでも構いません。検索エンジンは当初からリダイレクトに対処してきました」と、この立場を補強しています。

リダイレクト選択のための正しいフレームワーク:
301リダイレクトと302リダイレクトのどちらを選択すべきかは、PageRankの最適化ではなく、URL変更の意図と恒久性に基づいて判断されるべきです。リダイレクトの種類が送信する「恒久性」に関するシグナルは、インデックス登録の挙動（GoogleがどちらのURLをインデックスに残すか）に影響を与えます。さらにこのインデックス登録のシグナルは、リンクエクイティの転送とは別に、検索順位において重要な意味を持ちます。

SEOに悪影響を与える「致命的な間違い」

間違い1：恒久的な変更に302リダイレクトを使用する

これは実務において最も損害の大きいリダイレクトミスです。恒久的なURL変更に一時的なリダイレクトを使用すると、Googleはインデックスを新しい宛先に更新するのではなく、古いURLをインデックスし順位付けし続けることになります。新しいURLは、Googleによって一時的な一時退避先として扱われるため、独自のランキングシグナルを蓄積することができません。コンテンツを検索するユーザーには、SERPs（検索結果ページ）に表示された古いリダイレクトURLを経由させることになり、UX（ユーザーエクスペリエンス）が低下し、オーソリティの低い検索結果につながります。

修正案： すべての既存リダイレクトを精査し、意図と種類が一致していないものを特定します。3〜4週間以上経過しており、元に戻す予定のないURL変更は、すべて301リダイレクトを使用してください。

間違い2：リダイレクトチェーン

リダイレクトチェーンとは、最終的な到達先に至るまでに複数のURLを経由する状態を指します（例：URL A → URL B → URL C → URL D）。チェーン内の各ホップはサーバーの応答時間を発生させ、ページロードのレイテンシを増大させます。また、各ホップは信号が単一の直接的なパスを通るのではなく複数のリダイレクトを経由することで、リンクエクイティをわずかに希薄化させます。

さらに、Googleのクローラーにはクロールセッションごとのリダイレクト追跡数に上限があります。過度に長いチェーンは、クローラーが最終到達点に達する前に追跡を放棄するリスクを生みます。その結果、正規化が必要な最終URLではなく、中間URLがインデックスされてしまう可能性があります。

修正案： すべてのリダイレクトチェーンを単一の直接ホップに解消します。Screaming Frog SEO Spiderなどのツールを使用してリダイレクトチェーンを監査し、ソース側のリダイレクトを直接最終目的地へ向かうように更新してください。

間違い3：リダイレクトループ

リダイレクトループは、あるURLが別のURLへリダイレクトし、それが最終的に元のURLに戻るように設定されている場合に発生する無限ループです。ブラウザには「リダイレクトが多すぎます」というエラーが表示され、クローラーはアクセスを諦めます。ループに陥ったページは事実上、インデックスから削除されます。

修正案： デプロイ前に必ずリダイレクト先を確認してください。リダイレクトチェッカーを使用して各リダイレクトの最終目的地を確認し、相互リダイレクトが発生していないかを監視します。

間違い4：すべてのページをホームページにリダイレクトする

サイト移行やコンテンツ削除時、個別の関連コンテンツへリダイレクトする代わりに、すべての古いURLをホームページに飛ばす手法がよく取られます。Googleは、このパターンが「ソフト404」として扱われることが多いと明言しています。つまり、検索エンジンは「リダイレクト先に対応するコンテンツが存在しない」と判断し、それに応じてリダイレクトの評価を割引します。何百もの個別の商品やコンテンツページからホームページへリダイレクトすることは、クロールバジェットの浪費であり、リンクエクイティの維持にも失敗します。

修正案： 各古いURLを、最も関連性の高いコンテンツへマッピングします。明らかにコンテンツが存在しない、あるいはサイトの入り口となるようなURL以外は、ホームページへの一括リダイレクトを避けてください。

間違い5：無関係なページへのリダイレクト

リダイレクトによるリンクエクイティの転送は、宛先のページがソースURLとテーマ的に関連している場合に最も効果を発揮します。例えば、詳細な技術チュートリアルを全く無関係な商品カテゴリページにリダイレクトすると、ユーザーと検索エンジンの両方を混乱させます。Googleの品質評価システムは、リダイレクト元と宛先の関連性を評価し、どれだけのオーソリティを転送すべきかを決定します。

修正案： トピックの関連性に基づいてリダイレクト先をマップしてください。真に関連性の高い宛先が存在しない場合は、無関係なリダイレクトを行うよりも、404エラーを返す方が適切なケースが多いです。

間違い6：リダイレクトを早期に解除する

外部からの被リンクがあるURLや、重要なトラフィックがあるURLについては、301リダイレクトを無期限に維持する必要があります。リダイレクトを削除すると、元のURLは404エラーを返し、すべての既存の被リンクが断ち切られ、宛先URLに渡されていたリンクエクイティが即座に消失します。一度失われたエクイティは、リダイレクトを復旧させない限り回復することはできません。
修正案： 外部被リンクを獲得しているURLの301リダイレクトは、決して削除しないでください。リダイレクトの保守は一時的なタスクではなく、永続的な運用責任です。

ミス7：内部リンクの更新漏れ

URLをリダイレクトしても、サイト内の至る所に古いURLを指すリンクが残っていると、クローラーが巡回するたびにリダイレクト・ホップが発生します。これが数十、数百の内部リンクで積み重なると、無視できない不要なクロール負荷（Crawl Overhead）が生じます。外部被リンクの問題ほど致命的ではありませんが、古い内部リンクはクロールの効率を低下させ、サイト構造のシグナルを混乱させる恐れがあります。

修正案： リダイレクトを実装した後、内部リンクの全面的な監査（内部リンク監査）を実施し、すべての内部参照を最終的な正規URL（Canonical URL）に直接リンクするよう更新してください。

ミス8：サイトマップの更新漏れ

XMLサイトマップには、現在の正規URLのみを記載すべきです。リダイレクト済みや廃止されたURLがサイトマップに残り続けると、クロールバジェット（Crawl Budget）を浪費し、新しい正規ページのインデックス登録を遅延させる可能性があります。

修正案： リダイレクト実装後は、リダイレクトされたURLをすべてサイトマップから削除してください。コンテンツ移行やURL構造の変更を行うたびに、サイトマップを更新するワークフローを徹底してください。

リダイレクトの実装方法：プラットフォーム別ガイド

Apache Webサーバー (.htaccess)

Apache環境で最も一般的な実装方法は、.htaccess ファイルの使用です。サイトのルートディレクトリ、またはルールを適用したい特定のサブディレクトリに .htaccess ファイルを設置します。

単一URLのリダイレクト (301):

Redirect 301 /old-page https://www.yoursite.com/new-page

単一URLのリダイレクト (302):

Redirect 302 /temporary-page https://www.yoursite.com/destination

ドメイン全体のリダイレクト (HTTPからHTTPSへ):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

ワイルドカードリダイレクト (旧ドメイン全体を新ドメインへ):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [L,R=301]

Nginx Webサーバー

Nginxでは、サーバー設定ファイル（nginx.conf または /etc/nginx/sites-available/ 内の各サイト専用設定ファイル）でリダイレクトを管理します。

単一URLのリダイレクト (301):

location /old-page {
    return 301 https://www.yoursite.com/new-page;
}

ドメイン全体のリダイレクト:

server {
    server_name old-domain.com www.old-domain.com;
    return 301 https://new-domain.com$request_uri;
}

WordPress

WordPressでは、プラグインを使用するか、.htaccess を直接編集してリダイレクトを管理します。開発者以外には、専用のリダイレクト管理プラグインを使用するのが最も確実な方法です。

推奨プラグイン:

• Redirection — 無料。301/302リダイレクトの管理、ログ取得、インポート/エクスポートが可能
• Yoast SEO Premium — SEOワークフローに統合されたリダイレクトマネージャーが含まれています
• Rank Math — .htaccessのインポート/エクスポート機能付きのリダイレクトマネージャーが含まれています

WordPressで .htaccess を使用する場合、上記Apacheのルールがそのまま適用されます。

Shopify

Shopifyの管理画面には、標準でURLリダイレクト管理機能が備わっています。「オンラインストア」→「移動」→「URLリダイレクト」へ進みます。古いパスと新しいURLを入力し、リダイレクトタイプを選択します（Shopifyのインターフェース経由で作成されたリダイレクトはデフォルトで301になります）。大規模なリダイレクト管理が必要な場合は、CSVインポート/エクスポート機能が利用可能です。

リダイレクト戦略の監査および監視方法

手順1：サイトのクローリングによるリダイレクト問題の特定

Screaming Frog SEO Spider（500 URLまでは無料、それ以上は有料）を使用して包括的なリダイレクト監査を行います。

1. ドメインを入力し、フルクローリングを実行
2. 「Response Codes（レスポンスコード）」→「Redirection (3xx)」へ進み、すべてのリダイレクト応答を確認
3. 「Status Code（ステータスコード）」カラムで、各リダイレクトが適切なタイプかを確認
4. 「Reports（レポート）」→「Redirect Chains（リダイレクトチェーン）」で、簡素化が必要な多段リダイレクト（マルチホップ）を特定
5. 「Reports（レポート）」→「Canonical Errors（正規化エラー）」で、正規タグ（Canonicalタグ）の実装と競合するリダイレクトがないか確認
6. すべてのリダイレクトデータをエクスポートし、ドキュメント化および照合を行う

手順2：Google Search Consoleでの監視

Google Search Consoleは、リダイレクト監視に不可欠な2つの重要なレポートを提供します。

インデックス作成レポート: 「インデックス作成」→「ページ」に移動し、「リダイレクト」ステータスでフィルタリングします。GoogleがどのURLをリダイレクトとして処理しているかを確認できます。本来は正規インデックスされるべきページがリダイレクトされていないか注意が必要です。

クロールの統計情報: リダイレクト実装後にクロールエラーが急増していないか確認してください。これらは、導入後に発生したリダイレクトループや不適切なチェーンの問題を示唆していることがよくあります。

手順3：リダイレクト後のキーワード順位の検証

大規模なリダイレクト実装（サイト移行や大規模なURL構造の再構築）を行った後は、ターゲットとしているキーワードの順位をモニタリングし、ランキングシグナルが遷移先URLへ正常に引き継がれたことを確認してください。Googleの再インデックス期間中（小規模サイトで通常2〜6週間、大規模サイトではそれ以上）に一時的な順位低下が発生するのは正常な挙動です。8〜10週間を経過しても順位の低下が続く場合は、調査が必要です。

Dageno AI：サイト移行中および移行後におけるAI検索の可視性モニタリング

サイト移行やURL構造の変更は、従来のSEOツールでは対処できない重大な隙間を生み出します。それは、ChatGPT、Perplexity、Google AI Overviews（AIモード）などのAI検索エンジンが、リダイレクト移行中および移行後に貴社ブランドをどのように認識・表示しているかという点です。URLが変更された場合、古いURLで学習または直近でクロールを行ったAIシステムは、移行後数週間から数ヶ月にわたって、古いコンテンツや古い説明文、あるいは誤ったページとの関連付けを引用し続ける可能性があります。たとえGoogleの従来型インデックスが正しく更新されていたとしてもです。

Dageno AIは、この可視性のギャップを埋めるための専用プラットフォームです。サイト移行中、Dageno AIはAIシステムが新しい正規URL（canonical URL）を引用しているか、あるいは廃止されたページを参照し続けているかを監視します。また、AIが生成する回答内のブランド説明が新しいポジショニングやコンテンツを反映して更新されているか、競合他社が移行期間を突いて、貴社が以前に支配していたカテゴリーでAIの引用を獲得しようとしていないかを追跡します。

Dageno AIのセマンティック・ギャップ分析は、AIシステムが貴社ブランドを古いURL構造、古い製品名、あるいは廃止されたコンテンツと紐づけているタイミングを特定し、AIの再インデックスプロセスを加速させるための具体的な推奨事項を提供します。リンクビルディングやデジタルPR活動を積極的に行っているブランドに対しては、Dageno AIの引用ソース追跡機能が、AIシステムが頻繁に参照するサードパーティソースのうち、どれがまだ古いURLや古い情報を含んでいるかを可視化します。これにより、AIが生成する回答に定着する前に、それらの参照先を更新するプロアクティブなアウトリーチが可能となります。

複雑なサイト移行を管理するテクニカルSEOチームにとって、Dageno AIは移行完了を検証するための不可欠な「AI可視性測定レイヤー」となります。従来のSERP順位やSearch Consoleのカバレッジを確認するだけでなく、移行がAI検索エコシステム全体に正常に伝播したことを確認することで、移行の成功を完全なものにします。

Dageno AIがテクニカルSEO移行をどのようにモニタリングするかを確認する →

リダイレクトに関するFAQ

301リダイレクトでPageRankは失われますか？
いいえ。2016年以降、Googleはすべての3xxリダイレクトが同等にPageRankを継承することを認めています。リダイレクトの種類の選択は、PageRankの最適化ではなく、移行の目的に対する技術的な正当性に基づいて行うべきです。

301リダイレクトはどのくらいの期間維持すべきですか？
外部リンクがある、または実質的な流入があるURLであれば、無期限に維持してください。301リダイレクトを削除すると、元のURLが404を返すようになり、すべての外部リンクが直ちに切断され、それらが持っていたリンクエクイティも失われます。

ドメイン全体を新しいドメインにリダイレクトできますか？
はい。これは301リダイレクトの一般的なユースケースです。すべてのトラフィックを一律にトップページへ転送するのではなく、古いドメインの各URLを新しいドメインの等価なURLへ個別にマッピングしてください。

リダイレクトチェーンは何段まで許容されますか？
1〜2ホップを超えるチェーンは、不要な遅延（レイテンシ）を生じさせ、リンクエクイティを希薄化させる可能性があります。可能な限りすべてのチェーンを単一の直接的なホップに簡素化してください。

302リダイレクトは順位に悪影響を与えますか？
一時的な変更のために302を使用するのは問題ありません。しかし、恒久的な変更に302を使用することは有害です。遷移先URLへのランキングシグナルの蓄積が妨げられ、Googleが元のURLをインデックスおよびランク付けし続ける結果となる可能性があります。

サイト移行のためのリダイレクトチェックリスト

• 移行前に、旧URLから新URLへの完全なURLマップを作成する
• すべての恒久的なURL変更に対して、サーバーサイドでの301リダイレクトを実装する
• 既存のリダイレクトチェーンを単一の直接ホップに解消する
• 本番公開前に、すべてのリダイレクトがステージング環境で正しく機能していることを検証する
• デプロイ後、XMLサイトマップを更新してリダイレクト済みのURLを削除する
• すべての内部リンクを最終的な遷移先URLに直接向くよう更新する
• 移行後、更新されたサイトマップをGoogle Search Consoleに送信する
• Google Search Consoleの「クロールエラー（カバレッジレポート）」を監視する
• 移行後6〜8週間はキーワードランキングを継続的に監視する
• バックリンクが存在するURLの301リダイレクトは、恒久的に維持する
• 移行後、AI検索におけるブランド説明の正確性（検索可視性）を監視する

参考文献

• Google検索セントラル – SEOのためのリダイレクト管理
• Ahrefs – 301リダイレクト：SEOへの影響について
• Screaming Frog SEO Spider – リダイレクト監査ツール
• Google Search Console – カバレッジおよびクロールレポート
• マッキンゼー – 生成AIの経済的潜在能力
• Dageno AI – 2026年版：ベストLLM SEOトラッカー