.htaccessのリダイレクト｜ケース別の書き方と効かない原因

「.htaccessのリダイレクトは、記述をコピーして貼れば終わる」。最初の1本、たとえば旧ページから新ページへの転送がすんなり動いたときは、たしかにそう見えます。1行貼って、ブラウザで開いて、転送された。作業としてはそれで完結しました。

しかし、これまで数多くのサイトのリニューアルやドメイン移転に合わせて転送を組んできた弊社の立場から言えるのは、壊れ始めるのは2本目のルールを足したときだということです。ページ単位の転送とhttpsへの統一、wwwの統一が同じファイルに並んだ瞬間、書いた順番と使ったモジュールの組み合わせで結果が変わります。1本目が動いたのは、たまたま競合するルールがなかったからにすぎません。

本記事では、2つの書き方の選び方からケース別の記述例、ルールが増えたときに起きる衝突、反映されないときの確認順までを、Web運用の実務で使う順にお伝えします。

.htaccessで使うリダイレクトの2つの書き方

リダイレクトの記述は、大きく2系統に分かれます。mod_aliasというモジュールが提供するRedirectおよびRedirectMatchと、mod_rewriteが提供するRewriteRule。どちらも転送そのものは実現できますが、書ける条件の範囲がまったく違うのです。

Redirectは、転送元のパスと転送先のURLを並べるだけで書けます。そのかわり条件分岐は書けません。一方のRewriteRuleは、直前にRewriteCondを置くことで「アクセスがhttpのときだけ」「ホスト名がwww付きのときだけ」といった判定を挟めます。条件が要るならRewriteRule、単純な置き換えならRedirect。ここが最初の分岐点です。

Redirectでとくに注意したいのが、指定したパスの配下もまとめて対象になる点です。`Redirect 301 /old /new` と書いた場合、`/old/page.html` へのアクセスは `/new/page.html` へ転送されます。移転先に同じ階層構造が残っているなら手数が減って助かる一方、`/old` という1ページだけを移したいときには意図しない転送が起きる。1ページ単位で扱いたいなら、RewriteRuleか、正規表現で末尾を固定できるRedirectMatchを選んでください。

こうした話をすると、サーバー会社が用意している転送機能で足りるのではないか、という質問をよくいただきます。

Web担当者

契約しているサーバーの管理画面にもリダイレクト設定の項目があるのですが、それでは足りないのでしょうか。

Writers-hub
編集部

1ページずつの転送なら管理画面で十分でしょう。ただ、条件を付けた転送や、数十ページ分をまとめて移す設定は用意されていないことが多く、途中から.htaccessに書き直す手間が出てきます。移行の規模が先に見えているなら、はじめから.htaccessに寄せておくほうが早いはずです。

関連記事：【2025年最新版】初心者でもできるSEOのやり方完全ガイド | 上位表示するための具体的な方法を徹底解説

301と302の使い分けの判断基準

転送のステータスコードは複数ありますが、Web運用で使うのは301と302の2つでしょう。301は恒久的な移転、302は一時的な移転を示します。

判断は用途で分かれます。二度と元のURLに戻さないなら301、キャンペーン期間だけ別ページへ飛ばすなど元に戻す前提があるなら302。Googleの検索セントラルにも、URLを恒久的に変更した場合は301を返すよう記載されています。301を受け取った検索エンジンは、新しいURLのほうを正規のURLとして扱うようになるからです。

การเปลี่ยนเส้นทางและ Google Search | Google Search Central | Documentation | Google for Developers

ดูข้อมูลเกี่ยวกับการเปลี่ยนเส้นทางประเภทต่างๆ การตีความของ Google และการเปลี่ยนเส้นทางมีประโยชน์อย่างไรใน Google Search

🌐 developers.google.com

外部リンク

ここで、実際に何本も転送を組んできた立場から本音を言えば、検証中は302で書き、確認できてから301に書き換える進め方をおすすめします。301はブラウザに強くキャッシュされるため、誤った転送先を一度301で返してしまうと、記述を直しても自分のブラウザだけが古い転送先へ飛び続けます。原因がキャッシュだと気づくまでの時間が惜しい。302ならキャッシュが残りにくく、書き換えた結果がその場で画面に出ます。

関連記事：301リダイレクトの設定方法｜.htaccess・WordPress・Next.jsでの書き方

ケース別のリダイレクトの記述例

ここからは、運用で頻度の高い順にケース別の記述を並べます。いずれもドキュメントルート直下に置いた.htaccessに書く前提で、ドメイン名の部分はご自身のものに置き換えてください。

RewriteRuleを使う記述では、ファイルの先頭に次の2行を一度だけ書いておきます。RewriteEngine Onはmod_rewriteを有効にする宣言で、これがないとRewriteRuleは1行も動きません。RewriteBaseは書き換えの起点となるパスで、ドキュメントルート直下ならスラッシュを指定します。

RewriteEngine On
RewriteBase /

ページ単位でリダイレクトする

1ページを別の1ページへ移す場合の記述です。

RewriteRule ^old-page\.html$ /new-page.html [R=301,L]

ここで取り違えやすいのが、パターンの書き出しです。.htaccess内のRewriteRuleで照合されるのはファイルを置いたディレクトリからの相対パスで、先頭にスラッシュは付きません。`^/old-page\.html$` と書くと一致しなくなる。書き慣れた方でも、サーバー設定ファイルの書き方と混ざって取り違えやすい箇所でしょう。

mod_aliasで同じことを書くなら1行で済みます。

Redirect 301 /old-page.html /new-page.html

ディレクトリ単位でリダイレクトする

`/old-dir/` の配下をまるごと `/new-dir/` へ移し、その下のファイル名は変えない場合の記述です。

RewriteRule ^old-dir/(.*)$ /new-dir/$1 [R=301,L]

丸かっこで受け取った文字列が `$1` に入り、そのまま転送先へ引き継がれます。`/old-dir/a/b.html` は `/new-dir/a/b.html` へ転送されるため、ディレクトリ名だけが変わったリニューアルなら、この1行で数百ページ分をまかなえるでしょう。

配下のURLをすべて `/new-dir/` のトップへ集めたいときは `$1` を外します。ただし内容の対応しない転送は、検索エンジンから存在しないページと同等に扱われることがある。まとめて1ページへ寄せる判断は、転送先にその内容が実際にあるかを確かめてから決めてください。

別ドメインへ移転する

ドメインを変える場合は、パスを保ったまま新ドメインへ転送します。

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

RewriteCondで転送元のホスト名を絞っている理由は、旧ドメインと新ドメインが同じサーバーの同じディレクトリを見ている構成にあります。条件がないと、新ドメインへのアクセスまで自分自身へ転送し続けてしまう。無限ループの典型例がここです。

httpからhttpsへ統一する

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

サーバーの構成によっては、ロードバランサーを経由するために `%{HTTPS}` が常にoffのままになることがあります。その場合は `%{HTTP:X-Forwarded-Proto} !=https` を条件に使う書き方が案内されていますので、契約先のヘルプを確認してください。

wwwのあり・なしを統一する

wwwなしに寄せる場合の記述です。

RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

wwwありに寄せるなら、条件と転送先を入れ替えます。どちらに統一しても検索上の優劣はありません。決め手になるのは、すでに外部サイトから多く貼られている側に合わせることです。リンクの多いほうへ寄せておけば、外部から辿ってきた人が経由する転送が1段減ります。

index.htmlを含むURLをそろえる

RewriteCond %{THE_REQUEST} ^.*/index\.html
RewriteRule ^(.*)index\.html$ /$1 [R=301,L]

条件に `%{THE_REQUEST}` を使うのには理由があります。`%{REQUEST_URI}` で判定すると、内部で書き換えられたあとの値にも一致してしまい、転送が止まらなくなる。ここは定番の書き方として覚えてしまってよい箇所でしょう。

一部のディレクトリを転送から除外する

全体を新ドメインへ移しつつ、一部のディレクトリだけ手元に残す場合の記述です。除外の条件を、転送のルールより前に置きます。

RewriteCond %{REQUEST_URI} !^/keep-dir/
RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]

条件の先頭に付いた記号は否定を表し、「`/keep-dir/` で始まらないとき」という意味になります。移転の途中で、旧サーバーに問い合わせフォームだけ残しておきたい場面などで使う書き方です。

関連記事：302リダイレクトとは？301との使い分けと設定・エラー対処を解説

.htaccessファイルの作り方と設置場所

記述が決まったら、ファイルを作ってサーバーに置きます。すでに.htaccessが存在するサーバーも多いため、有無の確認から始めてください。

.htaccessの設定は、置いたディレクトリとその配下すべてに効きます。サイト全体へ適用したいならドキュメントルート直下、特定のディレクトリだけに効かせたいなら、そのディレクトリの中に置く。配下に別の.htaccessがある場合は下の階層の記述が優先される項目もあるため、どの階層に何が書かれているかを一度洗い出しておくと、あとで原因を探す手間が減ります。

ルールを足すたびに壊れる3つの原因

1本目の転送が動いたあと、2本目、3本目を書き足していくと、先に動いていたはずのルールが効かなくなることがあります。相談を受ける内容を並べてみると、原因はほぼ次の3つに絞られます。

上から順に評価され、一致した時点で止まる

mod_rewriteのルールは、ファイルの上から順に照合されます。`[L]` フラグが付いたルールに一致すると、そこで処理が終わります。裏を返せば、広い範囲に一致するルールを上に書いた時点で、その下に並べたルールは一度も評価されません。

サイト全体をhttpsへ統一する記述をファイルの先頭に置き、その下へ個別ページの転送を並べた構成は、まさにこの形です。書く順番の原則は、範囲の狭いルールを上、広いルールを下に書くこと。個別ページの転送を先に、全体へ効く統一系を最後に置きます。

転送後のURLが、もう一度先頭から評価される

`[L]` は「このルールセットの処理を終える」という意味であって、「以後いっさい書き換えない」という意味ではありません。.htaccessの中で書き換えが起きると、書き換わったあとのURLで再びファイルの先頭から処理が走ります。

そのため、条件を付けずに `RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]` とだけ書けば、転送先のURLが同じルールに一致し、同じ場所へ転送し続けます。ブラウザは「リダイレクトが多すぎます」と表示して止まる。無限ループを防ぐ役割を担っているのはRewriteCondです。ホスト名やプロトコル、リクエストされたパスを使って「まだ転送していない状態」を条件として切り出す。ここを省いて書いたルールは、遅かれ早かれループします。

mod_aliasとmod_rewriteが同じURLに当たっている

RedirectとRewriteRuleを1つのファイルに混ぜると、同じURLへ両方のルールが当たる場面が出てきます。どちらが先に処理されるかはモジュール側の実行順で決まるため、ファイル上での行の前後とは一致しません。

Redirectを上に書いたのにRewriteRuleの結果が返ってくる、という現象はここから起きます。切り分けに時間がかかる割に、混在させて得られるものは何もない。同じファイル内では、どちらか一方の書き方に統一するのが安全です。比較記事ではあまり語られませんが、複数人でサイトを触る現場ほど効いてくる決めごとだと感じています。

リダイレクトが効かないときの確認順

転送されない、あるいは意図と違うページへ飛ぶ。原因を思いつく順に探すと時間ばかりかかるため、影響範囲の大きいところから順に潰していきます。

順番には理由があります。サーバー側の制限は自分の記述をいくら直しても解決しないため最初に確認し、次に記述そのもの、最後に他のルールとの関係を見る。この順で進めると、上から3つを見た時点で解決するケースが大半です。

• サーバーが.htaccessを読み込む設定になっているか。共用サーバーでは使える記述が制限されている場合があり、nginxで動くサーバーでは.htaccess自体が機能しません
• `RewriteEngine On` が書かれているか。RewriteRuleを使う記述で、最も多い書き漏れです
• ブラウザに古い転送が残っていないか。シークレットウィンドウを開くか、`curl -I` でヘッダーを確認します
• パターンの先頭にスラッシュが入っていないか。.htaccess内では不要です
• 上に書いた別のルールで処理が止まっていないか。該当のルールを一時的にファイルの先頭へ移して確かめます
• ファイルの文字コードと改行コードがUTF-8とLFになっているか

それでも動かない場合は、記述を1行だけ残してほかをすべてコメントアウトし、動く状態から1行ずつ戻していきます。原因を推測で探すより、確実に動く状態を作ってから足すほうが早く終わることが多いはずです。

設定の前後で必要になる作業

リダイレクトの記述は、URL変更という作業の一部でしかありません。前後の工程を飛ばすと、転送は動いているのに検索からの流入だけが戻らない、という状態になります。

設定の前にやるのは、旧URLの一覧づくりと、転送先の1対1の対応づけです。アクセス解析で流入のあるページとサイトマップの両方から拾い、それぞれの転送先を決めてから記述に取りかかる。ここを飛ばして書き始めると、あとから対応漏れが見つかるたびにルールを継ぎ足すことになり、前章の衝突が起きやすくなります。

設定のあとは、サイト内のリンクの書き換え、canonicalの指定の見直し、サイトマップの更新とサーチコンソールでの送信が続きます。

• 旧URLをまとめてトップページへ転送する。内容の対応しない転送は、存在しないページと同等に扱われることがあります
• 数年後に転送を外す。旧URLへのリンクや古いブックマークは残り続けるため、一度設定した301は基本的に残します
• 転送したからとサイト内のリンクを直さない。内部のリンクは新URLへ書き換え、転送を経由しない状態にします
• サーバーで301を返せるのにmeta refreshやJavaScriptで代用する。表示されてから移動する分だけ待たせます

とりわけ見落とされがちなのが、転送が2段3段と連なる状態です。旧ドメインの旧URLから旧ドメインの新URLへ、そこから新ドメインの新URLへ、と経由すると、その回数だけ表示までの待ち時間が増えます。ルールを整理して、1回の転送で最終的なURLへ届く形にまとめてください。

.htaccessのリダイレクトでよくある質問

設定を進める中でいただくことの多い質問をまとめました。

まとめ｜.htaccessのリダイレクトは順番で決まる

.htaccessのリダイレクトでつまずくのは、個々の記述を知らないからではありません。RedirectとRewriteRuleのどちらで書くかを決めないまま書き足し、範囲の広いルールを上に置き、条件を付けずにループさせる。結果が変わるのは、記述そのものより並べ方と組み合わせのほうです。

進め方としては、条件が要るかどうかで書き方を決め、範囲の狭いルールから順に並べ、検証中は302で確認してから301へ変える。この3つを守るだけで、書き直しの回数はかなり減るはずです。設定の前には旧URLの一覧づくり、あとには内部リンクの書き換えとサイトマップの更新が続くことも、あわせて予定に入れておいてください。

私たち合同会社Writers-hubは、サイトのリニューアルやドメイン移転にともなうコンテンツの移行と、移行後の検索からの流入回復を支援しています。転送の記述だけでなく、どのURLをどこへ集約するかという整理から関わることが多く、書き始める前の一覧づくりで止まってしまうご相談を繰り返し受けてきました。