301リダイレクト（恒久的リダイレクト）

TL;DR — 301リダイレクトは、古いURLを訪れたユーザーやボットを新しいURLへ恒久的に送ります。ドメイン変更、URL変更、HTTPからHTTPSへの移行、ページ統合など「完全に移転する」場面に適した方法です。サーバーで設定し、各旧URLを実際の移転先（ホームページではなく）へ対応させて、そのルールを維持します。Googleは301でランキング価値が失われることはないと説明しているため、心配する必要はありません。

301リダイレクトとは何か

ブラウザーや検索エンジンがページを要求すると、サーバーは3桁のHTTPステータスコードで応答します。200は「ページはこちら」、404は「見つからない」という意味です。301は**「Moved Permanently（恒久的に移動）」**を示し、このURLには新しい場所があるので、そこへ進むよう伝えます。

つまり301リダイレクトは、サーバーが「要求されたものは別のアドレスにあり、移転は恒久的だ」と全員に伝える仕組みです。訪問者は自動的に新しいページへ送られ、検索エンジンの記録も新URLを指すよう更新されます。

使う場面

ページのアドレスが恒久的に変わるときは、301を選びます。

• URLを変更した場合 — ページ名を変えたり、サイト構造を組み替えたり、読みにくいURLを整理したりします。
• 新しいドメインへ移転した場合 — リブランドやサイト移行です。
• HTTPSへ切り替えた場合 — すべてのhttp:// URLを対応するhttps:// URLへ301で送ります。
• ページを統合した場合 — 似た記事を1つにまとめ、旧ページを残すページへ送ります。
• 代替ページのあるページを終了した場合 — 行き止まりではなく、最も近い同等ページへ送ります。

Google自身も、「検索結果に表示されるページのURLを変更する必要がある場合は、できる限り恒久的なサーバー側リダイレクトを使うことをおすすめします」と説明しています。

無視すべき1つの数字

301では「リンクジュースが10～15%失われる」と聞くかもしれませんが、それは古い神話です。Googleの明確な説明は、“301 and other permanent redirects don’t cause a loss in PageRank.” (翻訳)「301などの恒久的リダイレクトでPageRankが失われることはない」です。価値が漏れると心配してリダイレクトを避ける必要はありません。正しい301なら、旧URLが得ていたシグナルを移転先へ渡します。

さらに「301はリンク評価の90～99%を渡す」という断定も見かけますが、これも無視してください。Googleはそのような割合を公表しておらず、数字は作られたものです。

正しく行う3つのこと

1. 各旧URLを実際の移転先へ向ける — ホームページではない。 すべての終了ページをホームページへ送ると、Googleがエラー（「ソフト404」）と判断し、価値を渡さない可能性があります。旧URLと新URLを1対1で対応させます。
2. 偽ではない本物の301を使う。 JavaScriptだけで行うリダイレクトや「移動しない場合はここをクリック」というリンクは同じものではなく、Googleが見ないこともあります。サーバーで実装してください。
3. 維持する。 Googleはシグナルが移る時間を確保するため、リダイレクトを通常は少なくとも1年間維持するよう案内しています。可能なら永久に残します。

302はどうか

302は一時的な移転です。「今は移動しているが、元のページが本来のものだ」と伝えます。301のつもりで302を使うと、Googleは新URLではなく旧URLを検索結果に残すことがあります。移転が恒久的なら301を使います（301と302の比較は別記事で詳しく扱います）。

サーバー設定、時間の目安、リダイレクトチェーンのルール、静かに失敗する「偽301」の見つけ方を知りたい場合は、Advancedタブへ進んでください。

TL;DR — 301（HTTP「301 Moved Permanently」 (翻訳)「恒久的に移動」）はURLを恒久的に移すサーバー側レスポンスで、移転先へランキングを集約する最も強いシグナルの1つです。Googleは恒久的リダイレクトでPageRankが失われないと明言しています。「1ホップごとに約15%減る」という説は誤りで、渡される評価の割合を公表していない以上、数字を作ってはいけません。Apache、nginx、アプリ、Cloudflareなどのサーバーまたはエッジで実装し、JavaScriptや遅延meta refreshには頼りません。旧URLは関連する1対1のページへ送り、ホームページへの一括転送（ソフト404の危険）は避けます。チェーンは短く保ち、Googleの上限10ホップよりも、できれば約5ホップ未満にします。サーバーでは即時ですが、インデックスとシグナルの統合には数週間から通常少なくとも1年かかります。

301の実体

301はHTTPステータスコードで、ページ本体より前のレスポンスヘッダーとしてサーバー（またはCDNのエッジ）が返します。重要なのは、本物の301がリクエストへの応答というプロトコル層で発生することです。プラグイン機能、<meta>タグ、JavaScriptスニペットではありません。これらはサーバーで設定できない場合の代替で、挙動が異なります。

Googleは定義を簡潔に示しています。「301と308のステータスコードは、ページが新しい場所へ恒久的に移動したことを意味する」。308はリクエストメソッドも保持する新しい恒久リダイレクトコードです。SEOではGoogleは301と308を同じように扱い、「可能なら301や308などのHTTP恒久的リダイレクトを使う」と案内しています。

実装前に知っておきたいプロトコル上の注意があります。301レスポンスは既定でヒューリスティックにキャッシュ可能なので、ブラウザーや中間キャッシュが保持し、修正後もキャッシュが消えるまで古い移転先へ送ることがあります。また301はHTTP/1.0以来のコードで、ユーザーエージェントは追従時にPOSTをGETへ変えてよい仕様です。フォーム送信で元のメソッドが必要なら、308を使います。LocationヘッダーはURI参照（相対でも可）ですが、実務では絶対URLのほうが曖昧さを避けられます。

Googleが301を処理する方法（正規化とインデックス登録）

恒久的リダイレクトはGoogleが持つ最も強い正規化シグナルの1つです。Googlebotが301をたどると、インデックス処理は移転先を正規URLにすべきだというシグナルとしてリダイレクトを使います。Googleは両端を記録し、「URLをリダイレクトすると、旧URL（redirect source）と新URL（redirect target）の両方を追跡し、片方を正規URL、もう片方を正規URLの別名にする」と説明しています。

移転後もしばらく検索結果に旧URLが残ることがあるのはこのためです。Googleは旧URLを「別名」として保持しています。ドメイン移転では、“it’s very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal… the alternate names will fade away without you doing anything.” (翻訳)「新しいURLがすでにインデックスされていても、Googleが古いURLを検索結果に時々表示し続ける可能性は非常に高く、これは正常で、別名は何もしなくても消えていく」と説明しています。

リダイレクトは弱い正規化シグナルより上位です。Gary Illyesは、リダイレクトは「ページがhttpかhttpsか」よりはるかに高い重みを持つはずだと述べています。そのため、意図しない301がcanonicalタグやHTTPS優先設定を静かに上書きすることがあります（詳しくは正規化の記事を参照）。

このシグナルが保証することと、保証しないことを分けて考えましょう。301は正規化先を示す強いシグナルですが、保証ではありません。指定したURLがインデックスされること、順位を得ること、トラフィックが移ること、リンクや品質など他のシグナルが自動的にすべて移ることまでは約束しません。「正規URLの選択」と「インデックス・ランキング・トラフィックの結果」は別の問いであり、301が直接答えるのは前者だけです。

PageRank神話を正確に整理する

この点は最も誤解されているため、正確に説明します。

**Googleの正確な説明は「301などの恒久的リダイレクトでPageRankが失われることはない」**です。それだけです。「85%残る」でも「1ホップごとに10～15%失う」でもありません。損失はありません。

「1ホップごとに約15%減る」という説は、古い（2016年以前の）リダイレクト間のPageRank減衰の説明に由来し、Matt Cuttsの発言として広まりました。Googleは2016年ごろに公に方針を変え、30xリダイレクトでPageRankを希釈する処理をやめ、移転先に権威が渡るようにしたと報じられています。

逆方向にも注意が必要です。301が「リンク評価の90～99%を渡す」とは言わないでください。 Googleは割合を公表していません。「PageRankの損失がない」は方向を示す説明であり、割合ではありません。確認済みの数字として引用できるのは「損失がない」という文言だけです。

私自身の注意書きも加えます。4つのリンクの多いAhrefs記事から301を外し、「1年後もシグナルが残る」という主張を試しました。(1年後に301リダイレクトを削除してもよいか：テスト結果) リダイレクトを外すと参照ドメインは目に見えて減り、オーガニックトラフィックの結果は混在しました。1件は増え、1件は減り、2件はほぼ横ばいで、減少のように見えた1件は削除前に始まっていました。結論は「1年後も恒久リダイレクトが価値を渡すと断言するつもりはないが、Garyの説明はおおむね当てはまる」というものです。サンプルは小さいので慎重に見ますが、実務上は単純です。リダイレクトを削除しないでください。

3つの時計で見る時間

「301はいつ効くのか」という問いは、どの時計を見るかで答えが変わります。

• サーバーの時計：即時。 ルールを有効にした瞬間から、すべてのリクエストが301になり、利用者は新URLへ到達します。
• インデックスの時計：数日から数週間。 Googleが旧URLを再クロールし、リダイレクトを確認し、移転先を処理する時間です。小～中規模サイトの大半は数週間、大規模サイトはさらに長くかかることがあり、移転中に検索での表示が一時的に変動するのは正常です。
• シグナル統合の時計：通常少なくとも1年。 Googleは、可能な限り長く、通常は少なくとも1年間リダイレクトを維持すると、すべてのシグナルを新URLへ渡せると説明しています。利用者のためには永久保持も検討します。

実務上のルールは、リダイレクトを少なくとも1年間、できればURLの維持費がかからない限り永久に残すことです。

301の実装

できるだけサーバーに近い場所で行います。ほとんどのケースをカバーする4つの方法を紹介します。例なので、パスとホスト名は環境に合わせて変更し、Scriptsタブのコピー用例とテスト手順も確認してください。

編集前に既存の.htaccessまたはnginx設定をバックアップしてください。ルールの誤りで、リダイレクト対象のURLだけでなくサイト全体が停止する可能性があります。

Apache（.htaccess）

単一URLをmod_aliasで設定する場合：

Redirect permanent "/old-page" "https://example.com/new-page"

パターンベースのルールをmod_rewriteで設定する場合：

RewriteEngine on
RewriteRule "^/service$" "/about/service" [R=301,L]

nginx

location = /service {
  return 301 https://example.com/about/service;
}

WordPress

WordPressには標準のリダイレクト管理機能がないため、追加で用意します。

• Redirectionプラグイン（無料） — 最も一般的な方法で、UIから送信元と移転先を登録できます。
• Yoast SEO Premium — URLスラッグを削除・変更したときに自動でリダイレクトを作成できます。無料版Yoastにはリダイレクト管理機能がない点に注意してください。
• サーバー側 — .htaccessまたはnginxを直接編集できるなら、毎回PHPを実行するプラグインより高速です。

Cloudflare

Cloudflareを使っている場合は、リクエストがオリジンに届く前のエッジでリダイレクトできます。

• Single Redirects — ダッシュボードで作る単発ルールです。
• Bulk Redirects — 数千件の送信元→移転先をまとめたリダイレクトリストをアカウント全体に適用します。大規模移行で旧サーバーを廃止するときにも便利です。

アプリケーションコード（PHPの例）

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/new-url');
exit();

「偽」リダイレクト — 誰も確認しない失敗モード

意外ですが、URLは200 OKを返しながらリダイレクトすることがあります。 私が書いた「リダイレクト11種類とSEOへの影響」 でも、どのステータスコードでもページ読み込み後にJavaScriptでリダイレクトが起き得ると説明しています。この「リダイレクト」は簡単なステータス確認には見えず、301の保証もありません。

Googleは方法を次の順序で評価しています。

• サーバー側（301/308）：最善。 技術的に可能なら常にこれを使います。
• meta refresh：時間によって異なる。 Googleは即時meta refreshを恒久的、一方で遅延meta refresh（N秒後に発火）を一時的なものとして解釈します。したがってcontent="5;url=…"は301の代わりになりません。
• JavaScript：最後の手段。 サーバー側やmeta refreshができない場合だけ使います。レンダリングに失敗するとGoogleが見ない可能性があります。
• リンクだけの擬似リダイレクト：使わない。 新URLへのリンクだけでステータスコードもrefreshもないページは、Googleの言う「公式リダイレクトとして認識しない検索エンジンがある」方法です。

SEOを重視するなら、本物のサーバー301であり、ブラウザー内で遷移する200ではないことを確認してください。Scriptsタブのcurl手順でチェックできます。

301でよくある失敗

• すべてをホームページへ送る。 Googleは、関連性のない1つのURL（ホームページなど）へ大量に送ると利用者を混乱させ、ソフト404と判断する可能性があると警告しています。関連する代替ページへ送り、複数ページを本当に統合した場合だけ統合後のページへまとめます。
• 長いリダイレクトチェーン。 Googleは最大10ホップをたどりますが、最終移転先へ直接送り、できれば3以下、5未満にするよう勧めています。チェーンは利用者の遅延にもなります。新しいルールを追加したら、前のホップではなく最終URLへ更新します。
• 301のつもりで302を使う。 302は旧URLを正規とするシグナルなので、恒久移転なのに302を使うと誤ったURLが登録されます。意図に合うコードを使ってください。
• 早すぎる削除。 1年未満で外すと、旧URLに残る価値を取りこぼす可能性があります。少なくとも1年、できれば永久に維持します。
• 広すぎるワイルドカード。 フォルダー全体のルールが無関係なURLを誤ったページへ送ることがあります。できるだけ旧→新を1対1で対応させます。
• HTML以外の資産を忘れる。 画像やPDFにもリンクとトラフィックがあります。移転した資産は対応表に含め、JS/CSS/フォントを無差別にリダイレクトしないでください。
• 旧ホストを早く停止する。 DNS、TLS証明書、旧サーバーを先に止めると、301ではなく接続エラーになります。リダイレクトを維持する期間は、旧ホストのDNS・証明書・ルールも生かしてください。

Bing

Bingも301を移転先にランキングを統合し、旧URLをインデックスから外す強いシグナルとして扱います。Bingの従来の案内は、Googleの約1年より短い数か月程度の最低期間を推奨し、サイト移行では301で十分でSite Moveツールが代わりになるわけではないとしています。両方の検索エンジンを対象にするなら、厳しいほうに合わせ、本物のサーバー301を少なくとも1年間維持します。

このコードの位置づけ

301はステータスコードの一員で、最も直接的には一時的な302と対になります。「移転が恒久的かどうか」が301対302の判断軸です。正規化とも近い関係ですが、301は移転用の強い正規化シグナルであり、両方を存続させる重複URLの統合にはrel="canonical"を使います。301はサイト移行の背骨でもあります。302/307（一時）、308（恒久）、404/410（消失）、5xx（エラー）を含む全体像は、このページが属するHTTPステータスコードのクラスターを参照してください。

AI要約

Advanced版の要点をまとめます。

• 301 = HTTP「301 Moved Permanently」 (翻訳)「恒久的に移動」 — URLを恒久的に移すサーバー側レスポンスで、Googleが持つ最も強い正規化先シグナルの1つです。ただし保証ではなく、登録・順位・トラフィックを約束しません。SEOではGoogleは301と308を同じように扱いますが、301はPOSTをGETへ変えることがあり、既定でキャッシュ可能です。メソッド保持が必要なら308を使います。
• PageRankの損失はない。 Googleの正確な文言は「301などの恒久的リダイレクトでPageRankが失われることはない」です。「1ホップごとに約15%減る」は誤りで、Googleは渡される割合を公表していません。
• 3つの時計。 サーバーは即時、インデックス移行は数日～数週間（大規模サイトは長い）、シグナル統合は通常少なくとも1年です。少なくとも1年、できれば永久に維持します。
• サーバー／エッジで実装。 Apacheの.htaccess（Redirect permanent／mod_rewrite [R=301]）、nginx（return 301）、WordPress（RedirectionまたはPremium版Yoast。無料版には管理機能なし）、CloudflareのSingle/Bulk Redirects、アプリコードを使います。
• 「偽リダイレクト」。 JavaScriptで200を返したまま遷移することがあります。即時meta refreshは恒久的、遅延meta refreshは一時的、JSは最後の手段です。リンクだけのcryptoリダイレクトも信頼できません。
• 主な失敗。 ホームページへの一括転送（ソフト404）、長いチェーン（約5ホップ未満）、恒久移転での302、早すぎる削除、1対1対応をしない広いワイルドカードです。
• 実測上の注意。 1年後に301を外すテストでも結果は混在していたため、「1年で安全」と決めつけず、リダイレクトを維持します。

公式ドキュメント

検索エンジンが公開する一次資料です。

Google

• リダイレクトとGoogle検索 — 301の定義、サーバー側・meta refresh・JavaScriptの違い、meta refreshのタイミング、PHP・Apache・nginxの実装例。
• URL変更を伴うサイト移行 — PageRank損失なし、リダイレクトを通常少なくとも1年維持する案内、チェーン上限、ソフト404の警告、小規模／大規模サイトの移行期間。
• 正規URLの指定方法 — 正規化シグナルの中でのリダイレクトの位置づけ。
• クロールとインデックス登録 — リダイレクト、正規化、クロール制御の親ハブ。

Bing / Microsoft

• Bingウェブマスター向けガイドライン — Bingのリダイレクトと恒久移転に関する立場。
• Bingでのサイト移行 （2020年12月）— BingのSite Moveツールと、恒久リダイレクトが通常十分でツールが代替ではないという説明。

プラットフォーム実装

• Cloudflare — Bulk Redirects — エッジで適用するアカウント全体のリダイレクトリスト。
• Cloudflare — URL forwarding — SingleとBulk Redirectsの概要。
• Yoast — WordPressで301を作る方法 — WordPress固有の手順と、リダイレクト管理がPremium機能であること。

原典からの引用

Googleの記録に残る発言です。各リンクは引用箇所へ直接移動します。

Google — 301とは何か、いつ使うか

• 「The 301 and 308 status codes mean that a page has permanently moved to a new location.」 (翻訳)「301と308のステータスコードは、ページが新しい場所へ恒久的に移動したことを意味します。」（Google Search Central） 引用箇所へ移動
• 「If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.」 (翻訳)「検索結果に表示されるページのURLを変更する必要がある場合は、可能な限り恒久的なサーバー側リダイレクトを使うことをおすすめします。」 引用箇所へ移動
• 「Use server side permanent redirects if technically possible… we recommend that you use HTTP permanent redirects if possible, such as 301 and 308.」 (翻訳)「技術的に可能ならサーバー側の恒久リダイレクトを使い、可能なら301や308などのHTTP恒久リダイレクトを選びます。」（Google Search Central） 引用箇所へ移動

Google — PageRankと統合（正確性の中心）

• 「301などの恒久的リダイレクトでPageRankが失われることはない。」（Google Search Central） 引用箇所へ移動
• 「When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.」 (翻訳)「URLをリダイレクトすると、Googleは旧URL（リダイレクト元）と新URL（リダイレクト先）の両方を追跡する。一方が正規URLとなり、もう一方は正規URLの別名になります。」 引用箇所へ移動

Google — 時間

• 「Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.」 (翻訳)「リダイレクトは可能な限り長く、通常は少なくとも1年間維持してください。この期間でGoogleはすべてのシグナルを新URLへ移せます。利用者の観点では永久保持も検討します。」 引用箇所へ移動
• 「A small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer… the visibility of your content in Search may fluctuate temporarily during the move. This is normal.」 (翻訳)「小～中規模サイトでは大半のページの移動に数週間かかることがあり、大規模サイトはさらに長くなります。検索での表示が一時的に変動するのは正常です。」 引用箇所へ移動

Google — リダイレクトチェーン、ソフトエラー、偽リダイレクト

• 「While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects… we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.」 (翻訳)「Googlebotはチェーン内の最大10ホップまでたどれますが、最終移転先へ直接送り、できれば3以下、5未満にすることを勧めます。」 引用箇所へ移動
• 「Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.」 (翻訳)「無関係な1つのURL（新サイトのホームページなど）へ大量の旧URLを送らないでください。利用者を混乱させ、ソフト404と扱われる可能性があります。」 引用箇所へ移動
• 「Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.」 (翻訳)「サーバー側またはmeta refreshができない場合だけJavaScriptリダイレクトを使ってください。レンダリングに失敗するとGoogleが見ない可能性があります。」 引用箇所へ移動
• 「Google Search interprets instant meta refresh redirects as permanent redirects… Google Search interprets delayed meta refresh redirects as temporary redirects.」 (翻訳)「Google検索は即時meta refreshを恒久的、遅延meta refreshを一時的なリダイレクトとして解釈します。」（引用アンカー: 「Google differentiates between two kinds of meta refresh redirects」 (翻訳)「Googleはmeta refreshリダイレクトを2種類に区別します。」） 引用箇所へ移動

301リダイレクト実装チェックリスト

恒久リダイレクト（またはその一括設定）を公開する前・最中・後に行う確認です。

事前

• 移転が本当に恒久的か確認（一時的なら301ではなく302）。
• 旧URL→最も関連する新URLの1対1対応表を作る（旧URL→ホームページではない）。
• 統合では、各グループが送る単一の存続URLを決める。
• 画像とPDFも移転対象に含める（JS/CSS/フォントは除外）。

実装

• サーバー側（Apache/nginx/アプリ）またはエッジ（Cloudflare）で行い、JavaScriptや遅延meta refreshは使わない。
• 誤ったURLへ送る広いフォルダーワイルドカードではなく、1対1ルールを優先する。
• チェーンを作らないよう、全ルールを最終移転先へ向ける。
• WordPressではRedirectionプラグイン、Yoast Premium（無料版には管理機能なし）、またはサーバールールを使う。

検証

• 各旧URLが本物の**301（200でも302でもJavaScriptでもない）を返すことをテストする。curlの確認はScripts**タブを参照。
• 約5ホップを超えるチェーンがないことを確認し、見つけたら1ホップにまとめる。
• 移転先が別リダイレクトや404ではなく**200**を返すことを確認する。
• クエリ文字列、フラグメント、末尾スラッシュ、大文字小文字を含むURLも試す。
• GSCのURL検査でGoogleが移転先をどう解決するか確認する。
• 移行ではサイト全体をクロールし、ループ、チェーン、対応表から漏れた旧URLを検出する。

完了後

• リダイレクトを通常少なくとも1年間、できれば永久に維持する。
• 検索結果に旧URLが別名として残ることがあるが正常。消すためにリダイレクトを外さない。

リダイレクトを検出・テストする

Redirect Checkerで確認：

1. テストするURLを単一URL欄に貼り付け（最大20件の一括モードも可）。
2. Check redirectsを押してチェーン全体を追跡。
3. 最初のホップのステータスと判定ドットを読む。本物の恒久リダイレクトは301（または308）を通しで示します。302/307が混ざる、またはチェーンの重大度が緑を超えるなら、1ホップの301ではありません。

これらの確認が答えるのは、「このURLは本当にサーバー側301を返しているのか、それとも何かが偽装しているのか」という1つの問いです。ページは200 OKを返しながら、ブラウザーではJavaScriptで遷移することも忘れないでください。

裸のURLだけでなく、クエリ文字列、#fragment、末尾スラッシュ、大文字小文字の違いを含むURLでも再確認します。HTTP仕様は、書き換えルールがそれらを維持することを保証しません。RewriteRuleやパターンマッチが元のクエリ文字列やフラグメントを静かに落とすことがあります。

生のステータスコードとリダイレクトチェーンを見る（curl）

macOS / Linux / WSL

# Show response headers only — look for "HTTP/… 301" and the "location:" target
curl -sI https://example.com/old-page

# Follow the whole chain and print each hop's status + final URL
curl -sIL -o /dev/null -w "%{http_code}  %{url_effective}\n" https://example.com/old-page

# Print every status code in the chain (catches multi-hop chains)
curl -sIL https://example.com/old-page | grep -i "^HTTP\|^location"

クリーンな恒久リダイレクトは、最終URLを指す単一のlocationヘッダーを伴う301応答です。302なら一時的で、200なのにブラウザーが別の場所へ進むなら、JavaScript／meta refreshによる「偽」リダイレクトです。 「HTTP/1.1 301 Moved Permanently (or HTTP/2 301) with a single location: header pointing at the final URL. If you see 302, it’s temporary. If you see 200 but the browser still ends up somewhere else, it’s a JavaScript/meta-refresh “fake” redirect.」 (翻訳) 「HTTP/1.1の301（恒久的に移動）で、最終URLを指すlocationヘッダーが1つだけ返ります。302なら一時的で、200のまま別の場所へ移動する場合はJavaScriptやmeta refreshによる偽リダイレクトです。」

Windows (PowerShell)

# MaximumRedirection 0 stops at the first hop so you can read its status code
$r = Invoke-WebRequest -Uri "https://example.com/old-page" -MaximumRedirection 0 -SkipHttpErrorCheck
$r.StatusCode              # 301 for a permanent redirect
$r.Headers.Location        # the target URL

JavaScriptの「偽」リダイレクトを捕まえる

curlはサーバーの応答しか見ず、JavaScriptは実行しません。curlが200なのに本物のブラウザーで移動するなら、クライアント側リダイレクトです。Chrome DevToolsで確認します。

1. DevTools → Networkを開き、Preserve logを有効にする。
2. 旧URLを読み込む。
3. 最初のリクエストがStatus 301（または308）なら本物のサーバーリダイレクトです。最初が200で後からナビゲーションが出るなら、JS／meta refreshであり、本当の301ではありません。

Apache .htaccess

# Single URL (mod_alias)
Redirect permanent "/old-page" "https://example.com/new-page"

# Pattern / regex rule (mod_rewrite) — R=301 makes it permanent, L stops processing
RewriteEngine on
RewriteRule "^old-section/(.*)$" "https://example.com/new-section/$1" [R=301,L]

# Force HTTP → HTTPS for the whole site
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

nginx

# Single URL
location = /old-page {
  return 301 https://example.com/new-page;
}

# Whole-path prefix
location /old-section/ {
  return 301 https://example.com/new-section/;
}

# Force HTTP → HTTPS
server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

WordPress（プラグインなし — functions.php、慎重に）

// Runs on every request; a server rule or the Redirection plugin scales better.
add_action( 'template_redirect', function () {
    if ( is_page() && get_query_var( 'name' ) === 'old-page' ) {
        wp_redirect( home_url( '/new-page/' ), 301 );
        exit;
    }
} );

多くのWordPressサイトでは、RedirectionプラグインまたはYoast PremiumのRedirect Managerが現実的です。コード不要で、Yoast PremiumならURLを変更・削除したときに301を自動作成できます。

Cloudflare（エッジ、オリジン設定不要）

CloudflareのSingle Redirectsはダッシュボード（Rules → Redirect Rules）に組み込まれています。移行では、Bulk Redirectsリストに送信元→移転先の2列CSVを渡し、アカウント全体のエッジで適用できます。オリジンサーバー設定を触らず何千ものURLを移す最速の方法です。

クリーンな移転を壊す301の失敗

すべての旧URLをホームページへ送る

無関係な一括転送は利用者を混乱させ、ソフト404と判断されることがあります。各旧URLを最も近い実在の代替ページへ対応させ、代替がなければ404または410を返します。

古いチェーンの末尾に新しい移転先を追加する

旧URL→以前の移転先→現在の移転先とつなぐと遅延と失敗点が増えます。最も古いルールを更新し、最終的な200の移転先へ直接向けます。

恒久移転に302を残す

一時コードは検索エンジンに送信元URLを優先させます。恒久移転なら本物のサーバー側301または308を使い、通信上のステータスを確認します。

新URLが表示されたらすぐ削除する

インデックスが移動したことは、すべてのシグナルが統合されたことではありません。Googleは可能な限り、通常は少なくとも1年間リダイレクトを維持するよう勧めています。運用コストが低いなら、利用者と古いリンクのため永久保持が望ましいです。

移転先をテストせず広いワイルドカードを信頼する

フォルダー単位のルールは無関係なURLを誤ったページへ送ることがあります。まず1対1の対応表を作り、境界ケースをテストし、送信元→移転先の変換が一貫するURL構造にだけパターンを使います。

HTML以外のリソースを忘れる

画像やPDFにもリンクとトラフィックがあります。移転先が関連する場合は資産も対応表に含め、JS、CSS、フォントのリクエストを無差別にリダイレクトしないでください。

デプロイ前にリダイレクト対応表を監査する

少なくともsource_urlとtarget_urlを含むCSVを貼り付けます。可能なら現在の送信元／移転先ステータス、コンテンツタイプ、ページタイトル、トピック分類も追加します。

Audit this proposed permanent redirect map.

For each row:
1. Flag homepage or other catch-all targets that are not demonstrably relevant.
2. Flag duplicate sources, missing targets, source=target loops, and likely chains where a
   target also appears as a source.
3. Compare source and target titles/categories only from the supplied data and label the
   mapping relevant, questionable, or insufficient evidence.
4. Recommend one action: keep the 1:1 mapping, map to a closer replacement, return 404/410,
   or investigate manually.

Do not invent replacement URLs or assume a target returns 200 unless the data says so.
Return: critical blockers, row-by-row findings, then the exact URLs to test after launch.

PASTE REDIRECT CSV HERE

301の3つの時計フレームワーク

「301はいつ効くのか」に単一の答えはありません。3つの仕組みが異なる時計で動くためです。結果を解釈する前に、どの時計かを明確にします。

この枠組みは2つの分類ミスを防ぎます。動作するサーバールールをインデックス完了の証拠とみなすこと、検索結果が変わったことをルール削除の許可とみなすことです。各時計を固有の証拠で検証してください。

導入・確認のためのツール

Patrickの無料ツール

• リダイレクトチェッカー — 1件または簡単な一括URLを調べ、最初のステータス、各ホップ、最終移転先を確認します。「本当に1ホップの301か」を素早く確認できます。
• リダイレクトチェーンマッパー — 各ホップの変化を診断し、Cloudflare、Apache、nginx向けの整理ルールを出力します。チェーン自体を短くしたいときに使います。
• 一括HTTPステータスコードチェッカー — 対応表の最大500 URLをテストし、301以外の送信元と200以外の移転先を絞り込み、リリース前のQAセットを出力します。

検索とインフラの確認

• Google Search ConsoleのURL検査 — Googleが旧URLをリダイレクトとして取得したことと、移転先の正規URL選択を確認します。
• サーバー／CDNログ — 実際のGooglebotリクエストにも利用者と同じルールが返ることを確認します。
• サイト全体のクローラー — 移行後に漏れた内部リンク、古いサイトマップ、ループ、チェーン、リダイレクトされた資産を探します。

301リダイレクト理解度クイズ

恒久リダイレクトについての簡単な5問です。各問に答えてから確認してください。

リダイレクトが本当に機能したことを証明する

301を公開しました。ここでは、設定ファイルにルールがあるだけの状態と、Googleが旧URLから新URLへ統合している状態を区別する確認を行います。順番に実行してください。最初は即時、最後は数週間かかります。

テスト1 — 旧URLが本物のサーバー301を返す

• 実行するテスト — 旧URLをリダイレクトチェッカーに貼り付ける（またはcurl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/old-url)
• 期待結果 — 最初のホップが301（または308）でlocation:ヘッダーを持ち、最終URLが200を返す。1ホップで正常です。
• 失敗の解釈 — 旧URLの200はJavaScript／meta refreshの「偽」リダイレクトであり、サーバー301ではありません。302/307なら一時コードを誤って公開しています。
• 監視期間 — 即時（ルールが有効になった瞬間にサーバーが応答）。
• ロールバック条件 — チェッカーが約5ホップ超のチェーンまたはループを示す場合、ルールを外し、旧→最終移転先を1対1で指すよう修正して再公開します。

テスト2 — Googleがリダイレクトを認識し、新URLを選んだことを確認する

• 実行するテスト — Google Search Consoleで旧URLをURL Inspectionします。
• 期待結果 — ステータスが「Page with redirect」となり、新URLを調べると登録済みで、Googleが選んだ正規URLが自分自身になります。
• 失敗の解釈 — 数週間後も旧URLが自分自身の正規URLとして「Submitted and indexed」のままなら、Googleがリダイレクトを取得できないか、canonical・サイトマップ・内部リンクが旧URLを指しています。
• 監視期間 — 小～中規模サイトは数日～数週間、大規模サイトはそれ以上です。移転中に表示が変動するのは正常です。
• ロールバック条件 — 旧URLが残るからといってリダイレクトを外さないでください。Googleは別名として保持し、自然に消えます。新URLがまったく登録されない場合だけ再確認します。

テスト3 — 移行でトラフィックを取りこぼしていないことを確認する

• 実行するテスト — 対応表の旧URLをRedirect Checkerで（1回に最大20件）処理するか、サイト全体をクロールし、GSCのPerformanceレポートで移行後ページを観測します。
• 期待結果 — 対応した各URLが1ホップで200へ進み、移転先のクリック／表示回数が数週間以内に旧URLの水準へ戻ります。
• 失敗の解釈 — 持続的な減少は、PageRankが漏れたのではなく、Googleがソフト404とみなす誤った／無関係な移転先へ送る対応表の不具合であることが多いです。正しい301でPageRankが失われることはありません。
• 監視期間 — 傾向を信頼するにはGSCデータを2～4週間集め、日々のノイズではなく対応した前後期間を比較します。
• ロールバック条件 — 移行日と一致する明確で継続的な表示回数減少があれば、リダイレクト自体を疑う前に1対1対応表を再監査します。

変更履歴