301リダイレクトとは？.htaccessでの設定方法・必要なケース・注意点を解説

301と302の違いは、転送が永続的か一時的かという点と、検索結果に表示されるURLが入れ替わるかどうかにあります。301は新しいURLを検索結果に表示させ、302はリダイレクト元のURLを表示させたままにします。

（出典：Google 検索セントラル「リダイレクトと Google 検索」）

選ぶ基準は、旧URLを再び使う予定があるかどうかです。二度と戻さないURL変更には301を、一時的に別ページを見せるメンテナンス告知には302を設定します。永続的な移転に302を使うと、検索結果には旧URLが残り続け、評価も新URLへ移りません。

判断に迷った場合は、旧URLのページを今後も残すかどうかで決めましょう。残す予定がなければ301が適切です。Apacheの.htaccessでは、Redirectディレクティブでstatusを省略すると302が返るため、301を意図する場合はpermanentの指定を忘れないようにしてください。

（出典：Apache HTTP Server「mod_alias」）

301リダイレクトを設定すると、旧URLを開いた訪問者を自動で新しいページへ届けられます。古いURLは、サイト運営者が管理できない次のような場所にも残り続けます。

転送を設定しないまま旧URLを削除すると、これらの経路からの訪問者は404エラーページに着き、そのまま離脱してしまうでしょう。旧URLに対応する新しいページへ転送しておけば、訪問者は自分でサイト内を探し直さずに目的の情報へたどり着けます。

301リダイレクトは、旧URLが集めた検索評価を新URLへ集約する仕組みです。Googlebotはリダイレクトを追跡し、インデックス登録の過程で、リダイレクト先が正規版であることを示すシグナルとして301を使用します。

（出典：Google 検索セントラル「リダイレクトと Google 検索」）

重複ページを整理する場面でも、リダイレクトはリダイレクト先が正規ページになるべきことを強く示すシグナルとして扱われます。長年かけて獲得した被リンクの評価を捨てずに移せる点が、301リダイレクトを設定する最大の理由です。

（出典：Google 検索セントラル「重複した URL を統合する」）

旧URLに対応するURLがあるにもかかわらず、転送を設定しない場合、旧URLは404エラーになります。内部リンクや外部リンクなどから旧URLが引き続き発見されると、Googlebotが旧URLをクロールし、404エラーの確認にクロールが使われる状態です。Search Consoleのページのインデックス登録レポートにも「見つかりませんでした（404）」として表示される可能性があります。

数ページの404であれば影響は限られますが、数百ページ規模のリニューアルで転送を設定しなければ、404の件数はページ数と同じだけ増えます。リンクをたどるたびにエラーページへ着く状態は、訪問者から見てもサイトへの信頼を損なう要因です。

301リダイレクトは、検索結果に載るURLを旧URLから新URLへ切り替える合図です。Googleは永続的なリダイレクトについて、検索結果に新しいリダイレクト先を表示すると明記しています。

（出典：Google 検索セントラル「リダイレクトと Google 検索」）

転送を設定した旧URLは、Search Consoleのページのインデックス登録レポートで「ページにリダイレクトがあります」と表示され、非正規URLとしてインデックスから外れます。新旧のURLが両方とも検索結果に残る状態を避けられるため、同じ内容のページ同士で評価が割れる事態も防げるでしょう。

（出典：Google Search Console ヘルプ「ページのインデックス登録レポート」）

個別ページのURLを変えたときは、旧URLから新URLへ1対1で301リダイレクトを設定します。カテゴリの階層を変えた場合や、日本語URLを英数字に置き換えた場合も対象です。URLが1文字でも違えば、検索エンジンは別ページとして扱います。

グランネットが支援した着物のオンラインストアでは、2026年4月に同じページへ小文字URLと大文字URLの両方でアクセスできる状態が見つかりました。小文字URLから大文字URLへ301リダイレクトを設定し、アクセスできるURLを1つに統一しています。

対象URLが多い場合は、実装の進め方も検討材料になります。別の支援先では、2026年5月にパラメータ付きURLの301リダイレクトを、URLの静的化や正規化とあわせて検討しました。対象URLが多く制作会社側の実装負荷が大きいと判明したため、優先度の高いURLから段階的に301リダイレクトを実装する方針へ切り替えています。

ドメインの移転やサイトリニューアルでは、旧サイトの全ページを新サイトの対応ページへ転送します。Googleが小規模から中規模のサイトにすすめているのは、一度にサイトのすべてのURLを移転する方法です。大規模サイトであれば、分割して区分ごとに移す進め方も選べます。

（出典：Google 検索セントラル「URL の変更を伴うサイト移転」）

グランネットでは、2026年6月にサイトリニューアルの設計を担当した案件で、公開直後の目標を「アクセスを伸ばす」ではなく「301リダイレクトの設定漏れなどによるアクセス減少を防ぎ、現状を維持する」と定めました。あわせて旧サイトのアクセス状況を確認し、残すページと統合して301リダイレクトするページを選別しています。アクセス増加を目指すのは、公開から3〜6か月後を目安とする計画です。

内容が重なる複数ページを1つにまとめるときは、統合元のページから統合先へ301リダイレクトを設定します。Googleも、重複ページを取り除く方法としてリダイレクトを挙げています。分散していた評価を1つのURLへ集約できる手段です。

（出典：Google 検索セントラル「重複した URL を統合する」）

不動産業の支援先では、2026年4月から5月にかけて、同じテーマで内容が重なる旧記事と新記事が並存していました。SEO評価が分散する可能性があったため、旧記事から新記事へ301リダイレクトを設定して評価を集約しています。この案件はWordPressで構築されていたため、プラグインでの対応が可能と判断しました。

サイト構成そのものを見直す場面でも、ページの統合と301リダイレクトはセットで使います。ホームページ制作会社の支援先では、2026年5月から6月にかけて、コラム・サービス紹介・ブログが別々のURL群に分かれ、サイト構成が分散していました。そこで1つのドメイン配下へ統合した上で旧URLから301リダイレクトを設定し、あわせてサービスページとトップページの統合も実施しています。

SSL化では、httpのURLからhttpsのURLへサイト全体に301リダイレクトを設定します。httpsを導入しただけでは両方のURLでページが開けるため、検索エンジンにhttpsのURLを正規URLとしてより明確に示すためにも、301リダイレクトの設定が必要です。

同一ドメイン内でのプロトコル変更であるため、Search Consoleでの手続きは簡略です。GoogleはHTTPからHTTPSへの移行についてアドレス変更ツールの使用は不要と案内しています。

（出典：Google 検索セントラル「URL の変更を伴うサイト移転」）

サイト内のリンクやサイトマップのURLがhttpのまま残っていると、リンクをたどるたびに転送が発生します。SSL化の作業では、転送設定と同時にサイト内のURLもhttpsへ書き換えましょう。

wwwのあり・なしやindex.htmlの有無が混在している場合は、片方から片方へ301リダイレクトを設定してURLを1つに絞ります。同じ内容が表示されるとしても、検索エンジンはURLの文字列が異なれば別ページとして扱う可能性があるためです。

グランネットの自社サイト（https://grannet.co.jp/）では、https://grannet.co.jp/とhttps://grannet.co.jp/index.htmlの両方でトップページにアクセスできる状態がありました。SEO評価や被リンクが分散する可能性を考慮し、.htaccessでindex.html付きのURLからスラッシュで終わるURLへ301リダイレクトを設定して正規化しています。

ただし、設定した転送が意図どおりに動くとは限らないため、設定後に動作を確認する機会を組み込んでおきましょう。不動産仲介会社の支援先では、2026年2月にwwwのあり・なしを統一する301リダイレクトを設定したところ、意図した動作になりませんでした。いったん設定を元に戻し、月次定例会で状況を確認した上で、wwwありに統一する形で301リダイレクトを設定し直しています。

ドメインを変更したときは、旧ドメインのルートディレクトリに置いた.htaccessで、パス部分を保ったまま新ドメインへ転送します。旧ドメインをold-example.com、新ドメインをnew-example.comとすると、記述は次の通りです。

RewriteEngine onRewriteCond %{HTTP_HOST} ^(www\.)?old-example\.com$ [NC]RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]

2行目のRewriteCondで転送対象のホスト名を判定し、3行目のRewriteRuleで新ドメインへ転送します。$1には旧URLのパス部分が入るため、下層ページも同じ階層のまま引き継がれます。R=301は301リダイレクトの指定、Lはルールセットの処理を停止する指定です。

（出典：Apache HTTP Server「RewriteRule フラグ」）

個別ページのURLを変えたときは、旧ファイル名から新ファイル名への転送を1行ずつ記述します。/old-page.htmlを/new-page.htmlへ移した場合の記述は次の通りです。

RewriteEngine onRewriteRule ^old-page\.html$ /new-page.html [R=301,L]

mod_aliasのRedirectディレクティブでも同じ転送を設定できます。permanentを指定すると301、省略すると302が返るため、永続的な移転では必ずpermanentを書き添えてください。

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

（出典：Apache HTTP Server「mod_alias」）

転送するページが数十件に及ぶ場合は、旧URLと新URLの対応表を先に作り、1行ずつ記述漏れがないか照合しながら進めると確実です。

ディレクトリ構成を変えたときは、ディレクトリ名を書き換えて配下のファイルをまとめて転送します。/old-dir/配下のページを/new-dir/配下へ移した場合の記述は、次の通りです。

RewriteEngine onRewriteRule ^old-dir/(.*)$ /new-dir/$1 [R=301,L]

(.*)が旧ディレクトリ配下のパスとファイル名を受け取り、$1として新ディレクトリの後ろへ引き渡します。/old-dir/service/price.htmlは/new-dir/service/price.htmlへ転送されるため、ページごとに1行ずつ書く必要はありません。

ファイル構成を変えずにディレクトリ名だけを変更した場合に限り、この書き方が使えます。

URLの正規化では、統一したい形式へ片方向の301リダイレクトを設定します。wwwなしのURLをwwwありへ統一する場合は、次のように記述します。

RewriteEngine onRewriteCond %{HTTP_HOST} ^example\.com$ [NC]RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

index.htmlを含むURLを、スラッシュで終わるURLへ統一する場合の記述は次の通りです。

RewriteEngine onRewriteCond %{THE_REQUEST} \s/+(.*/)?index\.html[\s?] [NC]RewriteRule ^(.*)index\.html$ /$1 [R=301,L]

グランネットの自社サイト（https://grannet.co.jp/）でも、この記述で正規化を実施しました。index.htmlやindex.phpの有無、wwwのあり・なしといった違いがあると、検索エンジンから別ページとして認識される可能性があります。評価を1つのURLへ集約する判断から、https://grannet.co.jp/index.htmlからhttps://grannet.co.jp/へ301リダイレクトを設定しました。

wwwありとwwwなしの両方向に転送を書くと、ブラウザが2つのURLを往復し続けるリダイレクトループに陥ります。統一先はどちらか一方に決め、逆向きの記述を残さないよう注意してください。

SSL化では、httpでのアクセスを検知してhttpsの同一URLへ転送します。ドメインやパスを指定せずに書けるため、1つの記述でサイト全体へ適用できるのが利点です。

RewriteEngine onRewriteCond %{HTTPS} offRewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

%{HTTP_HOST}にアクセスされたドメイン、%{REQUEST_URI}にパス以降が入るため、転送先はhttpsに変わるだけで同じページになります。設定後は、httpのトップページと下層ページの両方を開いて、httpsへ転送されることを確かめましょう。

WordPressでは、プラグインの管理画面から旧URLと新URLを入力するだけで301リダイレクトを設定できます。代表的なプラグインであるRedirectionは有効インストール数200万以上で、301リダイレクトの管理と404エラーの記録に対応するプラグインです。

（出典：WordPress.org「Redirection」）

Redirectionは既定ではWordPress側で転送を処理しますが、設定を変えると.htaccessファイルへリダイレクトを自動保存できます。Nginx環境で運用している場合は、登録したリダイレクトをNginx用のrewriteルールとして書き出す機能も用意されています。投稿のURLを変更したときにリダイレクトを自動生成できるため、.htaccessを直接編集するより手順を減らせるでしょう。

Nginxを直接設定する場合は、サーバー設定ファイルにreturnディレクティブを記述します。httpからhttpsへ転送する記述は次の通りです。

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

rewriteディレクティブを使う場合は、末尾にpermanentを付けると301、redirectを付けると302を返します。

（出典：nginx「Module ngx_http_rewrite_module」）

301リダイレクトは、旧URLに付いた評価を良し悪しにかかわらず新URLへ引き継ぎます。被リンクや検索順位といったプラスの評価だけを選んで移すことはできません。

過去にスパム的な被リンクを大量に受けていたページや、手動による対策を受けた履歴があるページを転送先へつなぐと、そのマイナス評価も新しいURLへ持ち込まれます。買い取ったドメインや長く放置していたサイトを統合する場面では、転送を設定する前にSearch Consoleの手動による対策レポートと被リンクの状況を確認しておきましょう。評価に不安が残るURLは、転送せず削除して404を返す判断も選択肢に入ります。

301リダイレクトは、設定してから長期間維持することが前提です。Googleはサイト移転の解説で、リダイレクトをできるだけ長く保持すること、一般的には1年以上が目安であることを示しています。古いURLを指すリンクの再処理に時間がかかるためです。

（出典：Google 検索セントラル「URL の変更を伴うサイト移転」）

早い段階で.htaccessから記述を削除すると、検索エンジンは旧URLと新URLの関係を判断できなくなり、旧URLへのアクセスは404エラーになります。外部サイトからのリンクや紙媒体に記載されたURLは何年も残るため、解除する場合は旧URLへのアクセスがゼロに近づいたことをアクセス解析で確かめてから判断してください。

301リダイレクトの転送先は、旧URLと内容が対応する個別ページを指定します。旧サイトの全ページを新サイトのトップページへまとめて転送すると、訪問者は目的の情報を自分で探し直すことになり、ページごとの評価も引き継がれません。

グランネットが支援した1社では、2026年7月に本体サイトの一部ページを別サイトへ301リダイレクトし、SEO評価を移す案を検討しました。301リダイレクトで評価を引き継げること自体は確認できたものの、本体サイトの評価低下、移行先が上位表示される保証がないこと、内容が重複するリスクを考慮する必要がありました。移行先との関連性を評価した上で、実施を見送っています。

対応するページが新サイトにない場合は、無理に転送せず、旧ページを残す判断も検討しましょう。

リダイレクトチェーンとは、旧URLから新URLへ転送された先で、さらに別のURLへ転送が続く状態です。Googleはサイト移転の解説で、リダイレクトチェーンを避けて最終的な宛先へ直接リダイレクトするよう案内しています。

（出典：Google 検索セントラル「URL の変更を伴うサイト移転」）

ホームページ制作会社の支援先では、2026年5月から6月にかけて、301リダイレクトを設定したことで内部リンクがリダイレクト元のURLを経由する状態になっていました。リダイレクトを維持したまま、サイト内のリンクを転送先のURLへ直接張り替え、リダイレクトチェーンを解消してクローラビリティを改善しています。

.htaccessへリダイレクトを追記するときは、もともと書かれていた記述を消さないよう注意しましょう。.htaccessはWebサーバーの挙動全般を制御するファイルで、Basic認証によるアクセス制限、カスタム404ページの指定、WordPressのパーマリンク設定など、リダイレクト以外の役割も担っています。

追記は既存の記述の前後へ行い、編集前のファイルを別名で保存しておけば、不具合が起きてもすぐ元に戻せます。

最も確実な確認方法は、旧URLをブラウザで開き、ステータスコードと遷移先の両方を見ることです。ブラウザの検証ツールを開いてネットワークタブを表示し、旧URLへアクセスすると、最初のリクエストに対する応答が301と表示されます。アドレスバーの表示だけでは302との区別が付かないため、ステータスコードまで確認してください。

確認は、トップページだけでなく下層ページでも行います。グランネットが支援した1社では、2026年6月に301リダイレクトの設定自体は有効だったものの、一覧ページから詳細ページへの遷移だけが404エラーになっていました。URL変更対応の途中でこの不具合を見つけ、遷移先を見直して正しいページへリダイレクトされるよう修正しています。

サイト内の主要な導線をたどりながら、リンク先が404にならないかをあわせて点検すると、記述漏れを早い段階で拾えます。

検索結果への反映は、Search ConsoleのURL検査ツールで確認します。旧URLを検査すると「Google が選択した正規 URL」の欄に、Googleが正規と判断したURLが表示されます。ここに新URLが表示されていれば、Googleが新URLを正規URLとして認識していることを確認できます。

（出典：Google Search Console ヘルプ「URL 検査ツール」）

サイト全体の状況は、ページのインデックス登録レポートで把握できます。転送済みの旧URLは「ページにリダイレクトがあります」に分類され、非正規URLとしてインデックスから外れます。「リダイレクト エラー」に旧URLが計上されている場合は、転送が正しく完結していないため記述を見直してください。

（出典：Google Search Console ヘルプ「ページのインデックス登録レポート」）

車検サービス事業者の支援先では、2026年7月にHTTPSを正規URLとして運用しながら、HTTP側がHTTPSへ転送されないままインデックスされていました。定例会で状況を確認し、HTTPからHTTPSへ301リダイレクトを設定してURLをHTTPSへ統一する処理を行いました。

転送するURLが数十件を超える場合は、URLの一覧をまとめて検査できるツールを使います。クローラー型のツールに旧URLのリストを読み込ませると、URLごとにステータスコードと最終的な転送先が一覧で出力されるため、301以外が返っているURLや転送が2回以上続くURLをその場で洗い出せます。

日用品メーカーの支援先では、2026年5月に301リダイレクトを設定済みだったにもかかわらず、HTTPとHTTPSの両方のトップページにアクセスできる状態が残り、SEO評価が分散していました。施策の説明時にこの問題を確認し、HTTPからHTTPSへ301リダイレクトを正しく設定してURLをHTTPSへ統一しています。

一括確認の際は、旧URLと想定転送先を並べた対応表を用意し、ツールの出力と1行ずつ突き合わせます。判定の基準は、想定どおりのページへ転送されているかどうかです。転送が発生していることだけを見て合格としないよう注意してください。

HTTPによるリダイレクトは、サーバーがステータスコードと転送先を返して転送を行う方法です。.htaccessでの301リダイレクトも、この仕組みで動きます。ブラウザ側の設定に左右されず、HTMLページ以外の画像やPDFにも適用できる点が強みです。永続的な転送には301と308、一時的な転送には302・303・307が用意されています。

なお、HTTPリダイレクトはサーバーが応答を返す段階で処理されるため、ページの読み込みを待たずに転送が完了します。表示速度の面でも、meta refreshやJavaScriptによる転送より有利です。

meta refreshは、HTMLのheadタグ内にmeta要素を記述して転送する方法です。サーバーの設定を変更できないレンタルサーバーや、CMSの制約で.htaccessを触れない環境で使われます。記述は次の通りです。

<meta http-equiv="Refresh" content="0; URL=https://example.com/" />

content属性の先頭の数字は、転送までの待ち時間を秒数で示します。MDNは、アクセシビリティを高めるため常に0を設定するよう案内しています。0秒を指定したmeta refreshは、Googleも永続的なリダイレクトとして解釈する対象です。

（出典：MDN Web Docs「HTTP リダイレクト」）

ただし、この方法はHTMLでしか動作せず、画像やPDFの転送には使えません。HTTPリダイレクトを設定できる環境であれば、そちらを優先しましょう。

JavaScriptによるリダイレクトは、window.locationプロパティに転送先のURLを設定して実行します。ログイン状態や画面幅など、ブラウザ側でしか判定できない条件に応じて転送先を分ける場面で使われる方法です。

window.location = "https://example.com/";

Googleは、サーバー側のリダイレクトまたはmeta refreshリダイレクトを行えない場合にのみJavaScriptリダイレクトを使うようすすめています。理由として挙げられているのは、レンダリングが失敗することがある点です。訪問者がJavaScriptを無効にしている環境では、転送そのものが働きません。

（出典：Google 検索セントラル「リダイレクトと Google 検索」）

3種類の中では最も条件に左右されるため、恒久的なURL変更には向きません。サーバー設定を変更できるようになった時点で、HTTPリダイレクトへ切り替えることをおすすめします。