個別URLの転送・www統一・https強制・ドメイン移行・末尾スラッシュ統一・正規表現による一括転送まで、 選択するだけで.htaccessとnginxの設定コードを同時に生成します。反映前の動作テストにも対応。
リダイレクトルールを追加
生成された設定コード
# ルールを追加すると、ここに.htaccessの設定コードが生成されます。
動作テスト（このURLはどう転送される？）
まだルールが追加されていません。ルールを追加するとここで結果を確認できます。
反映前に確認してください
サーバーへ反映する前に、必ず元の設定ファイルをバックアップしてください。nginxの場合は反映前に構文チェック（nginx -t）を行うことをおすすめします。
リダイレクト設定とは？.htaccessとnginxの違いと基本の考え方
リダイレクト設定とは、あるURLにアクセスしてきたユーザーやクローラーを、自動的に別のURLへ転送する仕組みです。ページの移転、ドメインの変更、www表記の統一など、Webサイトを運用していく中で必ずといっていいほど必要になる設定のひとつです。
この設定を記述する方法は、利用しているサーバーの種類（Webサーバーソフトウェア）によって異なります。多くのレンタルサーバーで採用されているApacheでは「.htaccess」というファイルに、VPSやクラウド環境で広く使われるnginxではサーバーの設定ファイル内に、それぞれ異なる書式でルールを記述する必要があります。
本ツールは、よくある6つのリダイレクトパターン（個別URL転送・www統一・https強制・ドメイン移行・末尾スラッシュ統一・正規表現による一括転送）を選択するだけで、.htaccessとnginxの両方の設定コードを同時に生成します。さらに、反映前に「このURLはどこに転送されるか」を確認できる動作テスト機能も備えています。
こんなシーンで便利です
サイトリニューアルでURL構成が変わった時に
ページのURLを新しい構成に変更した際、旧URLにアクセスしてきたユーザーや検索エンジンを新URLへ確実に転送したい場合に使えます。
wwwあり・なしやhttpをhttpsに統一したい時に
表記ゆれによる評価の分散を防ぐため、www有無の統一や、httpからhttpsへの常時SSL化を一括で設定したい場合に活用できます。
ドメインを移行する・サイトを引っ越す時に
旧ドメインから新ドメインへサイト全体を移行する際、旧ドメインへのアクセスをすべて新ドメインへ恒久的に転送する設定が必要な場合に使えます。
サーバーの種類が変わった・両対応の設定を残しておきたい時に
Apacheからnginxへ、あるいはその逆へサーバーを移行する予定がある場合に、あらかじめ両方の設定コードを手元に用意しておきたい場合にも便利です。
使い方は簡単 4ステップ
- 追加したいリダイレクトの種類（個別URL転送・www統一・https強制・ドメイン移行・末尾スラッシュ統一・パターン一括転送）を選びます。
- 転送元・転送先のURLやドメイン名、ステータスコード（301/302/307）を入力し、「ルールを追加」で一覧に追加します。
- 必要なだけルールを追加したら、画面下部で「.htaccess（Apache）」と「nginx」のタブを切り替えて生成されたコードを確認します。
- 「動作テスト」欄にテストしたいURLを入力し、意図した通りに転送されるかを反映前に確認してからコピーまたはダウンロードします。
※入力した内容やドメイン名がサーバーに送信されることはなく、すべてブラウザ内の処理だけでコードを生成します。
ご利用時の注意点
- 生成されたコードは一般的な構文に基づく設定例です。ご利用のサーバー環境（バージョンや有効なモジュールなど）によっては、追加の調整が必要になる場合があります。
- 設定を反映する前には、必ず元の.htaccessファイルやnginx設定ファイルのバックアップを取得してください。
- nginxの設定を反映する際は、「nginx -t」コマンドなどで構文エラーがないことを確認してから、サーバーへの反映（reload）を行うことをおすすめします。
- 複数のルールを設定する場合、上から順に評価されるサーバーが多いため、意図しないルールが先に一致していないか、ルールの並び順にも注意してください。
リダイレクトのステータスコード早見表
リダイレクトの種類によって使い分けるべきステータスコードの目安です。
| コード | 名称 | 主な用途 | SEO評価の引き継ぎ |
|---|---|---|---|
| 301 | 恒久的なリダイレクト（Moved Permanently） | ページ移転・ドメイン移行・www統一など、今後ずっとそのURLを使う場合 | 引き継がれる |
| 302 | 一時的なリダイレクト（Found） | キャンペーンページやメンテナンス中など、いずれ元のURLに戻す予定がある場合 | 基本的には引き継がれない |
| 307 | 一時的なリダイレクト（Temporary Redirect） | 302と似た用途だが、POSTなどのリクエストメソッドを維持したい場合 | 基本的には引き継がれない |
※恒久的なURL変更（ドメイン移行、www統一、https化など）では、原則として301を選択することが推奨されています。用途に迷う場合は301を基本として検討してください。
リダイレクト設定で押さえておきたい実務ポイント
設定を反映する前に知っておきたい、SEOと運用面での注意点を解説します。
301と302を混同すると、検索エンジンの評価が引き継がれないことがある
恒久的にURLを変更したにもかかわらず302（一時的なリダイレクト）を設定してしまうと、検索エンジンが「いずれ元のURLに戻る」と判断し、評価が新しいURLに引き継がれない場合があります。
ページの移転やドメイン移行など、今後そのURLを使い続ける設定には必ず301を選ぶようにしましょう。
wwwあり・なし、httpとhttpsの統一はなぜ重要なのか
同じページであっても「www.example.com」と「example.com」、「http://」と「https://」は検索エンジンから見ると別々のURLとして扱われることがあります。
表記が統一されていないと、本来1つのページに集まるはずの評価やリンクが分散してしまうため、301リダイレクトでどちらか一方の表記に一本化しておくことが推奨されます。
ドメイン移行時は「パスを維持したリダイレクト」が原則
サイトを新しいドメインへ移行する際は、トップページだけでなくすべてのページのパス（URLの/以降の部分）を維持したまま新ドメインへ転送するのが原則です。
本ツールの「ドメイン移行」では、パスを維持する設定と、すべてトップページへ転送する設定の両方を選べるため、移行の規模に応じて使い分けてください。
設定を反映した後は、必ず実際にアクセスして動作確認を行う
設定ファイルの記述に誤りがあると、意図しないループが発生したり、サイト全体が表示されなくなったりすることがあります。
反映後は、リダイレクト元・リダイレクト先の両方のURLに実際にアクセスし、想定通りのステータスコードと転送先になっているかをブラウザやオンラインのステータスコード確認ツールで確認することをおすすめします。
よくある失敗と対策
同じURL同士を転送し合い、無限ループが発生してしまう
wwwの統一とドメイン移行のルールを両方設定した際に、条件の書き方が誤っていて転送先が転送元に戻ってしまい、ブラウザに「リダイレクトが多すぎます」といったエラーが表示される失敗です。
💡 対策・解決策を見る▼
一時的なつもりが301で恒久リダイレクトになってしまう
期間限定のキャンペーンページのつもりで301（恒久的なリダイレクト）を設定してしまい、キャンペーン終了後に元のURLへ戻したにもかかわらず、検索エンジンやブラウザに古い転送情報がキャッシュされ続けてしまう失敗です。
💡 対策・解決策を見る▼
mod_rewriteが無効なサーバーで.htaccessの設定が反映されない
生成した.htaccessの内容をそのまま設置したものの、サーバー側でmod_rewriteモジュールが有効になっておらず、リダイレクトがまったく機能しなかった失敗です。
💡 対策・解決策を見る▼
末尾スラッシュの統一を誤り、重複コンテンツとして扱われる
末尾に/が付いたURLと付いていないURLの両方で同じページが表示される状態を放置してしまい、検索エンジンから見て内容が重複した別々のページとして扱われてしまう失敗です。
💡 対策・解決策を見る▼
設定ファイルの記述ミスでサイト全体が表示されなくなる
括弧の閉じ忘れや構文の誤りがある状態のままnginxの設定を反映してしまい、サーバーの再起動に失敗してサイト全体がダウンしてしまう失敗です。
💡 対策・解決策を見る▼
よくある質問（FAQ）
Q.301リダイレクトと302リダイレクトはどちらを使うべきですか
A. 恒久的にURLを変更する場合（ページの移転、ドメイン移行、www統一など）は301（恒久的なリダイレクト）を使用してください。検索エンジンの評価（SEO評価）が新しいURLに引き継がれます。一時的なキャンペーンページやメンテナンス中の一時転送など、いずれ元のURLに戻す予定がある場合は302（一時的なリダイレクト）を使用します。
Q..htaccessの設定はどこに反映すればよいですか
A. Apache（多くのレンタルサーバー）を利用している場合、サイトのルートディレクトリにある「.htaccess」というファイルに生成されたコードを追記します。ファイルが存在しない場合は新規作成してください。反映後は必ずブラウザで実際にアクセスして、意図通りにリダイレクトされるか確認しましょう。
Q.nginxの設定はどこに反映すればよいですか
A. nginxの場合は.htaccessのような分散設定ファイルは使えず、サーバーの設定ファイル（例：/etc/nginx/sites-available/以下のファイルなど）内のserverブロックまたはlocationブロックに追記します。設定変更後は「nginx -t」コマンドで文法チェックを行い、問題がなければ「systemctl reload nginx」などでサーバーへ反映してください。
Q.wwwあり・なしはどちらに統一するべきですか
A. どちらが正解ということはなく、重要なのは表記を1つに統一し、リダイレクトで評価を集約することです。すでに検索エンジンに登録されている表記や、Google Search Consoleに登録済みのプロパティに合わせて統一すると、評価の分散を防ぎやすくなります。
Q.生成した設定を反映する前に確認できることはありますか
A. はい。本ツール内の「動作テスト」機能を使うと、設定を追加する前にテストしたいURLを入力するだけで、どのルールが適用され、最終的にどのURLへリダイレクトされるかをブラウザ上でシミュレーションできます。実際のサーバーに反映する前の確認用としてご活用ください。
Q.入力した内容やドメイン名がサーバーに送信されることはありませんか
A. ありません。本ツールはすべての設定コードの生成・シミュレーションをブラウザ内の処理だけで完結させており、入力したドメイン名やパスが外部に送信されることは一切ありません。
Q.リダイレクトの設定を間違えると、どのような問題が起こりますか
A. 設定内容によっては、無限ループ（同じURL同士が転送し合い続ける状態）が発生してブラウザにエラーが表示されたり、サイト全体が真っ白になったり500エラーになることがあります。反映前に本ツールの動作テストで確認し、実際のサーバーに反映した際は元のファイルを必ずバックアップしてから作業することをおすすめします。
あなたの声で、
このツールをより鋭く。
「こんな機能が欲しい」「ここを直してほしい」といったご意見や、新しいツールのリクエストを募集しています。エンジニアが直接目を通し、開発の参考にさせていただきます。