リダイレクトとは｜301・302・307・308の違いとPOST・キャッシュを実測

リダイレクトは、引っ越しのときの「転居届」に近い仕組みです。前の住所（URL）に届いた郵便を、新しい住所へ回してもらいます。Web では、この転送をサーバーがその場で返事として行います。

flowchart TD
    A[ブラウザが<br>前の URL を開く] --> B[サーバーが 3xx と<br>Location を返す]
    B --> C[ブラウザが<br>Location の URL を開く]
    C --> D[200 OK<br>新しいページを表示]
    B -.->|301・308| E[ブラウザが<br>転送を覚える]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、nginx 1.24.0（Ubuntu）と Apache 2.4.58（Ubuntu）をパッケージから作業場所に展開し、自分の設定ファイルを指定して 127.0.0.1 のポートだけで起動しました（システムの設定ファイルは使っていません）。301・302・303・307・308を自在に返す自作サーバーは Python 3.13.18 の標準ライブラリ（http.server）で作り、受け取ったメソッド・本文・Referer をすべて記録しています。フレームワークは Express 5.3.0（Node.js 22.23.4）、Next.js 16.4.3（React 19.3.1、テレメトリーを切って build と start）、PHP 8.3.6 の組み込みサーバーで実行しました。応答は curl 8.5.0 の curl -v・-L、ブラウザの挙動（フォームの POST・fetch・キャッシュ・ループ・meta refresh・履歴）は Chromium 153.0.8010.12（playwright-core 1.63.0・日本語の画面）で実測しています。各ステータスコードの意味は MDN（RFC 9110 を出典とする解説）、SEO での扱いは Google 検索セントラルと Search Console ヘルプ、開発者ツールの操作は Chrome for Developers の公式ドキュメントで確かめた範囲だけを書いています。図は mermaid 11.16.0 で描画を確かめました（確認日 2026年10月29日）。

リダイレクトとは（意味と仕組み）

この節では、リダイレクトの意味と、サーバーとブラウザの間で実際にどんなやり取りが起きているかが分かります。

リダイレクト（redirect）は「向きを変える」という意味の英語で、Web では「開いた URL から別の URL へ自動で移すこと」を指します。

中身は、サーバーが返す1回の返事です。手元の nginx に、/old-301 を /new.html へ移す設定をして、curl -v で見た結果です（> が送った内容、< が返ってきた内容）。

$ curl -v http://127.0.0.1:45451/old-301
> GET /old-301 HTTP/1.1
> Host: 127.0.0.1:45451
> User-Agent: curl/8.5.0
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.24.0 (Ubuntu)
< Content-Type: text/html
< Content-Length: 178
< Location: http://127.0.0.1:45451/new.html
<
<html>
<head><title>301 Moved Permanently</title></head>

• 1行目の 301：ステータスコード（サーバーが返す3桁の結果番号）。300番台（3xx）が「別の場所を見てください」という意味です。
• Location ヘッダー：移動先の URL。ブラウザはこの URL を自動で開き直します。
• 本文：nginx は小さな HTML を付けますが、ブラウザは通常これを表示せずに Location へ進みます。

curl は、何も付けなければ転送をたどりません。-L を付けると、ブラウザと同じように Location をたどります。

サーバー側のリダイレクトとクライアント側のリダイレクト

リダイレクトが使われる場面

301・302・303・307・308の違い（一覧表）

この節では、リダイレクトの5つのステータスコードが何を意味し、どう使い分けるのかが一覧で分かります。

違いは2つの軸で決まります。「恒久（もう戻さない）か一時か」と「POST を POST のまま転送するか」です。 意味は MDN（RFC 9110 を出典とする解説）、POST の扱いは手元の Chromium で実測した結果です。

MDN は、302について「GET 以外のメソッドは GET に変更されることがある」とし、GET 以外の操作を扱うなら302より307を勧めています。301と308の関係も同じです。迷ったら、ページの移転は301、API の移転は308、フォーム送信後の画面遷移は303、と覚えると使い分けがぶれません。

手元の nginx 1.24 は302のステータス行を「302 Moved Temporarily」（HTTP/1.0 時代の名前）、Apache・Express・PHP は「302 Found」と書きました。クライアントは名前ではなく数字で判断するため、動きは変わりません。

ほかのステータスコードの意味と対処は、関連記事「HTTPステータスコード 一覧｜全コードの原因と対処・curl実例つき」で扱っています。

POSTがGETに変わるか：ブラウザとcurlで実測

この節では、フォームや API の POST がリダイレクトされたとき、送った中身がどうなるのかが、実際の記録で分かります。

301・302・303では POST が GET に変わり、送った本文は転送先に届きませんでした。307・308では POST のまま、本文も届きました。 フォームの送信先を301で移すと、入力した内容が消えます。

Chromium でフォームを送った結果

自作サーバーに、a=1 を POST するフォームを置き、送信先を /s/301 〜 /s/308 にしました。どれも /echo へ転送し、/echo は受け取ったメソッドと本文をそのまま返します。

301 {"method": "GET", "body": "", "referer": "http://127.0.0.1:45452/form/301"}
302 {"method": "GET", "body": "", "referer": "http://127.0.0.1:45452/form/302"}
303 {"method": "GET", "body": "", "referer": "http://127.0.0.1:45452/form/303"}
307 {"method": "POST", "body": "a=1", "referer": "http://127.0.0.1:45452/form/307"}
308 {"method": "POST", "body": "a=1", "referer": "http://127.0.0.1:45452/form/308"}

JavaScript の fetch() で POST したときも、結果は同じでした。あわせて、転送をたどらない指定（redirect オプション）の結果も記録しました。

redirect: 'manual' では、ブラウザの JavaScript から Location の値もステータスも読めませんでした（status は 0）。ブラウザの fetch で「転送されたかどうか」を知りたいときは、res.redirected と res.url（最後にたどり着いた URL）を見ます。

curl で POST を転送したときの動き

$ curl -vL -d a=1 http://127.0.0.1:45452/s/302
> POST /s/302 HTTP/1.1
< HTTP/1.1 302 Found
< Location: /echo
* Ignoring the response-body
* Issue another request to this URL: 'http://127.0.0.1:45452/echo'
* Switch from POST to GET
> GET /echo HTTP/1.1
< HTTP/1.1 200 OK

303は「POST のあとに結果ページへ」のためのコード

フォームを POST した直後のページを再読み込みすると、ブラウザは同じ POST をもう一度送ろうとします。POST の処理が終わったら303で結果ページへ移し、結果ページは GET で表示する、という形（Post/Redirect/Get、略して PRG）にすると、再読み込みしても二重登録になりません。MDN も303の用途として、PUT や POST のあとにリダイレクトし、再読み込みで操作が繰り返されないようにする例を挙げています。

301はブラウザにキャッシュされる（実測）

この節では、301・308がブラウザに覚えられる様子と、それが設定の変更時に問題になる理由・避け方が分かります。

301・308は、特に指定が無くてもブラウザにキャッシュされました。 1回目に開いたあと、別のページを挟んで同じ URL をもう一度開くと、Chromium はサーバーに問い合わせずに転送先へ移りました。302・307は毎回サーバーに問い合わせています。

これが問題になるのは、まちがった301を出してしまい、あとからサーバーの設定を直した場合です。一度その URL を開いたブラウザは、設定を直したあとも、覚えた転送先へ移り続けます。

Cache-Control の書き方は、関連記事「Cache-Controlのno-cacheとno-storeの違いと正しい設定」で扱っています。

meta refresh・JavaScriptとの違い（HTMLだけで転送する）

この節では、サーバーの設定を変えずに HTML や JavaScript で転送する方法と、HTTP のリダイレクトとの違いが、時間と履歴の実測で分かります。

サーバーの設定を変えられないときは、ページの中に転送の指示を書けます。 ただし、ページをいったん読み込んでから移るため、HTTP のリダイレクトより遅く、検索エンジンの扱いも違います。

<!-- meta refresh：0秒後に /landing へ -->
<meta http-equiv="refresh" content="0; url=/landing">

<!-- JavaScript：履歴に残す -->
<script>location.href = "/landing";</script>

<!-- JavaScript：履歴を置き換える -->
<script>location.replace("/landing");</script>

HTTP のヘッダーで Refresh: 0; url=/landing を返す方法もあります。/start を開いたあと、それぞれのページを開いて /landing に着くまでの時間と、「戻る」を押したときの行き先を Chromium で測りました。

• 時間は 127.0.0.1 の中で測った値です。実際の回線では、クライアント側の転送はページを読み込む分だけ遅れます。
• 遅れて移る方法（meta refresh 3秒・1秒後の location.href）は、転送元が履歴に残りました。「戻る」を押すと転送元に戻り、そこからまた転送されるため、戻れなくなったように見えます。すぐに移すなら、meta refresh は0秒、JavaScript は location.replace にします。
• Chromium 153 では、読み込み中に実行した location.href も履歴を置き換えました。クリックなどの操作のあとに実行した場合とは結果が変わるので、確実に置き換えるなら replace を使います。

MDN は、複数の方法が重なったときの順番を、HTTP のリダイレクトが常に最初、次に JavaScript、最後に meta refresh と説明しています。そのうえで、可能な限り HTTP のリダイレクトを使い、<meta> を重ねて書かないよう勧めています。片方だけ直すと、転送先が食い違ったりループしたりするためです。

リダイレクトとSEO（Google検索セントラルの公式）

この節では、Google 検索がリダイレクトをどう扱うかを、Google 検索セントラルと Search Console ヘルプに書かれている範囲だけでまとめます。

Google は、URL を変えるときはできる限り「サーバー側の恒久的なリダイレクト」を使うよう勧めています。 Google 検索セントラル「リダイレクトと Google 検索」（2026年4月17日更新）の表を要約すると、次のとおりです。

• JavaScript のリダイレクト：「サーバー側のリダイレクトまたは meta refresh リダイレクトを行えない場合にのみ」使うよう書かれています。レンダリング（ページの組み立て）に失敗すると、Google が転送を認識できないことがあるためです。
• Googlebot が追う回数：「HTTP ステータスコード、ネットワーク エラー、DNS エラーが Google 検索に与える影響」（2026年3月6日更新）によると、Google のクローラーは既定で最大10回のリダイレクトをたどります。転送元から受け取った中身は無視され、最後の URL の中身が処理されます。307は302と、308は301と同じ扱いです。
• チェーン（転送の連続）：「URL の変更を伴うサイト移転」（2026年9月11日更新）は、最終的な宛先へ直接転送することを勧め、それができない場合は「チェーン内のリダイレクトの数を 5 個未満（理想的には 3 個以下）」に抑えるよう書いています。
• 保つ期間：同じページに「リダイレクトをできるだけ長く保持します（一般的には 1 年以上）」とあります。

Search Console に出るリダイレクトの表示

Search Console ヘルプの「ページのインデックス登録レポート」は、次の2つを分けて説明しています。

• 1URL を戻さないなら301か308302のままにすると、検索結果に前の URL が出続ける
• 2最終の URL へ1回で転送するhttp→https→www→新しいパス、の3段にしない。条件をまとめて1回で移す
• 3サイト内のリンクを新しい URL に書き換える転送に頼らず、内部リンク・サイトマップ・canonical を新しい URL にそろえる
• 4転送は1年以上残す外部のリンクやブックマークから来る人のためにも残す

nginxでリダイレクトを設定する（return・rewrite）

この節では、nginx でリダイレクトを書く方法と、書き方によって返るコードや Location がどう変わるかが、実際の応答で分かります。

nginx では return 301 URL; がいちばん分かりやすい書き方です。 手元で試した設定です（ログの場所などの行を省いています）。

server {                                  # 別ドメインからの一括転送
    listen 127.0.0.1:45451;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 127.0.0.1:45451 default_server;
    root /path/to/www;

    location = /old-301 { return 301 /new.html; }
    location = /bare    { return https://www.example.com/; }   # コードを省略
    rewrite ^/blog/(\d+)$ /news/$1 permanent;                  # 301
    rewrite ^/tmp/(\d+)$  /news/$1 redirect;                   # 302
    location = /keep-qs { return 301 /new.html$is_args$args; }
    location = /rel-off { absolute_redirect off; return 301 /new.html; }
}

• return でコードを省略し、URL だけを書くと302になりました。 恒久の転送のつもりなら、301を必ず書きます。
• return 301 /new.html; のように「/」から始まるパスを書くと、nginx は自分のホスト名とポートを付けた絶対 URL にして返しました。 手前にロードバランサーや別ポートの中継があると、内側のポート番号が Location に出ることがあります。absolute_redirect off; にすると、書いたとおりの相対パスで返りました。
• rewrite は、元のクエリ文字列（? の後ろ）を自動で付けます。return で残したいときは $is_args$args か、パスとクエリを含む $request_uri を付けます。

どの location に当たるかの決まりは、関連記事「nginx location書き方｜優先順位とtry_filesをcurlで検証」で扱っています。

Apache（.htaccess）でリダイレクトを設定する

この節では、Apache の .htaccess で書くリダイレクトの基本形と、省略したときのコード、https 化でループする典型例が分かります。

Apache には、単純な転送の Redirect（mod_alias）と、条件付きの転送ができる RewriteRule（mod_rewrite）があります。 手元の Apache 2.4.58 で試した .htaccess です。

# mod_alias
Redirect /a-default /new.html
Redirect 301 /a-301 /new.html
Redirect permanent /a-perm /new.html
RedirectMatch 301 ^/old/(.*)$ /new/$1

# mod_rewrite
RewriteEngine On
RewriteRule ^r-301$ /new.html [R=301,L]
RewriteRule ^r-plain$ /new.html [R,L]
RewriteRule ^r-308$ /new.html [R=308,L]
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Apache でも、コードを省略した Redirect と [R] は302でした。 MDN も、mod_alias の Redirect は既定で302を返すと説明しています。

ロードバランサーの後ろで https 化するとループする

https の暗号化をロードバランサーや CDN が受け持ち、Apache には http で届く構成では、Apache から見ると毎回「https ではない」ため、何度でも https へ転送してループします。手元では、https の通信を受けた中継が付けるヘッダー X-Forwarded-Proto: https を curl で付けて、その状況を再現しました。

# ループする書き方
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# 中継のヘッダーも見る書き方
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

X-Forwarded-Proto はクライアントが自由に付けられるヘッダーなので、信頼してよいのは、自分の中継を通ったリクエストだけです。https 化・www の統一・ディレクトリの移動などのコピーして使える書き方は、関連記事「.htaccessの書き方｜リダイレクト・https化・アクセス制限のコピペ集」で扱っています。

Next.js・Express・PHPのリダイレクトと既定のコード

この節では、アプリのコードからリダイレクトするときの書き方と、何も指定しないと何番が返るのかが、実行結果で分かります。

フレームワークごとに「何も指定しないときのコード」が違います。 恒久の転送のつもりで既定のまま使うと、一時的な転送になります。

Next.js（next.config.mjs と redirect()）

// next.config.mjs
export default {
  async redirects() {
    return [
      { source: '/cfg-perm', destination: '/new', permanent: true },   // 308
      { source: '/cfg-temp', destination: '/new', permanent: false },  // 307
      { source: '/cfg-301', destination: '/new', statusCode: 301 },     // 301
      { source: '/articles/:slug', destination: '/blog/:slug', permanent: true },
    ];
  },
};

// app/old/page.js
import { redirect } from 'next/navigation';
export const dynamic = 'force-dynamic';
export default function Page() { redirect('/new'); }

$ curl -si http://127.0.0.1:45454/cfg-perm
HTTP/1.1 308 Permanent Redirect
location: /new
Refresh: 0;url=/new

/new
$ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://127.0.0.1:45454/articles/hello
308 http://127.0.0.1:45454/blog/hello
$ curl -si http://127.0.0.1:45454/old
HTTP/1.1 307 Temporary Redirect
location: /new
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate

Next.js は、恒久の転送に301ではなく308を使います。308は POST を POST のまま転送するので、フォームや API の URL を移しても中身が消えません。redirect() の307には no-store が付いていて、ブラウザに覚えられない形でした。proxy.js（以前の middleware）の使い方は、関連記事「Next.js proxy.ts入門｜middleware移行とmatcher実例」で扱っています。

Express 5

const express = require('express');
const app = express();
app.get('/old', (req, res) => res.redirect('/new'));            // 既定は302
app.get('/moved', (req, res) => res.redirect(301, '/new'));     // 恒久
app.post('/form', (req, res) => res.redirect(303, '/done'));    // POST のあと
app.get('/back', (req, res) => res.redirect('back'));
app.listen(45453, '127.0.0.1');

$ curl -si http://127.0.0.1:45453/old
HTTP/1.1 302 Found
Location: /new
Content-Type: text/plain; charset=utf-8

Found. Redirecting to /new
$ curl -si http://127.0.0.1:45453/back
HTTP/1.1 302 Found
Location: back

Express 5.3.0 では、res.redirect('back') は Referer の URL にならず、Location: back という文字のまま返りました。

PHP

<?php
header('Location: /new');                 // 302
exit;

header('Location: /new', true, 301);      // 301
exit;

header() のあとに exit; を書かないと、転送の応答のあとも処理が続きます。手元の PHP 8.3.6 では、POST のリクエストに対しても既定は302でした。

リダイレクトループ（ERR_TOO_MANY_REDIRECTS）の原因と直し方

この節では、「リダイレクトが繰り返し行われました」と表示されたときに、何が起きていて、どこを直すかが分かります。

ERR_TOO_MANY_REDIRECTS は、転送の先がまた転送になり、いつまでもページにたどり着かない状態です。 手元で A→B→A と転送し合う URL を作り、Chromium（日本語の画面）で開いた表示です。

このページは動作していません
127.0.0.1 でリダイレクトが繰り返し行われました。
Cookie を削除してみてください.
ERR_TOO_MANY_REDIRECTS
再読み込み

Playwright の page.goto では net::ERR_TOO_MANY_REDIRECTS、curl では次のエラーになりました。

$ curl -sSL http://127.0.0.1:45451/loop-a -o /dev/null
curl: (47) Maximum (50) redirects followed
$ curl -sSL --max-redirs 5 http://127.0.0.1:45451/loop-a -o /dev/null
curl: (47) Maximum (5) redirects followed

ループでなくても、転送が長く続けばブラウザは同じエラーになります。 Googlebot は10回までなので、Google の勧める「5個未満（理想的には3個以下）」に収めておけば、どちらにも引っかかりません。

ループの主な原因

直す手順

リダイレクトの確かめ方（curl・開発者ツール・Search Console）

この節では、設定したリダイレクトが意図どおりに動いているかを確かめる方法が、コマンドと出力で分かります。

いちばん確実なのは curl です。 ブラウザと違って転送を覚えないので、毎回サーバーの今の設定を見られます。

$ curl -sIL http://127.0.0.1:45452/chain/3
HTTP/1.1 301 Moved Permanently
Location: /chain/2
HTTP/1.1 301 Moved Permanently
Location: /chain/1
HTTP/1.1 301 Moved Permanently
Location: /landing
HTTP/1.1 200 OK

$ curl -sL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' http://127.0.0.1:45452/chain/4
200 4 http://127.0.0.1:45452/landing

$ curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' http://127.0.0.1:45451/old-301
301 -> http://127.0.0.1:45451/new.html

1. 11段だけ見る：curl -sI URLステータスと Location が想定どおりか
2. 2最後までたどる：curl -sIL URL何段で着くか・途中に302が混ざっていないか
3. 3回数と着いた先：-w '%{num_redirects} %{url_effective}'たくさんの URL をまとめて確かめるときに便利
4. 4Host を変えて試す：-H 'Host: example.com'DNS を切り替える前に、ドメインごとの転送を確かめられる
5. 5ブラウザで見る：開発者ツールの Network「ログを保持」をオンにすると、転送前のリクエストも残る
6. 6検索での扱いを見る：Search Consoleページのインデックス登録レポートと URL 検査

• 開発者ツール：Chrome for Developers の公式ドキュメントによると、Network パネルの「ログを保持」をオンにすると、ページの読み込みをまたいでリクエストが残ります。「キャッシュを無効にする」をオンにすると、ブラウザのキャッシュを使わずに読み込みます。覚えた301に邪魔されずに確かめるときに使います。
• 転送先の Referer とフラグメント：手元の Chromium では、リンクをクリックして301で転送されたとき、転送先にも最初のページの Referer が届きました。/frag#section-2 を開いて301で転送されたときは、着いた URL が /landing#section-2 になり、「#」以降が引き継がれました。

どのリダイレクトを使うか：判断表と、やってはいけない転送

この節では、状況ごとに使うコードと方法が一目で分かり、事故になりやすい転送の避け方が分かります。

オープンリダイレクトを防ぐ判定は、手元では次のように書きました。

app.get('/go', (req, res) => {
  const next = String(req.query.next || '/');
  const ok = next.startsWith('/') && !next.startsWith('//') && !next.includes('\\');
  res.redirect(ok ? next : '/');
});

next=/mypage -> 302 http://127.0.0.1:45453/mypage
next=//evil.example -> 302 http://127.0.0.1:45453/
next=https://evil.example -> 302 http://127.0.0.1:45453/

「//」で始まる値は、ブラウザでは「同じ https・http のまま別のドメイン」という意味になるため、「/」で始まるかだけを見ると素通りします。

よくあるエラー・つまずき（原文つき）

この節では、リダイレクトの設定や確認でよく出る表示と、その原因・直し方がまとめて分かります。

よくある質問

この節では、リダイレクトについてよく調べられる疑問に、短く答えます。

Q. リダイレクトとは簡単にいうと何ですか？ A. ある URL を開いたときに、自動で別の URL へ移す仕組みです。サーバーが「3xx のステータスコード」と「移動先（Location）」を返し、ブラウザがその URL を開き直します。

Q. 301と302はどう使い分けますか？ A. URL をもう戻さないなら301、あとで元に戻すなら302です。Google は301を転送先を正規 URL とする強いシグナル、302を弱いシグナルとして扱い、302では検索結果に転送元の URL が残ります。

Q. 307と308はいつ使いますか？ A. POST などの GET 以外のリクエストを、メソッドと本文を保ったまま転送したいときです。307は一時、308は恒久です。手元の Chromium では、301・302・303では POST が GET に変わり本文が消え、307・308では POST のまま本文も届きました。

Q. Linux の「リダイレクト」とは別のものですか？ A. 別のものです。シェルの > や 2>&1 は、コマンドの出力の行き先を変える機能です。関連記事「Linuxリダイレクト 2>&1の意味と順序｜標準エラー出力・tee」で扱っています。

Q. リダイレクトするとSEOの評価は引き継がれますか？ A. Google 検索セントラルは、URL を変えるときはサーバー側の恒久的なリダイレクト（301・308）を勧め、恒久の転送では転送先を正規 URL のシグナルとして使うと説明しています。転送は一般に1年以上保つよう書かれています。

Q. リダイレクトの設定が反映されないのはなぜですか？ A. ブラウザが以前の301を覚えていることが多いです。curl で確かめるか、シークレットウィンドウで開きます。curl でも変わらなければ、設定の再読み込み忘れ、CDN のキャッシュ、別の規則が先に当たっていないかを見ます。

Q. meta refresh は使ってはいけませんか？ A. サーバーの設定を変えられないときに使えます。Google は0秒の meta refresh を恒久、0秒より長いものを一時の転送として扱います。手元では、3秒の meta refresh は転送元が履歴に残り、「戻る」で転送元に戻りました。

Q. リダイレクトと canonical タグはどう違いますか？ A. リダイレクトは利用者も検索エンジンも別の URL へ移します。canonical タグは、ページはそのまま見せたうえで、検索エンジンに代表の URL を伝えるだけです。両方の URL を見せる必要が無ければリダイレクト、必要があれば canonical を使います。

まとめ

• リダイレクトは、サーバーが3xx と Location を返し、ブラウザが別の URL を開き直す仕組み。サーバー側の転送がいちばん確実。
• 恒久は301・308、一時は302・303・307。手元の Chromium では、301・302・303で POST が GET に変わり本文が消え、307・308は POST のまま本文も届いた。
• Cache-Control の無い301・308はブラウザに覚えられ、2回目はサーバーに届かなかった。試すときは302から、または max-age を付ける。
• nginx の return・Apache の Redirect・Express・PHP はコードを省略すると302、Next.js は恒久が308・一時が307。恒久のつもりならコードを必ず書く。
• ループすると Chromium は20回目の転送で ERR_TOO_MANY_REDIRECTS になった。Google は最終の URL へ直接、無理でも5個未満（理想は3個以下）、転送は一般に1年以上保つよう勧めている。

参考・出典

確認日はいずれも 2026年10月29日です。

• Google 検索セントラル「リダイレクトと Google 検索」（2026年4月17日更新）：https://developers.google.com/search/docs/crawling-indexing/301-redirects
• Google 検索セントラル「HTTP ステータスコード、ネットワーク エラー、DNS エラーが Google 検索に与える影響」（2026年3月6日更新）：https://developers.google.com/search/docs/crawling-indexing/http-network-errors
• Google 検索セントラル「URL の変更を伴うサイト移転」（2026年9月11日更新）：https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Search Console ヘルプ「ページのインデックス登録レポート」：https://support.google.com/webmasters/answer/7440203
• MDN「HTTP のリダイレクト」（2026年4月12日更新）：https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Redirections
• IETF「RFC 9110 HTTP Semantics」15.4 Redirection 3xx：https://www.rfc-editor.org/rfc/rfc9110#section-15.4
• Chrome for Developers「ネットワーク機能リファレンス」：https://developer.chrome.com/docs/devtools/network/reference
• nginx「Module ngx_http_rewrite_module」：https://nginx.org/en/docs/http/ngx_http_rewrite_module.html
• nginx「Module ngx_http_core_module」（absolute_redirect）：https://nginx.org/en/docs/http/ngx_http_core_module.html#absolute_redirect
• Apache HTTP Server「mod_alias」：https://httpd.apache.org/docs/2.4/mod/mod_alias.html
• Apache HTTP Server「mod_rewrite」：https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html
• Next.js「redirects」：https://nextjs.org/docs/app/api-reference/config/next-config-js/redirects
• Next.js「redirect」：https://nextjs.org/docs/app/api-reference/functions/redirect
• Express「res.redirect()」：https://expressjs.com/en/5x/api.html#res.redirect
• PHP マニュアル「header」：https://www.php.net/manual/ja/function.header.php

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。