301リダイレクトは書く前に2つ確かめる｜自社12通りの実測

「記事で見たコードを .htaccess に貼ったのに、何も起きない」。301リダイレクトの設定でつまずくとき、原因は書き方ではないことがあります。そもそもそのファイルが読まれていない、という場合です。

結論から言えば、コードを探す前に確かめることが2つあります。自分のサーバーで .htaccess が効くのか。そして、その転送は本当に自分で書く必要があるのか。

この記事では、サーバーの種類を30秒で確かめる手順を示します。当社で12通りのURLを試して、どこまでが設定なしで転送されていたかも実測で公開しました。読み終えれば、自分の環境で効く1本を書き、効いていることを自分で確認できます。

先に結論｜コードを貼る前に確かめることが2つある

301リダイレクトのコードを探しているなら、貼る前に確かめてほしいことが2つあります。自分のサーバーでそのコードが動くのか。そして、そもそも自分で書く必要があるのかです。

この2つを飛ばすと、貼っても効かないコードと格闘するはめになります。書かなくてよかったものを、わざわざ書くことにもなりかねません。

この章では、確かめるべき2点と、読み終えたときにできるようになることを先に示します。

• サーバーによっては .htaccess が効かない
• 書く必要がある転送は思ったより少ない
• この記事で書けるようになること

サーバーによっては .htaccess が効かない

301リダイレクトの解説を開くと、そのほとんどが .htaccess というファイルにコードを書く方法を教えています。「301リダイレクト」などで検索して見つかる主要な解説記事10本を、実際に開いて数えました。

記事10本が扱っていた内容	本数
.htaccess の書き方を載せている	9
Nginx の書き方に触れている	3
設定したあとの確認方法を書いている	9

.htaccess は Apache というWebサーバーソフトの仕組みです。別のソフトである Nginx は、このファイルを読みません。

つまり Nginx を使っている人が、Nginx に触れていない7本のどれかを読んだとします。そこに載っている .htaccess の例は1行も動きません。

動かない理由も書かれていないため、原因にたどり着くのが難しくなります。

他人事ではありません。当社のサーバーも Nginx です。

書く必要がある転送は思ったより少ない

自分で書かないといけない転送は、思っているより少ないはずです。そもそも書く必要があるのか、というのが2つ目の確認になります。

当社のメディアで、「これは自分で転送を書かないといけない」と考えがちな入力を12通り試しました。末尾のスラッシュがない、www が付いている、http のまま、といった形です。

結果は次のとおりでした。

CMSやサーバーの既定の設定が、すでに処理していたということです。自分で書く必要があるのは、この自動処理の外側だけになります。

具体的には、中身が別のURLへ移動したときと、ページを削除したときの2つです。

この記事で書けるようになること

この記事が扱うのは、自分の環境で正しく効く1本の転送を書き、効いていることを自分で確認するところまでです。

順番を先に書いておきます。まず301というステータスコードが何を返しているのかを見ます。次に、書く前に確かめる2点を手順にしました。

そのうえで Apache・Nginx・WordPress それぞれの書き方を、公式ドキュメントの構文に沿って示します。

なお、301と302のどちらを使うかという判断は本記事では扱いません。恒久的な移転なのか一時的なものなのかで選ぶ話は、リダイレクトとは？恒久か一時かで選ぶで整理しました。この記事は、301を使うと決めたあとから始まります。

301 Moved Permanently とは

301は、Webサーバーがブラウザに返す3桁の番号のひとつです。番号だけでなく、次に行くべきURLがセットで返されます。

この章では、301がエラーではないこと、実際の応答の中身、公式がどの方法を勧めているかの3点を扱います。

• 301はエラーではなく「移転しました」の合図
• 応答ヘッダの中身を1本見てみる
• サーバー側で返すのが公式の推奨

301はエラーではなく「移転しました」の合図

「301エラー」という言葉を見かけることがありますが、301はエラーではありません。

HTTPの決まりごとは「HTTP Semantics」という文書が定めています。3桁の番号は百の位ごとに区分され、それぞれ名前が付いています。

番号	区分の名前	意味
3で始まる	Redirection	転送。301はここ
4で始まる	Client Error	エラー。404はここ
5で始まる	Server Error	エラー。サーバー側の不具合

出典: RFC 9110「HTTP Semantics」（2022年6月）の Section 15。エラーという名前が付いているのは4番台と5番台のほうです。

Googleの公式ドキュメントも、301を「ページが別の場所に完全に移転したことを意味します」と説明しています。壊れているのではなく、引っ越しの案内が出ている状態です。

当社で12通りのURLを試したときも、404が返ったのは実在しないスラッグを指定した1通りだけでした。転送されたものはすべて301です。

応答ヘッダの中身を1本見てみる

リダイレクトの正体は、たった2行です。

当社の記事URLから末尾のスラッシュを外してアクセスすると、サーバーは次のように応答しました。

HTTP/1.1 301 Moved Permanently
Location: https://machibun.co.jp/media/url-keyword/

1行目が番号、2行目が次に行くべきURLです。ブラウザはこの2行を読んで、自動的に Location のURLへ移動します。

これは HTTP/1.1 で取得したときの表示です。同じURLを curl で叩くと、HTTP/2 で応答が返ります。表記も HTTP/2 301・location: と小文字混じりになりますが、中身は同じものです。

画面には一瞬で次のページが出るため、見ている人は転送されたことに気づきません。

だからこそ、設定できたかどうかを画面で判断できないという問題が起きます。この点はあとの章で扱います。

301リダイレクトを設定するとは、この2行を返すようにサーバーへ指示することです。書き方はサーバーによって違いますが、返しているものはどれも同じです。

サーバー側で返すのが公式の推奨

転送を実現する方法はいくつかありますが、Googleははっきり優先順位を示しています。

検索エンジンの結果に表示されるページの URL を変更する必要がある場合は、可能な限りサーバー側の永続的なリダイレクトを使用することをおすすめします。これは、Google 検索とユーザーを確実に正しいページに導くための最善の方法です。

出典: リダイレクトと Google 検索（2026年4月17日更新）

HTMLのタグやJavaScriptで転送する方法もあります。ただしこれらは後回しです。同じページには「サーバー側のリダイレクトまたは meta refresh リダイレクトを行えない場合にのみ、JavaScript リダイレクトを使用してください」とあります。

この記事がサーバーの設定を扱うのは、そのためです。次の章では、その設定を書く前に確かめる2つを見ていきます。

書く前に確かめる2つのこと

設定を書き始める前に、2つだけ確かめてください。どちらも数分で終わる作業です。

この章では、サーバーの種類を確かめる手順と、すでに転送されている入力の実測を扱います。あわせて、自動では処理されない範囲と、自分で書くべき対象も整理します。

• 1つ目｜自分のサーバーが何かを30秒で確かめる
• 2つ目｜すでに301されている入力を数えた
• 自動では面倒を見てくれない範囲
• 自分で書くのは「中身が移動したURL」だけ

1つ目｜自分のサーバーが何かを30秒で確かめる

Apacheなのか、Nginxなのか。ここが分かれば、書くべきファイルと構文が決まります。

もっとも手軽なのは、応答ヘッダの Server という項目を見る方法です。ターミナルが使えるなら、次の1行で分かります。

curl -sI https://example.com/ | grep -i "^server:"

ターミナルを使わないなら、ブラウザの検証ツールを開いてネットワークのタブでページを読み込み直してください。一覧の先頭の項目を選ぶと、応答ヘッダの中に Server が見つかります。

2026年8月31日に当社で同じことをすると、コーポレートサイトもメディアも nginx と返ってきました。Apacheの仕組みである .htaccess は、当社では読まれません。

なお Server は設定で隠したり書き換えたりできる項目です。配信を肩代わりする仕組みや、アクセスを中継するサーバーを挟んでいることもあります。その場合は、前段のソフト名が返ります。空欄だったり見慣れない名前だったりしたら、契約しているサーバーの管理画面か提供元の案内で確認してください。

2つ目｜すでに301されている入力を数えた

当社では12通り中9通りが、設定を1行も書かずに301で正規のURLへ着きました。2つ目の確認は、そもそも書く必要があるのか、です。

当社のメディアで実在する記事を1本選び、「転送を書かなければ」と考えがちな入力を12通り試しました。2026年8月31日に読み取りだけを行い、設定は一切変更していません。

入力した形	最初の応答	正規のURLに着いたか
末尾のスラッシュなし	301	着いた
http のまま	301	着いた
www 付き	301	着いた
www 付き＋http	301	着いた（2回転送された）
index.php 付き	301	着いた
投稿IDでの指定	301	着いた
スラッグの一部だけ	301	着いた（推測された）
二重スラッシュ	301	着いた
末尾のスラッシュが2つ	301	着いた
大文字を含むパス	200	着かない
クエリ文字列付き	200	転送不要
実在しないスラッグ	404	着かない

自分で手を打つか考えることになるのは、301が返らなかった3通りだけです。まずは、残る9通りがなぜ書かずに済んだのかを見ていきます。

WordPressには、URLの揺れを正規の形へそろえる仕組みが標準で入っています。公式リファレンス（2026年8月31日閲覧）の説明は「サイトのURLを基準に、正規のURLへ寄せる仕組み」です。転送の番号として 301 を指定しているのは、同じページに載っている関数のソースのほうです。

ただし、9通りすべてをWordPressがやっていたわけではありません。同じ日に応答ヘッダを取り直すと、層が2つに分かれていました。

表にある X-Redirect-By は、その転送を誰が返したかを示す応答ヘッダです。代表的な4つを抜き出しました。

入力	X-Redirect-By	応答時間	返していた層
http のまま	なし	57.1ms	サーバー
www 付き	WordPress	259.1ms	CMS
末尾スラッシュなし	WordPress	276.2ms	CMS
スラッグの一部	WordPress	267.3ms	CMS

http からの転送だけは X-Redirect-By が付かず、応答も4.5〜4.8倍ほど速く返ってきました。おそらく、WordPressを起動する前にサーバーが返しています。

ただし応答時間はいずれも1回ずつの計測です。回線の状況で上下するので、桁の違いを見る程度に受け取ってください。

この区別は、あとで「なぜ2回転送されるのか」を読み解くときに効いてきます。

面白いのは、スラッグを途中までしか入力しなかった場合も正規のURLに着いたことです。公式リファレンスには「存在しないURLが入力されたとき、正しいリンクを探そうとする」という趣旨の記述があります。

自動では面倒を見てくれない範囲

すべてを自動でやってくれるわけではありません。WordPressの公式リファレンスには、正規化を行わない対象がはっきり書かれています。

この公式リストには載っていませんが、大文字を含むパスも転送されませんでした。この件はリダイレクトとは？恒久か一時かで選ぶで扱っています。

そして最も重要なのが、実在しないURLです。12通りのうち1通りだけ404が返りました。

中身が移動した、あるいは削除された場合、CMSは行き先を知りません。知らないものは転送のしようがないということです。

自分で書くのは「中身が移動したURL」だけ

ここまでを整理すると、自分で301を書くべき対象は絞られます。

• 中身のあるページが、別のURLへ移動した
• ページを削除して、代わりの行き先がある

URLの表記の揺れは、多くの場合すでに処理されています。末尾のスラッシュや www の有無をそろえるために設定を書き足す前に、一度そのURLを叩いてみてください。すでに301が返っているなら、書く必要はありません。

なお、この12通りは当社が選んだ入力であって、すべてのパターンを網羅したものではありません。使っているCMSやサーバーの設定によって結果は変わります。自分の環境で同じことを確かめるのが確実です。

環境別｜301リダイレクトの書き方

ここからが本題です。書く場所と構文は、サーバーによって変わります。前の章で確かめた種類に合わせて、必要なところだけ読んでください。

この章では Apache・Nginx・WordPress の3通りを扱います。あわせて「書いたのに効かない」で最も多い原因も見ます。

• Apache（.htaccess）の書き方
• 「書いたのに効かない」で一番多い原因
• Nginx の書き方
• WordPress でスラッグを変えるとき

Apache（.htaccess）の書き方

Apache なら .htaccess というファイルに1行足すだけです。ファイルはサイトの公開フォルダの一番上に置きます。

公式ドキュメントによると、構文は Redirect [status] [URL-path] URL です。status のところに permanent と書くと301になります。公式の説明は「Returns a permanent redirect status (301) indicating that the resource has moved permanently」です。

# 別のドメインへ移した場合
Redirect permanent "/old-page/" "https://example.com/new-page/"

# 同じサイト内での引っ越しなら、行き先はパスだけでよい
Redirect permanent "/old-page/" "/new-page/"

2つ目の書き方は公式の使用例にも Redirect "/one" "/two" として載っています。同じサイトの中で移すだけなら、行き先を https:// から書く必要はありません。

ここで押さえておきたいのが、Redirect は前方一致だという点です。公式には「Additional path information beyond the matched URL-path will be appended to the target URL」とあり、上の1行は /old-page/sub/ のような配下のパスも /new-page/sub/ へ送ります。

これはフォルダごと引っ越すときに便利な性質です。逆に、そのページ1枚だけを転送したいなら、次のように終端を指定します。

# そのページ1枚だけを転送する場合
RedirectMatch permanent "^/old-page/$" "/new-page/"

ここで1つ注意があります。status を省くと301になりません。

公式には temp、つまり302が既定だと書かれています。恒久的な移転のつもりなら permanent を必ず書いてください。

いま使った RedirectMatch [status] regex URL は、正規表現でパターンを指定したいときの書き方です。フォルダ単位の引っ越しは Redirect のままでできるので、正規表現が要る場面だけで使えば足ります。公式は使い分けをこう説明しています。

mod_alias is designed to handle simple URL manipulation tasks. For more complicated tasks such as manipulating the query string, use the tools provided by mod_rewrite

出典: Apache HTTP Server 2.4 ドキュメント mod_alias（2026年8月31日閲覧）

単純な引っ越しは Redirect、クエリ文字列をいじるような複雑な処理は別の仕組み、という切り分けです。

「書いたのに効かない」で一番多い原因

書いたのに効かないとき、まず疑うところは決まっています。

症状	原因	確かめ方
何も起きない	サーバーが Apache ではない	応答ヘッダの Server を見る
何も起きない	.htaccess の使用が許可されていない	サーバーの設定か提供元の案内を見る
何も起きない	旧URL側の書き方が違う	スラッシュで始まっているか見る
302で転送される	permanent の書き忘れ	応答の番号を見る

2つ目は気づきにくいところです。Redirect を .htaccess で使うには、サーバー側でその使用が許可されている必要があります。

公式のディレクティブ一覧にある Override: FileInfo という表記が、その許可の種類を表しています。許可が下りていない環境では、ファイルを置いても読まれません。

3つ目も見落としやすいところです。公式には旧URL側の条件がはっきり書かれています。

The old URL-path is a case-sensitive (%-decoded) path beginning with a slash. A relative path is not allowed.

出典: 同上

訳すと、旧URL側はスラッシュで始まるパスで書く必要があり、相対パスは使えないということです。old-page/ ではなく /old-page/ と書いてください。大文字と小文字も区別されます。

ここでもうひとつ。日本語版のドキュメントには、別の注意書きとして「URL-path は相対パスではなく、完全な URL でなければなりません」という記述が残っています。現行の英語版に同じ文はありません。

この日本語の一文だけを読むと、行き先まで https:// から書かないといけないように読めます。ですが公式の使用例は Redirect "/one" "/two" です。条件がかかっているのは旧URL側だと考えてください。

Nginx の書き方

Nginx には .htaccess にあたる仕組みがありません。サイトの設定ファイルを開き、server { } の中に書きます。置く場所を間違えると、設定の読み込みそのものが通りません。

書き方は公式ドキュメントに2通り載っています。1つは return code URL; です。301・302・303・307・308 では転送先のURLを指定できると明記されています。

server {
    # ここはサイトごとの設定。すでにある server ブロックの中に足す

    # 1ページを別のURLへ移した場合
    location = /old-page/ {
        return 301 https://example.com/new-page/;
    }
}

もう1つは rewrite regex replacement [flag]; です。flag に permanent と書くと301になります。

permanent returns a permanent redirect with the 301 code

出典: nginx ngx_http_rewrite_module（2026年8月31日閲覧）

server {
    # すでにある server ブロックの中に足す（server を二重に書かない）

    # パターンでまとめて移す場合
    rewrite ^/old/(.*)$ https://example.com/new/$1 permanent;
}

どちらを使うべきかについて、公式は優劣を書いていません。1本ずつ指定するなら前者、パターンでまとめるなら後者、という使い分けで足ります。

.htaccess との大きな違いは、設定ファイルを直しただけでは反映されない点です。順番は決まっています。

• 1. 構文をチェックする／nginx -t で確認できる。書き間違いがあればこの時点で止まる
• 2. 設定を読み込み直させる／ここで初めて反映される

構文チェックを飛ばして読み込ませると、書き間違いがあったときにサイト全体が落ちることがあります。チェックを先に通すのが鉄則です。

チェックの nginx -t はどの環境でも同じですが、実行にはサーバーへログインする権限が要ります。管理画面しか触れない場合は、提供元の案内で「設定の反映」「構文チェック」にあたる操作を確認してください。

WordPress でスラッグを変えるとき

WordPress の記事URLを変えるなら、転送は自分で用意してください。標準の推測機能に任せると、どこへ着くか分かりません。

前の章で、スラッグを途中までしか入力しなくても正規のURLへ着いたと書きました。それなら変更後も勝手に転送されるのでは、と思うかもしれません。

実際に、スラッグを変えたときに近い入力を6通り試しました。こちらも2026年8月31日に、読み取りだけを行っています。

入力した形	応答	着いた先
元のスラッグ＋接尾辞	404	—
元のスラッグ＋連番	404	—
語順を入れ替えた	404	—
日付を含む旧形式風	404	—
単語1つだけ	301	まったく別の記事
無関係な語	404	—

6通りのうち5通りは404でした。唯一転送された1通りも、意図した記事ではありません。別の記事に着いています。

これは不具合ではありません。公式リファレンスにあるとおり、存在しないURLに対して「正しいリンクを探そうとする」仕組みが働いた結果です。探した結果が当たるとは限らない、というだけのことになります。

したがって、スラッグを変えるなら転送は自分で用意するものと考えてください。サーバー側で書けるなら、ここまでに見た Redirect か return 301 が使えます。

設定ファイルに触れない場合でも、方法はあります。探す順番は2つです。

• 1. 契約しているサーバーの管理画面／「リダイレクト」「転送設定」といった項目が用意されていることがある。あればここが一番簡単
• 2. WordPress の管理画面／「リダイレクト」「転送」を扱う機能を追加すれば、記事ごとに旧URLと新URLを登録できる

どちらの場合も、登録したあとに確かめる作業は同じです。次の章のコマンドで、番号と行き先を見てください。

なお、この6通りも当社が選んだ入力です。すべての形を試したわけではありません。

書いたあとに確かめる

設定を書いたら、必ず応答を確かめてください。画面を見ても、効いているかどうかは分かりません。

この章では、なぜ画面で判断できないのか、1本のコマンドで終点まで追う方法、そして当社に残っている2段の転送を扱います。

• ブラウザではなく応答を見る
• 1本のコマンドで終点まで追う
• 当社にも2回転送される経路が1本ある

ブラウザではなく応答を見る

旧URLを開いて新しいページが表示された。これだけでは確認になりません。

理由は2つあります。1つは、301でも302でも画面の見え方が同じだからです。permanent を書き忘れて302になっていても、ブラウザには新しいページが出ます。

もう1つは、301がブラウザに記憶されるためです。一度301を受け取ったブラウザは、次から設定を確かめません。そのまま転送先へ向かいます。

設定を直したのに直る前の動きが残るのは、これが理由です。確認するときは、記憶を消すか、記憶を持たない方法で見てください。

確実なのは、応答ヘッダを直接見ることです。前に出した2行、つまり番号と Location が意図どおりかを目で確かめます。

1本のコマンドで終点まで追う

ターミナルが使えるなら、次の1行で経路が全部見えます。

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

-I は本文ではなくヘッダだけを取る指定、-L は転送を終点まで追う指定です。番号と行き先だけが順番に並ぶので、何回転送されたかがそのまま読めます。

grep に -i を付けているのは、大文字と小文字を区別させないためです。Location の頭文字は応答によって変わります。HTTP/1.1 で返ってくる場合は大文字始まりなので、-i がないと行き先が表示されません。

見るべき点は3つです。

• 番号が301か／302になっていたら permanent の書き忘れ
• 行き先が意図どおりか／別のページに着いていないか
• 何回転送されたか／1回で着くのが理想

ターミナルを使わない場合は、ブラウザの検証ツールのネットワークタブでも同じことが分かります。転送のたびに行が1つ増えるので、行数がそのまま転送の回数です。

当社にも2回転送される経路が1本ある

当社にも、終点まで2回転送される経路が1本あります。3つ目の「何回転送されたか」は、書いた本人が見落としがちなところです。

12通りを試したなかで、1つだけ終点まで2回転送された入力がありました。http で、しかも www が付いている形です。

順	応答	直したところ	返したと考えられる層
1	301	http を https へ	サーバー
2	301	www を外す	CMS
3	200	到着	—

前の章で見た層の違いを当てはめると、1段目はサーバー、2段目はWordPressが返していると考えられます。担当している層が違うので、それぞれが自分の仕事だけをして、結果として2段になったという見方です。

ただし、この2段については各段の X-Redirect-By を測っていません。前の章の層別の実測と応答時間から当てはめた推定です。

条件を別々のところに書くと、こうして段が増えます。

誤解のないように書いておくと、これが事故だという話ではありません。http と www を別々に扱う設定はよくある形ですし、Googleは転送を追跡すると明記しています。当社は検索順位を計測していないので、この2段が順位に影響したかどうかも分かりません。

それでも、1回で着く書き方にできるなら、そのほうが待ち時間は短くなります。転送のたびに通信が1往復増えるからです。応答時間の差についてはリダイレクトとは？恒久か一時かで選ぶで実測しています。

なお、URLを何本もまとめて移す場合は、1本ずつ確かめる作業が現実的ではなくなります。移行全体の進め方はサイトリニューアルのSEOで、対応表の作り方から扱いました。

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

設定するときに迷いやすい点を4つ選びました。なお、301と302のどちらを選ぶかという判断はリダイレクトとは？恒久か一時かで選ぶで扱っています。

301エラーとはどういう意味ですか

301はエラーではなく、転送を表す番号です。HTTPの決まりごとを定めたRFC 9110では、3で始まる番号がRedirectionという区分にあたります。エラーという名前が付いているのは、4で始まるClient Errorと5で始まるServer Errorのほうです。301は3番台なので、壊れているのではなく引っ越しの案内が出ている状態にあたります。

.htaccessに書いたのに転送されません

まずサーバーがApacheかどうかを確かめてください。.htaccessはApacheの仕組みで、Nginxはこのファイルを読みません。応答ヘッダのServerという項目で30秒ほどで分かります。Apacheだった場合は、旧URL側の書き方を見てください。Apache公式は「A relative path is not allowed」と明記しています。

転送は何回まで重ねてよいですか

回数の上限を示した記述は、今回確認したGoogle公式のページ「リダイレクトと Google 検索」にはありませんでした。ただし転送のたびに通信が1往復増えるため、1回で着く形にできるならそのほうが待ち時間は短くなります。当社にも2回転送される経路が1本あり、暗号化の有無を直す転送とwwwの有無を直す転送が別々に効いていました。

WordPressならスラッグを変えても自動で転送されますか

当てにしないでください。WordPressには存在しないURLから正しいリンクを探そうとする仕組みがあります。ただし当社が6通り試したところ、5通りは404でした。唯一転送された1通りも、意図した記事ではなく別の記事に着いています。不具合ではなく、探した結果が当たらなかっただけです。スラッグを変えるなら転送は自分で用意してください。

まとめ

301リダイレクトを書く前に、確かめることが2つあります。自分のサーバーが何かということと、その転送が本当に必要かということです。当社で12通り試したところ、9通りは設定を1行も書かずに301で転送されていました。

自分で書くのは、中身が別のURLへ移動したときと、削除して代わりの行き先があるときだけです。書いたら応答ヘッダを見て、番号と行き先と転送の回数を確かめてください。

• サーバーがApacheでなければ .htaccess は読まれない
• 旧URL側はスラッシュで始まるパスで書く
• permanent を省くと302になる
• スラッグを変えたら転送は自分で用意する

大規模なサイトでURLの移行を控えている場合は、当社のSEO相談で設計から一緒に整理します。