ドメイン転送（リダイレクト）完全ガイド：301設定・HTTPS対応・SEO移行チェックリスト

2025年11月18日 最終更新日時 : 2025年11月18日 エバープレイ編集部

ドメイン転送設定とは — 概要と基本の仕組み

ドメイン転送（ドメインリダイレクト、URL転送）とは、あるドメイン名で受けたリクエストを別のURLへ自動的に誘導（転送）する仕組みです。ユーザーのブラウザや検索エンジンが元のURLにアクセスした際に、HTTP ステータスコードやブラウザの命令で新しい場所へ移動させます。一般に「ドメイン転送」と呼ぶ場合、ドメイン単位で転送する（例：example-old.com → example-new.com）ことを指しますが、パスを維持するか否か、クエリ文字列を引き継ぐかなど、細かい挙動は設定によって異なります。

主な転送方式と違い

  • HTTPリダイレクト（サーバ側） — 301（恒久）、302（一時）、303、307 などのステータスコードを返し、Location ヘッダで新URLを指示。SEO・ブラウザの挙動に応じた正確な制御が可能。

  • DNSレベルの"転送"（実際はできない） — DNS 自体は名前解決を行うのみで、HTTP ステータスやパスの転送は扱えません。DNSで行えるのはA/CNAME/ALIASなどの名前解決とホスティング先の切替です。よく混同されますが、真のHTTP転送はDNS単体では実現できません。

  • Registrar（レジストラ）提供のURLフォワーディング — レジストラが用意する転送サービスを使うと、ユーザーはコントロールパネルから簡易に転送を設定できます。内部的にはレジストラのサーバでHTTPリダイレクトを返します。

  • マスキング/フレーム転送（URLマスク） — 元のドメインをブラウザに残しつつ、iframe等で別ドメインの内容を表示する方式。見た目は元のURLのままですが、SEOやセキュリティ、ブラウザ互換性で問題が多いため推奨されません。

  • プロキシ転送（リバースプロキシ） — NginxやCloudflare Workers等でリクエストを別サーバに中継。URL欄は元のまま中身を別のホストから供給する場合に使われますが、SSLやCookie、CORSの取扱いに注意が必要です。

よく使われるHTTPステータスコードの意味と推奨

  • 301（Moved Permanently） — 恒久的な移転。検索エンジンは通常インデックスを新URLへ移す。ドメイン変更や恒久的なURL正規化に推奨。

  • 302（Found） / 307（Temporary Redirect） — 一時的な移転。302は歴史的な扱いの差異があるため、HTTPメソッドの保持を厳密にしたい場合は307を使う。

  • 303（See Other） — POST後にGETで別リソースを示す等、特定の用途向け。

設定方法の種類（実例と注意点）

転送設定は主に次の方法で行います。いずれでも「HTTPS対応」と「パス／クエリの引き継ぎ」などの要件を意識してください。

  • Webサーバ（Apache / Nginx / IIS）でのリダイレクト

    Apache .htaccess 例（301、全てのトラフィックを新ドメインへ転送、パス維持）:

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

    Nginx 例:

    server {
    listen 80;
    server_name example-old.com www.example-old.com;
    return 301 https://example-new.com$request_uri;
}

    注意：HTTPSからの転送が必要な場合は、元ドメイン側でTLS証明書が必要です（またはロードバランサ／CDNでハンドリング）。

  • レジストラの転送機能を使う

    管理画面で転送先を指定するだけで簡単に設定できます。ただし、レジストラの実装によってはHTTPSサポートやパスの自動引き継ぎ、ステータスコードの選択が限定されることがあります。

  • CDN / エッジサービス（Cloudflare等）のルール

    CloudflareのPage RulesやWorkersを使えば、エッジで高速にリダイレクトを処理できます。SSL終端やHTTPヘッダの最適化も可能。

  • DNSの代替（ALIAS/ANAME）について

    ルート（apex）ドメインでCNAMEを使えない環境では、ALIAS/ANAMEで別ホストを参照する仕組みが使えますが、これは名前解決での代替でありHTTPリダイレクトとは別物です。

SEOとユーザー体験に関する注意点

  • 301を使う場面 — ドメイン移転や正規化（www有無統一）など恒久的な移行では301が原則。検索エンジンはリンク価値を新URLに転送しますが、完全に即時ではない場合があります。

  • 転送チェーンとループを避ける — 複数のリダイレクトが連なるとページ表示が遅くなり、検索エンジン評価やクロール予算に悪影響。ループは致命的なので設定検証を必ず行う。

  • パス・クエリの扱い — パスやクエリを保持すべきかを設計段階で決める。ECサイトやパラメータ依存のページでは誤ったリダイレクトでリンク切れを起こす可能性があります。

  • SSL（HTTPS）に関する考慮 — 元ドメインでHTTPSアクセスがある場合、TLS証明書が無いとブラウザが先に警告を出すため、HTTPS用の証明書を配置するか、エッジで完結する手段を使う。

  • Canonical と併用 — 重複コンテンツ対策や検索エンジンの指示を明確にするため、必要に応じて rel="canonical" を適切に設定する。

実務的なチェックリスト（移行時・設定時）

  • 目的（恒久/一時）を明確にして適切なステータスコードを選ぶ（301 vs 302/307）。

  • パス・クエリの保持方針を決め、設定で正しく反映されているか確認。

  • HTTPS対応の有無を確認。必要なら証明書を取得して更新する。

  • 転送後のレスポンスヘッダ（Location, Cache-Control 等）を検査する。

  • Google Search Console 等で移行を通知し、サイトマップや内部リンクの更新を行う。

  • リダイレクトチェッカーやcurl 等で挙動（ステータスコード、チェーン長）を検証する。

よくある誤解と落とし穴

  • 「DNSでリダイレクトできる」 — DNSは名前解決のみ。HTTPリダイレクトは別の仕組みが必要。

  • 「CNAMEでルートドメインを別に向ければ良い」 — 多くのDNS仕様ではルートにCNAMEを置けない。代替としてALIAS/ANAMEやAレコードを使うことになる。

  • 「マスキングはSEOに安全」 — iframe等でURLを隠すマスキングはSEO評価やブラウザ挙動で不利。可能な限り正しいHTTPリダイレクトを使うべき。

まとめ

ドメイン転送設定は見た目は単純でも、HTTPステータス、SSL、DNSの制約、SEO影響、パスやクエリの取り扱いなど複数の要素が絡むため、要件に合わせた設計と検証が重要です。恒久的な移転では301を基本に、HTTPS対応や転送チェーンの最小化、サーチコンソール等での移行通知を忘れず行ってください。特にビジネス用途では、転送の選択が検索順位やアクセス解析に大きく影響することがあります。

参考文献

カテゴリー
IT
前の記事
.htaccessリダイレクト完全ガイド：301/302の使い分け・WordPress対応と実践設定例New!!
2025年11月18日
次の記事
フィルハーモニア管弦楽団（Philharmonia Orchestra）完全ガイド：録音で聴く名盤と選び方New!!
2025年11月18日