この記事のポイント
  • 301リダイレクトは、URLが恒久的に移転したことをユーザーとGoogleに伝えるHTTPステータスコード
  • 301リダイレクトは単なる転送ではなく、Googleに新URLを代表として扱ってほしいと伝えるURL移転シグナル
  • 302は一時的な移動、301/308は恒久的な移動を示す
  • URL変更・サイトリニューアル・ページ統合では旧URLと新URLの1対1マッピングが重要
  • 301リダイレクト設定後は、内部リンク・canonical・サイトマップ・構造化データも新URLへ揃える必要がある
  • リダイレクトチェーン、トップページ一括転送、関連性の低い転送は避ける
  • サイト移行後はGSC・リダイレクトチェッカー・ログ・検索流入で継続的に確認する

301リダイレクトは、URLが恒久的に変わったときに設定するHTTPステータスコードです。

ユーザーを新しいURLへ自動転送するだけでなく、Googleに対して「今後は新しいURLを代表として扱ってほしい」と伝える、URL移転の宣言シグナルでもあります。言い換えれば、301リダイレクトはURLの住所変更届のようなものです。旧住所に来た人を新住所へ案内し、Googleにも「以後は新住所を代表として記録してほしい」と伝えます。

SEOの観点では、301リダイレクトは「ページを飛ばす設定」ではなく「URL移転の設計」です。旧URLと新URLの対応関係、転送先の関連性、内部リンクやサイトマップの更新、移行後の監視まで含めて考える必要があります。

この記事では、2026年5月時点のGoogle Search Centralの仕様に基づき、301リダイレクトの仕組みから302との違い、設定方法、確認方法、サイト移行手順、よくある失敗までを、URL移転シグナルを揃える実務観点で解説します。

\ リダイレクトの確認を無料で /

inSite リダイレクトチェッカー

URLを入力するだけでリダイレクトの種類(301/302)と転送先、最終到達URLを確認できます。設定後のチェックにお使いください。

inSiteの無料リダイレクトチェッカーの画面 無料でチェックする ↗

301リダイレクトとは

301リダイレクトとは?旧URLから新URLへ恒久的に転送し、ユーザー・クローラー・検索エンジンに移転を伝える仕組みを解説した図。301リダイレクトはURLの住所変更届のようなもの

まずは301リダイレクトの基本的な仕組みと、Googleがどう扱うかを整理しましょう。

HTTPステータスコード301の意味

301リダイレクトは、HTTPステータスコード「301 Moved Permanently(恒久的に移動)」を返す転送処理です。ブラウザでもクローラーでも、旧URLにアクセスすると自動的に新URLへ転送されます。

301リダイレクトの最大の特徴は「恒久的な移動」を示す点です。Googleはこの恒久リダイレクトを、新URLをcanonical(正規URL)として扱うシグナルの1つと捉えます。

301リダイレクトはURLの住所変更届

301リダイレクトは、URLの住所変更届のようなものです。

旧住所(旧URL)に来た人を新住所(新URL)へ案内するだけでなく、Googleにも「以後はこの新住所を代表として記録してください」と伝えます。Googleの中で、旧URLと新URLの関係を「同じものの新しい場所」として再接続するのが、301リダイレクトの役割です。

そのため301リダイレクトには、少なくとも次の3つの意味があります。

意味誰のため具体的な働き
ユーザーの転送サイト訪問者旧URLにアクセスした人を新URLへ自動で連れていく
クロール経路の再配線Googlebot旧URLではなく新URLを巡回するよう導く
URL移転の宣言Googleの検索処理新URLを代表URLとして扱い、旧URLのリンク・履歴・関連性を新URL側で理解してもらう

301リダイレクトはGoogleに新URLを代表として扱ってほしいと伝えるシグナル

301リダイレクトは、旧URLへアクセスしたユーザーを新URLへ転送するだけでなく、Googleに対して「検索結果では新URLを代表として扱ってほしい」と伝える、強い恒久移転のシグナルです。

ただし、301リダイレクトを設定したからといって、検索結果が即座に新URLへ切り替わるわけではありません。Googlebotが旧URLと新URLをクロールし、内容や周辺のシグナル(内部リンク・canonical・サイトマップなど)と合わせて処理する時間が必要です。

301リダイレクトは強いシグナルですが、サイト全体の整合性が揃ってはじめて、Googleにスムーズに伝わります。後ほど「301リダイレクトの本質はURL移行設計である」で詳しく扱います。

301・302・307・308の違い

301・302・307・308の違いを比較した図。意味・シグナル・主な用途で4種類のリダイレクトを並列比較。恒久的なURL変更は301または308、一時的な転送は302または307

リダイレクトには複数の種類があり、Googleへの伝わり方が変わります。

ステータスコード意味Googleへの伝わり方使うべき場面
301恒久的な移動新URLを代表として扱うシグナルになりやすいURL変更、ページ統合、ドメイン移行、HTTPS化
308恒久的な移動(HTTP/1.1)301リダイレクトと同様の恒久移転として扱われる301リダイレクトと同じ用途。フォーム送信のメソッドを維持したい場合
302一時的な移動恒久移転シグナルとしては弱いメンテナンス中の一時迂回、短期キャンペーン
307一時的な移動(HTTP/1.1)302と同様、恒久移転シグナルとしては弱い一時的な転送でHTTPメソッドを維持したい場合

302は「一時的な移動」を伝えるためのリダイレクトです。Googlebotは転送先を辿れますが、301リダイレクトのように新URLを恒久的な代表として扱ってほしい場合のシグナルにはなりにくいため、URL変更やページ統合には301リダイレクトを使うのが基本です。

308は301リダイレクトと同じ恒久移転を示します。ただし、SEO実務での認知度・対応環境の広さでは301リダイレクトが最も一般的なため、特別な理由がなければ301リダイレクトで問題ありません。

307は、フォーム送信時に転送先でも送信内容を維持したい場合などに使われる一時的リダイレクトで、SEO担当者が日常的に意識する場面はほぼありません。

301リダイレクトとcanonical・noindex・404/410・robots.txtの使い分け

301リダイレクト・canonical・noindex・404/410・robots.txtの5つのURL制御手段を比較した図。意味・使う場面・注意点を並列表示し、目的に応じた使い分けの判断軸を解説

URLの整理には、301リダイレクト以外にもcanonical・noindex・404/410・robots.txtといった選択肢があります。それぞれ伝えるシグナルが異なるため、目的に応じて使い分けましょう。

方法Googleへの意味使う場面注意点
301恒久的に新URLへ移転したURL変更、ページ統合、ドメイン移行関連性の高い新URLへ転送する
302/307一時的に別URLへ移動するメンテナンス、一時的なキャンペーン恒久移転には使わない
canonicalこのURLを正規として扱ってほしい重複URL、パラメータURL命令ではなくヒント。ページ自体は残る
noindex検索結果に出さないでほしい低価値ページ、管理系ページ評価統合目的では使わない
404/410ページが存在しない代替ページがない削除済みURL無理にトップページへ301リダイレクトしない
robots.txtクロールしないでほしい大量の不要URL群インデックス削除目的には不向き

判断基準を整理すると次のようになります。

URL整理の判断軸
  • 完全にURLを統合したい
    301リダイレクトを使う。最も強いシグナルで、旧URLは消える
  • ページは残すが正規URLを寄せたい
    canonicalを使う。ユーザーは元のURLにアクセス可能
  • 検索結果に出したくない
    noindexを使う。インデックスから除外される
  • 代替ページがない削除済みURL
    404または410を返す。無理に301リダイレクトしない
  • クロールさせたくない大量URL群
    robots.txtを使う。ただしGoogleがcanonicalを確認できなくなるので、canonical制御の代わりには使わない

301リダイレクトとcanonicalの違いをもう少し丁寧に整理すると、Googleに「移転として処理してほしい」のか「重複の代表指定として処理してほしい」のかという観点が中心になります。ページ自体を残す必要がないならcanonicalではなく301リダイレクト、残す必要があるならcanonicalが適切です。canonicalの詳細は「canonicalタグとは?書き方・設定が必要なケース・確認方法をわかりやすく解説」を参照してください。

301リダイレクトが必要な場面

301リダイレクトを設定すべき代表的な場面を整理します。

場面具体例
サイトリニューアル・URL構造変更/blog/article-123//column/seo/article-123/ に変えるなど
ドメイン変更会社名変更や独自ドメイン取得時のドメイン引っ越し
HTTPからHTTPSへの移行SSL化に合わせて全URLをhttpsに統一する
www・末尾スラッシュ・index.htmlの統一同じ内容が複数のURL形式で存在しているのをまとめる
重複コンテンツの統合似た内容のページを高品質な1記事に統合する
複数記事のリライト統合3〜5本に分散していた記事を網羅的なまとめ記事に統合する
商品・求人・サービスページの移転同一商品・同一求人を新しいURL構造に移す
閉鎖ページに後継ページがある場合古い特集・キャンペーンを後継ページに集約する

これらに共通するのは、旧URLにアクセスしたユーザーが期待する内容と、新URLで提供される内容が自然に対応していることです。後継ページが存在しないURLを無理に301リダイレクトする必要はありません(後述)。

301リダイレクトのSEOへの影響

301リダイレクトのSEOへの影響4つの効果を解説した図。リンクシグナルの統合・代表URLの切り替え・クロール効率の改善・データの集約。ただし関連性の低い転送や周辺シグナル未更新では期待通りに移行しないことがある

301リダイレクトのSEO効果は、単純に「評価を引き継ぐ」だけではありません。Googleが旧URLと新URLの関係を理解し、検索結果に表示するURLを切り替え、リンクシグナルやcanonical判断を新URLへ統合しやすくすることに意味があります。

旧URLのリンクシグナルを新URLへ統合しやすくする

旧URLに集まっていた被リンク・内部リンク・アンカーテキスト・クロール履歴といった情報を、Googleが新URL側で理解しなおす手がかりになります。

適切な301リダイレクトを設定すれば、旧URLに集まっていたリンク評価を新URLへ統合しやすくなります。ただし、リダイレクト先の関連性が低い場合や、内部リンク・canonical・サイトマップが旧URLのまま残っている場合は、期待通りに移行が進まないことがあります。「100%必ず引き継がれる」ものではない、という前提で考えましょう。

Googleに新URLを代表URLとして理解してもらいやすくなる

301リダイレクトは、Googleが正規URLを判断する際の強いシグナルになります。検索結果に表示されるURLが新URLへ切り替わり、ユーザーが見るURLの一貫性も保たれます。

ただし、置き換えには時間がかかります。Googlebotが旧URLと新URLを再クロールし、周辺シグナルも合わせて評価したうえで切り替わるため、サイト規模によっては数週間〜数ヶ月のスパンで考える必要があります。

Googlebotに見せるURLを整理できる

301リダイレクトは、Googlebotに対するURLの再配線でもあります。

旧URL・http版・wwwあり/なし・末尾スラッシュ違い・index.htmlあり/なし・古いカテゴリURL・統合済み記事の旧URLなどがサイト内に残っていると、Googlebotは不要なURL確認に時間を使います。301リダイレクトで正しく統合すれば、「この古いURL群ではなく、この新URLを見てください」と明確に伝えられます。

URLパラメータや並び替えURLが大量に発生するサイト(ECサイト、求人サイト、不動産サイトなどのデータベース型サイト)ほど、この観点は重要です。

Search Consoleやアクセス解析のデータを集約できる

301リダイレクトで正規URLを統一しておくと、GSCの検索パフォーマンスやGA4のページレポートで、データが新URLに集約されて表示されます。?utm_source=... のようなパラメータURLや旧URLがバラバラに並ぶ状態を防げるため、ページ単位の分析がやりやすくなります。

設定ミスがあると流入減少につながる

逆に、301リダイレクトの設定ミスやマッピングの粗さは、検索流入の大幅減少を招きます。「URLを変えたら検索順位が大幅に下がった」という典型的な失敗の多くは、リダイレクトの漏れ・関連性の低い転送・リダイレクトチェーン・周辺シグナルの未更新が原因です。

このあと「301リダイレクトでよくある失敗」で詳しく扱います。

301リダイレクトの本質はURL移行設計である

301リダイレクトの本質はURL移行設計であることを解説した図。301の基本フロー(旧URL→新URL)に加えて、新URLへ揃えるべき周辺シグナル(内部リンク・XMLサイトマップ・パンくず・canonical・構造化データ・hreflang・OGP・広告SNSリンク)を放射状に配置。URL移行の成功は『301設定』ではなく『周辺シグナルまで新URLに統一』で決まる

ここで本記事で最も伝えたい考え方を紹介します。

301リダイレクトは、Googlebotとユーザーに迷わせないためのURL移転設計です。

旧URLから新URLへ転送するだけでなく、内部リンク・canonical・XMLサイトマップ・構造化データまで含めて、サイト全体のシグナルを新URLへ揃える必要があります。

301リダイレクトは旧URLの記憶を新URLへ再接続する施策

旧URLには、Googleが過去に蓄積してきた情報があります。

旧URLにある情報意味
被リンク外部サイトから旧URLに集まっていたリンクの評価
内部リンクサイト内の他ページから旧URLに集まっていたリンク
アンカーテキスト旧URLが「何のページか」をGoogleに伝えてきた言葉
クロール履歴Googlebotが旧URLを過去にどう処理してきたか
検索パフォーマンスどんなクエリで表示・クリックされてきたか
ユーザー行動どこから訪れ、どう回遊してきたか

301リダイレクトは、これらをGoogleが新URL側で理解しなおすための再接続シグナルです。

1対1マッピングの精度が成功を決める

301リダイレクトの1対1マッピングの精度を解説した図。良い転送はA→Cへ直接転送し内容が近い後継ページへ揃える。悪い転送はトップページへ一括・関連性の低いページ・リダイレクトチェーン・転送先がnoindexや404など

301リダイレクトの本質は、旧URLと新URLの意味的な対応関係をGoogleに伝えることです。関連性の低いページへ転送すると、Googleは移転ではなく実質的な削除(soft 404相当)として扱う可能性があります。

良い転送と悪い転送を比較すると次のようになります。

観点良い転送悪い転送
転送先内容が近い後継ページトップページや無関係ページ
マッピング旧URLごとに個別対応一括で同じURLへ転送
経路A→Cへ直接転送A→B→Cのチェーン
新URLの状態200でindex可能noindex、404、5xx、再リダイレクト
内部リンク新URLへ更新済み旧URLのまま
サイトマップ新URLのみ旧URLやリダイレクトURLが混在
canonical新URLを指す旧URLや別URLを指す
ユーザー期待期待に合うページへ到達意図しないページへ飛ばされる

301リダイレクト設定後に揃えるべきURLシグナル

301リダイレクトは中心となる移転シグナルですが、周辺のシグナルが旧URLのままだと、Googleに矛盾した情報を送り続けることになります。

確認項目更新内容
内部リンク旧URLではなく新URLへ直接リンクする
XMLサイトマップ新URLのみを送信する
canonical新URLに自己参照canonicalを設定する
パンくず新URLのサイト構造に合わせる
構造化データurlmainEntityOfPage を新URLに更新する
hreflang各言語ページの新URLに更新する
OGP(og:url)新URLを指すように更新する
robots.txt新URLをブロックしていないか確認する
noindex移行用に入れたnoindexが残っていないか確認する
外部リンク重要な被リンク元には更新依頼を検討する
広告・SNSLPやプロフィールURLを新URLへ変更する

「301リダイレクトを設定したから移行完了」ではなく、サイト全体のシグナルを新URLへ揃えるところまでが移行プロジェクトだと考えてください。

301リダイレクトの設定方法

環境別に具体的な設定方法を解説します。SEO目的のURL移行では、サーバーサイドの301リダイレクトまたは308リダイレクトを基本にしましょう。JavaScriptリダイレクトやmeta refreshは、Googleのレンダリング処理に依存するため、重要なURL移行では最終手段として扱うのが安全です。

.htaccessで設定する(Apache)

Apacheサーバーを使っている場合は、.htaccessファイルに記述します。

個別ページのリダイレクト

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

ディレクトリ単位のリダイレクト

RedirectMatch 301 ^/old-directory/(.*)$ https://example.com/new-directory/$1

ドメイン全体のリダイレクト(httpからhttpsへ)

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
.htaccess編集時の注意

記述ミスがあるとサイト全体がアクセス不能になる可能性があります。編集前に必ずバックアップを取り、変更後はすぐにサイトが正常に表示されるか確認しましょう。

WordPressで設定する

WordPressの場合は、プラグインを使う方法が最も手軽です。

Redirectionプラグインを使えば、管理画面から旧URLと新URLを入力するだけで301リダイレクトを設定できます。コードを書く必要がなく、リダイレクトの一覧管理やログの確認も可能です。

少数のリダイレクトであれば、テーマの functions.php に以下のように記述する方法もあります。

function custom_redirects() {
    if ( is_page( 'old-page' ) ) {
        wp_redirect( 'https://example.com/new-page/', 301 );
        exit;
    }
}
add_action( 'template_redirect', 'custom_redirects' );

Nginxで設定する

Nginxサーバーを使っている場合は、サーバー設定ファイル(nginx.conf等)に記述します。

個別ページのリダイレクト

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

ドメイン全体のリダイレクト(httpからhttpsへ)

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Nginxは設定変更後にリロード(nginx -s reload)が必要です。.htaccessのようにファイル保存だけでは反映されない点に注意してください。

Cloudflareで設定する

Cloudflareを利用している場合は、Redirect RulesまたはBulk Redirectsで301リダイレクトを設定できます。

Redirect Rulesは、管理画面の「ルール」から個別のURLパターンに対してリダイレクトを設定する機能です。無料プランでも利用可能で、コードを書かずにGUI上で設定できます。

大量のリダイレクトが必要な場合はBulk Redirectsを使います。CSVでまとめてインポートでき、数百〜数千件のリダイレクトを一括管理できます。

サーバーサイドリダイレクトを基本にする

JavaScriptリダイレクトやmeta refreshは、ブラウザでHTMLが読み込まれた後に発火します。Googleはレンダリング処理を経てこれらのリダイレクトを認識しますが、レンダリングが失敗するとリダイレクト自体が見落とされる可能性があります。

設定後はブラウザ表示だけでなくHTTPレスポンスを確認しましょう。旧URLが301リダイレクトを返し、Locationヘッダーが最終的な新URLを指し、その新URLが200でindex可能な状態になっていることが重要です。

サイト移行・URL変更時の301リダイレクト手順

サイト移行・URL変更時の301リダイレクト手順を11ステップで解説したフロー図。旧URL一覧取得から1対1マッピング・実装・チェーン確認・GSC監視・1年以上の維持までの流れ。301は移行プロジェクトの一部

サイトリニューアルやドメイン変更では、301リダイレクト設定だけでなくプロジェクト全体として設計する必要があります。301リダイレクトはサイト移行プロジェクトの一部であり、移行前後の設計・実装・検証・監視まで含めて考えましょう。

STEP 1
旧URL一覧を取得する
XMLサイトマップ・GSCの「ページのインデックス登録」レポート・サーバーログ・クロールツールから旧URLを抽出します。検索流入や被リンクが多いURLを漏らさないことが重要です。
STEP 2
新URL一覧を取得する
新サイトのURL設計を整理し、サイトマップやステージング環境から新URL一覧を作ります。
STEP 3
旧URLと新URLの1対1マッピング表を作る
スプレッドシートに旧URLと新URLを1行ずつ対応づけます。記事・カテゴリ・商品・求人など、ページタイプごとに整理すると漏れが減ります。
STEP 4
検索流入・被リンク・CV貢献のあるURLを優先確認する
流入の上位ページや、外部リンクが多いページから個別に転送先を吟味します。これらのページが期待外れの転送先になると、流入減少のインパクトが大きくなります。
STEP 5
代替ページがないURLは404/410も検討する
後継ページがない場合は、無理にトップページへ転送せず、404または410を返すことも選択肢です。301リダイレクトは「削除の代替」ではなく「後継ページへの案内」と考えましょう。
STEP 6
301リダイレクトを実装する
サーバー環境に応じて .htaccess / nginx / Cloudflare / WordPressプラグインなどで301リダイレクトを設定します。マッピング表をそのまま使えるBulk Redirectsが大量URLでは便利です。
STEP 7
内部リンク・canonical・サイトマップを新URLへ更新する
301リダイレクトだけでなく、内部リンク・canonical・XMLサイトマップ・パンくず・構造化データ・hreflang・OGPを新URLへ揃えます。
STEP 8
リダイレクトチェーン・ループを確認する
A→B→Cのチェーンや、循環ループがないかをクロールツールやリダイレクトチェッカーで全件確認します。
STEP 9
GSCで新URLのインデックス状況を確認する
「ページのインデックス登録」レポートで新URLが順次インデックスされているか、旧URLが「ページにリダイレクトがあります」として整理されているかを追跡します。
STEP 10
旧URLへのクロール・流入・外部リンクを監視する
サーバーログやアクセス解析で旧URLへのアクセスが減っているか、被リンクの多いページは更新依頼を検討するかを判断します。
STEP 11
少なくとも1年以上リダイレクトを維持する
Google公式では、サイト移行時のリダイレクトは少なくとも1年維持することが推奨されています。可能ならそれ以上、外部リンクやアクセスが残るうちは長期維持が望ましいです。

サイト移行直後は、Googlebotが旧URLと新URLの関係を確認するため、通常より多くクロールすることがあります。大規模サイトでは、リダイレクト処理や新URLのレスポンスが遅くならないよう、サーバー容量・キャッシュ・CDN設定も合わせて確認しておきましょう。

301リダイレクトの確認方法

301リダイレクトの確認方法を4手段で解説した図。リダイレクトチェッカー・curl/HTTPヘッダー・Google Search Console・クロールツール/サーバーログ。Google側でURL移行が進む流れ(発見→クロール→canonical判断→インデックス→シグナル統合→収束→安定)も合わせて確認

設定後は、必ず動作を確認しましょう。301リダイレクトは設定して終わりではなく、Google側でURL移行が進んでいるかを継続的に監視するのが実務の中心です。

inSiteの無料リダイレクトチェッカーで確認する

inSiteの無料リダイレクトチェッカーの画面

inSiteの無料リダイレクトチェッカーを使えば、URLを入力するだけでリダイレクトの種類(301/302)と転送先、最終到達URLを確認できます。設定直後の「本当に301リダイレクトになっているか」「最終URLが正しいか」を素早くチェックできます。

無料でリダイレクトをチェックする →

ブラウザ・HTTPヘッダーで確認する

curl -I などでHTTPヘッダーを直接見る方法もあります。

curl -I https://example.com/old-page/

確認すべきは次の項目です。

確認項目理想状態問題例
旧URLのHTTPステータス301または308200、302、404、500
Locationヘッダー最終新URLを直接指定中間URLや旧URLを指定
リダイレクト回数1回2回以上のチェーン
最終URLのHTTPステータス200404、5xx、再リダイレクト
最終URLのindex可否index可能noindex、robots.txtブロック
canonical新URLに自己参照旧URLや別URLを指す

Google Search Consoleで確認する

GSCのURL検査ツールで旧URLを入力すると、リダイレクトの状態を確認できます。「ページのインデックス登録」レポートでは「ページにリダイレクトがあります」というステータスが表示されるので、意図したページが正しくリダイレクトされているか確認しましょう。

詳しい確認方法はページにリダイレクトがありますとは?原因と放置OKの判断基準で解説しています。

クロールツール・サーバーログで一括確認する

大量URLのサイト移行では、Screaming Frogなどのクロールツールでサイト全体を一括チェックすると、リダイレクトチェーン・ループ・404を漏れなく発見できます。サーバーログでGooglebotがどのURLを叩いているか確認することも、移行の進捗確認に役立ちます。

Google側でURL移行が進んでいるか確認する

301リダイレクトは、設定できているかだけでなく、Google側でURL移行が進んでいるかを見ることが重要です。

段階Google側で起きることサイト側で確認すること
発見Googlebotが旧URLから新URLへ到達する旧URLが301リダイレクトを返す
クロール新URLをクロールする新URLが200で高速に返る
canonical判断新URLを代表URLとして理解するcanonical・内部リンク・サイトマップを新URLへ揃える
インデックス新URLがインデックスされるGSCで新URLのインデックスを確認する
シグナル統合旧URLのリンク評価が新URLへ寄る検索表示・クリックが新URL側に移る
収束旧URLの露出が減る旧URLのインデックス・クリックが減る
安定新URLで順位・流入が安定する流入・CV・ログを継続監視する

inSiteでインデックス状況を継続監視する

inSiteはインデックス状況を毎日自動で取得するため、旧URLのインデックス解除と新URLのインデックス登録の進捗を日次で追えます。canonical不一致やリダイレクトエラー、内部リンクが旧URLのままになっているページなども継続的に検出できます。

合わせて、GSCの検索パフォーマンスレポートでオーガニック流入が移行前の水準まで回復しているかもチェックしましょう。リダイレクト設定後1〜2週間で流入が戻らない場合は、設定漏れやリダイレクトチェーンの発生を疑ってください。

\ リダイレクト後のインデックス状況を自動監視 /

inSite(インサイト)

インデックス状況を毎日自動取得。リダイレクト設定後の新URLが正しくインデックスされているか、旧URLのインデックスが解除されているか、canonical不一致や内部リンクの旧URL残置がないかを一画面で確認できます。

inSiteのインデックス状態チェック機能のダッシュボード 無料で試してみる ↗

301リダイレクトでよくある失敗

301リダイレクトでよくある失敗を8パターンで解説した図。トップページへ一括転送・関連性の低いページへ転送・1対1マッピング不足・リダイレクトチェーン/ループ・302のまま・内部リンクとサイトマップが旧URLのまま・canonicalとhreflangが旧URLのまま・転送先がnoindex/404/5xxなど

正しく設定したつもりでも、次のようなミスは頻繁に起きます。設定後に必ずチェックしましょう。

よくある失敗何が問題か
すべてトップページへ転送しているGoogleに「移転」ではなく「実質的な削除(soft 404相当)」と判断される可能性がある
関連性の低いページへ転送しているユーザーの期待と内容がズレるため、適切な移行とみなされにくい
1対1マッピングができていない旧URLごとに最適な新URLを決めずに、ざっくり統合してしまう
リダイレクトチェーンがあるA→B→Cのように何度も転送される。ユーザー速度低下・クロール効率低下
リダイレクトループがあるA→B→Aのように循環し、ページが表示されない
302のままになっている恒久移転シグナルが弱いため、新URLへの代表移行が進みにくい
内部リンクが旧URLのまま301リダイレクトを経由する内部リンクが大量に残り、シグナルが分散する
XMLサイトマップが旧URLのままGoogleに「旧URLもインデックスしてほしい」と矛盾した指示を送り続ける
canonicalが旧URLのまま301リダイレクトとcanonicalがバラバラの方向を指して、Googleが判断に迷う
hreflangや構造化データが旧URLのまま多言語サイトや構造化データの整合が崩れる
noindex・robots.txtブロックが残っている新URLがインデックスできない、または旧URLでGoogleが301リダイレクトを読めない
旧URLを早く削除して301リダイレクトを返せない404になり、被リンクの評価も失われる
リダイレクト先が404・5xx・noindex転送先が機能していないため、移転シグナルが成立しない
大規模移行後にサーバー負荷を見ていないクロール急増でレスポンスが遅くなり、移行が長引く
スマホ/PCで異なるリダイレクト挙動意図しないURLにユーザーが流れる

リダイレクトチェーンはなぜ問題なのか

リダイレクトチェーン(A→B→Cのように複数回連鎖)は、単なる速度問題ではありません。

リダイレクトチェーンが問題な理由
  • ユーザーの表示速度が遅くなる
  • Googlebotのクロール効率が下がる
  • 長いチェーンでは一部のユーザーエージェントが辿れない可能性がある
  • サイト移行時にどのURLが最終代表なのか分かりにくくなる
  • 大量ページではクロール負荷が増える

A→B→C ではなく A→C へ直接転送するのが基本です。詳しくは「リダイレクトチェーンとは?SEOへの影響と確認・解消方法を徹底解説」を参照してください。

トップページへの一括リダイレクトはNG

旧ページをすべてトップページにリダイレクトするのは避けましょう。Googleはユーザー体験の観点から、旧URLに期待していた内容と新URLの内容が大きくズレている場合、「移転」ではなく「ソフト404」相当として扱う可能性があります。

旧URLと関連性の高いページに1対1でマッピングするのが原則です。後継ページがない場合は、無理にトップページへ転送するのではなく、404または410を返すことも選択肢です。

開発チームとの連携が不足している

大規模なサイトリニューアルでは、SEO担当者と開発チームの連携が欠かせません。旧URLと新URLのマッピング表をSEO担当が作成し、実装は開発チームが行う体制を整えましょう。実装後にSEO担当がリダイレクトチェッカーで全件確認するフローを必ず入れてください。

AI検索時代に301リダイレクトが重要な理由

AI Overview、ChatGPT検索、Perplexityなど、生成AIを活用した検索体験の比重が高まっています。

AI検索時代でも、基本はGoogleがURLとコンテンツを正しく理解できる状態を作ることが重要です。重複URLや旧URLが散らばっていると、サイト内の情報の代表URLが分かりにくくなり、AI検索以前に通常のインデックス理解が濁ります。

AI検索時代には、ページ単位だけでなく情報の出どころや代表URLの一貫性も重要になります。301リダイレクトで旧URLや重複URLを適切に統合しておくことは、Googleがサイト内の情報を理解しやすくするうえでも有効です。

ただし、「301リダイレクトしないとAIに引用されない」という単純な話ではありません。AIに引用されるかどうかは、コンテンツの質・関連性・サイト全体の整合性など多くの要素が関わります。301リダイレクトは、その整合性を支える基盤の1つと考えてください。

よくある質問

301リダイレクトはいつまで維持すべきですか?
少なくとも1年は維持することがGoogle公式で推奨されています。可能であれば、それ以上、実質的には長期維持が望ましいです。1年は「外してよい期限」ではなく「Googleがシグナル移行を確認するための最低目安」と捉えてください。旧URLに外部リンクやユーザーアクセスが残っているなら、解除しないほうが安全です。
301リダイレクトでSEO評価は100%引き継がれますか?
「100%必ず引き継がれる」とは断定できません。適切な301リダイレクトを設定すれば、旧URLに集まっていたリンク評価を新URLへ統合しやすくなりますが、転送先の関連性が低い場合や、内部リンク・canonical・サイトマップが旧URLのまま残っている場合は、期待通りに移行が進まないことがあります。
302を長期間使うとどうなりますか?
302は「一時的な移動」を伝えるリダイレクトです。Googlebotは転送先を辿れますが、新URLを恒久的な代表として扱うシグナルにはなりにくいため、検索結果に旧URLが残り続けたり、新URLへの代表移行が進みにくかったりすることがあります。恒久的なURL変更には301リダイレクトまたは308を使ってください。
301リダイレクトと308は何が違いますか?
301リダイレクトも308も「恒久的な移動」を示すリダイレクトです。SEO観点ではほぼ同じ扱いですが、308はHTTP/1.1で標準化された比較的新しい仕様で、フォーム送信時にHTTPメソッドを維持できる特徴があります。一般的なSEO実務では301リダイレクトが最も馴染みがあり、サーバーやCMSの対応状況も広いため、特別な理由がなければ301リダイレクトで問題ありません。
301リダイレクトとcanonicalはどちらを使うべきですか?
ページを残す必要があるならcanonical、URLを完全に統合するなら301リダイレクトを使います。301リダイレクトは強い指示で、旧URLへのアクセスは新URLにリダイレクトされます。canonicalはヒントで、ユーザーは元のURLにアクセス可能なまま、評価だけを正規URLに寄せます。
301リダイレクトと404/410はどう使い分けますか?
同じ内容や後継ページがあるなら301リダイレクト、代替ページがないなら404または410が適切です。すべての削除済みページを301リダイレクトでトップページへ飛ばすと、Googleにソフト404相当として扱われる可能性があります。301リダイレクトは「削除の代替」ではなく「後継ページへの案内」と考えましょう。
削除ページをすべてトップページへ301リダイレクトしてもいいですか?
避けるべきです。ユーザーが旧URLに期待していた内容と、トップページの内容が一致しないため、Googleにソフト404相当として扱われる可能性があります。代替ページがある場合のみ、関連性の高いページに個別に301リダイレクトしましょう。
301リダイレクト設定後、内部リンクも新URLへ変更すべきですか?
はい。内部リンクが旧URLのままだと、リンク先で毎回301リダイレクトを経由することになり、クロール効率が下がります。また、Googleに「サイト内ではまだ旧URLが代表」というシグナルを送り続けるため、301リダイレクトとは反対方向のメッセージになります。リダイレクト設定後は、内部リンク・サイトマップ・canonicalの参照先もすべて新URLへ更新しましょう。
301リダイレクト設定後、サイトマップはどうすべきですか?
新URLのみを送信するように更新しましょう。旧URLやリダイレクトURLが混在していると、Googleに矛盾したシグナルを送ることになります。
301リダイレクトはページ速度に影響しますか?
1回のリダイレクトであれば、体感できるほどの遅延は発生しません。ただし、リダイレクトが複数回チェーンしている場合はCWVに悪影響を与えるため、A→Cへ直接転送するように修正してください。
リダイレクトチェーンは何が問題ですか?
表示速度が遅くなるだけでなく、Googlebotに余計な経路を辿らせ、URL移転のシグナルを分かりにくくする問題でもあります。長いチェーンでは一部のユーザーエージェントが辿れない可能性もあります。基本はA→Cへの直接転送にしましょう。
WordPressプラグインで301リダイレクトを設定しても問題ありませんか?
問題ありません。RedirectionプラグインなどはサーバーサイドのリダイレクトをWordPress経由で処理するため、SEO上は通常の301リダイレクトと同じように扱われます。ただし、プラグインに依存しすぎると将来の移行時に管理が複雑になるため、可能であればサーバー側(.htaccessやNginx)の設定も検討しましょう。
AI検索時代でも301リダイレクトは重要ですか?
はい。AI検索時代には、ページ単位だけでなく情報の出どころや代表URLの一貫性も重要になります。301リダイレクトで旧URLや重複URLを適切に統合しておくことは、Googleやその先のAIがサイト内の情報を理解しやすくするうえで有効です。ただし「301リダイレクトしないとAIに引用されない」と単純化せず、コンテンツの質や関連性とセットで考えましょう。
301リダイレクトエラーとはどういう意味ですか?
「301リダイレクトエラー」と呼ばれることがありますが、正確には301リダイレクトはエラーではなくリダイレクト(転送)のステータスコードです。URLが恒久的に移動したことを示しており、ブラウザや検索エンジンに新しいURLへの転送を指示する正常な動作です。

301リダイレクトと並んで重要な重複対策がcanonicalタグです。ページを残したまま評価を集約したい場合の設定方法を確認しておきましょう。

関連記事 canonicalタグとは?書き方・設定が必要なケース・確認方法をわかりやすく解説

まとめ

301リダイレクトは、旧URLから新URLへアクセスを転送するだけの処理ではありません。Googleに対して「このURLは恒久的に移転したので、今後は新URLを代表として扱ってほしい」と伝えるURL移転シグナルです。

ただし、301リダイレクトを設定しただけでURL移行が完了するわけではありません。内部リンク、XMLサイトマップ、canonical、パンくず、構造化データ、hreflangなど、サイト全体のURLシグナルを新URLへ揃えることが重要です。

301リダイレクトの本質は、Googlebotとユーザーに迷わせないURL移行設計です。サイトリニューアルやURL変更を行う際は、旧URLと新URLのマッピング、設定後の確認、インデックス移行の監視まで含めて対応しましょう。

関連記事 重複コンテンツとは?SEOへの影響と対策方法をわかりやすく解説 関連記事 インデックスカバレッジとは?全18ステータスの対処優先度と確認方法
この記事のポイント
  • 301リダイレクトは、URLが恒久的に移転したことをユーザーとGoogleに伝えるHTTPステータスコード
  • 301リダイレクトは単なる転送ではなく、Googleに新URLを代表として扱ってほしいと伝えるURL移転シグナル
  • 302は一時的な移動、301/308は恒久的な移動を示す
  • URL変更・サイトリニューアル・ページ統合では旧URLと新URLの1対1マッピングが重要
  • 301リダイレクト設定後は、内部リンク・canonical・サイトマップ・構造化データも新URLへ揃える必要がある
  • リダイレクトチェーン、トップページ一括転送、関連性の低い転送は避ける
  • サイト移行後はGSC・リダイレクトチェッカー・ログ・検索流入で継続的に確認する