.htaccessの書き方：リダイレクト・正規化の設定例

この記事の要点：

• .htaccessは、Apache（とその互換のウェブサーバー）で、ディレクトリごとに設定を変えるためのファイルです。リダイレクトやURLの正規化を、サーバーの管理者権限が無くても設定できます。nginxでは使えません。
• 1文字の書き間違いで、サイト全体が「500 Internal Server Error」になることがあります。編集の前に必ず元のファイルを保存し、エラーが出たら保存した内容に戻します。
• リダイレクトは、単純な転送ならRedirectMatch、条件を付けるならRewriteRuleを使います。RewriteRuleのRフラグは、番号を書かないと302（一時的）になるため、R=301と明記します。
• WordPressでは、自分で書くルールを「# BEGIN WordPress」より上に置きます。マーカーの間はWordPressが書き換えることがあります。
• 保存したら、curlで応答の番号と転送先を確かめます。httpとhttps、wwwの有無などの組み合わせが、1回の転送で正規のURLに届くかを見ます。

.htaccessとは：ディレクトリ単位でApacheの設定を変えるファイル

.htaccess（エイチティーアクセス）とは、ウェブサーバーのApacheで、ファイルを置いたディレクトリとその下の階層に対して設定を変えるためのファイルです。Apacheの公式文書では「分散設定ファイル」と呼ばれています（Apache HTTP Server：.htaccess ファイル）。

本来、Apacheの設定はサーバー全体の設定ファイルに書きます。しかし、レンタルサーバーのように1台のサーバーを複数の利用者で使う環境では、利用者がその設定ファイルを触れません。そこで、自分のディレクトリに置いた.htaccessで、必要な設定だけを変えられるようにしています。

SEOでよく使うのは、URLを変えたときの301リダイレクトと、httpとhttps・wwwの有無・末尾のスラッシュなど、URLの表記をそろえる設定です。この記事では、.htaccessを安全に編集し、正しく書く方法に絞ります。

編集する前に確かめること：使える環境と、設定の置き場所

.htaccessを書き始める前に、次の4点を確かめます。ここを飛ばすと、「書いたのに効かない」「同じ転送が二重にかかる」といった問題が起きます。

1. サーバーがApache（または互換のサーバー）か：レンタルサーバーの仕様のページで確かめます。nginxだけで動いている場合、.htaccessは使えません。
2. 管理画面に同じ機能が無いか：常時SSL化やwwwの統一は、レンタルサーバーやCDNの管理画面で設定できる場合があります。同じ転送を.htaccessと管理画面の両方に書くと、転送のループの原因になります。
3. すでに書かれている内容：WordPressや、サーバーの管理画面の機能が、自動で書き込んだ記述が入っていることがあります。心当たりの無い記述を消すと、その機能が止まります。
4. サーバーの設定ファイルを使えるか：自分で管理するサーバーなら、Apacheの公式文書は、.htaccessよりサーバーの設定ファイルに書くことを勧めています。.htaccessはリクエストのたびに読み込まれ、表示の速さと安全性の面で不利になるためです。

例：Xserverのマニュアルでは、サーバーパネルの「.htaccess編集」で、ドメインごとの公開フォルダの直下にある.htaccessを編集できると説明しています。

同じマニュアルでは、ファイルが無ければ確定時に作られ、下の階層の.htaccessはファイルマネージャやFTPで編集します。また、サーバーパネルの機能やWordPressなどが自動で書き込んだ記述がある場合があるため、編集後はサイトが正しく表示されるかを確かめるよう案内しています。ほかのレンタルサーバーでも、それぞれのマニュアルで編集の方法を確かめてください。

安全に編集する手順：バックアップから確認まで

.htaccessは、保存した瞬間にサイト全体へ効きます。そのため、次の順で進めます。

1. 元のファイルを保存する：FTPやファイルマネージャで.htaccessをパソコンにダウンロードし、日付を付けた名前で保管します。例：htaccess_20261010.txt。サーバー上にコピーを置く場合も、公開フォルダの中に置いたままにしないか、外から見られない名前と場所にします。
2. 変更する内容をテキストエディタで用意する：書き足す行を先に書き、何をするためのルールかをコメント（行頭に「#」）で残します。
3. 人の少ない時間に反映する：管理画面かFTPで保存します。
4. すぐに表示を確かめる：トップページ、記事ページ、管理画面、画像を開き、表示されるかを見ます。
5. 転送を確かめる：後の節の方法で、応答の番号と転送先を確かめます。

# 例：コメントを残してから書く
# 2026-10-10 旧URL /column/ を /blog/ へ移したため（担当：〇〇）
RewriteEngine On
RewriteRule ^column/(.*)$ https://example.com/blog/$1 [R=301,L]

文字コードは、サーバーの案内に従います。日本語のコメントを入れる場合、Xserverの新しいサーバーパネルではUTF-8で保存されると説明されています。不安があれば、コメントは英数字だけにすると文字コードの問題を避けられます。

500エラーが出たときの戻し方

.htaccessに書き間違いがあると、Apacheは「500 Internal Server Error」を返し、サイト全体が表示されなくなることがあります。慌てて書き足すより、まず元に戻すのが近道です。

1. 保存しておいたファイルに戻す：FTPやファイルマネージャで、編集前の.htaccessをアップロードして上書きします。管理画面で編集した場合は、編集前の内容を貼り直します。
2. 表示が戻ったかを確かめる：ブラウザの保存した表示が残ることがあるため、別のブラウザやcurlで確かめます。
3. 原因の行を探す：サーバーのエラーログを見ると、どの行の何が問題かが書かれていることがあります。レンタルサーバーでは管理画面からログを見られることが多いです。
4. 少しずつ足し直す：書き足したルールを1つずつ戻し、そのたびに表示を確かめます。

バックアップが無い場合は、書き足した行の先頭に「#」を付けてコメントにし、保存します。それでも直らなければ、ファイル名を一時的に変える（例：.htaccess_off）と、.htaccess全体が読まれなくなります。ただしWordPressのパーマリンクなど、ほかの設定も止まるため、記事ページが404になります。原因を見つけたら、すぐ元の名前に戻します。

書き方の基本：RedirectMatchとRewriteRuleの読み方

リダイレクトの書き方は、大きく2種類あります。Apacheの公式文書は、単純な転送にはmod_aliasのRedirectやRedirectMatchを使い、RewriteRuleは条件が必要な場合に使うよう勧めています（Apache HTTP Server：When not to use mod_rewrite）。

RewriteRuleの1行は、「パターン」「転送先」「フラグ」の3つでできています。.htaccessの中では、パターンはディレクトリ部分を除いたパスと照らし合わせるため、^column/ のように先頭の「/」を付けずに書きます。

RewriteEngine On
# 条件：ホスト名がwwwありのとき
RewriteCond %{HTTP_HOST} ^www.example.com$ [NC]
# パターン　転送先　[フラグ]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

コメントは、必ず行の先頭に「#」を付けて独立した行に書きます。命令と同じ行の後ろに書くと、命令の一部として読まれ、500エラーの原因になります。

正規表現の記号は、^が先頭、$が末尾、(.*)が「何でも」を表し、括弧の中は$1として転送先で使えます。「.」は「任意の1文字」の意味になるため、ドメイン名やファイル名の点は「.」と書きます。

RedirectとRewriteRuleを同じファイルで混ぜると、処理の順番が書いた順と一致しないことがあると、Apacheの文書は説明しています。リダイレクトのルールが多いファイルでは、どちらか一方にそろえます。

リダイレクト・正規化の設定例

ページ単位・ディレクトリ単位の転送、httpからhttps、wwwの統一、末尾のスラッシュの書き方は「サーバーでのリダイレクトの書き方」にまとめています。ここでは、それ以外によく必要になる設定を挙げます。どれも説明用の例で、ドメインやパスは自分のサイトに合わせます。

index.htmlを付けないURLにそろえる

RewriteEngine On
RewriteCond %{THE_REQUEST} ^[A-Z]+s/(.*/)?index.html[s?]
RewriteRule ^(.*/)?index.html$ https://example.com/$1 [R=301,L]

/blog/index.html を /blog/ へ転送します。THE_REQUESTの条件は、ブラウザが実際に「index.html」を付けて開いたときだけ転送するためのものです。これが無いと、サーバー内部でindex.htmlを表示する処理と食い違い、転送がループすることがあります。

パラメータで表示していた旧URLを、新しいURLへ

# 例：/?p=123 で表示していた記事を /blog/meta-tags/ へ
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)p=123(&|$)
RewriteRule ^$ https://example.com/blog/meta-tags/ [R=301,L,QSD]

RewriteRuleのパターンは「?」より後ろを見ないため、パラメータはRewriteCondの%{QUERY_STRING}で判定します。QSDを付けないと、転送先にも ?p=123 が引き継がれます。

ドメインを移したとき、旧ドメインの全URLを同じパスへ

# 旧ドメイン側の.htaccess
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?old-example.jp$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

パスの構成が変わらない移転の書き方です。パスも変わる場合は、旧URLと新URLの対応表を作り、1対1のルールにします。

転送から外すパスを決める

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/.well-known/
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

例：SSL証明書の更新の確認に使うパスなど、転送させたくない場所を条件で外します。

なお、URLの大文字を小文字にそろえる処理は、Apacheでは通常RewriteMapを使います。RewriteMapはサーバーの設定ファイルにしか書けず、.htaccessでは使えません。レンタルサーバーで大文字と小文字が混ざっている場合は、内部リンクとcanonicalを小文字のURLにそろえる方法を先に考えます。

書く順番：WordPressのルールとの位置と、ルールどうしの順番

WordPressの.htaccessには、「# BEGIN WordPress」と「# END WordPress」で囲まれた部分があります。この間はWordPressが自動で書き換えることがあり、パーマリンクの設定を保存したときなどに上書きされます。自分のルールはマーカーの外、それも上に書きます。下に書くと、WordPressのルールが先に処理され、転送されないことがあります。

# ここに自分のルール（転送・正規化）
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www. [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# BEGIN WordPress
（WordPressが書き込む部分。触らない）
# END WordPress

ルールどうしは、次の順に並べると意図どおりに動きやすくなります。

1. 転送から外すパスの条件
2. 個別のページの転送（1対1の対応）
3. ディレクトリ単位の転送
4. サイト全体の正規化（https・wwwの有無・末尾のスラッシュ）
5. WordPressなどのCMSのルール

個別の転送を先に書くのは、全体の正規化が先にあると、旧URL→正規化したURL→新URLと、転送が2回続くことがあるためです。個別の転送の転送先には、最初から正規のURL（https・wwwの有無もそろえた形）を書きます。

設定後の確かめ方と、当サイトでの確認の例

ブラウザは転送を自動でたどるため、301か302か、何回転送されたかが分かりません。ターミナルのcurlで、表記の組み合わせごとに確かめます。

for u in http://example.com/ http://www.example.com/ 
         https://www.example.com/ https://example.com/blog/index.html 
         "https://example.com/?p=123"; do
  curl -s -o /dev/null -L -w "%{http_code} %{num_redirects} $u -> %{url_effective}n" "$u"
done

すべての行が、最終の番号200で、転送が1回（正規のURLそのものは0回）になっていれば理想です。最初の応答が301かどうかは、-Lを付けずにcurl -Iで確かめます。設定の後は、Search ConsoleのURL検査で、Googleが選んだ正規URLが意図どおりかも確かめます。

当サイト（seoagent.jp）では、トップ / から日本語版 /ja/ への転送が302（一時的）になっていたため、301（恒久的）に変えました。旧サイト時代のURLも新しいURLへ1対1で301にし、2010年ごろの旧サイトのページ /seoagent.htm も、外部からのリンクが残っていたため、日本語版のトップ / へ301で転送しています。

また、範囲外のページ番号は404、親カテゴリーは一覧ページへの301にしました。これらは、サイトの反映のたびに301・404の応答を確認しています。決まったURLの一覧で応答を見続けると、更新で設定が崩れても気づけます。

.htaccessの書き方と関わるテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。

よくある質問

.htaccessが見つかりません。

先頭が「.」のファイルは、隠しファイルとして表示されないことがあります。FTPソフトやファイルマネージャの設定で、隠しファイルを表示します。それでも無ければ、まだ作られていないだけの場合があります。新しく作る場合は、ファイル名が「.htaccess」になっているか（末尾に.txtが付いていないか）を確かめます。

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

サーバーがApacheでない、AllowOverrideで許可されていない、WordPressのルールより下に書いた、ブラウザが以前の転送を記憶している、などが考えられます。curl -Iで応答を確かめ、別の転送が先に効いていないかを見ます。

302で設定してしまいました。301に直すとどうなりますか？

R=302をR=301に書き換えれば、それ以降は恒久的な転送として返されます。Googleは、恒久的な転送を転送先を正規URLとする強い手がかりとして扱います。直したら、curl -Iで301になっているかを確かめます。

.htaccessとサーバーの管理画面、どちらで設定すべきですか？

管理画面に同じ機能があるなら、管理画面の方が書き間違いの心配が少なくなります。ただし、同じ転送を両方に設定しないようにします。管理画面に無い細かい転送だけを.htaccessに書く、と分けると管理しやすくなります。

SEOAGENTでできること

SEOAGENTでは、内容の重なる記事を候補として示し、記事の整理やリライトを進められます。記事をまとめるときは、転送の設定とあわせて、記事同士の内部リンクも見直せます。.htaccessやサーバーの設定そのものは、サーバーやWordPress側で行います。

• 記事改善・リライト
• 内部リンクの提案・挿入

参考情報

• Apache HTTP Server：Apache Tutorial: .htaccess files
• Apache HTTP Server：When not to use mod_rewrite
• Apache HTTP Server：RewriteRule Flags
• Xserver マニュアル：.htaccess編集
• Google 検索セントラル：リダイレクトと Google 検索