ワイルドカードリダイレクト: 仕組みと設定方法

ワイルドカードリダイレクトとは、パターンに一致する多数の URL を 1 つのルールで受け取り、別の場所へ送るものです。4,000 個もの古いアドレスを 1 つずつ列挙する代わりに、「/blog/ 配下はすべて新しいドメインの同じパスへ送る」といったルールを書けば、あとはサーバーが処理します。このガイドでは、混同されがちな 2 つの意味（DNS のワイルドカードと HTTP リダイレクト）、Apache と NGINX での実用的なパターン、順位を落とす SEO の失敗、そして管理されたリダイレクト層のほうがよい場合について扱います。

ワイルドカードリダイレクトとは実際に何か#

「ワイルドカード」という言葉は 3 つの異なるものを指し、検索結果ではそれらが混ざって使われがちです。

ワイルドカード（パターン）リダイレクト。 プレースホルダーを含むルールです。そのプレースホルダーは、「この位置より後の任意の文字列」（プレフィックス一致）、「この位置より前の任意の文字列」（サフィックス一致）、または宛先で再利用されるキャプチャ部分を表せます。典型例: /old-blog/* を /blog/* へ、または *.olddomain.com を newdomain.com へ。

ワイルドカード DNS レコード。 左端のラベルにアスタリスクを含むレコード、たとえば *.example.com は、自身のレコードを持たないサブドメインへの問い合わせに応答します。AWS はレコード名におけるアスタリスクの扱いを説明しています^[1]。このトピックで重要なのは、DNS が決めるのはどのサーバーが応答するかだけだという点です。リダイレクト自体は HTTP の操作であり、DNS 解決の後、リクエストを受け取ったサーバー上で行われます。

レジストリレベルでのワイルドカード禁止。 3 つ目の用法はトップレベルドメインのレジストリに関するものです。運営者は、存在しないドメインに対して生成した応答を返すことを禁じられています。これはレジストリに対するルールであり、自分のサイトで設定するものではありません。

そのため、サブドメインの完全なワイルドカード設定には通常、2 層が必要です。すべてのサブドメインをサーバーに到達させるためのワイルドカード DNS レコードと、各リクエストの行き先を決めるサーバー側ルールです。

実際に使うパターン#

ほとんどの実際のニーズは6つのパターンに当てはまります。

最初の2行の違いが、最も重要な点です。パスを保持すると1対1の関連性が保たれ、これは新しいサイトが古いサイトをそのまま反映している場合に望ましいことです。パスを省略するのが適切なのは、対応するページが存在しない場合だけです。

Apache のワイルドカードリダイレクト（.htaccess）#

よくある質問は、.htaccess を使って特定のパス以降をまとめてリダイレクトする方法です。Apache では、それは mod_rewrite の役割です。Apache mod_rewrite のドキュメント^[2] には RewriteRule と、それに付随するフラグが説明されており、リダイレクトには R が含まれます。

パスの残りを保持するプレフィックスリダイレクト:

<code class="language-apache">RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]
</code>

カッコは old-section/ の後ろのすべてをキャプチャし、$1 がそれを転送先に挿入します。L はそれ以降のルール処理を停止し、意図しない二重マッチを防ぎます。

パスとクエリ文字列を保持するドメイン全体のリダイレクト:

<code class="language-apache">RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
</code>

人がつまずきやすい点がいくつかあります:

• 順序が重要です。 ルールは上から下へ実行されます。一般的なルールよりも具体的なルールを上に置きましょう。そうしないと、包括的なルールがすべてを飲み込んでしまいます。
• ドットはエスケープします。 正規表現内のエスケープされていない . は任意の文字にマッチします。
• まず 302 でテストしてください。 ブラウザは 301 を強力にキャッシュします。テスト中は R=302 を使い、ルールが期待どおりに動作したら 301 に切り替えてください。
• サーバーに注意してください。 .htaccess は Apache でのみ機能します。ホストが NGINX を使っている場合、このファイルは無視されます。

NGINX のワイルドカードリダイレクト#

NGINX はホスト名を server_name で扱います。NGINX ウェブサーバーガイド^[3] では、サーバー名は完全一致名、先頭または末尾にアスタリスクを付けたワイルドカード、または正規表現にでき、複数一致する場合は完全一致名がワイルドカードより優先されると説明されています。

古いドメインのすべてのサブドメインを新しいドメインにリダイレクトする:

<code class="language-nginx">server {
    listen 80;
    server_name .old-domain.com;
    return 301 https://new-domain.com$request_uri;
}
</code>

先頭のドットは old-domain.com と任意のサブドメインの両方に一致します。$request_uri は元のパスとクエリ文字列を保持するため、深いリンクも維持されます。

サイト内のパスプレフィックスの場合:

<code class="language-nginx">location ~ ^/old-section/(.*)$ {
    return 301 /new-section/$1;
}
</code>

シンプルなリダイレクトでは return を rewrite より優先してください。こちらのほうが分かりやすく、評価コストも低くなります。

ステータスコードの選択#

返すコードによって、ブラウザと検索エンジンがこの移動をどう扱うかが決まります。

• 301（恒久的に移動）と308（恒久的リダイレクト）は、リソースに新しい恒久的なアドレスがあることを示します。301 の MDN リファレンス^[4]では、ブラウザがLocationヘッダーに従って自動的に遷移することが説明されています。
• 302 と 307は一時的です。A/B テスト、短期間のキャンペーン、メンテナンスページに使用します。

Google のガイダンスでは、恒久的なリダイレクトは重複 URL の統合を助け、新しい URL がインデックスされるべきであることを示す^[5]一方、一時的なリダイレクトは元のページのインデックス優先度を維持します。変更が長期にわたる場合は、恒久的なコードを使います。移行後もワイルドカードルールが 302 のまま残っているのは、目立たない一般的なミスです。

RedirHub のトラフィックが示す恒久的コードと一時的コード#

2026年10月22日に RedirHub のエッジが処理したリダイレクト要求の6時間分のサンプルでは、42.2% がボットからのものでした。人間からの要求では、82.3% が 301 または 308、1.3% が 302 または 307、エラー（4xx または 5xx）は 0.03% 未満でした。

恒久的コードが大多数を占めているため、移行後も一時的コードのまま残っているワイルドカードルールは、監査すべき例外として際立ちます。これらの割合は人間の分のみを数え（ボットは除外）、アンケートではなくリダイレクトのアクセスログに基づき、特定の大口顧客による偏りを避けるために非常に大きなアカウントは除外されています。RedirHub では、301、302、307、308 のドメインリダイレクトは Core、Pro、Enterprise に含まれ、ワイルドカードのサブドメインリダイレクトはPro と Enterprise のみに含まれます。

ワイルドカードルールが招きやすいSEOのミス#

1つのルールが何千ものURLに作用するため、たった1つの誤ったルールで何千ものページが一度に損なわれます。

すべてをホームページへ送る#

安易な包括ルールである/* から /は見た目はすっきりしますが、関連性を失わせます。特定のガイドへのリンクをクリックした訪問者は汎用的なホームページに着地し、そのまま離脱してしまいます。検索エンジンも、無関係なページへの大量リダイレクトをソフト404として扱うことがあります。できるだけ近い等価ページへリダイレクトし、等価ページが存在しない場合にのみ、より広い親カテゴリを使ってください。

チェーンを作ってしまう#

たとえば、http://old.com/pageがhttps://old.com/pageへリダイレクトし、それがhttps://www.old.com/pageへ、さらにhttps://new.com/pageへリダイレクトするとします。これで3回の遷移です。Googleのドキュメントでは、Googlebotは限られた回数の遷移をたどれること、そしてチェーンは遅延を増やしてインデックス作成を遅らせるため直接リダイレクトが推奨される^[5]と述べています。ルールは、最初の応答でプロトコル、ホスト、パスをすべて一度に修正し、最終URLを直接指すように書いてください。

クエリ文字列とフラグメントを忘れる#

UTMタグのようなキャンペーンパラメータは、古いリンクに付随していることがよくあります。ルールがクエリ文字列を必要な形で保持するか確認してください。Apacheでは、絶対URLへのリダイレクトは、別途指定しない限り元のクエリ文字列も引き継がれます。Apacheのドキュメントにあるとおりです。NGINXでは、$request_uriにはそれが含まれますが、$uriには含まれません。

wwwありとwwwなしを混同する#

正規のホストを1つ選び、もう一方をそこへリダイレクトしてください。Googleの重複URLを統合するためのガイダンス^[6]では、リダイレクトは優先バージョンを示す強いシグナルとして挙げられています。どちらを選んでも構いませんが、一貫していることが大切です。手順が必要なら、wwwなしからwwwへのリダイレクトに関するメモをご覧ください。

ルールを早く外しすぎる#

Google は、リダイレクトは絶対的な命令ではなく正規化のシグナルとして扱われる場合があり、正規化に関するドキュメント^[7]で説明しているように、他の要因に基づいて別の正規 URL を選ぶこともあると述べています。実務上は、恒久的なリダイレクトは移転後少なくとも 1 年は維持し、外部リンクをまだ獲得している URL についてはさらに長く維持してください。

ワイルドカード移行の安全な手順#

1. 旧 URL を棚卸しする。 サイトマップ、サーバーログ、アナリティクス、クロールから取得します。Google の サイト移転に関するドキュメント^[8] では、すべての旧 URL を新しい移転先に対応付けることが重要だと強調しています。
2. パターンごとにまとめる。 ほとんどのサイトは、少数のワイルドカードルールと、より少ない個別例外に集約できます。
3. 例外を先に記述する。 個別のマッピングはワイルドカードルールより上に置き、優先されるようにします。
4. 実際の URL でテストする。 かなり変わったものも含め、数百件の旧 URL をサンプルとして実行し、ステータスコード、最終到達先、リダイレクト回数を確認します。リダイレクトチェッカー を使うと、単一の URL に対する各ホップとステータスコードを確認できます。
5. 恒久コードで公開する。 テストが通ったら、302 から 301 に切り替えます。
6. 監視する。 数週間にわたって、クロールエラー、404、セクション別のトラフィックを監視します。旧ルールを急いで編集するのではなく、新しいルールで不足分を修正します。

Google はまた、大規模サイトは効果をテストするためにセクションごとに移行できる一方、小規模サイトは一度にすべて移行したほうがうまくいくことが多いと指摘しています。ドメイン側の計画については、当社の SEO ドメイン変更ガイド で、切り替え前後に確認すべき項目を解説しています。

サーバーファイルが実用的でなくなるとき#

.htaccess や NGINX の設定を編集するのは、自分で管理している1つのサイトなら問題ありません。次のような場合には厄介になります:

• 何十ものドメインを所有しており、使われていないもの、旧サイトのもの、キャンペーン用に購入したものが混在している。
• マーケティングが遷移先を変更したいのに、その変更には開発者とデプロイが必要になる。
• あなたのサイトがサーバー設定にアクセスできないプラットフォーム上で動いている。
• リダイレクトルールが4か所（CMS、CDN、サーバー、レジストラ）に存在し、どれが優先されるのか誰も分からない。

順序も重要です。MDNの説明によると^[9]、リダイレクトはサーバーが Location ヘッダー付きの 3xx レスポンスを送ることで発生するため、ページの内容が送信される前に起こります。JavaScript やメタリフレッシュのようなクライアント側の手法は、サーバー層に届かないときの最終手段です。専用のリダイレクト層があれば、サーバーアクセスを必要とせずに適切な層で運用できます。

サーバー層を離れることで失うもう一つのものは速度で、その差は小さいです。RedirHub の最初のバイトまでの時間の中央値は 18 ms で、26社の中で最速の 11 ms と比べた場合の差です。これはワシントンD.C.、フランクフルト、東京から測定されたものです（RedirHub リダイレクト速度ベンチマーク、2026年10月18日〜25日^[10]）。

私たちの見解#

私たちが目にするリダイレクトの問題の大半は、構文の問題ではありません。所有権の問題です。ルールはプロジェクトに関わっていた誰かによって一度だけ書かれ、設定ファイルの中に置かれたまま、数年後にはなぜ /promo/* がその行き先を指しているのか誰も覚えていません。やがてドメインの期限が切れ、印刷されたパンフレットやQRコードが人々を死んだページへ送り続け、修正にはチケットが必要になります。

私たちは、リンクとリダイレクトは自分のドメイン上に置き、自分で管理でき、SSL は代行されるべきであり、共有短縮URLサービスや大量のサーバーファイルに依存すべきではない、という考えのもとで RedirHub を構築しました。ワイルドカードルールについての私たちの助言は、どのツールを使う場合でも同じです。目的を果たすうえで最も狭いパターンを書き、最終URLに直接向け、例外の一覧を保ち、定期的にルールを見直してください。リダイレクトは長期的な資産として扱いましょう。世に出たリンクは、今のサイトデザインよりも長生きするからです。

設定ファイルなしでワイルドカードとドメインのリダイレクトを管理する#

RedirHub を使えば、自分のドメイン上で ドメインリダイレクトとブランドリンク を、SSL と分析機能付きで管理でき、印刷物に手を加えることなく遷移先を変更できます。サイト移行を行う場合は、ウェブサイト移行サービス と SEO 移行向けの 301 リダイレクトサービス がそのために用意されています。料金は 価格ページ に掲載されています。Core は月額 49 ドル、Pro は月額 119 ドルです。Enterprise は契約により決定されます。ワイルドカードのサブドメインリダイレクト（キャッチオールのサブドメインリダイレクト）は Pro と Enterprise のみで利用でき、ドメインリダイレクト、パス転送、クエリパラメータ転送は Core、Pro、Enterprise で利用できます。

クイックリファレンス: ワイルドカード DNS とワイルドカードリダイレクトの違い#

マルチドメイン構成に関するもう1つのDNSの注意点があります。CNAMEはゾーンの頂点（裸のexample.com）には置けませんが、エイリアス形式のレコードを提供しているプロバイダーもあります。AWSはこれをエイリアスレコードと非エイリアスレコードの比較^[11]で説明しています。裸のドメインをリダイレクトサービスに向ける場合は、DNSプロバイダーが頂点でどのレコードタイプをサポートしているか確認してください。

実例: 3つのサブドメインを伴うブランド変更#

acme-tools.comからacme.comへ移行する会社を想像してください。ブログ、help.acme-tools.com上のサポートサイト、そしてuk.acme-tools.comのような地域別サブドメインがいくつかあります。

きれいな計画は次のようになります:

1. 古いドメインにワイルドカード DNS レコードを追加して、誰も覚えていないものを含むすべてのサブドメインがリダイレクト層に到達するようにします。
2. まず明示的なルールを作成します: help.acme-tools.com/* を support.acme.com/* に、uk.acme-tools.com/* を acme.com/uk/* に。
3. 一般的なルールを追加します: *.acme-tools.com/* を acme.com/* に、フォールバックとして。
4. ルートのルールを追加します: acme-tools.com/* を acme.com/* に。
5. これらすべてに対して 301 を返し、宛先には HTTPS を使って 1 回の遷移にします。
6. サイトマップと分析から 200 個の古い URL をテストし、1 週間後にもう一度確認します。

明示的なルールは構造の異なるセクションを保護し、フォールバックは取りこぼしを拾います。順序がなければ、フォールバックがサポートサイトをメインドメインのパスに平坦化してしまい、どこにも一致しなくなります。