301か302リダイレクト? 30秒でわかる正解

8分で読める · 最終更新 2026年5月2日

読まずに聴く

読まずに聴く

「90秒で要点」

0:00

0:00

1x

まとめ

ページを永久に移す? 301を使ってください。一時的なだけ? 302を使ってください。このルール一つで、あなたが今後下すリダイレクトの判断の10回中9回はカバーできます。(残りの1回、リクエストタイプを途中で変えられないAPIエンドポイントでは307か308を使います。ほとんどの人は触ることがありません。)

自分のサイトで実際に何が動いているか知りたい? サーバーが送っているコードを明らかにする1行のチェック方法があります。もし302と出ていて、その移行が永続のはずだったなら、あなたの順位はリアルタイムで滑り落ちています。コマンドラインの知識は不要で、下で手順をご案内します。

復旧には間違ったコードを直してGoogleに再クロールを依頼してから2〜6週間かかります。その待ち時間の大半は、Googleのボットが自分のペースで戻ってくるのを待つ時間にすぎません。

夜の11時。移行から3週間が経ち、オーガニックトラフィックは40%下がっています。開発チームはリダイレクトは問題ないと言い切る。Search Consoleも普通に見える。それでもアナリティクスのグラフの線は落ち続け、あなたは数字が違うことを告げてくれるのを期待するかのように、何度も更新ボタンを押しています。

誰も教えてくれなかった部分はここです。リダイレクトには2種類あって、人間の訪問者からは全く同じに見えます。Googleにとっては、まったく別物です。一方はこう言います。このページは永久に移った、だから全部引き継いでくれ。もう一方はこう言います。このページは少しだけ留守にしている、だから古い方を順位付けし続けてくれ。移行中に間違った方を使うと、検索エンジンはサイトのどちらのバージョンを実際に順位付けすべきか、何週間も混乱します。

修正はたいてい1行のコードです。難しいのは、そもそも問題に気づくことです。

このガイドでは、その全体を順を追って説明します。正しいリダイレクトを選ぶシンプルなルール(本当にたった2つの質問です)。あなたのサイトが動いている環境に合わせて、そのまま貼り付けられるコード(WordPress、Shopify、Next.js、Apache、Nginx、ぜんぶ揃っています)。修正後にGoogle Search Consoleで確認すべき、まさにその項目で、直ったことを証明する方法。そして他人のミスがあなたの膝に落ちてきた場合には、最後に4ステップの復旧プレイブックが待っています。

最初に1つだけ。リダイレクトについてSEOダッシュボードが言うことを鵜呑みにしないでください。開発者が言うことも鵜呑みにしないでください。あなたのサーバーが実際に何を返しているか、自分の目で確かめてください。自分で証明してください。信じるな。証明せよ。その簡単なやり方をお見せします。

30秒で分かる答え

ページを永久に移す? 301を使う。ちょっとの間だけ? 302を使う。他に覚える価値があるのはAPIエンドポイントの話で、ここでは307(一時)か308(永久)が必要になる。APIを触る開発者でもない限り、この2つに出くわすことはまずない。

このルール1つで判断の90%はカバーできる。なぜコード選びがそこまで重要なのか? リダイレクトコードは同時に2つの仕事をこなしているからだ。1つは、検索エンジンに「この移動は永久か一時か」を伝えること。もう1つは、ブラウザに「リクエストの種類(GETやPOSTなど)を途中で変えずに保つ必要があるか」を静かに伝えること。私たちのほとんどは、1つ目の仕事のことだけを考えればいい。

内部の仕組みは、どのリダイレクトも同じだ。訪問者が古いURLをリクエストする。サーバーは「このページは移動しました。新しいアドレスはこちらです」という短いメッセージを返す。そのメッセージに付いている番号(301、302、307、308)こそが、検索エンジンに移動の扱い方を指示するものだ。

1つ知っておく価値のある細かい点がある。Googleは2016年、302の扱い方をひっそりと更新した。リダイレクトが十分長く維持され、新しいページが古いページと実際に一致している場合に限り、302を正式なシグナルとして扱う柔軟性を持つようになった。つまり、SEO上の結果(どのURLが最終的にランクするか、リンクエクイティがどこに流れるか)は、単にどの番号を選んだかだけでは決まらない。リダイレクトがどれだけ長く続くか。コンテンツがどれだけ似ているか。Googleがどれだけ頻繁にクロールするか。すべてが関わってくる。証拠はこのあと一緒に見ていこう。

この表が短い答えだ。このガイドの残りでは、どちらを選ぶかによってランキング、クロールバジェット、インデックス済みURLに実際に何が起こるのかを紐解いていく。主要プラットフォームごとの貼り付けるだけで使えるコードと、実際のクロールデータおよびGoogle自身のドキュメントから引き出した証拠を見ていこう。

定義: 301、302、307、308、そして Location ヘッダー

このガイドの残りで出てくる定義を並べておきます。ブックマークしておく価値あり。何度も戻ってくるはずです。

301 Moved Permanently: リソースが Location ヘッダーで示された URL に恒久的に移動したことをブラウザに伝えるレスポンスステータスコード。検索エンジンはランキングシグナルを新 URL に引き継ぎ、ブラウザはこのリダイレクトを積極的にキャッシュします。

302 Found: リソースが一時的に Location ヘッダーで示された別の URL に存在することをブラウザに伝えるレスポンスステータスコード。検索エンジンは元の URL をインデックスに保持し、ブラウザはデフォルトではキャッシュしません。

307 Temporary Redirect: 302 に似ていますが、メソッドの厳密な保持が求められます。クライアントは同じメソッドでリクエストを繰り返す必要があります (POST は POST のまま)。API 契約で動詞を変更できない場合に使います。

308 Permanent Redirect: 301 に似ていますが、メソッドの厳密な保持が求められます。恒久的かつメソッド安全。

Location ヘッダー: あらゆる 3xx リダイレクトの遷移先 URL を運ぶ HTTP レスポンスヘッダー。

関連するものの別の仕組みである <link rel=canonical> については、canonical URL ガイドも参照してください。より深い実装の詳細については、MDN Web Docs の HTTP リダイレクション にブラウザ固有の挙動に関する良いメモがあります。

301 と 302 の使い分け：判断ルール

結局のところ、問いは一つです。その移動は恒久的ですか、それとも一時的ですか。以下のケースで、どちら側かが分かります。

301 を使うのはこんなとき…

新しいドメインへ永久に移転するとき。 oldbrand.com が newbrand.com になり、元に戻る可能性がゼロなら 301 を使います。検索エンジンに対して、旧ドメインについて知っている情報をすべて新ドメインへ引き継ぎ、旧ドメインはインデックスから外してくれ、と伝える合図です。

HTTP から HTTPS に移行するとき。 サイトのすべてのページが、非セキュア版（ブラウザに鍵マークが付かない方）からセキュア版へ移ります。これは恒久的です。301 を使えば、ブラウザも検索エンジンも今後は HTTPS を正式版として扱うようになります。

URL 構造を作り直すとき。 サイト全体の再編の一環で /blog/post-1 が /posts/post-1 になるなら、古いパスが二度と戻ってこないようにしたいはずです。301 はランク評価をまるごと新しい構造へ引き渡します。

ページを統合・整理するとき。 短い 2 ページを 1 つの強いページにまとめたら、古い URL を恒久的にリダイレクトします。統合されたページは両方のランク評価を受け継ぎます。

削除したページを親カテゴリへ送るとき。 終了した商品のページに「ページが見つかりません」を出す代わりに、親カテゴリのページへリダイレクトします。ユーザーは役立つ場所に着地し、ランク評価は消え去るのではなく関連ページに流れます。

末尾スラッシュあり／なしのどちらを採用するか決めるとき。 /page か /page/ のいずれかを選び、もう一方を恒久的にリダイレクトします。統一しておけば、Google が別々のページとして扱うのを防げます。

www あり／なしのどちらを採用するか決めるとき。 www.domain.com か domain.com のどちらかをメインバージョンに決めます。もう一方を 301 でリダイレクトすれば、検索エンジンはすべてのシグナルを 1 つに集約してくれます。

EC サイトの移行（Shopify から WooCommerce、独自ストアフロントから Shopify Plus など）は、ブランドが実施する 301 リダイレクト案件の中でも最大級のものです。移行プレイブックの全貌、特に URL 変更を公開する 前 に作り込むリダイレクトマップの話は、Revenue Funnel SEO メソドロジーの中で詳しく扱っています。

302 を使うのはこんなとき…

A/B テストを回しているとき。 トラフィックの半分をバリアント版に流している場合、実験中はどちらのバージョンもメイン URL に昇格させたくありません。302 は検索エンジンに「データを集めている間、元の URL が主役のままだ」と伝えます。

メンテナンス中のとき。 計画停止中に訪問者をステータスページへ送るなら、それは定義上一時的です。302 なら Google における元 URL の立場がそのまま保たれるので、修正作業中に順位が動きません。

まだ国別タグを設定していないとき。 インドからの訪問者を /in/ へ、米国からの訪問者を /us/ へ送っていますか。hreflang をまだ追加していないなら 302 を使いましょう（hreflang は、どの国でどのバージョンを表示するかを Google に伝えるタグです）。これで Google が間違った地域版をメイン URL と判断してしまうのを防げます。

期間限定のプロモページを運用しているとき。 12 月 1 日以降に消えるブラックフライデー用ページが、メインページの順位評価を吸い上げてしまうのは避けたいはずです。302 なら元の URL がメインのまま、プロモページはキャンペーン期間中だけ存在します。

リニューアル中にプレースホルダーページを使うとき。 サイトの一部をリデザインするとき、プレースホルダーへ一時的にリダイレクトすれば元 URL の評価は無傷のまま維持できます。リニューアルが公開されたらリダイレクトを外し、元の URL が再び主役に戻ります。

ルールだけでは割り切れない境界ケース

ショッピングカートの決済後のリダイレクトは、厳密には 303 を使うべきです（ブラウザに「フォームデータは忘れて、このページを取ってきて」と伝えます）。多くのプラットフォームは代わりに 302 を返しますが、ブラウザは同じように扱います。クライアントが POST データを送る API の移動は、本来リクエストの種類を固定する 308 を使うべきです。ほとんどのチームは代わりに 301 に手を伸ばします。10 年間それで回ってきて、何も壊れていません。ログイン関連のリダイレクトは通常 302 です。訪問者がログインページへ飛ばされ、サインイン後に戻ってきます。

選んだ後、SEOに何が起きるのか(2026年の現実)

正しいコードを選ぶことは、単なる技術的なチェック項目ではありません。同時に3つのことを静かに決定づけます。Googleが新しいURLにランクパワーを引き継ぐかどうか。新しいURLが検索結果で古いURLに取って代わるかどうか。そして、ChatGPTのようなAI検索エンジンがそもそもあなたを引用するかどうか。それぞれが次に影響を与え、後からダメージを元に戻すのは、最初から正しくやるより何倍も手間がかかります。

リンクエクイティの移転

リンクエクイティは、リダイレクトの理解とオフページSEOをつなぐトピックの要です。Earned Authority Methodは、そもそもそれを築き上げるためのフレームワークです。そして、正しい301の運用を通してそれを守ることが、多くの運用者が気づいている以上に重要な理由でもあります。

この分裂が最も問題になるのは、移行のときです。HTTPからHTTPSへ302で移行するサイトは、エクイティを失うわけではありません。ただ、プロトコルのバリアント間で永遠に断片化されるだけです。

Googleのインデックスはそれぞれをどう扱うか

GooglebotはGoogleのクローラーです。ページをインデックスに保存するとき、301と302をまったく別物として扱います。(インデックスとは、Googleが知っているすべてのページを収めた巨大なデータベースです。)

301はGoogleにこう伝えます。古いURLを新しいURLに入れ替えろ、と。その後の何度かの訪問で、Googleはまさにそれを実行します。一般的なサイトで通常は2~6週間以内、Googleがもっと頻繁にチェックする大規模サイトならもっと早く。新しいURLが検索結果に表示されるURLになります。古いほうは静かに落ちていきます。

302はGoogleにこう伝えます。古いURLをそのまま残せ、と。Googleは検索結果のメインとして古いURLを表示し続けます。新しいURLは訪問されるかもしれませんが、決して取って代わりません。Googleはそのリダイレクトを、恒久的な住所変更ではなく短期的な迂回路として読み取るからです。

Google Search Console(サイト運営者向けのGoogleの無料ツール)にはURL Inspectionという機能があり、これを自分の目で簡単に確認できます。301が設定されているURLは、最終的に「URLはGoogleに登録されていません」と表示され、理由として「リダイレクトを伴うページ」が出ます。そして新しいURLがインデックス済みとして現れます。302のURLは、元のURLをメインのまま保持し「リダイレクトを伴うページ」のタグがつきます。そして新しいURLはそこに放置され、取り上げられません。

移行にとってこれは、コードを直しに戻らない限り、302が2つのURLの間に恒久的な分裂を生む、ということです。

AI検索とリダイレクト:2025年のChatGPTデータ

2025年12月のSE Rankingの調査が、驚くべき事実を明らかにしました。AI検索エンジン(ChatGPT、Perplexity、GoogleのAI Overviews)は、リダイレクトされたURLを通常のGoogle検索よりもはるかに少なくしか引用しない、ということです。

数字がそれを物語っています。ChatGPTの引用のうち、リダイレクトを経由するURLを指すのはわずか0.79%で、通常のGoogle検索結果の5.75%と比べるとかなり少ない。つまりChatGPTは、リダイレクトされたURLをGoogleより3~7倍少なく引用しているのです。

ここが意外なポイントです。ChatGPTがリダイレクトを実際にたどるとき、強く恒久的なものを好みます。同じ調査で、ChatGPTは302より301を1.6倍多くたどることが分かりました。PerplexityやBingのAI機能も同じパターンを示します。AI検索システムは、恒久リダイレクトを一時リダイレクトよりも信頼できるものとして扱うのです。

これが移行において何を意味するか。リダイレクトのどこかに302が隠れていると、AI検索に引用される可能性が静かに削られます。両方の戦線で同時に負けるのです。Googleの通常検索はあなたのURLを断片化されたものとして扱い、さらに新しい波のAI検索エンジンも回答の中であなたに言及しなくなります。

間違ったコードのせいでChatGPTがあなたのコンテンツを引用しなくなれば、有料検索でその穴を埋めるしかなくなります。Pincer Methodで私たちが有料とオーガニックを一つのプレイブックで運用しているのは、まさにそのためです。AI検索が一つのチャネルを落としたとき、もう一方が需要を受け止めなければなりません。

7つのプラットフォーム向けコピペコード

Googleで「301 vs 302 redirect」と検索すると、上位の記事は7つのプラットフォームの名前を挙げるだけで、実際に使えるコードを載せていません。というわけで、ここに用意しました。以下のスニペットはすべてコピペで使え、各プラットフォームの最新ドキュメントと照合済み、よくあるミスについてもテスト済みです。

Apache (.htaccess)

Apacheでは、ドキュメントルートの .htaccess ファイルに記述します。

# Single URL 301
Redirect 301 /old-url /new-url

# Pattern-based 301 (regex)
RedirectMatch 301 ^/old/(.*)$ /new/$1

# Domain change with HTTPS
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldbrand\.com$ [NC]
RewriteRule ^(.*)$ https://newbrand.com/$1 [R=301,L]

落とし穴: RewriteRule を使う前に RewriteEngine On を書き忘れること。このディレクティブなしでは何も言わずに失敗し、「なぜ動かないんだ」と20分悩むことになります。詳しい比較は「htaccess vs Nginxのリダイレクトルール」で解説しています。

Nginx

Nginxでは、サーバーブロックの設定ファイル(通常は /etc/nginx/sites-available/yourdomain)に記述します。

# Single URL 301
location = /old-url {
    return 301 /new-url;
}

# Domain change
server {
    listen 443 ssl;
    server_name oldbrand.com;
    return 301 https://newbrand.com$request_uri;
}

落とし穴: return で済むところで rewrite を使うこと。return 301 は正規表現の評価より前に実行され、サーバーの負荷を減らします。詳細は「htaccess vs Nginxのリダイレクトルール」にまとめています。

Cloudflare Workers + Page Rules

Page Rules(UI、コード不要): Cloudflareダッシュボード → Rules → Page Rules → 「Forwarding URL」→ ドロップダウンから301か302を選択。無料プランではアクティブなPage Rulesが3つまでに制限されており、複数のリダイレクトが必要なサイトではすぐ埋まります。

Workers(コード、より柔軟):

export default {
  fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === '/old-url') {
      return Response.redirect('https://example.com/new-url', 301);
    }
    return fetch(request);
  }
}

落とし穴: Workersは1,000万リクエストあたり月$5かかりますが、Page Rulesでは真似できないパターンマッチングの柔軟性があります。応用的なユースケースは「Cloudflare Workersのリダイレクトパターン」で解説します。

WordPress: RankMath PRO + Redirectionプラグイン + 手動 .htaccess

RankMath PRO: WordPress管理画面 → Rank Math → Redirections → Add New。ドロップダウンから301か302を選び、ソースURLと遷移先URLを入力。変更は即座に反映され、サーバーの再起動は不要です。

Redirectionプラグイン(無料、John Godley氏作): ツール → Redirection。大量移行に最適。CSVのインポート/エクスポート、正規表現パターン、404トラッキングに対応。プラグインがリダイレクトのヒットをログするので、チェーンやループが積み重なる前に発見できます。

手動 .htaccess: 動作はしますが、.htaccess を触るプラグインやテーマのアップデートで消えてしまいます。WordPressの状態に関わらず残す必要がある、永続的なシステムレベルのルールにだけ使いましょう。

WordPressネイティブで、各リダイレクト変更をより大きなコンテンツエンジンの一部として扱っているなら、リダイレクトの工程はより広い方法論の中のひとつの動きにすぎません。Content Compounder方法論がそのエンジンを回しています。6本柱のフィードバックループがあり、リダイレクトリテラシーは柱2の配管部分として組み込まれています。プラグイン別の比較は、WordPressリダイレクトプラグインガイドで選定基準を深掘りしています。

WooCommerce + Shopify

WooCommerce: 上記のWordPressリダイレクトツールを使用。ただし、大量の商品URL移行には重複排除ロジックが必要です。500SKUのストアでは500個のリダイレクトルールが生成され、.htaccess のパース速度が落ちます。重複排除のワークフローは、下記の「よくある間違い」セクションで解説します。

Shopify: Online Store → Navigation → URL Redirects。Shopifyは標準の管理画面では301しかサポートしていません。302を設定するには、カスタムShopify FunctionかEasy Redirectsのようなサードパーティアプリが必要です。

落とし穴: ShopifyのURL Redirectsはテーマ変更では消えませんが、ソースの商品やページを削除した瞬間に壊れます。構造変更の前には必ずリダイレクトリストをエクスポートしましょう。Settings → Filesは助けてくれません。

Next.js (next.config.js)

Next.jsでは、プロジェクトルートの next.config.js に記述します。

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-url',
        destination: '/new-url',
        permanent: true, // permanent: true = 308; permanent: false = 307
      },
    ];
  },
};

落とし穴: Next.jsはデフォルトで307/308(メソッド厳格版)を使用し、301/302ではありません。レガシーなSEOツールが308をまだ認識しないなどの理由で301/302が必要な場合は、permanent: true の代わりに statusCode: 301 を指定してください。

Expressミドルウェア

Expressでは、メインサーバーファイル(通常は app.js または server.js)に記述します。

// Express
app.get('/old-url', (req, res) => {
  res.redirect(301, '/new-url');
});

// Pattern-based redirect
app.use('/old-section/*', (req, res) => {
  const newPath = req.originalUrl.replace('/old-section', '/new-section');
  res.redirect(301, newPath);
});

落とし穴: res.redirect() はステータスコードを渡さないとデフォルトで302になります。必ず明示的に指定しましょう。暗黙の302は、「リダイレクトを設定したのに順位が下がった」というサポート問い合わせの最大の原因です。

Vercel (vercel.jsonまたはnext.config.js)

Vercelでは、プロジェクトルートの vercel.json にリダイレクトを記述するか、Next.jsを使用している場合は next.config.js に記述します(上記参照)。

{
  "redirects": [
    {
      "source": "/old-url",
      "destination": "/new-url",
      "permanent": true
    },
    {
      "source": "/old/:path*",
      "destination": "/new/:path*",
      "permanent": true
    }
  ]
}

落とし穴: Next.jsと同じ。permanent: true は308、permanent: false は307を意味します。301/302のステータスコードが必要な場合は、"permanent" ではなく "statusCode": 301 を使ってください。

Netlify (_redirectsファイル)

Netlifyでは、公開ディレクトリ(または public/)の _redirects ファイルに記述します。

# Single URL 301
/old-url    /new-url    301

# Wildcard
/old/*    /new/:splat    301

# Domain change (full URL on the right)
https://oldbrand.com/*    https://newbrand.com/:splat    301!

落とし穴: 末尾の !(強制フラグ)は、遷移先に既存ファイルがあってもリダイレクトを上書きします。これがないと、Netlifyはソースが実ファイルと一致しないときだけリダイレクトします。便利ですが、忘れやすいです。

AWS CloudFront (FunctionsまたはLambda@Edge)

CloudFrontでは、CloudFront Functions(安価でシンプル)かLambda@Edge(高機能だが割高)としてリダイレクトを実行できます。ほとんどのリダイレクト作業では、Functionsが正解です。

function handler(event) {
  var request = event.request;
  if (request.uri === '/old-url') {
    return {
      statusCode: 301,
      statusDescription: 'Moved Permanently',
      headers: {
        location: { value: 'https://example.com/new-url' }
      }
    };
  }
  return request;
}

この関数をCloudFrontディストリビューションのビヘイビアに viewer-request イベントタイプとしてアタッチします。CloudFront Functionsは実行時間10msまで、ネットワークアクセスも不可ですが、月間1,000万呼び出しまで無料です。

Caddy

Caddyでは、Caddyfile にリダイレクトを記述し、驚くほどシンプルです。

# Single URL 301
oldbrand.com {
    redir /old-url /new-url permanent
}

# Domain change with HTTPS preserved
oldbrand.com {
    redir https://newbrand.com{uri} 301
}

落とし穴: Caddyの permanent は301です。302には temporary を使います。CaddyはLet’s Encrypt経由でHTTPSを自動処理するので、ドメインリダイレクトは通常1行で済みます。

IIS (Windows Server、web.config)

IISでは、サイトの web.config ファイルの <system.webServer> セクション内にリダイレクトを記述します。URL Rewriteモジュール(Microsoft公式の無料ダウンロード)が必要です。

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Old URL 301" stopProcessing="true">
          <match url="^old-url$" />
          <action type="Redirect" url="/new-url" redirectType="Permanent" />
        </rule>
        <rule name="Domain change" stopProcessing="true">
          <match url=".*" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="^oldbrand\.com$" />
          </conditions>
          <action type="Redirect" url="https://newbrand.com/{R:0}" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

落とし穴: IISでは redirectType="Permanent" が301です。302には Found、303には SeeOther、307には Temporary を使います。命名が直感的でなく、Temporary を302だと勘違いして誤ったコードをリリースする開発者が多いです。

移行の最中でセカンドオピニオンが欲しいですか? サイトマップと .htaccess を送ってください。30分の無料監査を通話で実施します。あなたの画面、私たちの声、本物のcurl出力。スライドなし。提案書なし。作業を引き受けてほしいときは、月額 ₹40,000 / $499 からのリテイナーで対応します。

30分の戦略通話を予約する → · WhatsApp +91 96366 50036

検証方法:信じるな。証明しろ。

リダイレクトが実際に何をしているかを確認する方法は3つあります。1つ目は特別なツールは不要です。2つ目はChromeに組み込まれた無料機能を使います。3つ目はGoogle自身の無料ダッシュボードを使います。自分が使いやすいものを選んでください。どれも真実を教えてくれます。

curl -I、ワンライン確認(開発者向け)

開発者ではないなら、下のブラウザDevToolsまたはGoogle Search Consoleの方法に進んでください。コマンドラインなしで同じ情報を見られます。

ターミナル(開発者が使う黒と白のテキストウィンドウ)があるパソコンで、こう実行します:

curl -I https://example.com/old-url

出力例:

HTTP/2 301
date: Tue, 1 May 2026 09:00:00 GMT
location: https://example.com/new-url
cache-control: max-age=31536000

curl-output.webp" alt="curl -I コマンドとその出力を表示したスタイライズされたターミナルウィンドウ。HTTP/2 301の行がゴールドで光り、locationヘッダーは新URLを指し、cache-control max-age値がハイライトされている。ブランドカラーはネイビーとゴールド。" loading="lazy" width="1600" height="900">

1行目はステータスを示します。ここでは301。location: ヘッダーはリダイレクト先を示します。指定したとおりの新URLです。cache-control: max-age=31536000(1年を秒で表した値)はリダイレクトが強めにキャッシュされていることを示し、これは恒久リダイレクトと整合します。ブラウザやCDNはこの指示を尊重し、再訪問時のルックアップをスキップします。

注意点:一部のサーバーはHTTP/2ではなくHTTP/1.1を返します。ステータス行は短い HTTP/2 301 ではなく HTTP/1.1 301 Moved Permanently と表示されます。挙動は同じです。バージョン番号はサーバーが対応している仕様を反映しているだけで、リダイレクトが有効かどうかとは無関係です。

ブラウザDevToolsのNetworkタブ

Chrome DevTools → Networkタブ → 「Preserve log」にチェック → 旧URLをアドレスバーに直接入力して読み込みます。

最初のリクエストのStatus列に301または302が表示されます。その行をクリックすると、右側のパネルでLocationヘッダーとレスポンスヘッダー全体を確認できます。

この方法はリダイレクトチェーンを視覚的に見つけるのに最適です。ホップごとに別の行が表示されます。最終的な200の前に3行あれば、折りたたむべきチェーンがあるということです。

GSC URL検査、デプロイ後の確認

Google Search Console → URL検査 → 旧URLを貼り付けます。

301が成功していれば、「URLはGoogleに登録されていません」と理由「リダイレクトのあるページ」が表示されます。これはGoogleがリダイレクトをクロールし、登録し、権威を転送先へ渡し始めた証拠です。

2〜6週間後、新URLを貼り付けます。見たい結果は:「URLはGoogleに登録されています」「ページはインデックスに登録されています」「ユーザーが指定した正規URL」です。これで統合が完了したことが確認できます。新URLが旧URLの積み上げた権威を保持しているのです。

URL検査機能の完全なリファレンスは、GoogleのURL検査ドキュメントを参照してください。

これがクライアントに転送して移行の成功を証明するスクリーンショットです。Semrushのエクスポートではありません。有料ツールのレポートでもありません。Google自身のコンソールがそのURLをGoogleに登録していると言っているのです。ダッシュボードを信じるな。レスポンスを読め。

間違ったコードを既に使ってしまった場合:復旧プレイブック

復旧は4つの小さなステップです。壊れたURLを見つける。コードを直す。Googleに戻ってきてもらうよう依頼する。待つ。時間のほとんどは、ただ待っているだけです。実際の修正作業は早く終わります。全工程は通常2〜6週間かかり、どのステップも急がせようとすると待ち時間が長くなるだけです。

実際のケース。 先の四半期、ShopifyからWooCommerceにストアを移行したばかりのスキンケアブランドをサポートしました。開発者が全URLに302を使っていて、それは移行プラグインが誰にも警告せず「一時的」をデフォルトにしていたからです。4週目までに、オーガニックトラフィックは38%減少していました。私たちは60の商品ページを確認し、すべてのリダイレクトが間違ったタイプであることを確認し、すべて301に切り替えました。その後、サイトマップを再送信し、収益の高い上位12ページをGoogleに再クロール依頼しました。18日後、新しいURLがメインバージョンとして表示されるようになり、トラフィックは移行前のベースラインから4%以内に戻りました。

症状

移行の2〜6週間後に順位が下がり、タイミングが偶然とは言えないほどぴったり一致します。Google Search Consoleは、本来もう新しいメインバージョンになっているはずのURLに「リダイレクト付きページ」のフラグを立てます。Googleは依然として古いURLを主要なものとして扱います。AI検索はさらに事態を悪化させます。ChatGPT、Claude、Geminiは、学習データが一時的リダイレクトのシグナルを捉えてしまったため、古いURLへ人を送り続けます。新しいURLは、Googleがサイトマップを問題なく受け入れたにもかかわらず、Google上でほとんど、または全く存在感を示しません。古いURLへの直接トラフィックは予測不能に変動し、ブラウザやブックマークが古いアドレスを覚えているため、訪問者をリダイレクトループや古いページへ送り込みます。

診断

古いURLから20〜50個を選び、サーバーが実際に何を返しているかを確認します。(開発者ならcurl -Iを使ってください。そうでなければ、ChromeでURLを開き、DevToolsのNetworkタブを使います。)CMSが「送っている」と言っているものではなく、実際のステータスコードを書き留めてください。それから、同じURLをGoogle Search ConsoleのURL検査ツールに通します。不一致こそがリークの場所です。根本原因を突き止めるために、プラットフォームの設定やサーバーの構成を確認しましょう。よくある犯人は3つ:デフォルトで「一時的」に設定されたリダイレクトプラグイン、明示的なステータスコードがないExpress呼び出し、またはpermanent: falseのNext.jsリダイレクトです。チェーンがあれば別途メモしてください。A→B→C→Dのようなチェーンは、間違ったコードの問題の上に、さらに第二の問題を積み重ねます。

修正

関連する設定をすべて301に切り替えて(APIでリクエストタイプを固定する必要がある場合は308に)、変更を本番環境に反映します。問題を発見したのと同じ方法で各修正を確認し、301が表示されることを確かめます。Google Search Consoleにサイトマップを再送信して、変更があったことをGoogleに知らせます。GSCのURL検査ツールで、最も重要な遷移先URLに対して「インデックス登録をリクエスト」をクリックします。収益やバックリンクを生み出しているページを優先しましょう。非常にトラフィックの多いリダイレクトについては、ホームページから新しいURLへ一時的にリンクすることでGoogleのスピードを上げられます。その内部リンクが、Googleを早めに再訪させるきっかけになります。

再インデックス

新しいURLがメインとして引き継がれるまでの典型的な待ち時間は2〜6週間です。Googleが頻繁に訪れる大規模サイトではもっと速くなります。AI検索の復旧はさまざまです。ChatGPTとGeminiは、学習サイクルが更新されれば正しいURLを引用し始めます。PerplexityとBingのチャットは通常、新しいURLが安定してから1〜2週間で追いつきます。Googleが301リダイレクトを処理するのにどのくらいかかるかの具体的なベンチマークについては、詳細なクロールタイミングデータを今後の記事で公開する予定です。

引き継いだリダイレクトがぐちゃぐちゃで、どこから流出しているか分からない? サイトマップを無料5分監査に貼り付けてください。リダイレクトグラフ内のすべての301、302、チェーンの一覧と、今まさにインデックスを失っているものを送り返します。ほとんどのクライアントは、原因不明のトラフィック低下の3週目に連絡してきます。2週間を節約しましょう。

WhatsAppでサイトマップを送る →

順位をひそかに奪う7つのミス

これらは、ほぼすべての監査で見かける7つのミスです。それぞれに、素早く見つける方法と素早く直す方法をつけています。

実際のケース。 昨年、初めての大型投資ラウンドの調達準備をしていたソフトウェア企業を監査しました。6年にわたる製品変更の積み重ねで、サーバー構成には4,200のリダイレクトルールが溜まっていました。41は4ホップ以上のチェーンを形成していました。6つはライブのループで、サーバーをぐるぐる回らせていました。私たちはすべてのチェーンを単一ホップのリダイレクトに折りたたみ、ループを潰し、総数を1,180にまで削減しました。ページは340ms速く読み込まれるようになりました。2週間後、Googleはサイトのより多くを再びクロールするようになりました。

1. リダイレクトチェーン(AがBへ、BがCへ、CがDへ)。 チェーン全体を各ステップで辿っていくと見つけられます。ホップごとに少量のランク力を失い、遅延が加わります。AをDへ直接送るように修正します。リダイレクトチェーンのデバッグガイドが、全ステップの手順を詳しく説明しています。

2. リダイレクトループ。 リダイレクトが円を描いてぐるぐる回った後、サーバーがエラーを返すか、ブラウザがタイムアウトします。チェーン内の以前のURLを指しているルールを削除して修正します。

3. 1回の移行で301と302が混在。 一部のページは恒久的コードを受け取り、他は一時的コードを受け取り、Googleは一貫性のない絵を見ています。サイトマップ上のすべてのURLを確認し、すべてのルールを301に切り替えて修正します。

4. /pageと/page/が別のURLであることを忘れる。 末尾スラッシュの有無で、Googleは2つの別ページとして扱います。両方が同じページにリダイレクトしなければ、2つのバージョンの間でランク力を分割することになります。

5. http://とwww.のバリアントを忘れる。 すべてのURLには4つのバージョンがあります:httpsあり/なし、wwwあり/なし。そのうち3つは1つのメインバージョンに301する必要があります。どれか1つでも抜けると、権威性が複数のアドレスに分散されます。

バリエーションURLの爆発は、WooCommerce特有の関連する失敗モードです。5つの属性にそれぞれ8つの値があると、1つの商品から40,000のインデックス可能なURLが生まれる可能性があります。WooCommerce特有のテクニカルSEOが、WC Towerの3階に位置するバリエーションURL重複排除パターンを解説しています。

6. リダイレクト後の空ページ。 遷移先URLは機能するものの、ページが短すぎるか、ほぼ空っぽです。Googleはこれを「ソフト404」(技術的には読み込まれるが、欠けているページのように振る舞うページ)として扱い、ひっそりと除外します。遷移先に本当に役立つコンテンツがあることを確認して修正します。ソフト404復旧プレイブックが、どれだけのコンテンツがあれば十分かを正確に説明しています。

7. 国に基づいて人を自動リダイレクトする。 訪問者の閲覧場所に基づいて別のページに送り、オプトアウトの方法を提供しないのは、Googleのルール違反です。地域ごとに人を正しくルーティングする方法を示すMulti-Region Authority Stack Layer 1に従って修正します。

手動オーバーライドなしのGeo-IP自動リダイレクトは、Googleのスパムチームがフラグを立てるクローキングリスクパターンです。正しく行われた多地域ルーティング(hreflang、ccTLDアーキテクチャ、そして静かに302しないLayer 1 Geo-IPルール)については、Multi-Region Authority Stackを参照してください。

よくある質問

301リダイレクトと302リダイレクトの違いは何ですか?

301は恒久的な移転を示します。Googleは古いURLを新しいURLに置き換え、正規URLとして扱います。302は一時的な移転を示します。Googleは元のURLを正規URLとして保持します。Googleの公式ドキュメントによれば、どちらもリンクエクイティを渡しますが、インデックスの挙動はまったく異なります。移転が恒久的なら301を使いましょう。元に戻す予定なら302を使いましょう。

302リダイレクトはSEOに悪影響を与えますか?

はい。誤った使い方をすると悪影響があります。恒久的な移転に302を使うと、Googleはいつまでも元のURLを正規URLとして扱い続けるため、移転先のURLが独自のランキングシグナルを蓄積できません。エクイティ自体はどちらの場合も渡されますが(Muellerが2016年に確認しています)、新しいURLに集約されずに両方のURLに分散してしまいます。結果として、どちらのURLも難しいクエリで上位表示するのに必要な権威性を築けません。対処法は、301に切り替え、サイトマップを再送信し、インデックス登録をリクエストすることです。

302リダイレクトはリンクエクイティを渡しますか?

はい。GoogleのJohn Muellerは、301と302の両方がリンクエクイティを渡すことを確認しています。落とし穴は、302では移転先のURLが正規URLにならないため、エクイティが集約されずに両方のURLに分散し続けることです。301に切り替えるか、リダイレクト自体を削除するまで、リンクシグナルは分散したままになります。

301ではなく302リダイレクトを使うべきなのはどんなときですか?

明確に一時的なシナリオでは302を使います。元に戻す予定のA/Bテスト。数時間から数日のメンテナンスウィンドウ。キャンペーン終了後に失効するプロモーションページ。ジオテスト中の地域別一時配信。判断基準は、合理的な時間内に元のURLに戻す意図が実際にあることです。

Googleが301リダイレクトを反映するまでどのくらいかかりますか?

通常、新しい正規URLがGoogleのインデックスで古いURLを完全に置き換えるまで2〜6週間かかります。権威性が高く、クロールバジェットが活発なサイトは処理が速くなります。権威性の低いサイトでは、統合が完了するまで8〜12週間かかることがあります。GSCのURL検査ツールで進捗を追跡しましょう。「301リダイレクトはGoogleでどのくらい時間がかかるか」という問いの答えは、主にGoogleがあなたのサイトをどれだけ頻繁にクロールするかに依存します。

302を後から301に変更できますか?ランキングは回復しますか?

はい。サーバー設定を302から301に更新し、Google Search Consoleでサイトマップを再送信し、影響を受けるURLのインデックス登録をリクエストしてください。Googleがリダイレクトを再処理し、シグナルを移転先URLに集約するにつれ、通常2〜6週間でランキングは回復します。ミスを早く修正するほど、回復も速くなります。

301と308の違いは?302と307の違いは?

308は厳格な恒久リダイレクト(メソッド保持)です。リダイレクト中にクライアントがHTTPメソッドを変更することを禁じます。307は厳格な一時リダイレクト(メソッド保持)で、同じくメソッドを保持します。301と302は歴史的に、クライアントがPOSTリクエストをGETリクエストに変更することを許していました。元のリクエストメソッドを保持することが重要なAPIエンドポイントでは、307と308を使いましょう。

WordPressでURLをリダイレクトするにはどうすればいいですか?

3つの選択肢があります。RankMath PROのリダイレクトマネージャーは最もクリーンなインターフェースと自動404検知を備えています。無料のRedirectionプラグインは、プレミアム料金なしで同様の機能を提供します。手動での.htaccess編集は最大のコントロールを提供しますが、サーバーアクセスが必要です。より広いWordPressテクニカルSEOの方法論については、WordPress SEOプレイブックをご覧ください。

リダイレクトが正しく機能しているか確認するにはどうすればいいですか?

ターミナルでcurl -I [old-url]を実行して、サーバーが実際に返しているステータスコードとLocationヘッダーを確認します。ブラウザのDevToolsのNetworkタブでも、同じ情報をチェーンのビジュアル表示付きで確認できます。Google Search ConsoleのURL検査ツールでは、Google自身がリダイレクトをどう読み取っているかがわかります。

301リダイレクトチェーンはSEOに悪影響を与えますか?

はい。各ホップでリンクエクイティのわずかな割合が失われ、レイテンシが追加されます。Googleはおよそ5ホップを超えるとチェーンを追跡しなくなる可能性があり、途中でエクイティが取り残されます。四半期ごとにリダイレクトを監査し、チェーンを1ホップに短縮しましょう。Screaming Frogはチェーンを自動的に検出します。

AI検索エンジン(ChatGPT、Claude、Gemini)はGoogleと異なるリダイレクト処理をしますか?

はい。SE Rankingの2025年12月の調査によれば、ChatGPTはリダイレクトされたURLをGoogleの3〜7分の1の頻度でしか引用しません。AIシステムはソースを選ぶ際、安定したリダイレクトなしのURLを好みます。AIトラフィックが戦略上重要なら、302より301を優先し、価値の高いコンテンツではリダイレクトチェーンを排除しましょう。

301リダイレクトはどのくらいの期間維持すべきですか?

最低12か月、理想的には永久に維持すべきです。Googleがシグナルを新しいURLに集約した後、リダイレクトはもう不要だと考えるかもしれません。そうではありません。残しておきましょう。古いURLにリンクしている他サイトは、何年もの間、リダイレクト経由でユーザー(とボット)を送り続けます。削除すれば、それらのリンクは404になります。合理的な経験則は、移転先URL自体が廃止されない限り、301は永久に残すことです。

?utm_source=Xのようなクエリ文字列パラメータはどうリダイレクトしますか?

2つの選択肢があります。保持する:ほとんどのプラットフォームはクエリ文字列を自動的に通過させます(ApacheのRewriteRule、Nginxの$request_uri、Cloudflare Workersのrequest.url)。除去する:クエリなしの移転先に明示的にリダイレクトします(例:ApacheのRewriteRule ^old$ /new? [R=301,L]で、末尾の?がクエリをクリアします)。特定の理由(アナリティクスの整頓、正規化のクリーンアップ)がない限り、デフォルトは保持です。

リダイレクトはCore Web Vitalsやページ速度に影響しますか?

はい。各リダイレクトホップは、DNS、TLSハンドシェイク、サーバー応答時間に応じて100〜400msのレイテンシを追加します。単一のリダイレクトがCWVの問題になることは稀です。しかしクリティカルパス上のリソースで3つ以上のリダイレクトがチェーンすると、LCPが2.5秒を超えてCWVを悪化させる可能性があります。常にチェーンを短縮し、最速の応答のためにエッジ(Cloudflare Workers、CloudFront Functions)でリダイレクトをホストしましょう。

ハード301とソフト301の違いは何ですか?

HTTP仕様には「ソフト301」は存在しません。この用語はSEOの文章で、JavaScriptベースやメタリフレッシュのリダイレクトを指して使われることがあります。それらは本物の301ではありません。クライアントサイドのハックです。ハード(本物の)301は、サーバーがステータスコード301で返すHTTPレベルの応答です。「ソフト301」(JSやメタリフレッシュ)はエクイティを確実に渡さず、すべてのクローラーに認識されず、レイテンシも追加します。常に本物のHTTPレベル301を使いましょう。

外部ドメインへリダイレクトできますか?

はい。リダイレクトの仕組みは同じです。Locationヘッダーが外部URLを指し、ステータスコードは任意に選べます。SEO上の結果も同じです:外部ドメインへの301はランキングシグナルをそのドメインに移し、302はシグナルを自サイトに残します。外部301リダイレクトは控えめに使いましょう。他人のサイトにエクイティを渡すことになります。よくある正当な用途は、買収後のリダイレクト、パートナーサイトへの誘導、ブランドの終了です。

リダイレクトループを修正するにはどうすればいいですか?

curl -L -I [url]を実行します。-Lフラグはリダイレクトを追跡し、-Iはヘッダーを表示します。トレースが2つ以上のURLの間を行き来していれば、ループがあります。よくある原因:A→BリダイレクトとB→A正規タグの併用、.htaccessルールの競合、オリジンサーバーのリダイレクトと戦うCDNレベルのリダイレクトです。問題のルール(通常は最後に追加されたもの)を特定して削除することで修正します。修正後、再度curl -L -Iで検証します。解決に成功すれば、トレースの最後に単一の200が表示されます。

移行の真っ最中ですか?こちらがオファーです。

サイトマップと.htaccessを送ってください。30分の通話をします。あなたの画面とこちらの画面を共有します。5つのURLをライブでcurl実行し、GSCでリダイレクトグラフを確認し、どの修正が最もランキングエクイティを救うかをお伝えします。スライドなし、提案書なし、フォローアップの営業シーケンスなし。

30分の戦略コールを予約 → · WhatsApp +91 96366 50036

先に料金を見たいですか?公開されている料金インデックスで、すべてのリテイナー階層をINR、USD、GBP、EUR、AUDで表示しています。ディスカバリーコールによる価格上乗せはありません。

マスター方法論が欲しいですか?Prove-Itプロトコルをご覧ください。Ship → Measure → Prove → Iterate。

著者について

Kunal Singh DabiはKD Digitalの創業者です。New Delhiで開催されたWASME World MSME Business Summit 2023において、MSME向けのBest SEO Specialist in Indiaとして表彰されました。2021年5月以降、17か国以上で250以上のビジネスをスケールさせてきました。140件以上の認証済みレビューで4.9★。すべての変更をMonday Reportとともに納品する親となるSEOコンサルティング実践の構築者です。