301リダイレクトの設定方法｜.htaccess・WordPress・Next.jsでの書き方

「301リダイレクトなら.htaccessに数行貼れば終わるはず」と考えて作業に入る方をよく見かけます。国内の共用レンタルサーバーはApacheやその互換のLiteSpeedを使っている例が多く、.htaccessに書く方法が長く定番として紹介されてきたためです。ところが同じ記述を貼っても転送されず、サーバーが500エラーを返すことがあります。

しかし、サイト移行時のURL設計を支援してきた弊社の立場から言えるのは、301リダイレクトでつまずくかどうかは、記述を書き始める前の段取りでほぼ決まる、ということです。稼働しているサーバーの種類を確かめ、どの範囲を転送するのかを先に決めておけば、記述そのものは数行で終わります。ページ数の多いリニューアルでも、時間がかかるのは旧URLと新URLの対応表を作る工程です。

本記事では、転送をどこに書くかの判断から、.htaccessでのページ・ディレクトリ・ドメイン単位の記述、WordPressやNext.jsでの設定、curlで転送を確かめる手順まで、制作支援の現場の視点で順を追ってお伝えします。

301リダイレクトを書く場所は、サーバー環境で決まる

301リダイレクトとは、旧URLへのアクセスに対して、サーバーが「このページは新しいURLへ恒久的に移りました」と返すHTTPステータスコードです。ブラウザは受け取った転送先へ自動的に移動し、検索エンジンは新旧URLの結び付きを認識します。

設定方法を調べると`.htaccess`の記述例が真っ先に出てきますが、.htaccessが読み込まれるのはApache系のサーバーだけです。国内の共用レンタルサーバーはApacheかその互換であるLiteSpeedを採用している例が多いため定番の方法として紹介されますが、Nginx単体の構成やVercelのようなホスティングでは、ファイルを置いても無視されます。

自分のサイトがどれに当たるか分からないときは、サーバーのコントロールパネルに`.htaccess`編集機能があるかを見ます。あればApache系と考えて差し支えありません。制作を外部に委託している場合は、稼働しているWebサーバーの種類を先に確認しておくと、あとの手戻りが減ります。

301と302は「元に戻す予定があるか」で選ぶ

302リダイレクトは一時的な転送を表すコードで、キャンペーンページへの誘導やメンテナンス中の退避など、いずれ旧URLに戻す前提の場面で使います。判断に迷ったら、旧URLを将来また使うかどうかだけを考えれば十分です。

URLの変更、ドメイン移転、常時SSL化、重複ページの統合は、いずれも旧URLに戻す予定がありません。恒久的な移転を伝える301を選ぶことになります。

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

.htaccessで301リダイレクトを設定する手順

`.htaccess`はディレクトリ単位で設定を上書きするファイルで、通常はドキュメントルート（`public_html`や`www`など、サイトの入口となるフォルダ）に置きます。編集そのものは数行の追記で終わりますが、書き損じるとサイト全体が表示できなくなるため、順番を決めて進めるのが安全です。

`.htaccess`の編集で怖いのは、記述ミスが1行あるだけでサーバーが500 Internal Server Errorを返し、サイト全体が閲覧できなくなる点です。控えを取っていれば戻すだけで復旧します。手順2を飛ばさないでください。

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

ページ・ディレクトリ・ドメイン単位での書き方

301リダイレクトの記述は、Apacheの`mod_alias`（`Redirect`・`RedirectMatch`）と`mod_rewrite`（`RewriteRule`）の2系統に分かれます。単純な1対1の転送なら前者、条件分岐や正規表現を伴うなら後者、という使い分けが実務では定着しています。

ページ単位で転送する

1ページだけを別のURLへ移すときは、`mod_alias`の1行で足ります。

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

左側は転送元のパス、右側は転送先の絶対URLです。転送元をパス、転送先をURL全体で書く点を取り違えると動きません。同じ処理を`mod_rewrite`で書くと次のようになります。

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

RewriteRuleは行末のフラグを省略すると301になりません。`R=301`が301を返す指定、`L`はここで処理を打ち切る指定です。`L`を忘れると後続のルールも評価され、意図しない多重転送につながります。

ディレクトリ単位で転送する

フォルダ配下をまとめて移す場合は、`RedirectMatch`で正規表現を使うと1行で済みます。

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

`(.*)`が受け取った文字列を`$1`で転送先に引き渡すため、`/old-dir/a.html`は`/new-dir/a.html`へ着きます。階層構造をそのまま移すリニューアルではこの形が使えますが、フォルダ名だけでなくファイル名も変わる場合は個別に書く必要があります。

ドメイン単位で転送する

ドメインごと移転するときは、リクエストされたホスト名を条件にして全パスを引き渡します。

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

`RewriteCond`が条件、直後の`RewriteRule`が処理です。`[NC]`は大文字小文字を区別しない指定になります。旧ドメインの`.htaccess`に置く記述である点に注意してください。新ドメイン側に書いても、旧ドメインへのアクセスはそもそも新サーバーに届きません。

mod_rewrite - Apache HTTP Server Version 2.4

🌐 httpd.apache.org

外部リンク

※ RewriteRuleのフラグや条件式の一覧は、Apache HTTP Server公式ドキュメント「mod_rewrite」を参照しています。

関連記事：GA4でコンテンツの成果を計測する方法——記事ごとのCV貢献を可視化する設定

https化とwww統一を1ファイルにまとめる書き方

URLの正規化は、同じ内容のページが複数のURLで開ける状態を1本に絞る作業です。`http`と`https`、`www`のありなし、`index.html`のありなし。この3つが放置されていると、内容が同一のページが最大で8通りのURLで存在することになり、被リンクや評価が分散します。

httpからhttpsへ転送する

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

ロードバランサーやCDNを前段に置いている構成では、Webサーバーまでの通信がhttpのままになり、`%{HTTPS}`が常に`off`と判定されて転送が無限に繰り返される場合があります。その環境では`%{HTTP:X-Forwarded-Proto}`を条件に使います。

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

wwwのありなしを統一する

`www`ありに寄せるか、なしに寄せるかはどちらでも構いません。すでに運用しているサイトなら、被リンクや広告の入稿URLが多い方に合わせるのが無難でしょう。`www`ありからなしへ寄せる記述は次のとおりです。

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

記述の順番でつまずく

複数のルールを並べるときに見落としやすいのが評価順です。リダイレクトは書いた順に上から評価されます。https化とwww統一を別々の`RewriteRule`で書くと、`http://www.example.com/`へのアクセスがhttpsへ1回、www除去でもう1回転送され、301が2回続くチェーンになります。

条件をまとめて1回の転送で着地させると、この重複が消えます。

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

WordPressとサーバー管理画面での設定

WordPressをApache系サーバーで動かしている場合、`.htaccess`は使えます。ただしWordPress自身がパーマリンク処理用の記述を自動生成しており、`# BEGIN WordPress`から`# END WordPress`で囲まれた範囲は更新時に上書きされます。転送の記述はこの範囲の外に書いてください。

FTPを触らずに管理したい場合は、プラグインを使う方法もあります。Redirectionのような転送管理プラグインは、管理画面から旧URLと新URLを入力するだけで設定でき、404が発生したURLの記録も残ります。

Web担当者

サーバーの管理画面にもリダイレクト機能があります。.htaccessとプラグイン、どれで設定するのが正解でしょうか。

Writers-hub
編集部

どれか1か所に寄せるのが正解です。3つとも最終的には同じ転送を行うため、複数に散らばると「なぜここに着くのか」を追えなくなります。運用担当がFTPを触れないならプラグイン、開発者が触るなら.htaccessという決め方で問題ありません。

寄せ先を決める材料として、プラグイン方式の性質を整理しておきます。

ファイル単位の移動が多いリニューアルでは、サーバー側に寄せた方が確実です。逆に、公開後に記事のURLを個別に変えていく運用が続くなら、担当者が自分で追加できるプラグイン方式に利があります。

.htaccessが使えない環境での301リダイレクト

近年はヘッドレスCMSやフレームワークで構築したサイトが増え、`.htaccess`という概念がそもそも存在しない案件が珍しくなくなりました。この場合、転送はアプリケーションの設定ファイルかサーバー設定に書きます。

Next.jsで設定する

Next.jsは設定ファイルに転送ルールを列挙する方式です。

// next.config.js
module.exports = {
  async redirects() {
    return [
      { source: '/old-page', destination: '/new-page', permanent: true },
      { source: '/blog/:slug', destination: '/news/:slug', permanent: true },
    ]
  },
}

`permanent: true`が恒久的な転送を表し、返るステータスコードは308になります。301ではない点に驚くかもしれませんが、308は301と同じく恒久的な移転を示すコードで、Googleもサーバー側の永続的リダイレクトとして301と並べて扱っています。`:slug`のような動的な区切りを使えば、パスの一部を引き継いだ一括転送も書けます。

Nginxで設定する

Nginxはサイトごとの設定ファイルに記述し、反映には設定の再読み込みが必要です。

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

個別ページなら`location`ブロックで指定します。`.htaccess`のようにファイルを置けば効く仕組みではないため、サーバーへのアクセス権限がない場合は管理者に依頼することになります。

CDNの管理画面で設定する

CloudflareなどをDNSの前段に置いている構成では、CDN側でリダイレクトルールを設定できます。オリジンサーバーに触れない状況でも転送を追加できる反面、サーバー側にも同じ転送が残っていると二重に評価されます。どちらで管理するかを決めて、片方に寄せてください。

リダイレクトの種類ごとにGoogleがどう扱うかは、公式ドキュメントに整理されています。実装方式を選ぶ前に一度目を通しておくと判断が早くなるはずです。

リダイレクトと Google 検索 | Google 検索セントラル | Documentation | Google for Developers

リダイレクトの違いや、それらを Google がどう解釈するのか、Google 検索にどう役立つのかについて解説します。

🌐 developers.google.com

外部リンク

※ リダイレクトの種類とGoogleの扱いについては、Google検索セントラル「リダイレクトとGoogle検索」を参照しています。

リニューアルで大量のURLを転送するときの進め方

ページ数が数百を超えるリニューアルでは、`.htaccess`の書き方よりも先に決めることがあります。どの旧URLをどの新URLに向けるかという対応の設計です。旧URLと新URLの対応表を作る作業が実質の本体です。記述はその表を機械的に変換するだけの工程になります。

対応表は、旧サイトのURLを漏れなく集めるところから始めます。XMLサイトマップ、Search Consoleのページレポート、クロールツールの結果を突き合わせると、リンクが切れて放置されている旧ページも拾えます。

• 旧サイトの全URLを一覧化した（サイトマップとSearch Consoleの両方から）
• 各URLに新URLを割り当てた（内容が最も近いページを選ぶ）
• 転送先が決まらないURLを抽出し、扱いを決めた
• 検索流入や被リンクの多い順に並べ、上位から個別に検証した

対応先が決まらない旧ページを、まとめてトップページへ向ける処理は避けてください。Googleは内容の異なるページへの転送を、転送ではなくソフト404として扱うことがあります。旧ページと関連するカテゴリページや一覧ページへ向けるか、それも難しければ404を返す判断の方が、結果としてサイト全体の評価に響きません。

設定後に転送を確認する方法

ブラウザで旧URLを開いて新URLに着けば成功、と判断するのは早計です。ブラウザは301の結果をキャッシュするため、一度成功すると設定を消しても転送され続けます。実際に何が返っているかは、コマンドで直接見るのが確実でしょう。

curl -sIL https://example.com/old-page.html | grep -iE "^(HTTP/|location:)"

`-I`はヘッダーだけを取得する指定、`-L`は転送を追う指定です。出力にステータスコードと転送先が並ぶため、301が何回続いているかまで一度に読み取れます。ここに`301`が2行以上並んでいたら、転送が中継されている状態です。

Search Console側では、ドメインを変更した場合にアドレス変更ツールを使います。旧ドメインと新ドメインの両方をプロパティとして登録したうえで申請すると、移転の認識が早まります。

• 旧URLが1回の転送で新URLに着いている
• 返っているコードが301である（302や200になっていない）
• httpとhttps、wwwのありなしのすべての組み合わせが同じURLに着く
• 転送先のページ自体が200を返している
• ドメイン変更の場合、Search Consoleでアドレス変更を申請した

※ サイト移転の手順とアドレス変更ツールの使い方は、Google検索セントラル「URL変更を伴うサイト移転」に手順がまとまっています。

サイト・ホームページ移行について | Google 検索セントラル | Documentation | Google for Developers

ドメイン変更、URL 変更を伴うサイト移転方法をご覧ください。Google 検索結果への影響を抑えながら移行する、SEO のベスト プラクティスを解説します。

🌐 developers.google.com

外部リンク

設定でつまずきやすい失敗

記述そのものが正しくても、周辺の設定が原因で転送が効かない、あるいは効いているのに評価が引き継がれない状況が起きます。実際の案件で見かける頻度が高いものを挙げます。

• 旧URLをrobots.txtで拒否したまま転送を設定する
• アクセスが残っているうちに転送を解除する
• 転送先をさらに転送し、301を2回3回と中継させる
• 受け皿のないページをまとめてトップページへ向ける
• 内部リンクとcanonicalタグを旧URLのまま残す

最初の項目は影響が読みにくいので補足します。robots.txtで旧URLを拒否すると、転送そのものが読まれません。クローラーは旧URLへアクセスできず、301が返っていることを知る手段がなくなります。ドメイン移転で旧サイトを閉じるつもりでrobots.txtを書き換えるのは、転送の効果を自分で消す操作になります。

内部リンクとcanonicalタグの修正も後回しにされがちです。転送が効いていれば表示上は問題なく見えるため、気づかれないまま残ります。ただしサイト内のリンクをたどるたびに1回余分な転送が挟まる状態で、クロールの効率は落ちる。転送の設定が終わったら、サイト内に旧URLの記述が残っていないかを検索して置き換えてください。

経営者

転送は設定したのに、リニューアル後に検索流入が戻りません。設定を疑うべきでしょうか。

Writers-hub
編集部

まず1回の転送で着いているかを確認し、そのうえで転送先のページ内容を比べてください。転送は移転先を伝える手段であって、中身が別物になっていれば評価は同じところに戻りません。旧ページで扱っていた内容が新ページから抜け落ちていないかを、流入の多いページから順に見ていくのが早い進め方です。

転送の設定を疑って何日も調べたあとで、原因が新ページの情報量だったという例は珍しくありません。旧サイトで詳しく書いていた項目が、リニューアルの過程で削られていたというパターンです。

301リダイレクトについてよくある質問

設定の現場で受けることが多い質問をまとめます。

質問の傾向を見ていると、記述そのものより「設定したあとに何を確認すればよいか」で迷っている方が多い印象があります。確認の項目を先に決めておくと、設定作業も迷いにくくなるはずです。

まとめ

301リダイレクトの設定は、記述を覚える作業というより、環境を確かめてから転送の単位を決める作業です。`.htaccess`が使えるかどうかを最初に確認し、ページ単位・ディレクトリ単位・ドメイン単位のどれで書くかを決めれば、記述自体は数行で済みます。

リニューアルのように対象が多い場合は、対応表の設計に時間をかけるほど後工程が軽くなります。設定後はcurlで1回の転送になっているかを確かめ、robots.txtと内部リンクの整合も併せて見てください。

合同会社Writers-hubでは、SEO記事の制作に加えて、サイト移行時のURL設計や移行後の流入回復の支援も行っています。転送の設定は終わったものの結果に不安が残る場合は、実績データを見ながら次の手を一緒に整理できます。