BLOG

リダイレクトがSEOに与える影響|301と302の違いと対応表の作り方

リダイレクトで順位が落ちたという相談の原因は、記述ミスよりも、旧URLをどこへ送るか決めないまま切り替えた点にあることが多いです。まず旧URLを全部書き出し、そのまま移す・統合する・なくすの3つに仕分けてください。この仕分けが終わっていれば、あとはサーバー側の記述と切り替え後の確認だけで済みます。

旧サイトのURL一覧と新サイトのURL一覧が矢印で一本ずつ結ばれている対応表の様子

「301リダイレクトさえ設定しておけば、URLが変わっても検索順位はそのまま移る」。サイトのリニューアルを控えた担当者の方から、そう聞かされる場面があります。リダイレクトはサーバーの設定ファイルに数行書けば終わる作業として紹介されることが多く、記述さえ間違えなければ完了するものだと思われがちです。

しかし弊社はこれまで、リニューアルにともなう記事の移し替えや統合を数多く手がけてきました。その経験から言えるのは、切り替え後に順位が戻らなかった案件のほとんどで、原因が設定ファイルの書き方ではなく、どの旧URLをどこへ送るかを決めないまま切り替えた点にあったということ。

本記事では、リダイレクトが検索エンジンに対して何をしているのかという役割から、301と302の使い分け、旧URLと新URLの対応表の作り方、サーバーごとの設定、切り替え後に見るべき項目までを、記事制作会社の視点で順にお伝えします。

この記事でわかること
  • リダイレクトが検索エンジンに対して果たしている2つの役割
  • 301と302の違い、307と308を選ぶ場面、meta refreshを避ける理由
  • 旧URLを3つに仕分けて対応表を作るまでの手順
  • 旧ページを一律でトップページへ送ってはいけない理由
  • 切り替えたあとに当日中に確認しておく4つの項目

SEOにおけるリダイレクトの役割

リダイレクトとは、あるURLにアクセスがあったときに別のURLへ自動で転送する仕組みを指します。開こうとしたページとは違う画面に、気づかないうちにたどり着いている。閲覧者から見えているのは、その動きだけです。

ただし検索を意識する場面では、転送はリダイレクトの仕事の半分にすぎません。もう半分は、検索エンジンに向けて「このページの正しい住所はこちらへ変わった」と伝える通知の役割が占めています。

リダイレクトが果たす2つの役割

Googleは、301と308を恒久的な転送として扱い、転送先を正しいURLとみなす判断材料に使うと公式ドキュメントに記載しています。一方で302や303、307は一時的な転送と判断し、転送先を正しいURLとして扱う材料にはしません。同じ転送でも、返すコードによって検索エンジンの受け取り方が変わります

Redirects and Google Search | Google Search Central | Documentation | Google for Developers
Learn about the different types of redirects, how Google can interpret them, and how they can be useful in Google Search.
🌐 developers.google.com
外部リンク

※ Google検索セントラル「リダイレクトと Google 検索」

そしてこの通知が届いたあとに、旧URLへ集まっていた評価が新URLへ受け渡されていきます。ここで押さえておきたいのは、受け渡しは設定した瞬間に完了するものではなく、検索エンジンが新旧のURLを読み直して初めて進むという点。この時間差が、後半で扱う「順位が戻らない」相談の背景にもなっています。

関連記事:【2025年最新版】初心者でもできるSEOのやり方完全ガイド | 上位表示するための具体的な方法を徹底解説

301と302の違いと307・308の使い分け

実務で扱うリダイレクトは、4つのステータスコードに整理できます。恒久的な転送を示す301と308、一時的な転送を示す302と307です。

301リダイレクトは恒久的な移転に使う

URLが今後ずっと変わらない場合に選びます。ドメインの変更、常時SSL化、パーマリンクの変更、ページの統合は、いずれも301の出番です。検索評価を新しいURLへ引き継ぎたいのであれば、選択肢は301と考えて差し支えありません。

302リダイレクトは一時的な移転に限る

キャンペーンページへの差し替え、メンテナンス中の案内、在庫切れ商品の代替ページなど、もとのURLへいずれ戻す予定があるときだけ302を使ってください。

戻す予定がないのに302のままにすると、検索エンジンは旧URLを正しい住所として保持し続けます。新旧のどちらを検索結果に出すかで迷った状態が長く続き、新URLがなかなか表示されない。順位が戻らないという相談で、いちばん多く見つかる設定の取り違えがこれです。

307と308はHTTPメソッドを保持する

307は302の、308は301の、それぞれ厳密版にあたります。両者は転送のときにPOSTをGETへ書き換えません。フォームの送信先URLが変わるようなケースでは308を選ぶ場面があるでしょう。とはいえ通常のWebページの引っ越しであれば、301と302の2つで足ります。

meta refreshとJavaScriptによる転送は最後の手段

HTMLのmeta refreshタグや、JavaScriptでの画面遷移でも転送は実現できます。ただしGoogleは、サーバー側で返す転送をもっとも確実な方法として挙げ、JavaScriptによる転送は他の方法が使えない場合に限るよう案内しています。サーバーの設定を触れる環境なら、迷わずサーバー側で設定してください。

301302307・308meta refresh
意味恒久的な移転一時的な移転メソッドを保持する移転HTML側での転送
評価の引き継ぎ×308は◎・307は×
検索エンジンの判断転送先を正しいURLとして採用旧URLを正しいURLとして保持308は301と同じ扱い転送先を読みに行く
使う場面ドメイン変更・SSL化・統合期間限定の差し替えフォーム送信先の変更サーバーを触れない場合

並べてみると、選ぶ場面はかなり限られているとわかります。恒久的にURLが変わるなら301、戻す予定があるなら302。実務で迷う場面のほとんどは、この2択で決着します。

関連記事:302リダイレクトとは?301との使い分けと設定・エラー対処を解説

リダイレクトが必要になる4つの場面

リダイレクトが要るのは、URLが変わるときです。とはいえ「URLが変わる」の中身は案件ごとに違うため、代表的な4つの場面に分けて整理しておきます。

ドメインやサブドメインを変更するとき

社名変更やブランド統合で、ドメインごと引っ越す場合です。4つのなかでもっとも影響範囲が広く、旧ドメインの全ページが対象になります。Googleサーチコンソールのアドレス変更ツールを使うのも、このケースだけと覚えておいてください。

常時SSL化でhttpからhttpsへ移すとき

httpとhttpsは、検索エンジンから見ると別のURLです。SSL証明書を入れただけでは旧URLが残り続けるため、http側からhttps側への301が欠かせません。wwwの有無を統一する作業も、同じ考え方で扱えるでしょう。

URL構造やパーマリンクを変更するとき

CMSの入れ替え、カテゴリ階層の作り直し、日付入りURLからの変更などが該当します。ページの中身は変わらずURLだけが変わるため、1対1で素直に対応させやすい場面と言えるでしょう。

似た内容のページを1本に統合するとき

同じ問いに答える記事が複数あり、互いに評価を分け合っている状態を解消する目的で行います。他の3つと違い、こちらは中身の作り替えをともなう作業になります。

💡

URLが変わるかどうかを先に確かめておけば、リダイレクトの要否は自然に決まります。見た目を作り直すだけのリニューアルで、URLが1本も変わらないのであれば、リダイレクトの設定そのものが不要です。

関連記事:CMS別・SEOに強い記事入稿設定——WordPress/PayloadCMS/LeadGridの違いと最適化

301を設定したのに順位が落ちる理由

「301で設定したはずなのに、リニューアルから1か月経っても検索順位が戻らない」。この相談は毎年届きます。設定ファイルを開いて確認すると、記述そのものは正しい。原因は、別のところにありました。

Web担当者Web担当者

リニューアル前と同じ内容を新URLにも載せて、301も入れました。それでも順位が戻らないのは、設定の書き方が悪いのでしょうか。

Writers-hub編集部Writers-hub
編集部

記述が正しく、ステータスコードも301で返っているのなら、書き方の問題ではないと考えてよいと思います。私たちがまず確認するのは、旧URLの一本一本がどこへ送られているかの一覧です。トップページへまとめて送っていないか、転送先の内容が旧ページと入れ替わっていないか。この2点で説明がつく場合がほとんどでした。

旧URLをまとめてトップページへ送っている

もっとも多い失敗です。旧サイトの全ページをトップページへ301で飛ばすと、閲覧者は探していた情報にたどり着けません。Googleも、関連性のない1つのURLへ多数の旧URLを送る形は、ソフト404として扱われる場合があると明記しています。

Site Moves and Migrations | Google Search Central | Documentation | Google for Developers
Learn how to change the URLs of existing site pages, including domain name changes. Explore moving a website with little impact on search results.
🌐 developers.google.com
外部リンク

※ Google検索セントラル「URL の変更を伴うサイト移転」

ソフト404として扱われると、転送先が中身のないページとみなされ、旧URLの評価は受け渡されません。設定した本人には転送が正常に動いて見えるだけに、最後まで原因として疑われずに残ってしまう失敗でもあります。

旧URLをトップページへ一括で送ったときに起きること

転送先の中身が旧ページと別物になっている

リニューアルで文章を作り直した結果、転送元と転送先で扱う話題がずれてしまう場合があります。URLの引っ越しはできていても、中身の引っ越しまでは終わっていません。検索エンジンは転送先のページを読んで評価を決め直すため、旧ページの評価が移るのは、転送先に同じ答えが載っているときだけになります。

反映を待たずに元へ戻してしまう

Googleは、中規模のサイトで新しいURLが検索結果に出そろうまで数週間以上かかる場合があると説明しています。切り替え直後の順位変動を失敗と判断して旧URLへ戻すと、検索エンジンからは短期間に2回の引っ越しが起きたように見えるでしょう。判断は、最低でも数週間ぶんのデータを見てから下してください。

  • 旧URLを一律でトップページへ送る
  • 転送先の内容を確かめないまま切り替える
  • 切り替えから数日の順位変動で設定を元に戻す
  • 恒久的な移転に302を使い続ける

旧URLと新URLの対応表の作り方

ここまでの3つの失敗は、どれも同じ作業を省いたところから起きています。省かれていたのは、旧URLと新URLの対応表をつくる作業でした。Googleも、サイト移転の手順として旧URLの一覧を作り、それぞれの送り先を決めるところから始めるよう案内しています。

旧URLを3つに仕分けて対応表を作る流れ

作る順番は4段階です。表計算ソフト1枚で足りる作業ですから、専用のツールを探すところから始める必要はありません。

1
STEP
旧URLをすべて書き出す

CMSから出力したURL一覧、XMLサイトマップ、サーチコンソールの検索パフォーマンス、アクセス解析、サーバーのアクセスログを照らし合わせて、旧サイトのURLを漏れなく集めます。画像やPDFなど、ページ以外のファイルも対象に含めてください。

2
STEP
3つに仕分ける

集めたURLを、そのまま新URLへ移すもの、他のページへ統合するもの、なくすものの3つに分けます。ここが対応表づくりの中心にあたる工程です。

3
STEP
統合先と削除の扱いを決める

統合するURLには、内容を実際に引き受ける新URLを1本ずつ指定します。なくすURLは、無理に転送先を探さず404または410で返す選択も検討してください。

4
STEP
表に落として関係者で確認する

旧URL・新URL・分類・ステータスコードの4列を並べた表にまとめ、制作側と運用側の双方で目を通します。設定作業に着手するのは、この表が固まってからです。

1対1で移せないページをどう裁くか

ここが対応表づくりで最も時間を使う部分であり、設定方法を解説する記事ではほとんど触れられない部分でもあります。

旧サイトの全ページのうち、URLだけ変えて中身がそのまま移るページは、経験上それほど多くありません。残りは「3本の記事を1本にまとめる」「特集ページをなくしてサービスページへ寄せる」といった判断が要ります。判断の順番は決まっていて、まず転送先の候補を開き、旧ページを探していた人がそこで目的を果たせるかを見る。果たせるなら統合、果たせないなら削除という分け方になります。

アクセス数の少なさだけで削除を決めないでください。検索からの流入がなくても、外部サイトから参照されているページを消せば、そのリンクの価値ごと失われます。削除候補にはサーチコンソールで確認できる外部リンクの数を添えておくと、判断で迷う時間が減るはずです。

過去のリニューアルの転送も引き継ぐ

2回目以降のリニューアルには、もう一つ確認する項目があります。前回のリニューアルで設定した301が、サーバーにそのまま残っている場合です。

放置すると、旧々URLから旧URLへ、旧URLから新URLへと2段階で転送される形になります。転送が重なるほど閲覧者の待ち時間は延び、検索エンジンが最終的な転送先へたどり着くまでの経路も長くなるでしょう。過去の対応表を掘り起こし、旧々URLからも新URLへ一段で送る形に書き直すのが正しい対処です。

リニューアルで検索からの流入を落としたくないとお考えなら

対応表の精度は、旧サイトの中身をどこまで把握できているかで決まります。弊社では、旧URLの洗い出しから統合先の判断、切り替え後の順位の追跡までを一緒に進めてきました。公開予定日が決まっている段階でご相談いただくほど、打てる手が増えます。

統合先ページの中身をどう作り直すか

3本の記事を1本にまとめるとき、301の設定だけでは足りません。転送先のページが、統合された3本分の内容を実際に持っている必要があります。

とはいえ、3本の本文をつなげれば済むわけでもありません。同じ話題を扱っていた記事どうしですから、重複する説明が3回並び、読み進めるほど話が前に戻る文章ができあがります。統合は足し算ではなく、組み直しの作業だと考えてください。

実際の進め方としては、3本それぞれから「この記事にしかない情報」を先に抜き出します。次に、統合後のページを読む人が知りたい順番へ並べ替え、重複する説明は最も詳しいものを1つだけ残す。最後に、旧ページで検索からの流入を集めていた見出しが、新しいページにも残っているかを確かめます。

統合後のページから旧ページ特有の情報が抜け落ちていると、その情報を探していた人が求めていた答えを返せなくなります。統合前に、各ページがどのキーワードで読まれていたかを控えておき、統合後のページでも同じ問いに答えられているかを確認してください。

301はURLの引っ越しであって、中身の引っ越しではない。この線引きを外すと、設定は正しいのに評価が移らないという状態に行き着きます。

統合するページの中身まで手が回っていないときは

リニューアルの期日が近づくほど設定作業が優先され、中身の作り直しは後回しになりがちです。弊社は統合先の構成づくりから本文の書き直しまでを引き受け、転送先のページが旧ページ分の役割を果たせる状態にしてお渡ししています。

サーバー別のリダイレクト設定方法

対応表が固まれば、あとは環境に合わせて記述するだけです。代表的な4つの方法を挙げます。

Apacheの場合は.htaccessに書く

レンタルサーバーの多くはApacheで動いており、.htaccessファイルに記述します。

TEXT
RewriteEngine On
RewriteRule ^old-page\.html$ https://example.com/new-page.html [R=301,L]

書き換える前には、必ず元のファイルを控えておいてください。.htaccessは1行の記述ミスでサイト全体が表示されなくなる場合があります。書き方のパターンは.htaccessのリダイレクトの書き方で詳しく扱いました。

Nginxの場合は設定ファイルに書く

VPSやクラウド上の環境ではNginxが使われます。

TEXT
location = /old-page.html {
    return 301 https://example.com/new-page.html;
}

記述したあとは構文を確認してから設定を再読み込みします。Nginxは.htaccessのような後付けのファイルを読まないため、サーバーへ接続する権限が必要になる点は押さえておきましょう。

WordPressはプラグインでも設定できる

サーバーの設定ファイルを触れない場合、WordPressならプラグインで管理する方法があります。管理画面から旧URLと新URLを入力するだけで済み、変更の履歴も残ります。ただしページを開いてからPHPが処理する分、サーバー側での転送よりわずかに表示が遅れる。件数の多い移転では、サーバー側での設定を優先してください。

フレームワークは設定ファイルで一括管理する

Next.jsであればnext.config.jsのredirects、ホスティングサービスであれば専用の設定ファイルに記述します。コードとして管理できるため、対応表をそのまま設定へ落とし込みやすい方法です。具体的な書き方は301リダイレクトの設定方法にまとめました。

どの方法を選んでも、記述する内容は対応表がそのまま元になります。サーバーの種類で悩む前に、送り先が決まっているかどうかを先に確かめてください。設定を書きながら送り先を考え始めると、判断が甘いまま公開日を迎えることになります。

切り替え後に確認する4つの項目

設定を入れた直後に見るべき項目を4つに絞ります。どれも切り替え当日のうちに終えられる内容です。

返ってきたステータスコードが301か

ブラウザの検証ツールのネットワークタブ、またはコマンドラインで旧URLを開き、301が返っているかを確かめます。画面が新URLへ切り替わっていても、実際には302で返っている取り違えは珍しくありません。

転送が重なっていないか

旧URLから新URLへ届くまでに、複数の転送を挟んでいないかを見ます。前の章で触れた過去の転送の残りは、ここで見つかることが多いでしょう。あわせて、転送先が転送元へ戻ってしまう無限ループも同時に確認します。

サーチコンソールの登録と申請

ドメインやサブドメインを変えた場合は、新しいドメインをサーチコンソールへ登録し、アドレス変更ツールで申請します。httpからhttpsへの変更やwwwの有無の統一では、このツールは使いません。新しいXMLサイトマップの送信は、どのケースでも行ってください。

内部リンクとサイトマップの書き換え

サイト内の他ページから旧URLへ張られたリンクが残っていると、閲覧者は毎回転送を経由することになります。本文中のリンク、グローバルナビゲーション、フッター、構造化データ、そしてcanonicalタグの指定先を、新URLへ書き換えましょう。

  • 旧URLへのアクセスが301で新URLへ返っている
  • 旧URLから新URLまでの転送が一段で終わっている
  • 新しいXMLサイトマップをサーチコンソールへ送信した
  • サイト内のリンクとcanonicalタグの指定先を新URLへ書き換えた

リダイレクトをいつまで残すのかという質問もよく受けます。Googleは、可能な限り長く、少なくとも1年は維持するよう案内しています。サーバーの移設で設定が消えてしまわないよう、対応表そのものを社内の資料として保管しておいてください。

リダイレクトのよくある質問

最後に、相談の場で繰り返し挙がる質問をまとめます。

301リダイレクトはいつまで残すべきですか

少なくとも1年は残してください。Googleは可能な限り長く維持するよう案内しています。旧URLへの外部リンクが残っている間は、外しても得はありません。サーバーを移設する際に設定ごと消えてしまう事故が起きやすいため、対応表を社内資料として保管しておくことをおすすめします。

評価が新しいURLへ移るまでどのくらいかかりますか

数週間以上を見込んでください。Googleは、中規模のサイトで新しいURLが検索結果に出そろうまで数週間以上かかる場合があると説明しています。切り替え直後の順位の上下で成否を判断せず、サーチコンソールで新URLのクリック数が積み上がっていくかを追ってください。

canonicalタグとリダイレクトはどちらを使いますか

旧URLを閲覧させる必要がないならリダイレクトです。canonicalタグは、両方のURLを残したまま正しいほうを伝える指定にとどまります。旧URLを閲覧させずに新URLへ寄せるなら301、パラメータ違いなどで同じページが複数の住所を持つ状態を整理するならcanonicalタグ、と分けて考えてください。

評価の低いページも転送してよいですか

転送して構いません。ただし低い評価も一緒に移る点は理解しておいてください。検索からの流入がほとんどなく、外部からのリンクもないページであれば、無理に転送先を探さず404で返す整理も選べます。

リダイレクトでペナルティを受けることはありますか

通常の移転では受けません。問題になるのは、閲覧者と検索エンジンへ別のページを見せる設定のように、意図的に内容を偽る場合です。旧URLを内容の異なる新URLへ大量に送る形も、結果として評価が受け渡されない状態を招きます。

まとめ|リダイレクトは設定より対応表で決まる

リダイレクトの設定そのものは、対応表さえあればサーバーへの記述と確認だけで終わります。順位が落ちるかどうかを分けているのは記述の巧拙ではなく、旧URLを一本ずつどこへ送るかを決めたかどうかでした。

やるべきことを順に並べると、旧URLを全部書き出す、そのまま移す・統合する・なくすの3つに仕分ける、統合先の中身を作り直す、301で設定する、切り替え後に4項目を確認する。この5つになります。とりわけ見落とされがちなのが、3つ目の中身の作り直しです。URLをつないでも、転送先に同じ答えが載っていなければ評価は移りません。

私たち合同会社Writers-hubは、サイトのリニューアルや記事の統合にともなう移行を、対応表づくりから統合先の本文制作まで一貫して支援しています。旧サイトで積み上げた評価をどこまで残せるかは、切り替える前の判断で決まります。

公開日は決まっているのに、対応表がまだ手つかずでしたら

どのページを残し、どこへ統合し、何を削るのか。切り替え前のこの判断だけでも外から見てほしい、というご相談を受けています。現状のURL数と公開予定日をお知らせいただければ、進め方をご案内します。

この記事を書いた人

米山拓真

米山拓真

合同会社Writers-hub 代表社員

滋賀県立大学工学研究科の修士課程を修了後、大手制作会社の編集部を経て2019年にWebライターとして独立。2020年に記事制作を手順化した「ハブ式SEOライティングメソッド」を開発し、これまでに200人以上のライターを育成しました。2022年3月に合同会社Writers-hubを設立し、会社として累計8,000記事以上のSEO記事制作に携わっています。2024年にAIライティングシステム「一気通貫Pro」、2025年から書き手の文体を再現するAI編集者「Edico」を開発。このブログでは、クライアント案件と自社サイトで実際に試したことを書いています。

読んで終わりにしないために

記事の内容を自社に当てはめるとどうなるか、オンライン30分で一緒に整理します。費用はかかりません。

無料で相談する