301リダイレクトが機能しない？ 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 を確認する

修正方法：

• 予定変更の前に TTL を下げ、まず以前の TTL が期限切れになるのを待ちます。リゾルバーが古いレコードをキャッシュした後に TTL を下げても、その既存のキャッシュエントリは短くなりません。
• 権威 DNS の応答と再帰リゾルバーからの応答を比較します。タイミングは以前の TTL とプロバイダーによって異なります。一定時間待つだけでは、レコードが正しいことの証明にはなりません。
• 伝播が止まっているように見える場合は、正しい DNS プロバイダーでレコードを更新したか確認してください（ネームサーバーが向いている先であり、必ずしもドメイン登録業者ではありません）

#2 .htaccess の構文エラー#

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

なぜ起こるのか： Apache の mod_rewrite は強力ですが、容赦がありません。スペースの欠落、フラグの誤り、競合するルールが 1 つあるだけで、設定全体が壊れることがあります。よくあるミスには次のようなものがあります：

• ルールブロックの先頭に RewriteEngine On がない
• ターゲットURLで http:// の代わりに https:// を使用している
• 使用しているディレクティブの構文を確認してください。ディレクトリ単位の .htaccess RewriteRule パターンでは、Apache は先頭のスラッシュを削除します。ほかのコンテキストのルールは異なる動作をする場合があります。
• 順序のために互いに上書きし合う競合するルール

診断方法:

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

修正方法:

• 最小限のルールから始め、複雑にする前にテストする
• 基本的な301リダイレクトの正しい構文:

apacheRedirect 301 /old-page https://example.com/new-page

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

apacheRewriteEngine 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 回現れる場合、それはループです
• URL を当社の リダイレクト速度テスト に入力すると、すべての遷移先、そのステータスコード、最終的な到達先を確認できます

修正方法:

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

#4 キャッシュの残像#

問題: リダイレクトを更新または削除したのに、訪問者はいまだに古い転送先へリダイレクトされます。

なぜ起こるのか: ブラウザ、CDNのエッジノード、サーバーレベルのキャッシュは、301リダイレクトを強力にキャッシュします。ブラウザが一度301を見つけると、そのリダイレクトを永久に記憶することがあります。変更後でも同様です。CloudflareのようなCDNキャッシュにも同じことが当てはまり、エッジノードから古いリダイレクト応答が返される場合があります。

診断方法:

• プライベートウィンドウでの結果、通常のセッション、コマンドラインからのリクエストを比較してください。違いがあればブラウザの状態またはキャッシュを示唆しますが、それだけで完全な診断にはなりません。
• curl -I https://example.com/old-page を使って、ブラウザの影響を受けずに実際のサーバー応答ヘッダーを確認します
• 応答の Cache-Control と Age ヘッダーを確認してください

対処方法:

• ブラウザのキャッシュされた画像とファイルを削除するか、プライベートウィンドウで引き続きテストしてください
• 古いURLに対するCDNのキャッシュをパージしてください。ほとんどのCDNでは単一のURLをパージできます
• 今後のリダイレクトでは、テスト中は 302（一時的）を使用し、遷移先が正しいと確信できた時点でのみ 301（恒久的）に切り替えてください
• 明示的なキャッシュヘッダーを追加します: Cache-Control: no-cache, max-age=0 変更が想定されるリダイレクト向け

#5 HTTP/HTTPS の混在による問題#

問題: リダイレクト先は HTTPS を使用しているのに、リダイレクトはトラフィックを HTTP 版へ送っている、またはその逆です。訪問者には証明書の警告、または壊れたページが表示されます。

なぜ起こるのか: これは見落とされがちなリダイレクト失敗の一つです。http://old-domain.com から http://new-domain.com へのリダイレクトを設定したのに、新しいドメインは HSTS により HTTPS を強制しています。ブラウザは一度リダイレクトされたあと、すぐに 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（恒久的に移動）: ほとんどのリンク評価を引き継ぎます。ドメイン変更やサイト構造の再編成など、恒久的な移動に使用します
• 302（見つかりました）: 一時的。Google は通常、古い URL をインデックスに残すため、ランキングシグナルもそこに維持されます。A/B テストや季節限定のランディングページなど、一時的なリダイレクトにのみ使用してください
• 307（一時的リダイレクト）: 302 に似ていますが、HTTP メソッドを保持します。一時的な API リダイレクトに使用されます
• メタリフレッシュ: HTTP ではなく HTML のリダイレクトです。Google は即時（0秒）のメタリフレッシュを恒久的、一方で遅延のあるものを一時的と見なしますが、これはページが読み込まれた後にしか機能しないため、可能であればサーバー側のリダイレクトを使用してください

診断方法:

• curl -I https://example.com/old-page を使ってレスポンスのステータスコードを確認します
• レスポンスの先頭行にある Location ヘッダーと 3xx ステータスコードを探します

修正方法:

• 関連する代替先への恒久的な移動には 301 または 308 を使用します。ページが削除され、適切な代替先がない場合は、無関係なリダイレクトの代わりに 404 または 410 が適切なことがあります。
• 302 または 307 は、本当に一時的なリダイレクト（プロモーション、メンテナンスページ、A/B テスト）にのみ使用してください
• 重要な URL にはメタリフレッシュ（<meta http-equiv="refresh">）を避け、代わりに実際の HTTP 301 を使用してください
• 移動が恒久的か一時的かに応じてステータスを選び、その後で動作を確認してください。すべての一時的なレスポンスが SEO 価値の固定的な損失を引き起こすと決めつけないでください。

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

リダイレクトの問題の診断と修正のサイクルは時間がかかります。以下の方法で、事前にその大半を回避しましょう:

• 公開前に curl でテストする: URL 変更を告知する前に、curl -IL https://source-url.com を実行して、完全なリダイレクトチェーンを確認してください
• リダイレクトマップを維持する: すべてのリダイレクトルールを文書化してください。移行や再構成を行う際は、マップを更新します。これにより、意図しないチェーンや孤立したルールを防げます
• 専用のリダイレクト管理プラットフォームを使用する: .htaccess、WordPress プラグイン、またはサーバー設定ファイルでリダイレクトを管理するのは、機能するうちは問題ありません。しかし、何十件、何百件ものリダイレクトがあると、手作業の方法ではミスが生まれやすくなります。専用プラットフォームなら、リダイレクトチェーンの視覚的なデバッグ、自動 HTTPS 対応、リダイレクトトラフィックの分析、一括インポート/エクスポート、変更を追跡するための監査ログを利用できます。
• DNS 変更を行う前に TTL を低く設定する: 計画された DNS 更新の少なくとも 24 時間前に、TTL を 300 秒に下げてください
• ステージング環境でテストする: 全体の流れをテストせずに、リダイレクトの変更を本番環境へ直接反映しないでください
• 古いURLをそれぞれ最も近い新しいページに割り当ててください。すべてをホームページに送る方法は技術的には「動作」しますが、訪問者や検索エンジンは探していたページを見失います

RedirHubのアプローチ：推測をやめる#

リダイレクトの失敗は、どのような構成でも起こりえます。管理型サービスは運用するサーバー設定を減らせますが、DNSレコード、証明書の前提条件、キャッシュされた応答、転送先の可用性には引き続き注意が必要です。

RedirHubは、自社のエッジネットワークから、Webサーバーとは別にリダイレクトを応答します。壊れる .htaccess ファイルはなく、ルールを追加しても再起動するサーバーはありません。ダッシュボードでリダイレクトを管理でき、HTTPSはルートドメインとwwwに対して無料SSL証明書で自動発行され、大規模な移行も手作業のルールではなくCSVリダイレクトインポートで読み込めます。

上記の原因にどう対応するか：

• DNS設定：Connect DNSで必要な値を使用します。ルートドメインには表示されているAレコードと検証用TXTレコードを使用し、対応サブドメインにはCNAMEを使用します。既存のDNSキャッシュエントリは期限切れを待つ必要があります。
• .htaccessのエラー：編集するサーバー設定はありません。Redirect from、Redirect to、Redirect typeを入力すると、保存前にサンプルURLがどこへ移動するかをWhat happensでプレビューできます。
• チェーン：すべてのリダイレクトは1つのLinksリストに存在するため、複数箇所にルールを重ねるのではなく、古いURLを直接最終到達先に向けられます。
• キャッシュ：保存すると当社側ではすぐに変更が反映されます。古い301をすでにキャッシュしているブラウザーは、その内容を覚えている場合があるため、プライベートウィンドウやcurlで変更をテストしてください。
• HTTPS：証明書はルートとwwwの両方に対して自動で発行・更新されるため、古いドメインもhttps://で動作します。
• ステータスコード：各リダイレクトごとに 301、302、307、308 のいずれかを選び、作成する前に各サンプル URL の横にあるコードを確認してください。

サーバー上に自分で管理するサイトが1つだけあるなら、そこでルールを修正するのは無料で手早くできます。リダイレクトサービスが効果を発揮するのは、多数のドメインや数千の URL を伴うサイト移行を管理している場合です。手作業で管理するルールには、チェーンや টাইポが入り込みやすいためです。プランは月額49ドル（Core）からで、14日間の無料トライアルがあります。

クイックリファレンス チェックリスト#

• 古いドメインの DNS は、リダイレクトが設定されている場所を指していますか？（dig または DNS チェッカー）
• curl -IL https://old-url で、最初のホップに 301 が表示され、最後の URL が正しいことを確認できますか？
• http://、https://、www あり、www なしのすべてがリダイレクトされますか？
• ループなしで、最終 URL までのホップは 1 回だけですか？
• 古いドメインに有効な証明書はありますか？
• キャッシュされたリダイレクトを排除するために、プライベートウィンドウでテストしましたか？
• 各旧ページはホームページではなく、対応する新しいページに移動しますか？

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