301リダイレクトとは?基本と記述方法
301リダイレクトとは、HTTPレスポンスステータスコードの一つで、リクエストされたURLが恒久的に別のURLへ移動したことを示すものです。英語では「Moved Permanently(恒久的な移動)」と呼ばれ、ブラウザでアクセスしたユーザーは自動的に転送先のページへ送られます。検索エンジンに対しても「このURLは今後ずっと新しいURLに置き換わる」という意思表示になり、転送元ページが持っていたSEO評価を転送先に引き継ぐためのもっとも標準的な方法として推奨されています[1]。
仕様面ではRFC 9110で定義されており、301を受け取ったクライアントはキャッシュを更新し、以降のリクエストを新URLに対して行うべきだとされています[2]。つまり301は、単なる「飛ばし先の指定」ではなく、URLそのものの正式な引っ越し届と理解しておくとよいでしょう。
301リダイレクトが使われる主なユースケース
実務で301リダイレクトを設定する場面は、大きく次のパターンに整理できます。新規にサイトを公開するときや、運営中の構成変更が発生したときに、漏れがないか確認してください。
- ドメイン移転(example.jp → example.com など、サイト全体を別ドメインへ引っ越す場合)
- HTTPSへの常時SSL化(http:// → https:// の統一)
- wwwあり/なし、末尾スラッシュあり/なし、index.htmlあり/なしといったURLの正規化
- 類似テーマの古いページを新しい1ページに統合する場合(重複コンテンツの整理)
- パーマリンク構造の変更(/blog/2020/post → /column/post など)
- キャンペーンページ終了後に関連する常設ページへ誘導する場合
.htaccessによる記述例
Apacheサーバーで301リダイレクトを設定する場合は、ドキュメントルートに置いた.htaccessファイルにディレクティブを記述するのが一般的です。文字コードはUTF-8(BOMなし)、改行コードはLFで保存し、本番に反映する前にステージング環境で挙動を確認しましょう。代表的な記述パターンは以下のとおりです。
1. 特定ページを別URLへ転送する
Redirect permanent /old-page.html https://www.example.com/new-page.html
2. ディレクトリ単位で転送する
RedirectMatch 301 ^/old-dir/(.*)$ https://www.example.com/new-dir/$1
3. httpからhttpsへ統一する(mod_rewrite使用)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
設定後はブラウザの開発者ツールやcurlコマンド(curl -I https://example.com/old-page.html)でレスポンスヘッダーを確認し、ステータスが「301 Moved Permanently」となり、Locationヘッダーに正しい転送先URLが入っているかを必ず検証してください。NginxやIIS、各種CDNなど環境によって書き方は異なりますが、「恒久的な移動を示す301を返し、Locationで転送先を指定する」という考え方は共通です。

SEO上の意味とページランクの受け渡し
SEO観点で301リダイレクトが重視される最大の理由は、転送元ページに蓄積された被リンクやコンテンツの評価を、転送先ページにまとめて引き継げる点にあります。Googleの公式ドキュメントでも、サイト移転やURL変更の際は301(または同等の308)を使うことが推奨されており、ソフト404やmeta refreshを使うよりも明確にシグナルが伝わります[3]。一方で、転送はあくまで「ページ単位」での指定が必要で、トップページだけにリダイレクトを設定しても下層ページの評価は引き継がれません。具体的な評価の引き継ぎ度合いや維持期間の考え方については、本記事の後半で詳しく解説します。
httpからhttpsへの301転送とURL正規化
同じコンテンツでも、URLの表記揺れがあるとGoogleは別ページとして扱う場合があります。代表的なのは「wwwあり/なし」「末尾のindex.htmlあり/なし」「http/https」の違いで、これらが混在しているとリンク評価が分散し、想定どおりの順位がつきにくくなります。これを防ぐために、サイト全体で正規URLを1つに統一する「URL正規化」を行い、そのうえで301リダイレクトをセットで設定するのが基本です。
なぜhttpsへの301転送が必須なのか
Googleは2014年からHTTPSをランキングシグナルの一つとして利用しており、Chromeでもhttpページは「保護されていない通信」と表示されます[4]。サーバーに常時SSLを導入したら、httpでアクセスされた場合に対応するhttpsのURLへ301リダイレクトする設定をあわせて行いましょう。これをしないとhttp版とhttps版が同時にインデックスされ、評価が割れる可能性があります。常時SSL対応の詳細はウェブサイトの常時SSL(HTTPS)対応で解説しています。
統一しておきたいURLの代表的なパターン
サイト立ち上げ時に決めておきたい正規化のパターンは以下のとおりです。いずれも301リダイレクトを使い、片方の表記からもう片方の正規URLへ恒久的に転送します。
- http → https へ統一(例:
http://example.com/→https://example.com/) - www あり/なしを統一(例:
https://example.com/→https://www.example.com/、あるいはその逆) - 末尾の
index.htmlやindex.phpを取り除き、ディレクトリ表記に統一 - 末尾スラッシュ(trailing slash)の有無を統一
- 大文字/小文字の混在を避け、小文字に統一
301リダイレクトが使えない場合のrel=canonical
サーバー側で301リダイレクトを設定できないケース(ECモールの商品ページや、パラメータで生成される一覧ページなど)では、Googleは rel="canonical" によるURL正規化を推奨しています[5]。両者は目的こそ似ていますが、訪問者からの見え方やSEO上の扱いが異なります。基本的には301リダイレクトが優先で、使えない場面の代替としてcanonical属性を使う、と覚えておくとよいでしょう。
| 項目 | 301リダイレクト | rel=canonical |
|---|---|---|
| 訪問者からの見え方 | URLが正規版に切り替わる(気づける) | URLは変わらない(ソースを見ないと気づけない) |
| SEO上の扱い | 恒久的な転送として強く解釈される | 正規URLの「ヒント」としてGoogleが参照 |
| サーバー設定 | .htaccessやサーバー設定が必要 | HTMLの<head>に1行追加するだけ |
| 使うべき場面 | http→https、ドメイン移転、ページ統合など恒久的な変更 | 301が設定できないとき、重複コンテンツの正規版を示したいとき |
| 転送先以外のURLでのアクセス | 不可能(強制的に転送される) | 可能(元URLも閲覧できる) |
訪問者にとってもURLバーが正規版に切り替わる301リダイレクトの方が親切で、ブックマーク時の混乱も避けられます。一方、canonicalは「あくまでヒント」であり、Googleが別のURLを正規と判断することもあります。両方を併用しているサイトも多いですが、その場合は301の転送先とcanonicalの指定先が必ず一致するように揃えるのが鉄則です。
301リダイレクトはどの程度ページランクを受け渡す?
301リダイレクトを設定したとき、転送元ページが持っていたSEO評価(被リンクやページランク)はどの程度、転送先に引き継がれるのでしょうか。この点はGoogleの公式見解が時期によって少しずつ変化しており、運用判断に迷うポイントの一つです。ここでは過去から現在までのGoogle側の発言を整理し、実務でどう扱うべきかを明確にします。
かつては「リダイレクトで一部のページランクが失われる」とされていた
古くは、301リダイレクトを経由するとページランクの一部が減衰するとGoogleが説明していました。SEO担当者の間でも「リダイレクトを挟むほど評価が薄まる」という前提で運用するのが一般的で、リダイレクトチェーンを避ける根拠の一つにもなっていました。ページランクの基本についてはページランクとは?で詳しく解説しています。
2016年:Gary Illyes氏「30x系リダイレクトでページランクは失われない」
この前提が大きく変わったのが、2016年7月のGoogleのGary Illyes氏による発言です。同氏は、301を含む30x系のリダイレクトでは「ページランクは失われない(no PageRank is lost)」と明言し、長年の通説をひっくり返しました[1]。これは301だけでなく302や30x系全般に当てはまるとされ、リダイレクト方式の選択がページランクの観点では大きな差にならないことを示すアナウンスでした。
この発言以降、「301でも302でも評価の受け渡しに差はない」とする見方が広がりましたが、実装上は恒久的な移転には301(または308)、一時的な転送には302を使うという原則は引き続き有効です。
2022年:John Mueller氏「重要な古いリンクは新しいURLに更新するのがベスト」
一方、2022年6月にGoogleのJohn Mueller氏は、301でどの程度評価が渡るかという質問に対し、「フルクレジットかどうか」という二元論で捉えるのではなく、Googleの公式ドキュメントにある通り「重要な古いリンクは新しい正しいページを指すように更新するのが良いプラクティスだ」と回答しています[3]。
つまり、「301でも100%評価が引き継がれる」とは断言せず、可能であればリダイレクトを介さずリンク元のURLそのものを最新のURLに張り替えることが推奨されている、というニュアンスです。リダイレクトに頼り切るのではなく、コントロールできる範囲のリンクは直接更新するのが最も安全という指針と言えます。
運用上のベストプラクティス
これまでの公式見解を踏まえると、301リダイレクトと評価の引き継ぎについては、次の方針で運用するのが現実的です。
- 恒久的な移転・URL変更には、まず301(または308)を必ず設定する。これは評価継承だけでなく、ユーザー体験とクローラー効率の観点からも必須。
- サイト内の内部リンクは、リダイレクト経由ではなく最新URLを直接指すように一括で書き換える。
- 外部からの重要な被リンク(業務提携先、主要メディア、ディレクトリ掲載など)は、可能であればリンク元の運営者に依頼して新URLへ更新してもらう。
- リダイレクトチェーン(A→B→C…)は最小限に抑え、常に「旧URL→最新URL」の1ホップで完結させる。
- 301を設定したからといって即座に削除せず、十分な期間維持する(具体的な期間は後の章で解説)。
301の評価継承率を数字で語ることにはあまり意味がありません。むしろ「リダイレクトはセーフティネット、本命はリンクの直接更新」と捉えると、サイト移転やURL変更時の判断がぶれにくくなります。
多言語サイトでの301リダイレクト活用
多言語サイトを運用していると、「同じ内容を別の言語で複数ページ持っている」「ある言語の対応をやめたい」といった場面に直面します。こうしたケースで301リダイレクトをどのように扱えばよいのかは、運営者にとって悩みどころです。基本的な考え方として、ページの内容が実質的に同じであれば、言語が異なっていても301リダイレクトで統合して問題ないとされています。
対応をやめた言語ページは301で別言語版に統合できる
たとえば英語・日本語・ドイツ語の3言語でサイトを運営していたものの、ドイツ語の対応を打ち切ることになった場合、ドイツ語ページを残しておくと内容が古くなり、ユーザー体験を損ねるおそれがあります。このとき、ドイツ語ページを英語版(または最も近い言語の正規ページ)へ301リダイレクトすることで、訪問者を有効なページへ誘導しつつ、検索エンジンに対してもページランクを統合先へ受け渡すことができます。Googleの公式ドキュメントでも、リダイレクトは「ユーザーが必要としているコンテンツへ確実に到達させる」ことが目的とされており、言語が異なるという理由だけでこの原則が変わるわけではありません[6]。
「同じ内容を複数言語で持っている」場合の正しい扱い
一方で、運用を続けている言語ページ同士、つまり「英語版と日本語版を両方公開し続けたい」というケースで301リダイレクトを使うのは適切ではありません。この場合はhreflang属性で各言語バージョンの対応関係をGoogleに伝えるのが正攻法です。hreflangを正しく設定すれば、Googleはユーザーの言語・地域に応じて最適なバージョンを検索結果に表示してくれます。301リダイレクトで一方に寄せてしまうと、別言語ユーザーがアクセスできなくなり、本来狙えたはずの検索流入を失ってしまいます。
整理すると、多言語サイトでの301リダイレクトは「ある言語版の運用をやめてコンテンツを統合する」フェーズで活きる手段であり、「並行運用する複数言語をどう正しく案内するか」はhreflangの守備範囲と覚えておくとよいでしょう。両者を混同せず、状況に応じて使い分けることが、多言語SEOで評価を取りこぼさないためのポイントです。
301リダイレクト・サイト移転時の注意点
301リダイレクトは正しく設定すればページランクをスムーズに引き継げる一方、設定の抜け漏れや過剰な連鎖があるとクロール効率の低下や評価の取りこぼしにつながります。ここではサイト移転や日常運用で陥りがちな4つの落とし穴を整理し、実務で失敗しないためのポイントを解説します。
リダイレクト連鎖(チェーン)は10回まで
サイトを長期運用していると、古い記事の統合、HTTPSへの移行、ドメイン変更などが重なり、1つのURLから目的のページにたどり着くまでに複数回のリダイレクトが発生するケースが出てきます。Googleはクロール時に最大10回までのリダイレクトホップを追跡しますが、それを超えるとリダイレクトエラーとして扱われ、最終的な転送先がインデックスされない可能性があります[1]。

仕様上はリダイレクトを何段でも書くことはできますが、ブラウザ側のエラーやサーバー負荷、ページ表示の遅延を招くだけでなく、Search Consoleでもエラーとして検出されます。古いリダイレクト設定が積み重なってチェーンになっていないかを定期的にチェックし、可能な限り「旧URL → 最新URL」の1ホップで完結するよう書き換えるのが理想です。
301リダイレクトはページ単位で指定する
サイト移転で見落とされがちなのが、「トップページだけリダイレクトすれば旧ドメイン全体の評価が新ドメインに引き継がれる」という誤解です。Googleは各URLを個別に評価しているため、旧サイトのすべてのページについて、対応する新サイトのURLへ1対1でリダイレクトを設定する必要があります。
旧URLをすべて新URLのトップページに一括転送してしまうと、Googleはそれを「ソフト404」として扱う可能性があり、ページランクは引き継がれません。下層ページ・カテゴリページ・記事ページなど、URLごとに対応関係を整理してマッピング表を作成しておくと、移転後の検証もスムーズです。URLの正規化方法(canonical属性の使い方)と合わせて、URL設計全体を見直す良い機会にもなります。
サブドメインも忘れずに設定する
サイト移転でとくに見落としやすいのがサブドメインの扱いです。`www`の有無はもちろん、ブログ・サポート・ECなどでサブドメインを分けて運用している場合、それぞれを個別に新ドメインへ301リダイレクトする必要があります。サイト内で301を返すページと200(OK)を返すページが混在していると、Googleは移転の意図を正しく解釈できなくなる恐れがあります。
移転前に、自社で運用しているサブドメインの一覧を棚卸しし、DNS設定・サーバー設定・リダイレクトルールがそれぞれ漏れなく更新されているかを確認してください。Search Consoleには新旧それぞれのドメイン・サブドメインを登録しておくと、移行状況をモニタリングしやすくなります。
無関係のサイトから301転送しても評価は引き継がれない
「中古ドメインや別ジャンルのサイトから自社サイトへ301リダイレクトをかければ評価を盛れるのでは?」と考える人もいますが、Googleはコンテンツの関連性がない転送をサイト移転とは見なしません。GoogleのJohn Mueller氏も、無関係なサイトからの301は移転扱いにならず、ページランクなどの評価は引き継がれないと説明しています。スパム的な手法として古くから知られており、対策アルゴリズムも整備されています。
一方で、無関係なサイトからリダイレクトを受けたとしても、転送先ページのテーマ性が薄まったり、検索順位にネガティブな影響が出ることは基本的にないとされています。意図しない外部からの転送を受けても過度に心配する必要はありませんが、自社で行う場合は「あくまで実体としてコンテンツや運営者に連続性がある移転に限って301を使う」と覚えておきましょう。
サイト移転前のチェックリスト
ここまでの注意点を、移転前後に確認すべき項目としてまとめました。本番移行の直前に最終チェックとして活用してください。
- 旧URLと新URLの対応表を作成し、すべてのページを1対1で301リダイレクトしているか
- www有無・HTTP/HTTPS・index.html有無など、URLバリエーションがすべて新ドメインに集約されているか
- 運用中のサブドメイン(blog、shop、support など)が漏れなくリダイレクト設定されているか
- リダイレクトチェーンが3ホップ以内に収まっているか(理想は1ホップ)
- 200を返すページと301を返すページが旧サイト内で混在していないか
- 無関係なドメインからの転送で評価を盛ろうとしていないか(評価は引き継がれない)
- Search Consoleに新旧両方のプロパティを登録し、移行状況を確認できる状態か
- 新ドメイン向けのXMLサイトマップを作成・送信したか
これらの基本を押さえておくことで、移転に伴う順位下落リスクを最小限に抑えられます。次章では、こうした301リダイレクトをどのくらいの期間維持すべきかという、運用面で頻出する疑問について解説します。
301リダイレクトはいつまで維持すべきか
サイト移転やURL変更で301リダイレクトを設定したあと、「いつまでリダイレクトを残しておくべきか」は多くの運用担当者が悩むポイントです。サーバー設定が肥大化したり、旧ドメインの契約更新が発生したりするため、できれば早めに整理したい一方で、短期間で外してしまうと検索評価の引き継ぎに支障が出るおそれがあります。ここではGoogleのGary Illyes氏とJohn Mueller氏の公式発言を踏まえ、推奨される維持期間と、削除した場合に何が起こるかを整理します。
Gary Illyes氏が示した「最低1年」という目安
GoogleのGary Illyes氏は2021年7月、「リダイレクトをどれくらいの期間維持すべきか」という長年の質問に対し、「具体的な答えがある:最低でも1年」と明言しました。さらに、「可能であればユーザーのために無期限で維持してほしい」とも付け加えています[7]。
1年という数字は、Googleのクローラーが旧URLを再訪し、新URLへのシグナル統合(カノニカル化)を完了するために十分な時間を確保するための目安です。クロール頻度が低い深い階層のページや、外部からの被リンクが古いURLに残り続けているページもあるため、短期間で打ち切るとそれらの評価が宙に浮いてしまいます。
John Mueller氏「3ヵ月では短すぎる」
同様の論点について、John Mueller氏も2022年3月のX(旧Twitter)で「サイト移転では旧ドメインをより長く保持することを強く推奨する。リダイレクトは少なくとも1年は維持すべきで、3ヵ月は短すぎる」と回答しています(出典:John Mueller 公式X)。
つまり、Googleの中の人2人がそろって「1年が最低ライン」という見解で一致していることになります。サイト移転の費用対効果を考えると、ドメイン更新料を惜しんで1年未満で旧サイトを閉じてしまうのは、それまで積み上げた検索評価を捨てるリスクと釣り合いません。Google公式のURL 変更を伴うサイト移転ガイドでも、最低1年間はリダイレクトを維持し、可能な限り長く保持するよう推奨されています(出典:Google検索セントラル)。実務的にはGary氏・John氏の発言を踏まえ、1年以上を目安にするのが安全です。
301リダイレクトを削除するとどうなるか
では、設定済みの301リダイレクトを期限切れや設定ミスで外してしまうと、検索評価はどうなるのでしょうか。John Mueller氏は以前から、リダイレクトが解除された時点で、Googleは旧URLと新URLを「別々のページ」として再評価し始めると説明しています。リダイレクトが続いている間は2つのURLが同一のシグナルプールに統合されますが、解除されると統合が解け、旧URLは404や別コンテンツとして扱われ、新URLは新URL単独の評価に戻ります。
このとき問題になるのが、外部サイトからの被リンクや、ブックマーク・SNSに残っている古いURLです。リダイレクトが生きている間はそれらが新URLへの評価として機能しますが、解除後はリンク先がエラーになるか、関係のないページに変わってしまい、せっかくの被リンクが死蔵されます。1年経過しても旧URLへのアクセスログが一定数残っているなら、リダイレクトは無理に外さず、サーバー設定として継続する判断が無難です。
運用上の推奨:1年は厳守、可能なら恒久維持
- 最低1年はGary Illyes氏・John Mueller氏ともに一致した推奨ライン
- 旧ドメイン契約も1年以上は更新し、リダイレクト元のサーバーを稼働させ続ける
- 1年経過後も、アクセスログに旧URLへの訪問が残っているならリダイレクトは継続
- 外部からの重要な被リンクは、可能ならページランクの損失を防ぐためにリンク元に依頼して新URLへ書き換えてもらう
- リダイレクトを削除する際は、旧URLが404を返すのか、別コンテンツに置き換わるのかを事前に設計する
301リダイレクトは「設定して終わり」ではなく、移転後も長期にわたって運用すべきインフラの一部です。ドメイン契約やサーバー設定の更新計画に、リダイレクト維持の項目をあらかじめ組み込んでおくと、評価喪失のリスクを最小化できます。
サイト移転時にやるべきSearch Console・サイトマップ運用
サーバー側で301リダイレクトを設定するだけでは、サイト移転の作業は完結しません。Googleに移転の事実をできるだけ早く・正確に伝え、再クロールとインデックス更新を促すためには、Search Consoleの「アドレス変更」ツールとXMLサイトマップの再登録をセットで運用する必要があります。ここでは実務的な移転手順を、操作する場所と注意点に分けて整理します。
Search Consoleの「アドレス変更」ツールを使う
移転元と移転先の両方をSearch Consoleに登録した状態で、移転元プロパティの左メニュー「設定」を開き、「アドレス変更」を選択します。Googleが指示するチェック項目(301リダイレクトが正しく設定されているか、移転先プロパティの所有権が確認できているかなど)をクリアすると、移転を申請できます。アドレス変更ツールはユーザーを移転先の検索結果へ案内する期間を長めに確保してくれるため、移転後の評価引き継ぎを安定させるうえで重要です[8]。

XMLサイトマップを新ドメイン向けに再作成・登録する
移転後はURLがすべて新しいドメインに変わっているため、旧サイトマップのままでは意味がありません。新ドメインのURLでXMLサイトマップを作り直し、移転先プロパティのSearch Consoleに登録してクロールを促しましょう。GoogleはサイトマップをURL発見の重要なシグナルとして扱っており、移転直後の再クロールを早めるうえでも有効です。サイトマップの基本的な作り方や運用方法はXMLサイトマップの実践ガイドも参考にしてください。
- 新ドメインのURLで全ページ分のXMLサイトマップを生成する
- 移転先プロパティのSearch Consoleでサイトマップを送信する
- 旧サイトマップは当面残しておき、Googleが旧URLを再クロールして301を発見できる状態を維持する
サイト統合ではアドレス変更ツールは使えない
たとえば「x.com というサイトを y.com/x 配下に統合した」というケースでは、John Mueller氏が「サイトの統合は移転ではないのでアドレス変更ツールは使えない」と説明しています。アドレス変更ツールはあくまで1対1のドメイン移転を前提とした機能であり、複数サイトを1つに束ねるような構成変更ではツールでの申請ではなく、ページ単位の301リダイレクトと内部リンク・サイトマップの整備で対応することになります。
異なるドメインへの移転はトラフィック変動リスクがある
301リダイレクトとアドレス変更ツールを正しく設定したとしても、移転前と完全に同じパフォーマンスが維持される保証はありません。John Mueller氏も「ウェブサイトの移転時には大抵一時的な順位変動が発生してすぐに落ち着くものの、異なるドメインで正確に同様のパフォーマンスを維持できるかは決して保証しない」と述べています。短期的な順位変動や流入減はある程度織り込んだうえで、移転タイミング(繁忙期を避ける、広告キャンペーンと重ねないなど)を計画するのが現実的です。
実務的には、「301リダイレクトの設定 → 移転先プロパティでの所有権確認 → アドレス変更ツールの申請 → 新ドメインのXMLサイトマップ送信 → Search Consoleでカバレッジとインデックス状況を継続監視」という流れを押さえておけば、移転で起きがちなトラブルの大半は予防できます。
アドレス変更ツールはドメインの全バリエーションで実行する
サイト移転時にSearch Consoleの「アドレス変更」ツールを使う際、つい代表的なドメイン1つだけで実行して終わりにしてしまうケースが見られます。しかしGoogleはサイト移転に関するヘルプドキュメントを更新し、www/non-wwwなどすべてのサブドメインバリエーションでアドレス変更ツールを実行すべきであると明記しました。301リダイレクトを正しく設定していても、この手順を省くとGoogleへの通知が不完全になり、移転の認識が遅れる可能性があります。[8]
なぜ全バリエーションでの実行が必要なのか
Search Consoleでは、`https://example.com`、`https://www.example.com`、`http://example.com`、`http://www.example.com` といったURLバリエーションは、原則として別プロパティとして扱われます(ドメインプロパティを除く)。Googleはこれらを内部的にひも付けて評価しますが、アドレス変更ツールによる「移転の通知」はプロパティ単位で行われるため、登録済みのバリエーションそれぞれで実行しないと、Googleはどのバージョンが新ドメインへ移転したのかを完全には把握できません。
特に古くから運用しているサイトでは、過去のリンクや被リンクが `http://` 版や `www` なし版に向いていることが珍しくありません。これらのバリエーションが旧来Search Consoleに登録されているなら、すべて漏れなくアドレス変更を申告することで、被リンク評価の引き継ぎや新URLのインデックス化がスムーズに進みます。
実行前に確認すべきチェックポイント
- Search Consoleに登録済みの旧ドメインのプロパティを一覧で洗い出す(www有無・http/https・主要サブドメインを含む)
- 各バリエーションから新ドメインの該当URLへ、ページ単位で301リダイレクトが返っているかを確認する
- 新ドメイン側のプロパティもSearch Consoleに登録し、所有権確認を済ませておく
- 各旧プロパティで「設定」→「アドレス変更」を順に実行し、移転先として新ドメインを指定する
- blog.example.com など独立したサブドメインを運用している場合は、それらも個別にアドレス変更を申告する
なお、URLプレフィックスではなくドメインプロパティで登録している場合は、そのドメイン配下のすべてのサブドメイン・プロトコルがまとめて扱われるため、アドレス変更ツールの実行は1回で済みます。複雑なバリエーション管理を避けたいなら、ドメインプロパティでの登録に統一しておくと、今後の移転時の手間も減らせます。[9]
あわせて、新ドメイン側でXMLサイトマップを新URLで再作成し、Search Consoleに登録しておくと、移転後のクロール・インデックスがさらに加速します。アドレス変更ツールは「全バリエーションで」「301リダイレクトとセットで」「サイトマップ更新と併せて」運用するのが、現時点でのベストプラクティスです。
302・308・JavaScript・meta refreshなど他のリダイレクト
恒久的な転送には301リダイレクトを使うのが基本ですが、用途によっては別の方式を選んだ方が適切な場合もあります。ここでは302・308・JavaScript・meta refreshといった301以外のリダイレクト方式について、それぞれの特徴とSEO上の扱い、そして実務での使い分けを整理します。Googleはサーバーサイドの3xxリダイレクト(特に301/308)を最も推奨しており、それ以外は基本的に補助的な手段と捉えるのが安全です([1])。
302リダイレクト:一時的な転送に使う
302は「Found(一時的な移動)」を意味するステータスコードで、ページの一時的な転送を表します。キャンペーン期間中だけ別ページに飛ばしたい、メンテナンス中に代替ページを見せたい、A/Bテストで一部ユーザーを別URLに誘導したい、といったケースに向いています。.htaccessでの記述例は以下の通りです。
Redirect 302 /old-page/ https://www.example.com/new-page/
SEO上は、Googleは302をシグナルとして「元のURLをインデックスに残す」傾向があると説明しています。恒久的な移転に誤って302を使うと、転送先がなかなか正規URLとして認識されないリスクがあるため、移転が確定しているなら必ず301または308を選びましょう([1])。
308リダイレクト:301と同様に処理される
308は「Permanent Redirect」を意味し、HTTP仕様上は301と同等の恒久的転送を示します([10])。301との違いは、308がリクエストメソッド(POSTなど)を変更せずに転送するという点で、フォーム送信を伴うAPI的な処理を維持したい場合に有用です。Googleは公式ドキュメントで308も301と同様に「恒久的な転送のシグナル」として扱うと明記しています。一般的なWebページの移転であれば301でも308でも結果はほぼ同じと考えて差し支えありません。
JavaScriptを使用したリダイレクト
window.location.href などを使ったJavaScriptによるリダイレクトは、Googleはレンダリング後に処理して認識できると公式に説明していますが、サーバーサイドの3xxリダイレクトに比べてクロール・処理に時間がかかります。また、Googleは認識しても他の検索エンジンや一部のクローラーは追従できない可能性があるため、サーバー側で301を設定できる環境ならまずそちらを優先すべきです([11])。
サーバー設定をどうしても触れない場合(静的ホスティングの一部やCMSの制約下など)の代替手段として割り切って使い、可能な限り早めに3xxリダイレクトへ移行するのが安全な運用です。
meta refreshタグを使ったリダイレクト
HTMLの<head>内にmeta refreshタグを記述してページを転送する方式です。記述例は以下の通りです。
<meta http-equiv=”refresh” content=”0; url=https://www.allegro-inc.com/” />
サイト移転用途でmeta refreshは推奨されません。理由は以下の通りです。
- 301を使用していないとSearch Consoleのアドレス変更ツールが利用できない
- W3Cがアクセシビリティの観点から長年非推奨としている([12])
- ブラウザの履歴に余分なエントリが残るなどユーザー体験を損なう
- HTMLの解析が必要になるためクロール・処理に時間がかかる
どうしても3xxリダイレクトを設定できない環境でmeta refreshしか手段がない場合は、待機時間を0秒に設定して即時転送にするのが望ましいとされています。Googleは「待ち時間が0に近いmeta refreshは301に近いシグナルとして扱う」と説明しており、これはJavaScriptリダイレクトでも同様です。
5つのリダイレクト方式を比較
| 方式 | 主な用途 | SEO上の扱い | 推奨度 |
|---|---|---|---|
| 301 | 恒久的なページ移転・URL正規化 | 強い恒久転送シグナル。評価を転送先に受け渡す | ★★★ 最推奨 |
| 302 | 一時的な転送(キャンペーン・メンテナンス・A/Bテスト) | 元URLをインデックスに残す傾向。恒久移転には不適 | ★★ 用途限定で推奨 |
| 308 | POST等を維持した恒久転送・API | 301と同様に処理される | ★★★ 301の代替として可 |
| JavaScript | サーバー設定が変更できない場合の代替 | Googleはレンダリング後に認識。他検索エンジンは不確実 | ★ 代替手段 |
| meta refresh | HTMLしか触れない環境での最終手段 | 0秒指定なら301に近く扱われるが処理は遅い | △ 非推奨 |
結論として、301リダイレクトを基本に据え、メソッドを保持したい場合は308、明確に一時的な転送のみ302を使うのが安全です。JavaScriptやmeta refreshは「サーバー側で何もできない場合の代替」と位置づけ、可能になり次第サーバーサイドの3xxへ移行するのが望ましい運用です。サーバー側のレスポンスコード全般の挙動については、サーバーのレスポンスコードとGoogleの認識もあわせて参考にしてください。
ツールでリダイレクト関連の問題点を一括チェック
301リダイレクトは個別ページごとに設定するため、サイト規模が大きくなるほど「設定漏れ」「リダイレクトチェーンの肥大化」「内部リンクが旧URLのまま放置されている」といった問題が発生しやすくなります。これらを目視で洗い出すのは現実的ではないため、クロール型のSEO監査ツールを使ってレスポンスコードを一括チェックする運用がおすすめです。
SE RankingのサイトSEO検査ツールで何がわかるか
SE RankingのサイトSEO検査(ウェブサイト監査)ツールでは、対象ドメインをクロールし、各URLが返すHTTPステータスコードを一覧で確認できます。301/302などのリダイレクト、404のリンク切れ、5xx系のサーバーエラーまでまとめて抽出されるため、サイト公開直後の初期チェックや、サイト移転後の検証フェーズに特に有効です。

優先的にチェックしたい項目
- リダイレクトチェーン:A→B→Cのように多段になっているURLを抽出し、できるだけ「A→C」の1段に圧縮する。Googleはリダイレクトを最大10回まで追跡するとされていますが、評価の確実な引き継ぎとクロール効率の観点から短縮が望ましい。
- 内部リンクが旧URLを指していないか:301リダイレクトが効いていても、サイト内リンクは最新URLに直接張り替えるのがベストプラクティスです[1]。
- 302が使われていないか:恒久的な移転であるはずの箇所に302(一時的)が設定されていないかを確認する。
- 404と410の混在:意図的に削除したページが404のままになっていないか、また内部リンクから参照され続けていないかを確認する。
- http→httpsの転送漏れ:URL正規化のための301転送が全ページで効いているかを抜き打ちで検証する。
定期チェックを運用に組み込む
サイトSEO検査ツールはスケジュール実行に対応しているものが多く、月1回程度のクロールを設定しておけば、CMSのリンク更新ミスや、外部要因による500エラーなどを早期に検知できます。あわせてSearch Consoleの「ページのインデックス登録」レポートで「リダイレクト エラー」や「ページのリダイレクト」項目を確認すれば、Google側から見たリダイレクトの扱われ方も把握できます。
301リダイレクトは「一度設定したら終わり」ではなく、コンテンツの追加・削除に合わせて常に整合性を保つべきものです。ツールによる定期検査を運用フローに組み込み、サイト全体のレスポンスコードを健全な状態に保ちましょう。サーバーのレスポンスコードとGoogleの認識もあわせて参考にしてください。
よくある質問(FAQ)
- Q. 301リダイレクトと302リダイレクトの違いは何ですか?
- A. 301は恒久的な転送を意味し、検索エンジンに対して転送元の評価を転送先へ受け渡します。一方302は一時的な転送で、元のURLが再び使われる可能性を示すため、評価は基本的に転送元に残ります。サイト移転やURL正規化など、URLを完全に変更する場合は301を使用してください。
- Q. 301リダイレクトと301転送、rel=canonicalはどう使い分ければよいですか?
- A. サーバー側で恒久的にURLを変更する場合は301リダイレクトが第一選択です。サーバー設定で301が使えない場合や、内容は同じだが両方のURLを残したい場合にはrel=canonicalを使用します。301は訪問者にも転送が伝わるため、ユーザー体験の面でもcanonicalより親切と言えます。
- Q. 301リダイレクトはいつまで維持すべきですか?
- A. GoogleのGary Illyes氏は「最低でも1年」、可能であれば無期限に維持することを推奨しています。John Mueller氏も「3ヵ月では短すぎる」と発言しており、削除すると元URLと先URLが別ページとして扱われ評価が分散するリスクがあります。サーバー負荷の問題がなければ、できる限り長期間維持するのが安全です。
- Q. 301リダイレクトを設定するとページランクはすべて引き継がれますか?
- A. 2016年のGary Illyes氏の発言では「30x系リダイレクトでページランクは失われない」とされていますが、2022年のJohn Mueller氏は評価の度合いには明言を避けています。確実性を高めるため、重要な被リンクやサイト内リンクはリダイレクト任せにせず、最新URLへ直接張り替えるのがベストプラクティスです。
- Q. 301リダイレクトのチェーン(連鎖)は何回までなら問題ありませんか?
- A. Googleが評価を受け渡す上で追跡するリダイレクトチェーンは10回まで(やむを得ない場合でも3ホップ以内)とされています。それを超えるとSearch Consoleでエラーとして扱われる可能性があります。ブラウザの表示速度やサーバー負荷の観点からも、可能な限り1回で目的URLへ転送するよう整理してください。
- Q. サイト移転時にSearch Consoleでやるべきことは何ですか?
- A. Search Consoleの「アドレス変更」ツールで新ドメインへの移転を通知し、新サイトのXMLサイトマップを再作成・登録します。Googleの公式ヘルプ更新により、www有無などすべてのサブドメインバリエーションでアドレス変更ツールを実行することが推奨されています。あわせて301リダイレクトをページ単位で全URL分設定することも忘れないでください。
参考リンク
- [1] Google検索セントラル
- [2] IETF RFC 9110
- [3] Google検索セントラル
- [4] Google Search Central Blog
- [5] Google検索セントラル
- [6] Google 検索セントラル
- [7] Gary Illyes 公式X
- [8] Google検索セントラル
- [9] Search Console ヘルプ
- [10] IETF RFC 7538
- [11] Google検索セントラル
- [12] W3C WCAG
📌 Search Times を Google の「優先ソース」に追加しませんか?
優先ソースに登録すると、Google 検索や AI による要約で Search Times の最新記事が届きやすくなります。こちらから優先ソースに追加できます(数十秒で完了します)。

