htaccessのリダイレクトの書き方|301の設定例と確かめ方・注意点
公開

サイトのリニューアルやページの統合で URL を変えたのに転送を設定しないと、古い URL に張られたリンクやブックマークから来た人は「ページが見つかりません」の画面に着きます。転送を書く .htaccess は、数字や記号が1つ違うだけで、一時的な転送や転送の失敗につながるファイルです。
転送が効いているかは、ブラウザの画面ではなく、サーバーが返す応答の番号で確かめる必要があります。この記事では、.htaccess で301リダイレクトを書く方法を場面別に示し、効いているかの確かめ方と、やってはいけない書き方を解説します。記事に載せた .htaccess の書き方は、すべて株式会社メリルが検証用の Apache 2.4 に置き、応答を確かめたものです。
記事を読めば、古い URL を1回の転送で新しい URL へ送る設定を書けます。htaccess のリダイレクトは、旧 URL と新しい URL の対応表を作り、301を明記して書き、アップロードしたあとに応答の番号を確かめれば失敗を防げます。
場面別のhtaccessの301リダイレクトの書き方

.htaccess で転送を書く方法には、Redirect と RewriteRule の2つがあります。Redirect は旧 URL を前方一致で受ける簡単な転送に向き、RewriteRule はホスト名などの条件を付けた転送に向いています。
URL を変える場面ごとの書き方は、以下のとおりです。
- 1ページを別のURLへ転送する
- フォルダの中をまとめて別のフォルダへ転送する
- ドメインを変えたときに全ページを新しいドメインへ転送する
- wwwの有無とhttp・httpsをそろえる
1ページを別のURLへ転送する
1ページだけを転送するなら、Redirect permanent の1行で書けます。
Redirect permanent "/old-page.html" "https://example.com/new-page/"
1つ目の値は旧 URL のパスです。ドメインを付けず、/ から書き始めます。2つ目の値は転送先の URL で、https:// から書きましょう。
permanent は、恒久的な移転を示す301を返す指定です。旧 URL に ?utm_source=a のようなパラメータが付いていた場合、パラメータは転送先の URL にそのまま引き継がれます。
似た2つの記事を1本にまとめるときも、残さない記事の URL から残す記事の URL へ、同じ1行で転送します。
» カニバリのSEO対策は1検索語に1ページ|サーチコンソールでの見つけ方と直し方
フォルダの中をまとめて別のフォルダへ転送する
フォルダの名前だけを変え、中のファイル名を変えない場合は、Redirect permanent にフォルダのパスを書きます。
Redirect permanent "/old-dir" "https://example.com/new-dir"
Redirect は旧 URL のパスを前方一致で受け、一致した部分より後ろのパスを、転送先の URL の後ろに付けて返します。検証用の Apache で確かめた結果は、以下の表のとおりです。
| アクセスした旧 URL | 応答 | 転送先 |
|---|---|---|
| /old-dir/a/b.html | 301 | https://example.com/new-dir/a/b.html |
| /old-dir/a.html?x=1 | 301 | https://example.com/new-dir/a.html?x=1 |
| /old-dirx | 404 | 転送なし |
前方一致はパスの区切り(/)の単位で比べるため、/old-dirx のような名前の似たフォルダは転送されません。
フォルダの中のファイル名も変える場合、フォルダ単位の1行では足りなくなります。旧 URL と新しい URL を1行ずつ対応させて書く必要があります。
ドメインを変えたときに全ページを新しいドメインへ転送する
ドメインを変え、ドメインより後ろのパスを変えない場合は、旧ドメインの一番上のフォルダの .htaccess に次の1行を書きます。
Redirect permanent "/" "https://new.example.com/"
"/" はすべてのパスに前方一致するため、旧ドメインの /blog/a.html?x=1 は、新しいドメインの /blog/a.html?x=1 へ301で転送されます。
転送を返すのは旧ドメインのサーバーです。転送を残す間は、旧ドメインとサーバーの契約を続けます。
転送はできるだけ長く残し、一般的には1年以上が目安です。
wwwの有無とhttp・httpsをそろえる
http:// と https://、www の有無の違いで同じページが開ける状態は、1つの URL にそろえます。ホスト名と接続の種類を条件にするため、RewriteRule で書きます。
RewriteEngine On
RewriteCond %{HTTPS} !on [OR]
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]
4行の意味は、以下のとおりです。
- 1行目: 書き換えの機能を有効にする
- 2行目: 接続が https でないときを条件にする(
[OR]は「または」) - 3行目: ホスト名が example.com でないときを条件にする(
[NC]は大文字と小文字を区別しない) - 4行目: どちらかの条件に当たれば、同じパスの https://example.com へ301で転送し、書き換えを終える
%{REQUEST_URI} はパラメータを含まないパスですが、パラメータは既定で転送先に引き継がれます。
サーバーが独自に https へ転送しているレンタルサーバーでは、2行目を消し、ホスト名の条件だけを残します。
htaccessを置く場所とサーバーの対応を確かめる

.htaccess は、置いたフォルダによって効く範囲が変わります。書く前に確かめておくことは、以下の3つです。
- htaccessは置いたフォルダとその下に効く
- 下のフォルダでRewriteEngine Onにすると上のフォルダの書き換えは効かない
- サーバーがhtaccessを読み込むかをマニュアルで確かめる
htaccessは置いたフォルダとその下に効く
.htaccess に書いた設定は、ファイルを置いたフォルダと、その下のすべてのフォルダに効きます。ドメインの一番上に置けばサイト全体が対象になり、/media/ に置けば /media/ より下だけが対象です。
メリルは、運営する次の3つのメディアを、それぞれのドメインのサブディレクトリに置いています。
- WWS メディア(wwstd.jp/media/)
- Web集客ブック(hands-plus.com/media/)
- オウンドメディア相談室(blog-soudan.com/owned-media/)
3つのメディアは、どれもメディアのフォルダに .htaccess を置き、404のページの指定などをメディアの中だけに効かせています。ドメインの一番上のページの設定には触れずに済むのが、フォルダに置く利点です。
下のフォルダでRewriteEngine Onにすると上のフォルダの書き換えは効かない
下のフォルダの .htaccess で RewriteEngine On にして書き換えを書くと、上のフォルダの .htaccess の書き換えのルールは、既定では引き継がれません。mod_rewrite は、同じ種類の設定が重なると、下の設定で上の設定を置き換える仕組みです。
検証用の Apache で、上のフォルダに /media/old.html を転送するルールを書き、/media/ の .htaccess の中身を変えて比べた結果は、以下のとおりです。
- /media/ の .htaccess で RewriteEngine On にした場合: 404(上のルールが効かない)
- /media/ の .htaccess に書き換えを書かなかった場合: 301(上のルールが効く)
上のフォルダのルールも効かせたいときは、下のフォルダの .htaccess に RewriteOptions Inherit を書きます。ただし、引き継いだルールのパターンは、下のフォルダを基準に比べられます。検証用の Apache では、上のルールが ^media/old\.html$ のままでは Inherit を書いても一致せず、%{REQUEST_URI} の条件で書き直すと301になりました。
オウンドメディア相談室は、WordPress で動くサイトと同じドメインの、下のフォルダにあります。フォルダの .htaccess には、RewriteEngine On にすると上の WordPress の書き換えがこのフォルダに効かなくなる、と注意書きを残しました。
サーバーがhtaccessを読み込むかをマニュアルで確かめる
.htaccess は、サーバーの設定で読み込みが許可されている場合にだけ効きます。Apache の AllowOverride の既定値は None で、None のままでは .htaccess は読まれません。
レンタルサーバーでは、.htaccess と mod_rewrite が使えるかを、サーバーのマニュアルや FAQ で確かめます。ConoHa WING は .htaccess と mod_rewrite のどちらにも対応しており、コントロールパネルからも .htaccess を設定できます。
応答のヘッダーの Server の欄だけでは、.htaccess が効くかは判断できません。hands-plus.com を置いている Xserver では、2026年9月の確認で Server の欄は nginx でしたが、転送のルールは Apache の .htaccess が処理していました。
htaccessのリダイレクトでやってはいけないこと

.htaccess の転送は、書き方の小さな違いで結果が変わります。公式の文書と検証用の Apache で確かめた、避けたい書き方は以下の5つです。
- 301を書かずに転送する
- htaccessのパターンの先頭に/を付ける
- サーバーのhttpsへの自動の転送に重ねて書く
- 多数の古いURLを関係のないページへまとめて転送する
- 転送を何段もつなぐ
301を書かずに転送する
Redirect に permanent や301を書かないと、転送は一時的な302になります。RewriteRule の [R] も、番号を書かなければ302です。検証用の Apache でも、Redirect "/old-page.html" … と [R,L] の2つの書き方は、どちらも302を返しました。
一時的な転送のままでは、検索結果に旧 URL が表示されます。Google は、永続的な転送(301・308)を転送先が正規のページであることを示すシグナルとして使い、一時的な転送(302・303・307)はシグナルとして使いません。
URL を恒久的に変えたときは、Redirect permanent か [R=301,L] と書きましょう。[R] には [L] を組み合わせます。[R] だけでは、書き換えた URL が次のルールに渡されてしまうためです。
htaccessのパターンの先頭に/を付ける
.htaccess の RewriteRule では、パターンの先頭に / を付けると一致しません。.htaccess では、アクセスされたパスから置いたフォルダまでの部分が取り除かれ、先頭に / の無い文字列で比べられます。
書く場所ごとの、/images/a.jpg に一致させるパターンの書き方は以下の表のとおりです。
| 書く場所 | パターンの書き方 |
|---|---|
| サーバー全体の設定(httpd.conf) | ^/images/(.+)\.jpg |
| ドメインの一番上の .htaccess | ^images/(.+)\.jpg |
| /images/ の .htaccess | ^(.+)\.jpg |
httpd.conf 向けの例では、パターンが / から始まります。.htaccess に写すときは、先頭の / を外してください。検証用の Apache でも、.htaccess に ^/old\.html$ と書いたルールは一致せず、/old.html は404のままでした。
サーバーのhttpsへの自動の転送に重ねて書く
サーバーが独自に https へ転送している場合、.htaccess に https への転送を重ねて書くと、リダイレクトのループが起きることがあります。ConoHa WING は、独自の仕組みで https へ自動で転送するレンタルサーバーです。

出典:「よくある質問 Webサイト設定」(ConoHa WING サポート)(https://support.conoha.jp/wing/faq/website-q/)の一部を切り取って掲載(2026年10月31日の画面)。
ConoHa WING に置いたオウンドメディア相談室の .htaccess には、https への転送の行を書いていません。書いているのは、ホスト名が blog-soudan.com でない(www 付きなど)ときに、同じパスの https://blog-soudan.com へ301で転送する設定だけです。
RewriteEngine On
RewriteCond %{HTTP_HOST} !^blog-soudan\.com$ [NC]
RewriteRule ^ https://blog-soudan.com%{REQUEST_URI} [R=301,L]
一方、Xserver に置いた Web集客ブックの .htaccess は、接続が https でないときと、ホスト名が hands-plus.com でないときの両方を条件にして、https://hands-plus.com の同じパスへ301で転送しています。https への転送の仕組みはサーバーによって違うため、サーバーのマニュアルで確かめてから書きます。
多数の古いURLを関係のないページへまとめて転送する
転送先にふさわしいページが無い古い URL を、トップページなど関係の薄い1つのページへまとめて転送するのは避けます。関係の薄い1つの URL への大量の転送は、利用者を混乱させ、ソフト404と見なされる場合があります。
転送先にするのは、旧 URL と同じ内容を載せた新しい URL です。複数のページの内容を1つのページにまとめた場合は、元の複数の URL を、まとめた後のページへ転送できます。
新しいサイトに移さないページの URL は、無理に転送せず、404か410を返すのが基本です。対応表を作るときは、旧 URL ごとに「転送する」か「404か410にする」かを決めておきましょう。
転送を何段もつなぐ
転送は、旧 URL から最終的な転送先へ1回で届くように書きます。Google も、転送の連鎖を避け、最終的な転送先へ直接転送することを勧めています。転送の連鎖が長すぎる URL やループする URL は、Search Console のページのインデックス登録で「リダイレクト エラー」の扱いです。
フォルダの .htaccess に転送を書くときに気を付けたいのは、末尾に / の無い URL です。Apache の mod_dir は、フォルダを指す URL の末尾に / が無いと、/ を付けた URL へ転送します。/corp/ のフォルダの .htaccess に転送を書くと、/corp へのアクセスは /corp/ への301を経てから転送先に届きます。
検証用の Apache で、/corp と /corp/ を転送するルールの置き場所を変えて比べた結果は、以下の表のとおりです。
| ルールを書いた .htaccess | /corp の応答 | /corp/ の応答 |
|---|---|---|
| /corp/ のフォルダ | 301(/corp/ へ。転送は2段) | 301(転送先へ) |
| ドメインの一番上 | 301(転送先へ) | 301(転送先へ) |
1回で届けるには、ルールをドメインの一番上の .htaccess に書き、末尾の / の有無を両方受けます。メリルが hands-plus.com/corp を meril.co.jp/hands-plus へ転送している設定も、ドメインの一番上の .htaccess に書いています。ルールの本体は、次の1行です。
RewriteRule ^corp/?$ https://meril.co.jp/hands-plus [R=301,L,QSA]
/? は「/ が有っても無くてもよい」の意味です。
htaccessのリダイレクトが効いているかの確かめ方

ブラウザは転送を自動でたどるため、画面を見るだけでは301と302の区別がつきません。転送の設定をアップロードしたあとの確かめ方は、以下の3つです。
- curlで応答の番号と転送先を見る
- 確かめるURLの組み合わせを先に書き出す
- Search Consoleで転送したURLの扱いを見る
curlで応答の番号と転送先を見る
curl を使うと、サーバーが返した応答の番号と転送先を、転送をたどらずに表示できます。Mac のターミナルでの入力の例は、次のとおりです。
curl -I https://hands-plus.com/corp
表示の1行目の番号が301で、location の行に新しい URL が出ていれば、転送は効いています。メリルが2026年10月30日に自社の URL を1本ずつ確かめた結果は、以下の表のとおりです。
ブラウザの開発者ツールのネットワークの画面でも、応答の番号は確かめられます。

Mac のターミナルで curl -I を実行した出力を、オウンドメディア相談室がターミナルの見た目の画像にしたもの(2026年10月31日)。
表の1行目の URL を2026年10月31日に調べ直した出力でも、1行目は「HTTP/2 301」、location は https://meril.co.jp/hands-plus でした。
確かめるURLの組み合わせを先に書き出す
1本の URL を確かめただけでは、末尾の / の有無や http・www の違いで転送が漏れていても気づけません。転送を書く前に、確かめる URL の組み合わせと、期待する応答を表に書き出します。
メリルが hands-plus.com/corp の転送で確かめた URL は13本で、組み合わせは以下のとおりです。
- 末尾の / の有無(/corp と /corp/)
- パラメータ付きの URL(/corp/?utm_source=test)
- http:// と www 付きの URL
- 転送してはいけない URL(トップページ・/works/・/corp/ の中の画像と index.html)
- 名前の似た URL(/corpx)
転送してはいけない URL も表に入れるのは、ルールが広すぎて関係のないページまで転送していないかを確かめるためです。13本はすべて期待どおりで、/corp/ の中の画像は200、/corpx は404のままでした。
Search Consoleで転送したURLの扱いを見る
転送が Google にどう扱われたかは、Search Console のページのインデックス登録レポートで確かめます。「ページにリダイレクトがあります」は、別のページへ転送する正規でない URL が入る理由です。転送した旧 URL が並んでいれば、Google は転送を見つけています。
「リダイレクト エラー」の理由に入った URL には、転送の連鎖が長すぎる、転送がループしている、空や不正な URL を含むといった問題があります。該当する URL は、curl で1本ずつ確かめ直しましょう。
URL を大きく変えたあとは、見つからない(404)の URL が普段より増えていないかも確認の対象です。
URLを変える前に旧URLと新URLの対応表を作る

転送を書く前に、どの旧 URL をどの新しい URL へ送るかを、1本ずつ決めておく必要があります。対応表があれば、.htaccess の行と確かめる URL の一覧を、表からそのまま作れます。
メリルは、2026年9月に meril.co.jp を新しいサイトに切り替えるときに、企業向けの解説記事などの旧 URL と新しい URL の対応表を作りました。対応表からわかったことは、以下の3つです。
- 末尾の/を変えるだけでもページの転送が要る
- 対応表の9割以上は画像のURLだった
- 別のドメインにあるURLはそのドメインのサーバーで転送する
末尾の/を変えるだけでもページの転送が要る
対応表は1,736件で、1件ごとに旧 URL・新しい URL・転送の扱いを書いています。ページの136件のうち135件は、旧 URL の末尾の / を外しただけの変更でした。
記事の URL なら、/(フォルダ名)/(記事の名前)/ が /(フォルダ名)/(記事の名前) に変わる形です。末尾の / の有無が違えば、サーバーにとっては別の URL です。新しいサイトでは末尾に / を付けない URL にそろえたため、対応表では135件すべてに301の転送を割り当てています。
対応表の9割以上は画像のURLだった
対応表の1,736件のうち1,600件(92%)は、記事に使っていた画像の URL でした。画像は、WordPress の wp-content/uploads の下から新しいサイトの画像のフォルダへ保存場所が変わり、ファイル名も付け直したため、1件ずつの転送が必要でした。
URL の種類ごとの件数は、以下の表のとおりです。
| URL の種類 | 件数 | 新しい URL との違い |
|---|---|---|
| 記事 | 105件 | 末尾の / だけ |
| 一覧のページ | 27件 | 末尾の / だけ |
| 固定のページ | 4件 | 3件は末尾の / だけ、1件は転送先を変更 |
| 画像 | 1,600件 | 保存場所とファイル名 |
画像の旧 URL のうち522件は、日本語のファイル名を含み、URL の中では %E3%82… のような形に変わっていました。日本語のファイル名の URL は、対応表に実際の URL の形のまま控え、設定したあとに転送を確かめます。
別のドメインにあるURLはそのドメインのサーバーで転送する
画像の旧 URL のうち24件は、meril.co.jp ではなく、別のドメインにありました。転送を返すのは旧 URL のドメインのサーバーなので、meril.co.jp の設定では転送できません。
記事の中の画像の URL を書き出すと、別のドメインに置いた画像が混ざっていることがあります。対応表の旧 URL はドメインごとに分けて数え、転送を書くサーバーごとに作業を分けると、作業の漏れを防げます。
htaccessのリダイレクトは対応表を作ってから書き、アップロード後に応答を確かめる
htaccess のリダイレクトは、Redirect permanent か、RewriteRule の [R=301,L] で書きます。どちらの書き方でも、301を明記しなければ一時的な302になります。
記事の要点は、以下のとおりです。
- 1ページ・フォルダ・ドメインの転送は Redirect permanent の1行で書ける
- http・www をそろえる転送は RewriteCond と RewriteRule で書く
- .htaccess は置いたフォルダとその下に効き、パターンの先頭に / を付けない
- サーバーが独自に https へ転送しているかを先に確かめる
- 関係のないページへまとめて転送せず、転送先が無いページは404か410にする
- アップロードしたあとは curl で応答の番号と転送先を確かめる
旧 URL と新しい URL の対応表を先に作れば、.htaccess の行も確かめる URL の一覧も、表から作れます。まずは変える予定の URL を書き出し、1本ずつ転送先を決めましょう。
この記事の数字の出どころ
- 株式会社メリルが meril.co.jp の切り替えで作った旧URLと新URLの対応表2026年9月の meril.co.jp の切り替えに向けて、企業向けの解説記事などの旧URLと新URLを1件ずつ対応させた1,736件の表を、URLの種類・末尾のスラッシュ・ドメインごとにスクリプトで数えた(集計は2026年10月30日)
- メリルの自社サイトの転送の設定と確認の記録hands-plus.com/corp から meril.co.jp/hands-plus への転送を13本のURLで確かめた記録(2026年9月)、Web集客ブックとオウンドメディア相談室の .htaccess の設定(2026年10月30日時点)と、2026年10月30日に自社のURL4本の応答を1本ずつ確かめた結果
- 記事に載せた .htaccess の書き方の動作確認記事の書き方の例を検証用の Apache 2.4.67 に置き、34本のURLについて応答の番号と転送先を確かめた(2026年10月30日)
- hands-plus.com/corp の応答を curl で調べ直した結果2026年10月31日に curl -I で1回取得し、応答の番号と location を読んだ
参考にしたページ
- リダイレクトと Google 検索(Google 検索セントラル)(2026年10月30日に確認)
- サイトを移転する方法(Google 検索セントラル)(2026年10月30日に確認)
- ページのインデックス登録レポート(Search Console ヘルプ)(2026年10月30日に確認)
- Apache Module mod_rewrite(Apache HTTP Server 2.4)(2026年10月30日に確認)
- RewriteRule Flags(Apache HTTP Server 2.4)(2026年10月30日に確認)
- Apache Module mod_alias(Apache HTTP Server 2.4)(2026年10月30日に確認)
- Apache Module mod_dir(Apache HTTP Server 2.4)(2026年10月30日に確認)
- Apache HTTP Server Tutorial: .htaccess files(Apache HTTP Server 2.4)(2026年10月30日に確認)
- よくある質問 Webサイト設定(ConoHa WING サポート)(2026年10月30日に確認)
運営:株式会社メリル(このメディアについて)。相談の内容を記事にするときは、ご本人の許可を取り、社名と数字を伏せます。


