301リダイレクトとは？.htaccess・nginxの書き方と確認方法

この記事の要点：

• 301リダイレクトは恒久的な移動を伝える転送で、Googleは転送先を正規のURLとする強いシグナルとして扱う
• 元に戻さないURL変更・ドメイン移転・http→httpsには301（または308）、一時的な移動には302（または307）を使う
• 削除したページを関係のないページやトップへまとめて転送せず、代わりのページが無ければ404を返す
• 設定後はcurl -Iで301と転送先を確かめ、転送が2回以上続くチェーンは最終のURLへ直接転送するよう直す
• サイト移転のリダイレクトは、Googleの案内どおり少なくとも1年は残す

301リダイレクトとは

301リダイレクトとは、あるURLのページが別のURLへ恒久的に移動したことを、サーバーがステータスコード「301」で伝える転送の方法です。古いURLを開いた人やクローラーは、自動で新しいURLへ移動します。

Googleは、恒久的なリダイレクトを「転送先のURLを正規のURLとして扱うべき」という強いシグナルとして扱うと説明しています。URLを変えたときに301を設定しておくと、次の3つを守れます。

• 読者：ブックマークや他サイトのリンクから来た人が、404ページで行き止まりにならない
• 検索での扱い：古いURLに集まっていたリンクなどのシグナルが、新しいURLにまとめられる
• クロール：Googleが古いURLの代わりに新しいURLを見つけ、検索結果のURLを入れ替える

正規のURLの考え方は「canonicalとは」で説明しています。

リダイレクトの種類と使い分け

リダイレクトは、サーバーが返すステータスコード（ページの状態を表す3桁の番号）で種類が分かれます。Googleは、恒久的か一時的かで扱いを変えます。

どれを使うかの判断の目安

設定したつもりの種類と、実際にサーバーが返している番号が合っているかは、後で説明するcurlで必ず確かめます。

リダイレクトとは：307・308が301・302と違う点

リダイレクトとは、あるURLを開いた人やクローラーを、別のURLへ自動で移す仕組みです。307と308は、元のリクエストのメソッド（POSTなど）と本文を変えずに転送する点が301・302と違い、古いクライアントは301でGETに変えてしまうことがあります（MDN：307・308、2026年10月14日に確認）。フォームの送信先のURLを移すときは308（一時的なら307）を選びます。Googleは308を301と、307を302と同じ扱いにします。

301リダイレクトを使う場面・使わない場面

使う場面

• URLを変えたとき：例：/blog/2024/seo-tips.html を /blog/seo-tips/ に変えた
• サイト構造を変えたとき：例：/column/ 配下の記事を /blog/ 配下へ移した
• ドメインを変えたとき：例：old-example.jp から example.com へ移転した
• httpからhttpsへ切り替えたとき
• URLの表記をそろえるとき：wwwの有無、末尾のスラッシュ、index.html の有無（URLの正規化）
• 記事を統合したとき：内容が重なる2本の記事を1本にまとめた（カニバリゼーションの解消）

使わない場面

• 削除したページを、関係のないページやトップページへまとめて転送する：Googleは、内容の合わない転送先をソフト404（実質的に「ページが無い」）として扱うことがあります。代わりのページが無ければ404を返します。
• 一時的な移動：元のURLに戻すなら302を使います。
• 同じ内容のページを両方残したいとき：例：印刷用ページのように両方を見せる必要があるなら、転送ではなくcanonicalで正規のURLを示します。

サーバーでの書き方（.htaccess・nginx）

Apacheを使うサーバー（多くのレンタルサーバー）では、サイトのルートにある .htaccess に書きます。nginxでは、サーバーの設定ファイルの server ブロックに書きます。どちらも、書き間違えるとサイト全体が表示されなくなることがあるため、変更前に元のファイルを保存しておきます。例のドメインは説明用です。

WordPressの .htaccess では、転送のルールを「# BEGIN WordPress」の行より上に書きます。下に書くと、WordPressのルールが先に処理され、転送されないことがあります。

ページ単位

# Apache（.htaccess）
RedirectMatch 301 ^/old-page/$ https://example.com/new-page/

# nginx
location = /old-page/ {
    return 301 https://example.com/new-page/;
}

Apacheの Redirect 301 /old /new という書き方は「前方一致」です。/old を指定すると /old-campaign/ まで転送されてしまうため、1ページだけを転送したいときは、上のように先頭（^）と末尾（$）を指定した RedirectMatch を使うと安全です。

ディレクトリ単位

# Apache（.htaccess）
RewriteEngine On
RewriteRule ^column/(.*)$ https://example.com/blog/$1 [R=301,L]

# nginx
location ^~ /column/ {
    rewrite ^/column/(.*)$ https://example.com/blog/$1 permanent;
}

例：/column/seo-tips/ は /blog/seo-tips/ へ転送されます。記事のスラッグを変えずにディレクトリだけ移した場合に使えます。nginxの permanent は301を返す指定です。

httpからhttpsへ

# Apache（.htaccess）
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

# nginx（80番ポートのserverブロック）
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

CDNやロードバランサーの後ろにあるサーバーでは、サーバーから見た通信が常にhttpになり、この条件で転送がループすることがあります。その場合は、レンタルサーバーやCDNの管理画面にある「常時SSL化」などの設定を使います。

wwwの有無をそろえる（httpsと同時に1回で）

# Apache（.htaccess）：http と www ありを、まとめて https://example.com へ
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# nginx（443番ポートのwwwありを転送）
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

httpsへの転送とwwwの統一を別々のルールで書くと、http://www.example.com/ → https://www.example.com/ → https://example.com/ の2回の転送になります。上のように条件をまとめると、1回で最終のURLへ届きます。

httpからhttpsへのリダイレクトで確かめること

httpからhttpsへのリダイレクトは、http・httpsとwwwの有無の4通りのURLが、すべて1回の301で同じhttpsのURLへ届けば完了です。

for u in http://example.com/ http://www.example.com/ https://www.example.com/ https://example.com/; do
  curl -s -o /dev/null -L -w "%{http_code} %{num_redirects} $un" "$u"; done

• 混在コンテンツ：httpsのページがhttpのスクリプトなどを読み込むと、ブラウザが読み込みを止めます（MDN：混在コンテンツ）。開発者ツールのコンソールで見つけ、URLをhttpsに直します。
• HSTS：Strict-Transport-Securityヘッダーを返すと、ブラウザは以後そのホストにhttpsだけで接続します（MDN）。全ページがhttpsで動くことを確かめてから設定します。
• Search Console：ドメイン プロパティはhttpとhttpsの両方を含みます。URLプレフィックス プロパティならhttpsのURLで追加します。

Googleは2014年8月に、HTTPSをランキングのシグナルとして使い、当面はその重みを非常に小さくすると発表しています（Google 検索セントラル ブログ）。

末尾のスラッシュをそろえる

# Apache（.htaccess）：ファイル以外のURLに「/」を付ける
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !/$
RewriteRule ^(.*)$ https://example.com/$1/ [R=301,L]

# nginx：拡張子のないURLに「/」を付ける
rewrite ^([^.]*[^/])$ $1/ permanent;

どちらも、サイトのURLが「/」で終わる設計の場合の例です。画像やCSSのような拡張子のあるファイルには付けません。CMSが同じ処理をしている場合は、二重にしないよう先に確かめます。nginxは、設定を変えたら nginx -t で構文を確かめてから再読み込みします。

WordPressでの設定方法

例：パーマリンク設定を「日付と投稿名」から「投稿名」に変えると、すべての記事のURLが変わります。本体の推測に任せず、.htaccess で ^d{4}/d{2}/d{2}/(.+)$ のような規則で新しいURLへ301を設定し、主要な記事を個別に確かめます。パーマリンクの設定の種類と決め方は「パーマリンクとは」で説明しています。

設定後の確認方法（curl・URL検査）

curl -I でステータスコードを見る

ブラウザは転送を自動でたどってしまい、301か302かが分かりません。ターミナルで curl -I を使うと、サーバーの返事（ヘッダー）だけを表示できます。

$ curl -I http://example.com/old-page/
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/

1行目の番号が301（または308）で、Locationが意図した転送先になっていれば正しく設定されています。転送が何回続くかは、-L を付けて最後までたどると分かります。

$ curl -sIL http://www.example.com/old-page/ | grep -iE "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
Location: https://example.com/old-page/
HTTP/2 301
location: https://example.com/new-page/
HTTP/2 200

この例では転送が2回続いています。1回で /new-page/ へ届くように、ルールを直します。

多くのURLをまとめて確かめる

移転のときは、古いURLの一覧（1行に1URL）を用意して、最終的なステータスと転送の回数をまとめて出します。

while read -r u; do
  curl -s -o /dev/null -L -w "%{http_code} %{num_redirects} $u -> %{url_effective}n" "$u"
done < old-urls.txt

すべての行が「200 1」（最終が200で、転送は1回）になっていれば理想です。「404」や「200 3」の行を拾って直します。

Search Consoleで確かめる

• URL検査：新しいURLを検査し、「URL は Google に登録されています」になっているか、「Google が選択した正規 URL」が新しいURLかを確かめます。古いURLを検査すると、転送されていることが分かります。
• ページのインデックス登録：古いURLが「リダイレクトを含むページ」に入るのは正常です。「リダイレクト エラー」に入ったURLは、チェーンやループを疑います。

リダイレクトチェーン・ループとよくある失敗

リダイレクトチェーンとは、A→B→Cのように転送が何回も続く状態です。Googlebotは最大10回まで転送をたどり、それまでに内容を取得できないと、Search Consoleでリダイレクト エラーとして表示されます。回数が少なくても、転送が続くほど表示は遅くなります。リダイレクトループは、A→B→Aのように転送が循環し、ページがいつまでも表示されない状態です。

サイト移転のチェックリスト

ドメインの変更やURL構造の大きな変更は、手順を分けて進めます。Googleは、移転のリダイレクトをできるだけ長く、少なくとも1年は残すよう勧めています。ページの棚卸しから公開後の監視までのリニューアル全体の進め方は「サイトリニューアルのSEO：順位を落とさない移行の手順」で説明しています。

例：移転と同時にデザインや記事内容も大きく変えると、検索での変化が起きたときに原因を切り分けにくくなります。可能なら、URLの移転と内容の変更は時期を分けます。外部から張られたリンクの見方は「被リンクとは」で説明しています。

当サイト（seoagent.jp）の実例

当サイト（seoagent.jp）では、トップ / から日本語版 /ja/ への転送が302（一時的）になっていました。恒久的な構成のため301に変更し、旧サイト時代のURLも新しいURLへ1対1で301を設定しました。その後、検索エンジンに登録される前に日本語版をトップ / に置く構成に変え、/ja/ で始まる URL は対応するページへ1対1で301にしています。サイトの反映のたびに、この301を確認しています。

また、2010年ごろの旧サイトのページ /seoagent.htm に外部からのリンクが残っていたため、相当する現在のページであるトップ / へ301で転送しています。転送を確認したうえで、被リンクの調査ツールで有効な被リンクを約45件確認しましたが、ほとんどは自動生成のスパムで、否認は不要と判断しています。古いURLに残るリンクは、移転から何年たっても見つかることがある、という例です。

ほかのテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。

よくある質問

301リダイレクトを設定すると、古いURLはいつ検索結果から消えますか。

Googleが古いURLを再びクロールし、転送に気づいたあとに新しいURLへ入れ替わります。かかる時間はサイトやページによって異なります。URL検査で新しいURLが登録されているかを確かめ、内部リンクやサイトマップも新しいURLにそろえておくと、入れ替わりを妨げません。

サブディレクトリへの移動にも、Search Consoleの「アドレス変更」ツールを使いますか。

使いません。Search Consoleのヘルプでは、アドレス変更ツールはドメイン単位のプロパティでだけ使え、パス（ディレクトリ）単位のプロパティは移せないと説明しています。ディレクトリの移動は、301リダイレクトと内部リンクの書き換えで対応します。

一度設定した301を、後から取り消せますか。

サーバーの設定は戻せますが、301はブラウザに記憶されることがあり、一度転送された人の環境では、設定を消した後も転送が続く場合があります。元に戻す可能性がある移動なら、最初から302を使います。

画像やPDFのURLも301で転送できますか。

できます。サーバーの設定（.htaccessやnginx）で、HTMLのページと同じように書けます。WordPressのプラグインの中には投稿や固定ページだけを対象にするものもあるため、ファイルの転送はcurl -Iで実際のステータスを確かめます。

SEOAGENTでできること

SEOAGENTでは、重なっている記事の整理や、記事同士の内部リンクの見直しを進められます。リダイレクトそのものの設定は、WordPressやサーバー側で行います。

• 記事改善・リライト
• 内部リンクの提案・挿入

参考情報

• Google 検索セントラル：リダイレクトと Google 検索
• Google 検索セントラル：URL の変更を伴うサイト移転
• Google 検索セントラル：HTTP ステータス コードが Google のクローラーに与える影響