リダイレクトとは？ — URLを自動転送する仕組み
リダイレクトとは、ユーザーや検索エンジンのクローラーが特定のURLにアクセスした際に、自動的に別のURLへ転送する仕組みです。Googleのクローラーもリダイレクトを認識し、転送先のURLをインデックスします。
Webサイトの運用では、URLの変更は日常的に発生します。ページの統合、ドメインの変更、SSL化、サイトリニューアルなど、URLが変わる理由は多岐にわたります。こうした場面でリダイレクトを正しく設定しなければ、ユーザーは404エラーに遭遇し、検索エンジンに蓄積されたSEO評価も失われてしまいます。
つまり、リダイレクトは「URLの変更を安全に行うためのセーフティネット」であり、SEO施策の根幹を支える技術的な仕組みです。リダイレクトを正しく理解し運用することは、すべてのSEOコンサルタントにとって必須スキルといえます。
リダイレクトの基本的な仕組み
リダイレクトは、HTTPステータスコードを使用してブラウザや検索エンジンに「このURLは別のURLに移動しました」と通知します。具体的には、以下のステップで処理が行われます。
1. ユーザーが旧URL（example.com/old-page/）にアクセスする
2. サーバーがHTTPステータスコード（301や302）とともに新URLを返す
3. ブラウザが自動的に新URL（example.com/new-page/）に転送する
4. ユーザーには新URLのページが表示される
——この一連の処理は通常1秒未満で完了します。ユーザーはほとんど意識することなく新しいページを閲覧できます。なお、検索エンジンのクローラーも同様のプロセスを辿りますが、クローラーはHTTPレスポンスヘッダーのLocationフィールドを直接読み取るため、ブラウザよりも高速にリダイレクト先を認識します。
リダイレクトを設定する主な目的
|
目的 |
具体例 |
リダイレクトなし時のリスク |
|
URLの変更に対応 |
サイトリニューアルでURL構造が変わった場合 |
旧URLが404エラーとなり検索流入が消失 |
|
ドメインの統一 |
wwwあり/なし、http/httpsの統一 |
重複コンテンツとして評価が分散 |
|
ページの統合 |
類似コンテンツを1つのURLにまとめる場合 |
被リンク評価が複数URLに分散 |
|
一時的なメンテナンス |
メンテナンス中に仮ページへ転送する場合 |
ユーザーがエラーページに遭遇 |
|
404エラーの回避 |
削除したページへのアクセスを関連ページへ誘導する場合 |
ユーザー体験の悪化と離脱率上昇 |
|
正規化（canonical対応） |
重複URLを1つのURLに統一する場合 |
クロールバジェットの浪費 |
リダイレクトのHTTPレスポンスの仕組み
サーバーがリダイレクトを返す際のHTTPレスポンスヘッダーの構造を確認しましょう。
|
HTTPレスポンス要素 |
301の場合の値 |
302の場合の値 |
|
ステータスライン |
HTTP/1.1 301 Moved Permanently |
HTTP/1.1 302 Found |
|
Locationヘッダー |
Location: https://example.com/new-page/ |
Location: https://example.com/temp-page/ |
|
ブラウザのキャッシュ |
キャッシュされる |
キャッシュされない |
|
Googleの解釈 |
恒久的な移転 |
一時的な転送 |
リダイレクトの種類 — 301・302・307・メタリフレッシュの違い
リダイレクトにはいくつかの種類があります。目的に応じた使い分けが必要です。正しい種類を選ばなければ、SEO評価の引き継ぎに失敗したり、ブラウザのキャッシュが意図しない挙動を引き起こしたりする可能性があります。
なぜなら、検索エンジンはリダイレクトのステータスコードを「シグナル」として読み取り、転送元URLと転送先URLの関係性を判断しているからです。たとえば301は「恒久的な移転」のシグナルであり、Googleは旧URLの評価を新URLに引き渡します。一方で302は「一時的な転送」のシグナルであり、旧URLの評価はそのまま旧URLに保持されます。
主要なリダイレクトの比較表
|
種類 |
ステータスコード |
転送の性質 |
SEO評価の引き継ぎ |
HTTPメソッドの維持 |
主な用途 |
|
301リダイレクト |
301 |
恒久的（Permanent） |
引き継ぐ |
GETに変換される |
URL変更、ドメイン移行、ページ統合 |
|
302リダイレクト |
302 |
一時的（Found） |
原則引き継がない |
GETに変換される |
メンテナンス中の一時転送、A/Bテスト |
|
307リダイレクト |
307 |
一時的（Temporary） |
原則引き継がない |
維持される |
HTTPメソッドを維持する一時転送 |
|
308リダイレクト |
308 |
恒久的（Permanent） |
引き継ぐ |
維持される |
HTTPメソッドを維持する恒久転送 |
|
メタリフレッシュ |
— |
非推奨 |
不確実 |
— |
HTMLのmetaタグによる転送 |
|
JavaScriptリダイレクト |
— |
非推奨 |
不確実 |
— |
JavaScriptによる転送 |
301リダイレクトと302リダイレクトの違い
最も重要な違いは「恒久的か一時的か」です。この違いは、SEO評価の引き継ぎに直結するため、正確に理解しておく必要があります。
301リダイレクト（恒久的転送）
・「このURLは永久に新しいURLに移動しました」という意味です
・Googleは旧URLの評価（リンクジュース）を新URLに引き継ぎます
・ブラウザはリダイレクト先をキャッシュします
・使うべき場面: URL変更、ドメイン移行、ページ統合など、元に戻す予定がない場合
302リダイレクト（一時的転送）
・「このURLは一時的に別のURLに転送しています」という意味です
・Googleは旧URLの評価を保持し、新URLには引き継ぎません
・ブラウザはリダイレクト先をキャッシュしません
・使うべき場面: メンテナンス、A/Bテスト、季節的なキャンペーンページなど、元に戻す予定がある場合
——なお、Googleは長期間302リダイレクトが設定されている場合、それを301として解釈することがあります。ただし、意図的に302を使う場面では最初から正しいステータスコードを返すべきです。
307と308 — HTTP/1.1で追加されたリダイレクトの理解
307と308はHTTP/1.1で導入された比較的新しいステータスコードです。301/302との最大の違いは「HTTPメソッドを維持する」ことにあります。
たとえば、ユーザーがフォーム送信（POST）をした際に301や302でリダイレクトされると、ブラウザはPOSTをGETに変換してしまいます。307/308はこの変換を行わず、元のHTTPメソッドを維持したまま転送します。つまり、API連携やフォーム処理を伴うリダイレクトでは307/308が適切です。
|
シナリオ |
推奨コード |
理由 |
|
ページURLの恒久的変更 |
301 |
一般的なSEOリダイレクト |
|
メンテナンス中の一時転送 |
302 |
元URLに戻す予定がある |
|
APIエンドポイントの恒久移転 |
308 |
POSTメソッドを維持する必要がある |
|
フォーム送信先の一時変更 |
307 |
POSTメソッドを維持しつつ一時転送 |
リダイレクトの種類を選ぶ判断フローチャート
|
判断ポイント |
回答 |
推奨リダイレクト |
|
元のURLに戻す予定はありますか？ |
いいえ |
301リダイレクト |
|
元のURLに戻す予定はありますか？ |
はい |
302リダイレクト |
|
HTTPメソッド（POST等）を維持する必要がありますか？ |
はい（恒久的） |
308リダイレクト |
|
HTTPメソッド（POST等）を維持する必要がありますか？ |
はい（一時的） |
307リダイレクト |
|
サーバー設定にアクセスできますか？ |
いいえ |
メタリフレッシュ（非推奨） |
参考: Google 検索セントラル — リダイレクトと Google 検索
リダイレクトが必要になるケース
実務でリダイレクトが必要になる代表的なケースを整理します。SEOコンサルタントとしてクライアント対応をしていると、以下のいずれかのケースに必ず遭遇します。それぞれのケースで「なぜリダイレクトが必要なのか」「何を設定すべきか」を正確に把握しておくことが重要です。
ケース1: サイトリニューアル
サイトリニューアルでURL構造が変更される場合、旧URLから新URLへの301リダイレクトが必須です。——これを怠ると、旧URLにアクセスしたユーザーは404エラーに遭遇し、蓄積されたSEO評価も失われます。
サイトリニューアルは最もリダイレクト設計が複雑になるケースです。なぜなら、URL構造の変更がサイト全体に及ぶため、数十〜数千のURLに対してリダイレクトマッピングを作成する必要があるからです。特に、カテゴリ構造の変更やCMSの移行を伴うリニューアルでは、パターンマッチによる一括リダイレクトと個別リダイレクトの両方を組み合わせる設計が求められます。
ケース2: ドメイン変更
old-domain.com から new-domain.com へ移行する場合、全ページに対して301リダイレクトを設定します。ドメイン変更時は旧ドメインのDNS設定とサーバーを一定期間維持し、リダイレクトが正常に動作する状態を保つ必要があります。
つまり、旧ドメインの契約をすぐに解約してはいけません。旧ドメインの契約が切れるとリダイレクトが動作しなくなり、被リンク評価の引き継ぎも停止します。最低でも1年間、理想的には2年以上は旧ドメインを維持しましょう。
ケース3: HTTP→HTTPSの移行
SSL化に伴い、http:// から https:// への301リダイレクトを設定します。2026年現在、HTTPSはGoogleのランキングシグナルの一つです。SSL化自体は多くのサーバーやCDNで簡単に行えますが、リダイレクトの設定を忘れると、HTTPとHTTPSの両方でページがインデックスされ、重複コンテンツの問題が発生します。
ケース4: URLの正規化
同じコンテンツに複数のURLでアクセスできる状態（重複URL）を解消します。
|
正規化の対象 |
リダイレクト元 |
リダイレクト先 |
影響 |
|
www有無の統一 |
www.example.com |
example.com（またはその逆） |
被リンク評価の分散を防止 |
|
トレイリングスラッシュ |
example.com/page |
example.com/page/（またはその逆） |
重複コンテンツの解消 |
|
index.htmlの除去 |
example.com/index.html |
example.com/ |
URLの簡潔化 |
|
パラメータ付きURL |
example.com/page?ref=123 |
example.com/page |
クロールバジェットの最適化 |
|
大文字/小文字の統一 |
example.com/Page |
example.com/page |
重複URLの解消 |
ケース5: ページの統合・削除
類似コンテンツを1つのページに統合する場合や、不要なページを削除する場合に、関連性の高いページへ301リダイレクトを設定します。コンテンツ統合は「キーワードカニバリゼーション」を解消するための有効な手段です。複数のページが同じキーワードで競合している場合、最も評価の高いページに301リダイレクトで統合することで、検索評価を集約できます。
ケース6: 多言語・多リージョンサイトの統合
グローバルサイトの再編で国別URLを統合する場合にもリダイレクトが必要です。たとえば example.co.jp と example.com/ja/ を統合する場合、hreflangタグとの整合性も考慮しながら301リダイレクトを設計します。
リダイレクトの設定方法 — .htaccess・サーバー別の実装
.htaccessでの設定（Apache）
最も一般的なリダイレクト設定方法です。Apacheサーバーの.htaccessファイルに記述します。.htaccessはドキュメントルートに配置し、サーバーのAllowOverrideディレクティブが有効になっている必要があります。
なお、.htaccessファイルの記述ミスはサーバーエラー（500 Internal Server Error）を引き起こす原因になります。設定を変更する前に必ずバックアップを取得し、テスト環境で動作確認をしてから本番に反映しましょう。
#### 個別ページの301リダイレクト
# 単一ページのリダイレクト
Redirect 301 /old-page/ https://example.com/new-page/
# 複数ページを個別に指定
Redirect 301 /blog/old-post-1/ https://example.com/blog/new-post-1/
Redirect 301 /blog/old-post-2/ https://example.com/blog/new-post-2/
#### 正規表現を使ったリダイレクト
RewriteEngine On
# ディレクトリ全体を新ディレクトリへリダイレクト
RewriteRule ^old-directory/(.*)$ https://example.com/new-directory/$1 [R=301,L]
# 特定の拡張子を持つURLをリダイレクト
RewriteRule ^(.*)\.html$ https://example.com/$1/ [R=301,L]
# パラメータ付きURLをクリーンURLへリダイレクト
RewriteCond %{QUERY_STRING} ^id=([0-9]+)$
RewriteRule ^product\.php$ https://example.com/products/%1/? [R=301,L]
#### ドメイン全体の301リダイレクト
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
#### HTTP→HTTPSのリダイレクト
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
#### www有無の統一（wwwなしに統一）
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
.htaccessの主要ディレクティブ一覧
|
ディレクティブ |
用途 |
記述例 |
|
Redirect |
単純なURLリダイレクト |
Redirect 301 /old/ /new/ |
|
RedirectMatch |
正規表現によるリダイレクト |
RedirectMatch 301 ^/blog/(.*)$ /articles/$1 |
|
RewriteRule |
高度なURLリライト+リダイレクト |
RewriteRule ^old/(.*)$ /new/$1 [R=301,L] |
|
RewriteCond |
リライトの条件指定 |
RewriteCond %{HTTPS} off |
Nginxでの設定
# 個別ページのリダイレクト
location = /old-page/ {
return 301 https://example.com/new-page/;
}
# ディレクトリ全体のリダイレクト
location /old-directory/ {
rewrite ^/old-directory/(.*)$ https://example.com/new-directory/$1 permanent;
}
# ドメイン全体のリダイレクト
server {
server_name old-domain.com;
return 301 https://new-domain.com$request_uri;
}
# HTTP→HTTPSのリダイレクト
server {
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}
主要サーバー・CMS別の設定方法まとめ
|
環境 |
設定方法 |
ファイル/設定場所 |
難易度 |
|
Apache |
.htaccessファイル |
ドキュメントルートの.htaccess |
中 |
|
Nginx |
設定ファイル |
/etc/nginx/conf.d/ |
中〜高 |
|
WordPress |
プラグイン（Redirection等） |
WordPress管理画面 |
低 |
|
Cloudflare |
Page Rules / Redirect Rules |
Cloudflareダッシュボード |
低 |
|
Vercel |
vercel.json |
プロジェクトルート |
低〜中 |
|
Netlify |
_redirects または netlify.toml |
プロジェクトルート |
低 |
|
AWS CloudFront |
CloudFront Functions |
AWSコンソール |
高 |
|
Firebase Hosting |
firebase.json |
プロジェクトルート |
低〜中 |
WordPress/Cloudflare/Vercelでの具体的設定手順
サーバーの設定ファイルを直接編集できない場合でも、CMS・CDN・ホスティングプラットフォームの機能を使えばリダイレクトを設定できます。ここではWordPress・Cloudflare・Vercelの3つについて、コード例付きで具体的な設定手順を解説します。
WordPressでのリダイレクト設定
WordPressでリダイレクトを設定する方法は主に3つあります。
|
方法 |
メリット |
デメリット |
推奨ケース |
|
Redirectionプラグイン |
GUI操作で簡単、ログ機能あり |
プラグイン依存 |
数十〜数百件のリダイレクト |
|
Yoast SEOプレミアム |
SEOプラグインと統合管理可能 |
有料プラン必要 |
Yoastを既に導入済みのサイト |
|
functions.phpに記述 |
プラグイン不要 |
コード知識が必要 |
少数の固定リダイレクト |
#### Redirectionプラグインでの設定手順
1. WordPress管理画面 →「プラグイン」→「新規追加」→「Redirection」を検索してインストール
2. 「ツール」→「Redirection」を開く
3. 「新しいリダイレクトを追加」をクリック
4. ソースURL（旧URL）とターゲットURL（新URL）を入力
5. グループを「Redirections」に設定
6. 「リダイレクトを追加」をクリック
#### functions.phpでのリダイレクト（コード例）
// functions.php に追記
function custom_redirects() {
$redirects = array(
‘/old-page/’ => ‘/new-page/’,
‘/blog/old-post/’ => ‘/blog/new-post/’,
‘/service/old/’ => ‘/service/new/’,
);
$request_uri = $_SERVER[‘REQUEST_URI’];
foreach ( $redirects as $from => $to ) {
if ( strpos( $request_uri, $from ) === 0 ) {
wp_redirect( home_url( $to ), 301 );
exit;
}
}
}
add_action( ‘template_redirect’, ‘custom_redirects’ );
#### CSVインポートによる一括リダイレクト設定
Redirectionプラグインでは、CSVファイルで一括インポートが可能です。
|
CSVカラム |
内容 |
例 |
|
source |
リダイレクト元URL |
/old-page/ |
|
target |
リダイレクト先URL |
/new-page/ |
|
code |
ステータスコード |
301 |
|
match |
マッチタイプ |
url |
Cloudflareでのリダイレクト設定
Cloudflareはエッジサーバーでリダイレクトを処理するため、オリジンサーバーに負荷をかけずに高速なリダイレクトが可能です。
#### Redirect Rulesでの設定手順
1. Cloudflareダッシュボードにログイン → 対象ドメインを選択
2. 「Rules」→「Redirect Rules」を開く
3. 「Create rule」をクリック
4. ルール名を入力（例: Old blog to new blog）
5. 「When incoming requests match…」で条件を設定
・フィールド: URI Path
・演算子: equals または starts with
・値: /old-directory/
6. 「Then…」でリダイレクト先を設定
・タイプ: Static または Dynamic
・URL: https://example.com/new-directory/
・ステータスコード: 301
7. 「Deploy」をクリック
#### Cloudflare Bulk Redirects（大量リダイレクト対応）
数百〜数千件のリダイレクトを設定する場合は、Bulk Redirectsを使用します。
|
機能 |
Page Rules |
Redirect Rules |
Bulk Redirects |
|
リダイレクト数の上限 |
3件（無料プラン） |
10件（無料プラン） |
最大20,000件 |
|
正規表現対応 |
非対応 |
対応 |
非対応 |
|
エッジ処理 |
はい |
はい |
はい |
|
推奨ケース |
少数の単純ルール |
中規模のルール |
大量の個別リダイレクト |
Vercelでのリダイレクト設定
Vercelではvercel.jsonファイルにリダイレクトルールを記述します。
#### vercel.jsonの基本設定
{
"redirects": [
{
"source": "/old-page",
"destination": "/new-page",
"permanent": true
},
{
"source": "/blog/:slug",
"destination": "/articles/:slug",
"permanent": true
},
{
"source": "/docs/:path*",
"destination": "https://docs.example.com/:path*",
"permanent": false
}
]
}
#### Vercelリダイレクトの設定パラメータ
|
パラメータ |
型 |
説明 |
例 |
|
source |
string |
リダイレクト元のURLパターン |
/old-page |
|
destination |
string |
リダイレクト先のURL |
/new-page |
|
permanent |
boolean |
true = 308、false = 307 |
true |
|
has |
array |
マッチ条件（ヘッダー、クエリ等） |
[{"type": "query", "key": "ref"}] |
——Vercelのpermanent: trueは301ではなく308を返す点に注意してください。SEO上は301と同等に扱われますが、クライアント側のHTTPメソッド維持に影響する場合があります。
#### Next.jsのnext.config.jsでの設定
Vercel上でNext.jsを使用している場合、next.config.jsでもリダイレクトを設定できます。
// next.config.js
module.exports = {
async redirects() {
return [
{
source: ‘/old-blog/:slug’,
destination: ‘/blog/:slug’,
permanent: true,
},
{
source: ‘/old-docs/:path*’,
destination: ‘/docs/:path*’,
permanent: true,
},
];
},
};
より体系的にテクニカルSEOを学びたい方は → 第2章 テクニカルSEOの基礎
大規模リニューアル時のリダイレクトマッピング設計手法
数百〜数千URLの移行を伴う大規模リニューアルでは、個別にリダイレクトを設定するのではなく、体系的な「マッピング設計」が不可欠です。マッピング設計とは、旧URLと新URLの対応関係を整理し、パターンベースのルールと個別ルールを組み合わせてリダイレクト計画を策定することです。
マッピング設計なしに場当たり的にリダイレクトを設定すると、漏れや重複が発生し、リダイレクトチェーンやリダイレクトループの原因になります。つまり、マッピング設計は「リダイレクトの品質管理」そのものです。
マッピング設計の5ステップ
|
ステップ |
作業内容 |
担当 |
成果物 |
|
1. 旧URLの棚卸し |
Screaming Frogで旧サイト全URLをクロール |
SEOコンサルタント |
旧URLリスト（CSV） |
|
2. 優先度付け |
被リンク・検索流入・PVに基づく優先度設定 |
SEOコンサルタント |
優先度付きURLリスト |
|
3. 新URL構造の確定 |
新サイトのURL設計をディレクトリ単位で確定 |
ディレクター + エンジニア |
新URL設計書 |
|
4. マッピングシート作成 |
旧URL→新URLの対応表を作成 |
SEOコンサルタント |
マッピングシート |
|
5. パターンルール設計 |
正規表現ルールと個別ルールの振り分け |
エンジニア |
リダイレクト設定ファイル |
マッピングシートのテンプレート
以下は実際の案件で使用するマッピングシートのテーブル例です。
|
No. |
旧URL |
新URL |
リダイレクト種類 |
優先度 |
被リンク数 |
月間検索流入 |
備考 |
|
1 |
/blog/seo-basics/ |
/articles/seo-guide/ |
301（個別） |
高 |
45 |
1,200 |
主力記事 |
|
2 |
/blog/keyword-research/ |
/articles/keyword-guide/ |
301（個別） |
高 |
32 |
890 |
被リンク多数 |
|
3 |
/services/consulting/ |
/service/seo-consulting/ |
301（個別） |
高 |
28 |
560 |
CVページ |
|
4 |
/category/news/* |
/blog/news/* |
301（パターン） |
中 |
— |
— |
カテゴリ一括 |
|
5 |
/tag/* |
/blog/tags/* |
301（パターン） |
低 |
— |
— |
タグ一括 |
|
6 |
/old-landing-page/ |
/ |
301（個別） |
低 |
3 |
15 |
終了LP→トップ |
パターンルールと個別ルールの使い分け
|
ルール種別 |
適用ケース |
メリット |
デメリット |
|
パターンルール（正規表現） |
ディレクトリ構造が規則的に変更された場合 |
一括で大量のURLを処理可能 |
例外的なURLに対応しにくい |
|
個別ルール |
被リンク数が多い重要ページ、URL構造が不規則な場合 |
正確な1対1マッピングが可能 |
数が多いと管理が煩雑 |
|
組み合わせ |
大規模リニューアル |
効率性と正確性の両立 |
設計・テストに時間がかかる |
リダイレクト設定の検証チェックリスト
マッピングシートに基づいてリダイレクトを設定した後は、以下の項目を必ず検証します。
|
検証項目 |
確認方法 |
OKの基準 |
|
全URLが正しくリダイレクトされるか |
Screaming Frogで全旧URLをクロール |
全旧URLが新URLに301で転送 |
|
リダイレクトチェーンがないか |
httpstatus.ioで抽出確認 |
1ホップ以内 |
|
リダイレクトループがないか |
Screaming Frogのレポートで確認 |
ループなし |
|
ステータスコードが正しいか |
curlコマンドでサンプル確認 |
301 Moved Permanently |
|
旧URLのクエリパラメータの扱い |
パラメータ付きURLで動作確認 |
意図通りの挙動 |
リダイレクトとJavaScript SPA
近年、React・Vue.js・Next.js・Nuxt.jsなどのJavaScriptフレームワークを使用したSPA（Single Page Application）が増加しています。SPAはクライアントサイドでルーティングを行うため、従来のサーバーサイドリダイレクトとは異なるアプローチが必要です。
SPAにおけるリダイレクトの課題
SPAでは、ページ遷移がブラウザ上のJavaScriptで制御されます。つまり、サーバーには初回アクセス時の1リクエストしか到達しません。このため、クライアントサイドのルーティングで行われる「リダイレクト」は、検索エンジンのクローラーが正しく認識できない可能性があります。
|
項目 |
従来のWebサイト |
SPA |
|
ページ遷移の仕組み |
サーバーが新しいHTMLを返す |
JavaScriptがDOMを書き換える |
|
リダイレクトの処理 |
サーバーが301/302ステータスコードを返す |
クライアント側のルーターが処理 |
|
Googleの認識 |
即座に認識 |
レンダリング後に認識（遅延の可能性） |
|
クローラビリティ |
高い |
設定次第で低下する可能性 |
SPAでのリダイレクト実装方法
#### 方法1: SSR/SSGフレームワークのリダイレクト機能を使う（推奨）
Next.jsやNuxt.jsなどのSSR（Server-Side Rendering）対応フレームワークでは、サーバーサイドでリダイレクトを処理できます。これが最もSEOに安全な方法です。
// Next.js: next.config.js でのリダイレクト設定
module.exports = {
async redirects() {
return [
{
source: ‘/old-page’,
destination: ‘/new-page’,
permanent: true, // 308（SEO上は301と同等）
},
];
},
};
// Nuxt.js: nuxt.config.ts でのリダイレクト設定
export default defineNuxtConfig({
routeRules: {
‘/old-page’: { redirect: ‘/new-page’ },
‘/blog/**’: { redirect: ‘/articles/**’ },
},
});
#### 方法2: エッジ/CDNレベルでリダイレクトする
CloudflareやVercelのエッジでリダイレクトを処理することで、SPAのクライアントサイドルーティングに依存しないリダイレクトが可能です。
#### 方法3: クライアントサイドリダイレクト（非推奨）
React Routerなどのクライアントサイドルーターでリダイレクトを実装する方法です。ただし、この方法はGoogleのクローラーがJavaScriptをレンダリングするまで認識されないため、SEO目的のリダイレクトには推奨しません。
SPA別リダイレクト対応まとめ
|
フレームワーク |
推奨リダイレクト方法 |
設定ファイル |
SEO安全性 |
|
Next.js（Vercel） |
next.config.js + vercel.json |
サーバーサイド |
高 |
|
Nuxt.js（Netlify） |
nuxt.config.ts + _redirects |
サーバーサイド |
高 |
|
Gatsby（Netlify） |
gatsby-node.js + _redirects |
ビルド時+サーバーサイド |
高 |
|
React SPA（S3+CloudFront） |
CloudFront Functions |
エッジ |
中〜高 |
|
Vue SPA（Apache/Nginx） |
.htaccess / nginx.conf |
サーバーサイド |
高 |
|
Angular SPA（Firebase） |
firebase.json |
サーバーサイド |
高 |
——SPAのリダイレクトで最も重要な原則は、「クライアントサイドに頼らず、サーバーサイドまたはエッジでリダイレクトを処理する」ことです。JavaScriptによるリダイレクトはSEO上のリスクが高いため、必ずサーバーレベルで処理しましょう。
リダイレクトとSEOの関係 — 評価の引き継ぎと注意点
301リダイレクトによるSEO評価の引き継ぎ
Googleは2016年に「301リダイレクトでPageRankの損失はない」と公式に発表しています。つまり、正しく301リダイレクトを設定すれば、旧URLが持っていたSEO評価は新URLに引き継がれます。
ただし、「損失がない」とは理論上の話であり、実際のリニューアル案件では一時的な検索順位の変動が発生することが一般的です。なぜなら、Googleが旧URLから新URLへの評価移行を完了するまでには数週間〜数ヶ月を要するからです。つまり、リダイレクトを正しく設定したとしても、短期的な順位変動は想定の範囲内として計画に組み込むべきです。
リダイレクト種類別のSEO影響比較
|
リダイレクトの種類 |
PageRankの引き継ぎ |
インデックスされるURL |
クロールバジェットへの影響 |
推奨度（SEO） |
|
301リダイレクト |
引き継ぐ |
新URL |
初回クロール時にコスト発生 |
最も推奨 |
|
302リダイレクト |
状況による |
旧URLが維持される傾向 |
毎回クロール時にコスト発生 |
一時的な場合のみ |
|
308リダイレクト |
引き継ぐ |
新URL |
301と同等 |
API移転時に推奨 |
|
リダイレクトなし（404） |
引き継がない |
インデックスから削除 |
— |
非推奨 |
|
リダイレクトチェーン |
引き継ぐが、速度面で不利 |
最終URLがインデックス |
多段階でコスト増大 |
解消推奨 |
|
メタリフレッシュ |
不確実 |
不定 |
Googleが正しく処理できない場合あり |
非推奨 |
SEO観点での注意点
#### リダイレクトチェーンを避ける
リダイレクトチェーンとは、A→B→Cのように複数回リダイレクトが発生する状態です。Googleはチェーンを追跡できますが、クロール効率が下がります。A→Cの直接リダイレクトに修正しましょう。
特に過去に複数回のリニューアルを行ったサイトでは、旧リダイレクトの上に新しいリダイレクトが追加され、3段階以上のチェーンが発生しているケースがあります。Screaming Frogなどのツールで定期的にチェーンの有無を確認し、見つけた場合は直接リダイレクトに修正することが重要です。
#### 関連性のないページへのリダイレクトはNG
旧ページと無関連なページへリダイレクトすると、Googleはそれを「ソフト404」として扱う可能性があります。——必ず、コンテンツの関連性が高いページへリダイレクトしてください。
たとえば、商品ページが廃止になった場合、トップページへリダイレクトするのではなく、同カテゴリの商品一覧ページや後継商品のページへリダイレクトするのが適切です。関連ページが存在しない場合は、リダイレクトではなく410（Gone）ステータスコードを返すことも選択肢の一つです。
#### リダイレクトの維持期間
Googleは「少なくとも1年間はリダイレクトを維持すること」を推奨しています。なぜなら、Googleが評価を完全に新URLに移行するまでに時間がかかるからです。被リンクが多い重要ページについては、恒久的にリダイレクトを維持することを推奨します。
#### クロールバジェットへの影響
大量のリダイレクトはクロールバジェットを消費します。特に大規模サイトでは、Googlebotがリダイレクトの追跡に時間を費やし、新しいコンテンツのクロールが遅れる可能性があります。
|
サイト規模 |
URL数 |
クロールバジェットへの影響 |
対策 |
|
小規模 |
〜100ページ |
ほぼ影響なし |
通常のリダイレクト設定で問題なし |
|
中規模 |
100〜1,000ページ |
軽微な影響 |
チェーンの解消、不要なリダイレクトの削除 |
|
大規模 |
1,000ページ以上 |
無視できない影響 |
RewriteMapの活用、段階的な移行 |
リダイレクトのよくあるエラーと対処法
エラー一覧と対処法
|
エラー |
症状 |
原因 |
対処法 |
深刻度 |
|
リダイレクトループ |
「リダイレクトの回数が多すぎます」と表示 |
A→B→Aのような循環リダイレクトが発生 |
リダイレクト設定を見直しループを解消する |
高 |
|
リダイレクトチェーン |
ページ表示が遅い、クローラビリティが低下 |
A→B→C→Dのように多段階のリダイレクト |
直接リダイレクト（A→D）に修正する |
中 |
|
302の誤使用 |
SEO評価が新URLに移行しない |
恒久的な移行に302を使用している |
301リダイレクトに変更する |
中 |
|
ソフト404 |
Search Consoleで「ソフト404」と報告される |
関連性のないページへリダイレクトしている |
関連性の高いページへ変更する |
中 |
|
リダイレクトの欠落 |
旧URLが404エラーを返す |
リダイレクトが未設定 |
マッピングを作成し設定する |
高 |
|
HTTPS/HTTPの混在 |
一部ページがHTTPのままアクセス可能 |
HTTPSリダイレクトの設定漏れ |
サイト全体のHTTPSリダイレクトを確認 |
中 |
|
トレイリングスラッシュの不統一 |
同一ページが2つのURLでアクセス可能 |
スラッシュあり/なしの統一が未実施 |
一方に統一するリダイレクトを設定 |
低 |
エラーのトラブルシューティングフロー
|
症状 |
最初に確認すること |
次のステップ |
ツール |
|
ページが表示されない |
ブラウザのDevToolsでステータスコード確認 |
リダイレクトループの有無を確認 |
Chrome DevTools |
|
検索順位が下落した |
Search Consoleのインデックスレポート確認 |
リダイレクトの欠落・302誤使用を確認 |
GSC + Screaming Frog |
|
500エラーが発生 |
.htaccessの構文エラーを確認 |
エラーログでエラー箇所を特定 |
サーバーエラーログ |
|
リダイレクトが反映されない |
ブラウザキャッシュをクリアして再確認 |
サーバーキャッシュ・CDNキャッシュを確認 |
curl -I コマンド |
リダイレクトの確認ツール
|
ツール |
確認できること |
費用 |
推奨場面 |
|
Google Search Console |
リダイレクトエラー、インデックス状況 |
無料 |
事後モニタリング |
|
httpstatus.io |
HTTPステータスコード、リダイレクトチェーン |
無料 |
個別URL確認 |
|
Screaming Frog |
サイト全体のリダイレクト状況 |
500URLまで無料 |
サイト全体の検証 |
|
Redirect Checker（Chrome拡張） |
ブラウザ上でリアルタイム確認 |
無料 |
日常的な確認 |
|
curl コマンド |
ターミナルからのステータスコード確認 |
無料 |
技術的な検証 |
|
Ahrefs Site Audit |
リダイレクトチェーン・ループの検出 |
有料 |
大規模サイトの監査 |
curlコマンドによる確認方法
ターミナルからリダイレクトの動作を確認する方法です。
# ステータスコードとリダイレクト先を確認
curl -I https://example.com/old-page/
# リダイレクトチェーンを追跡
curl -IL https://example.com/old-page/
# ステータスコードのみを表示
curl -o /dev/null -s -w "%{http_code}" https://example.com/old-page/
【実践事例】サイトリニューアル時のリダイレクト設計
scale-basics.comのURL構造変更時の事例
scale-basics.comでは、サイト構造の改善に伴いURL構造を変更しました。以下の手順でリダイレクト設計を実施しています。このケースでは、コンテンツの充実に伴いカテゴリ構造を再設計したことで、約150URLのリダイレクトが必要になりました。
事前の計画段階で特に重視したのは、「被リンクが多いページの確実な移行」と「パターンルールで一括対応できるURLの洗い出し」の2点です。なぜなら、被リンクの多いページはSEO評価への影響が大きく、パターンルールの活用は設定ミスの削減と保守性の向上に直結するからです。
#### リダイレクト設計の手順
|
ステップ |
作業内容 |
使用ツール |
所要時間（目安） |
|
1. 旧URLの洗い出し |
サイト全体のURLリストを作成 |
Screaming Frog |
1時間 |
|
2. リダイレクトマッピング |
旧URL→新URLの対応表を作成 |
Google Sheets |
2〜4時間 |
|
3. 被リンクの確認 |
旧URLへの被リンクを確認し、優先度を設定 |
Ahrefs |
1〜2時間 |
|
4. リダイレクト設定 |
.htaccessファイルにルールを記述 |
テキストエディタ |
2〜3時間 |
|
5. 設定の検証 |
全リダイレクトの動作確認 |
httpstatus.io + Screaming Frog |
2〜3時間 |
|
6. 事後モニタリング |
Search Consoleでエラー有無を4週間監視 |
Google Search Console |
継続 |
#### 成果
|
指標 |
数値 |
|
リダイレクト対象 |
約150URL |
|
リダイレクト完了率 |
100%（全URL正常転送を確認） |
|
検索順位の変動 |
リニューアル後2週間で一時的に5〜10%下落 → 4週間後に回復 |
|
被リンク評価の引き継ぎ |
Ahrefsで確認、ドメインレーティングに変化なし |
|
リダイレクトチェーン |
0件（全URL1ホップ以内） |
——この事例から学べるのは、「事前のマッピング作成」と「事後のモニタリング」が成功のカギだということです。特に、被リンクの多い上位20ページに対しては個別にリダイレクト先を精査し、パターンルールではなく個別ルールで設定したことが、SEO評価の維持に寄与しました。
リダイレクトに関するよくある質問
Q. 301リダイレクトはいつまで維持する必要がありますか？
Googleは「少なくとも1年間」を推奨しています。可能であれば恒久的に維持することが望ましいです。なぜなら、外部サイトからの被リンクが旧URLに向けられている場合、リダイレクトを解除するとそのリンク評価が失われるからです。
実務では、サーバーコストの関係でリダイレクトを永久に維持できないケースもあります。その場合は、被リンク数が多い上位ページのリダイレクトのみ維持し、被リンクのない低優先度ページのリダイレクトは1年後に解除するという段階的なアプローチが有効です。
Q. 301リダイレクトとcanonicalタグはどう使い分けますか？
301リダイレクトは「URLが変更された場合」に使用します。canonicalタグは「複数のURLで同じコンテンツにアクセスできる状態を解消する場合」に使用します。——URLそのものが変わるなら301、URLは残すが正規URLを指定するならcanonicalです。
|
状況 |
推奨手法 |
理由 |
|
URLが完全に変わった |
301リダイレクト |
ユーザーも検索エンジンも新URLに転送する必要がある |
|
同じコンテンツに複数URLでアクセス可能 |
canonicalタグ |
URLは残しつつ正規URLを検索エンジンに伝える |
|
パラメータ違いの重複URL |
canonicalタグ |
パラメータ付きURLを残しつつ正規URLを指定 |
|
HTTP→HTTPS移行 |
301リダイレクト |
HTTP版へのアクセスをHTTPS版に転送 |
Q. 大量のリダイレクトはサイト速度に影響しますか？
.htaccessに大量のリダイレクトルールを記述すると、サーバー処理に負荷がかかる場合があります。数千件以上のリダイレクトがある場合は、RewriteMapやデータベースベースのリダイレクトを検討しましょう。
具体的には、.htaccessに1,000件以上の個別リダイレクトルールを記述するとApacheのリクエスト処理時間が増加する傾向があります。RewriteMapを使えば、リダイレクトルールをテキストファイルやDBMファイルに外出しし、メモリ上でハッシュマップとして処理できるため、パフォーマンスの劣化を防げます。
Q. JavaScriptリダイレクトはSEOに影響がありますか？
JavaScriptリダイレクトは、Googleがレンダリングして初めて認識されます。サーバーサイドの301リダイレクトと比べて認識が遅れる可能性があります。SEO目的のリダイレクトには、必ずサーバーサイドの301/302リダイレクトを使用してください。
Q. リダイレクト設定後、Search Consoleでエラーが増えたのはなぜですか？
リダイレクト設定直後はGoogleが旧URLの再クロールを行うため、一時的にSearch Consoleのレポートでエラーが検出されることがあります。通常は2〜4週間で収束します。4週間以上エラーが解消しない場合は、リダイレクト設定に不備がないか再確認してください。
Q. リダイレクトマッピングはどのように管理すべきですか？
Google Sheetsやスプレッドシートで管理するのが一般的です。マッピングシートには「旧URL」「新URL」「リダイレクト種類」「優先度」「被リンク数」「設定日」「確認日」のカラムを設け、チームで共有します。——大規模なサイトではCMS内でリダイレクトを管理する機能を使うか、専用のリダイレクト管理ツールの導入も検討しましょう。
まとめ — リダイレクトは「正しい種類」と「正確な設定」が命
リダイレクトとは、URLの変更時にSEO評価を守り、ユーザー体験を維持するための不可欠な仕組みです。
本記事のポイントを整理します。
・リダイレクトとはURLを自動転送する仕組みで、HTTPステータスコードで制御される
・恒久的な転送は301、一時的な転送は302を使用する
・301リダイレクトではSEO評価（PageRank）が新URLに引き継がれる
・WordPress・Cloudflare・Vercelなどプラットフォーム別に適切な設定方法がある
・大規模リニューアルではマッピングシートによる体系的な設計が必須
・SPAサイトではサーバーサイドまたはエッジレベルでリダイレクトを処理する
・リダイレクトチェーン・リダイレクトループは必ず回避する
・サイトリニューアル時は事前のマッピング作成と事後のモニタリングが必須
・リダイレクトは最低1年間維持する
テクニカルSEOの実践方法をさらに学びたい方は → 第2章 テクニカルSEOの基礎
リダイレクトの設定ミスは、検索順位の大幅な下落につながります。——本記事の内容を参考に、「正しい種類を選び、正確に設定する」ことを徹底しましょう。