ドメインリダイレクトが機能しない？ 6つの一般的な原因とその修正方法

ドメインのリダイレクトを設定し、反映（プロパゲーション）を待って、旧URLをテストしたのに何も起きません。ページは同じまま、エラーが出るか、あるいは無限ループします。

リダイレクトの失敗はイライラするだけでなく、時間以上の損失につながります。リダイレクトが壊れているということは、失われるのはトラフィックだけではありません。バックリンクも損なわれ、旧リンクをクリックする人にとっても体験が悪くなります。オーガニック検索に依存するビジネスでは、設定ミスのリダイレクトが、誰も気づくまで静かにSEOの価値を何週間も削ってしまうことがあります。

良いニュースは、リダイレクトの失敗の多くが、原因としてはほんの数パターンに集約されることです。このガイドでは、DNSの問題からサーバー設定ミスまで、それぞれの原因を具体的な診断・修正手順とともに解説します。

#1 DNS がまだ反映されていない

問題： ドメインのDNSレコードをリダイレクトサービスまたは新しいサーバーに向けたのに、訪問者にはまだ旧サイトが表示されます。

起きる理由： DNSの変更はすぐには反映されません。各DNSレコードにはTTL（Time to Live）値があり、通常は300秒（5分）から86,400秒（24時間）です。旧TTLが世界中で期限切れになるまで、インターネット上のDNSリゾルバは古いIPアドレスを引き続き返し続けます。

診断方法：

• •
  ターミナルで dig example.com を実行し、ANSWER セクションを確認してください。表示されるIPは旧ですか、新ですか？
• •
  whatsmydns.net のようなグローバルDNS反映チェックツールを使って、地域ごとの反映状況を確認します
• •
  DNSプロバイダの設定で、ドメインのTTLを確認してください

修正方法：

• •
  DNSの変更を行う前に、TTLを300秒（5分）に下げてください。これにより、伝播（プロパゲーション）の猶予が大幅に短縮されます
• •
  待ってください—標準的なTTLでは、完全な伝播に最大48時間かかることがありますが、通常はずっと早く（数分〜数時間）完了します
• •
  伝播が止まっているように見える場合は、レコードを正しいDNSプロバイダーで更新したか確認してください（必ずしもドメイン登録事業者ではなく、ネームサーバーが向いている先です）

#2 .htaccess の構文エラー

問題： .htaccess ファイルにリダイレクトルールを追加したのに、サーバーが 500 Internal Server Error を返す、ルールを完全に無視する、または誤って適用する。

起きる理由： Apacheの mod_rewrite は強力ですが、融通がききません。スペースの1つの欠落、誤ったフラグ、または競合するルールがあるだけで、設定全体が壊れてしまうことがあります。よくあるミスは次のとおりです：

• •
  ルールブロックの先頭に RewriteEngine On がない
• •
  ターゲットURLで https:// ではなく http:// を使っている
• •
  パターンの先頭スラッシュを付け忘れている
• •
  互いに矛盾するルールが、順序によって上書きされてしまう

診断方法：

• •
  サーバーのエラーログを確認してください。Apacheは構文エラーの正確な行番号を記録します
• •
  一時的に .htaccess の名前を別のものに変更してください。エラーが消えるなら、原因は .htaccess です

修正方法：

• •
  まずは最小限のルールから始め、複雑さを追加する前にテストしてください
• •
  基本的な 301 リダイレクトの正しい構文：

apache
301 リダイレクト /old-page https://example.com/new-page

• •
  mod_rewrite を使った正規表現ベースのリダイレクトの場合：

apache
RewriteEngine On
RewriteRule ^old-path/(.*)$ https://example.com/new-path/$1 [R=301,L]

• •
  サイトが Apache ではなく Nginx で動作している場合、 .htaccess ファイルは完全に無視されます。サーバーブロックの設定にルールを追加する必要があります

#3 リダイレクトチェーンまたはループ

問題：リダイレクトは開始されるものの、目的地に到達しません。ブラウザには「リダイレクトが多すぎます」が表示されるか、ページの読み込みにいつまでも時間がかかります。

なぜ起きるのか：リダイレクトチェーンは、URL A が B にリダイレクトし、B が C にリダイレクトし…というように続くときに発生します。ループは、チェーンが以前の URL に戻ってしまうときに発生します。どちらも、古いリダイレクトと新しいリダイレクトが後片付けなしで重なってしまう、サイト移行の際によく見られます。

診断方法：

• •
  Chrome DevTools →［Network］タブ → ページを再読み込み— 3xx のリクエストチェーンを確認します
• •
  チェーン内に同じ URL が 2 回表示される場合、それはループです
• •
  リダイレクトチェッカー（redirectcheck.com など）を使って、チェーン全体を可視化します

修正方法：

• •
  現在有効なすべてのリダイレクトルールを洗い出してください。 .htaccess、CMS プラグイン、CDN のエッジルール、そしてリダイレクト管理ツールにあるものを含めます
• •
  不要になった中間ルールを削除します。チェーンを1つの直接リダイレクトに統合します（A → D ではなく A → B → C → D）
• •
  WordPressを使用している場合は、すべての有効なプラグインを確認してください。キャッシュ系プラグイン、SEOプラグイン、セキュリティプラグインはいずれも競合するリダイレクトルールを追加する可能性があります

#4 キャッシュの幽霊

問題： リダイレクトを更新または削除したのに、訪問者は依然として古い行き先にリダイレクトされます。

なぜ起きるのか： ブラウザ、CDNのエッジノード、そしてサーバーレベルのキャッシュは、301リダイレクトを積極的にキャッシュします。ブラウザが301を一度確認すると、たとえ変更した後でも、そのリダイレクトを無期限に記憶してしまうことがあります。同様に、CloudflareのようなCDNキャッシュも、エッジノードから古いリダイレクト応答を返す場合があります。

診断方法：

• •
  ページをシークレット／プライベートウィンドウで開きます。そこで正しく動作するなら、問題はブラウザキャッシュです
• •
  ブラウザの影響を受けずに実際のサーバー応答ヘッダーを確認するには、 curl -I https://example.com/old-page を使用します
• •
  レスポンス内の Cache-Control と Age ヘッダーを確認します

対処方法：

• •
  ブラウザのキャッシュをクリアしてください（Chrome: 設定 → プライバシー → 閲覧データを消去 → キャッシュされた画像とファイル）
• •
  CDNキャッシュをパージしてください（Cloudflare: ダッシュボード → キャッシュ → すべて削除 または 単一URLのパージ）
• •
  今後のリダイレクトでは、テスト中は302（一時）を使用し、その後、目的地が正しいと確信できたときだけ301（恒久）に切り替えてください
• •
  明示的なキャッシュヘッダーを追加： 期待される変更があるリダイレクトには Cache-Control: no-cache, max-age=0

#5 混在するHTTP/HTTPSの問題

問題： リダイレクト先はHTTPSを使用しているのに、リダイレクトがHTTP版へ送信している（またはその逆）ためです。訪問者は証明書の警告、または表示できないページを目にします。

なぜ起きるのか： これは見落とされがちなリダイレクト失敗パターンの1つです。 http://old-domain.com から http://new-domain.com へリダイレクトを設定したものの、新しいドメインがHSTSによってHTTPSを強制している場合があります。ブラウザは1回リダイレクトした直後に、すぐにHTTPSへ再リダイレクトされます。あるいはさらに悪いことに、古いドメインのHTTPS版で期限切れ、または一致しない証明書が使われていることがあります。

診断方法：

• •
  ソースURLの http:// 版と https:// 版の両方を確認する
• •
  ブラウザのコンソールで混在コンテンツの警告を探す
• •
  HSTSが有効化されているか確認（レスポンスヘッダーの Strict-Transport-Security を確認）

修正方法：

• •
  常に完全なHTTPS URLへリダイレクトする： https://new-domain.com/page のように、単に new-domain.com/page ではなく
• •
  チェーン内のすべてのドメインに有効なSSL証明書がインストールされていることを確認する
• •
  古いドメインからリダイレクトする場合は、古いドメインにもSSL対応があることを確認する — たとえリダイレクトのみを提供している場合でも
• •
  リダイレクトルール全体で単一の正規プロトコルを使用する（常にHTTPS）

#6 誤ったリダイレクト種別

問題： リダイレクトは機能していますが、検索エンジンがリンクエクイティを引き継いでいない、または訪問者が目的地を適切にブックマークできない。

起きる理由： 異なるHTTPステータスコードが、ブラウザと検索エンジンにリダイレクトについて異なる意味を伝えるため：

• •
  301（Moved Permanently：恒久的に移動）： ほとんどのリンクエクイティを引き継ぐ。ドメイン変更やリストラクチャリングなどの恒久的な移動に使用する
• •
  302（Found）：リンクエクイティを引き継ぎません。A/Bテストや季節限定のランディングページなど、仮リダイレクトのみに使用してください
• •
  307（Temporary Redirect）：302と似ていますが、HTTPメソッドを保持します。仮のAPIリダイレクトに使用されます
• •
  メタリフレッシュ：HTMLベースのリダイレクト（HTTPではありません）。遅く、リンクエクイティを失い、ユーザー体験も悪くなります

診断方法：

• •
  curl -I https://example.com/old-page でレスポンスのステータスコードを確認する
• •
  レスポンスの最初の行で、Locationヘッダーと3xxのステータスコードを探す

修正方法：

• •
  恒久的なリダイレクトにはすべて301を使用する — ドメイン移転、URL構造の変更、ページ削除
• •
  本当に一時的なリダイレクトにのみ、302または307を使用する（プロモーション、メンテナンスページ、A/Bテスト）
• •
  SEO上重要なリダイレクトにメタリフレッシュ（<meta http-equiv="refresh">）を決して使わない — 代わりに適切なHTTPリダイレクトを使用する
• •
  どの種類を使うべきか迷った場合は、まず301を選んでください。後から302を301に変更しても問題ありませんが、恒久的な移動に302を使うとSEOの価値が失われます

リダイレクト失敗を防ぐ方法

リダイレクトの問題に対する診断と修正のサイクルは時間がかかります。最初から多くの問題を回避する方法は以下のとおりです。

• •
  公開前にcurlでテストする： URL変更を告知する前に、curl -IL https://source-url.com を実行して完全なリダイレクトチェーンを確認してください
• •
  リダイレクトの対応表を作成する： すべてのリダイレクトルールを記録してください。移行や構成変更を行う際は、対応表を更新します。これにより、意図しないチェーンや孤立したルールを防げます
• •
  専用のリダイレクト管理プラットフォームを使う： .htaccess、WordPressプラグイン、サーバー設定ファイルでリダイレクトを管理することは機能しますが、いつかは破綻します。リダイレクトが数十〜数百件になると、手作業の方法ではミスが増えます。専用プラットフォームなら、リダイレクトチェーンの視覚的なデバッグ、HTTPSの自動対応、リダイレクト通信の分析、大量のインポート／エクスポート、変更を追跡する監査ログが利用できます。
• •
  DNS変更の前に低いTTLを設定する： 予定しているDNS更新の少なくとも24時間前に、TTLを300秒に下げてください
• •
  ステージング環境でテストする： リダイレクトの変更を本番環境に直接デプロイする前に、完全な経路をテストすることなく行わないでください

RedirHubのアプローチ：当てずっぽうをやめる

このガイドにあるあらゆる原因――DNSの遅延、.htaccessのエラー、リダイレクトチェーン、キャッシュの“幽霊”、SSLの不一致、誤ったステータスコード――はすべて、そこに行き着きます。つまり、それに対応するように作られていないインフラでリダイレクトを管理していることです。

RedirHub はエッジでリダイレクトを処理し、Web サーバーや DNS 設定とは切り離します。つまり、壊れる可能性のある .htaccess ファイルは不要、ルールを追加してもサーバー再起動は不要、TTL やキャッシュの幽霊（ゴースト）を気にする必要もありません。すべてのリダイレクトは、視覚的なダッシュボードで管理され、即時反映、自動 HTTPS、内蔵分析、そして大規模移行向けの一括インポートに対応しています。

このガイドで挙げた各課題を、RedirHub がどう解消するかはこちら：

• •
  DNS の伝播—RedirHub は CNAME ベースのセットアップを使用します。A レコードの変更は不要です。リダイレクトは数秒で世界中に反映され、数時間ではありません。
• •
  .htaccess エラー—編集するサーバー設定ファイルはありません。すべてのルールは視覚的なインターフェースで管理され、バリデーション（検証）が組み込まれています。構文が間違っていれば、ルールが公開される前に UI が教えてくれます。
• •
  リダイレクトチェーン—ダッシュボードには、すべてのルールの完全な経路が表示されます。ワンクリックでチェーンを確認し、解消できます。ループがどこから始まるのかを推測する必要はもうありません。
• •
  キャッシュの幽霊—RedirHub はデフォルトで最適なキャッシュヘッダーを設定します。リダイレクトを更新すると、その変更はエッジですぐに反映されます。ブラウザのキャッシュ削除は不要です。
• •
  HTTPS の問題—すべてのリダイレクトで自動 SSL。手動の証明書設定は不要で、混在コンテンツによる驚きもありません。
• •
  誤ったステータスコード—インターフェースでルールごとに 301、302、307 を設定できます。設定するための生ヘッダーは不要です。

サイトを前に進める代わりにリダイレクトのデバッグに時間を費やしているなら、それはセットアップが適切でないサインです。目的に合わせて作られたリダイレクト基盤により、インフラ面の摩擦がなくなり、仕組みではなく移行に集中できます。

クイック参照チェックリスト

まだ解決できていませんか？ 問題がインフラレベルにある場合もあります。たとえば、CDNのルールが競合している、サーバー側の書き換えがアプリケーション側のルールを上書きしている、またはレジストリレベルでDNS設定が適切でないなどです。このチェックリストをすべて確認してもリダイレクトがまだ機能しない場合は、視覚的なリダイレクト診断ツールを使うことで、各ホップで何が起きているのかを正確に確認できます。