「.htaccessは、必要なコードを調べて貼り付ければ動くファイル」。そう受け取っている方は少なくないはずです。レンタルサーバーの管理画面に「.htaccess編集」という項目があらかじめ用意され、常時SSL化やリダイレクトの記述例も検索すればいくらでも出てくるため、テキストを書いて保存するだけの操作に見えるからです。
しかし、これまで多くのサイト移転やSSL化の作業に立ち会ってきた弊社の立場から言えるのは、.htaccessでつまずくのは記述の中身ではなく、置いた場所と、間違えたときに戻せるかどうかだということ。保存した瞬間に反映され、1行の誤りで配下のページが表示できなくなる点が、ほかの設定ファイルとの大きな違いになります。
本記事では、.htaccessが何をするファイルなのかという前提から、作り方と置き場所、目的別の記述例、そして設定が効かないときの切り分けまで、Webサイトの運用を預かる立場で順を追ってお伝えします。
- .htaccessの読み方と、Apacheの設定を上書きする仕組み
- リダイレクトや認証など.htaccessで扱える制御の範囲
- ファイルの作り方と、置く場所の決め方
- 目的別の記述例と、書き換える前に確保しておく復旧の経路
- 設定が反映されないときに、何から順番に確認するか
.htaccessとは
.htaccessは、Apache HTTP Serverというソフトウェアの動きを、ディレクトリ単位で変更するための設定ファイルです。拡張子を持たず、先頭にドットが付いた名前そのものがファイル名になります。中身は1行1命令のテキストで、専用のツールや形式は必要ありません。
役割を一言でまとめるなら、サーバー全体の設定を、ディレクトリ単位で上書きするための仕組みということになります。
.htaccessの読み方と成り立ち
読み方は「ドットエイチティーアクセス」が一般的で、頭のドットを省いて「エイチティーアクセス」と呼ぶ現場もあります。公式に定められた読み方があるわけではないため、どちらで呼んでも通じるはずです。
名前はhypertext accessに由来するとされ、もともとはディレクトリへのアクセス制御を担うファイルでした。現在は認証、転送、エラーページの指定まで扱える範囲が広がり、名前と実態が少しずれた状態のまま使われています。
httpd.confとの違い
Apacheの設定は本来、httpd.confという1つのファイルに書かれます。サーバー全体に効く親元の設定で、書き換えたあとはApacheの再起動が必要です。
対する.htaccessは、そのhttpd.confで許可された範囲だけを、置いたディレクトリの中で部分的に上書きするもの。再起動は要らず、保存した瞬間から反映されます。両者は対立する仕組みではなく、後者が前者の一部を借りて使っている関係だと考えると整理しやすいでしょう。
| ディレクトリ単位（.htaccess） | サーバー全体（httpd.conf） | 管理画面やプラグイン | |
|---|---|---|---|
| 設定が効く範囲 | 置いた場所より下すべて | サーバー全体 | ツールが用意した機能の中 |
| 反映のタイミング | 保存した直後 | Apacheの再起動後 | 保存した直後 |
| 必要な権限 | 対象ディレクトリへの書き込み | サーバーの管理者権限 | ツールの管理者権限 |
| 書き間違いの影響 | 配下がすべて500エラー | Apacheが起動しない | ツール側で弾かれることが多い |
| 共用サーバーでの可否 | 使える | 触れない | 提供されていれば使える |
| 向いている場面 | 共用サーバーでの細かい制御 | 自分で管理する専用サーバー | 定型的な設定だけで足りるとき |
3つのうちどれを選ぶかは、好みではなく権限で決まります。レンタルサーバーの契約ではhttpd.confに手が届かないため、実質的に.htaccessか管理画面の二択になる、というのが現実的なところです。
.htaccessが使える条件
前提となる条件は2つあります。WebサーバーがApacheであること、そしてhttpd.conf側で.htaccessの使用が許可されていることです。
許可を決めているのがAllowOverrideという設定になります。ここがNoneになっていると、.htaccessをいくら置いても中身は読まれません。レンタルサーバーは最初から使える状態で提供されるのが通常ですが、VPSや専用サーバーを自分で構築した場合、初期状態のままNoneになっていることがあります。
なお、nginxは設計上、.htaccessに相当する仕組みを持ちません。Windows ServerのIISではweb.configという別のファイルが同じ役割を担います。契約したサーバーのWebサーバーソフトが何かを、作業に入る前に確かめておいてください。
関連記事：【2025年最新版】初心者でもできるSEOのやり方完全ガイド | 上位表示するための具体的な方法を徹底解説
.htaccessでできること
.htaccessで指定できる内容は、httpd.conf側の許可範囲によって変わります。一般的なレンタルサーバーであれば、次のような制御はほぼ使えると考えて差し支えありません。
用途 | 何ができるか | よく使う場面 |
|---|---|---|
リダイレクト | 旧URLへのアクセスを新URLへ転送する | サイト移転、ページ統合、URL構造の変更 |
URLの正規化 | httpsやwwwの有無を1つの形に揃える | 常時SSL化、重複したURLの整理 |
BASIC認証 | IDとパスワードでページを保護する | 公開前のテストサイト、社内向けページ |
IPアドレス制限 | 特定の接続元だけを許可、または拒否する | 管理画面の保護、社内からのみの公開 |
エラーページの指定 | 404や403で独自のページを表示する | 独自デザインのエラーページ |
ファイル一覧の制御 | ディレクトリの中身の一覧表示を止める | index.htmlのないディレクトリの保護 |
文字コードの指定 | 配信時の文字コードを揃える | 文字化けの解消 |
上の7つのうち、Webサイトの検索結果に直接関わるのはリダイレクトとURLの正規化、そしてエラーページの指定です。残りは公開範囲やセキュリティの話で、検索エンジンからの評価とは切り離して考えて構いません。
Web担当者リダイレクトなら、WordPressのプラグインでも設定できますよね。どちらを使えばよいのでしょうか。
Writers-hub編集部
どちらでも動きます。ただ、片方に寄せてください。プラグインと.htaccessの両方に同じURLの設定が残っていると、転送先がおかしくなったときにどちらが原因か追えなくなります。WordPressの中だけで完結するサイトならプラグイン、静的なページやサブディレクトリも含めて転送したいなら.htaccessが扱いやすいはずです。
関連記事：301リダイレクトの設定方法｜.htaccess・WordPress・Next.jsでの書き方
.htaccessファイルの作り方と置き場所
.htaccessはパソコンのテキストエディタで作れます。特別なソフトは不要ですが、ファイル名と保存形式に決まりがあり、そこを外すとサーバーに置いても読み込まれません。
メモ帳やCotEditor、VS Codeなど、書式情報の入らないエディタを使います。WordやGoogleドキュメントのように装飾を持つソフトでは作れません。
文字コードはBOMなしのUTF-8、改行コードはLFを選びます。BOMが付いていると先頭の1行が正しく読まれず、原因の分かりにくい500エラーになります。
拡張子は付けません。Windowsで拡張子が隠れている状態だとhtaccess.txtになりがちなので、保存したあとに実際の名前を確かめてください。
FileZillaやWinSCPなどで接続し、設定を効かせたいディレクトリへ転送します。転送モードはアスキー（テキスト）を選びます。
604か644が一般的な値です。サーバーごとに推奨値が異なるため、提供元のマニュアルの記載に従います。
手順そのものは5分で終わります。注意すべきなのは、その5分の前後にある確認のほうです。
アップロードの前に、同じディレクトリに.htaccessがすでに置かれていないかを必ず確認してください。上書きすると既存の設定が消え、サイトの表示が崩れます。存在する場合は、元のファイルを手元にダウンロードしてから追記する形にします。
WordPressでの置き場所
WordPressの.htaccessは、wp-config.phpやwp-contentと同じ階層、つまりWordPressをインストールしたディレクトリの直下にあります。見当たらない場合の原因は2つで、FTPソフトの表示設定で隠しファイルが非表示になっているか、まだ生成されていないかのどちらかです。
生成されていないときは、管理画面の「設定」から「パーマリンク」を開き、そのまま「変更を保存」を押してください。書き込み権限があれば、その場でファイルが作られます。中身は次のような記述になっているはずです。
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressここで覚えておきたいのが、BEGIN WordPressからEND WordPressまでのブロックは、WordPressが自動で書き換える領域だという点です。独自の記述をこの中に書くと、パーマリンクの設定を保存し直したタイミングで消えます。追記はブロックの外側に置いてください。
関連記事：dofollowとは？nofollowとの違いと設定不要な理由を解説
.htaccessの目的別の記述例
ここからは実際の記述を見ていきます。以下の例はexample.comの部分を自分のドメインに置き換えて使う前提です。綴りを1文字誤るだけでも配下のページが表示できなくなるため、書き換える前に元のファイルをダウンロードしておきましょう。
常時SSL化とURLの正規化
httpへのアクセスをhttpsへ、wwwありをwwwなしへ揃える記述です。検索エンジンに同じ内容のページが複数のURLで認識される状態を避けられます。
RewriteEngine On
# httpをhttpsへ
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# wwwありをwwwなしへ
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]この記述で転送が終わらず、ブラウザがループを検出する場合があります。原因の多くはサーバー構成でしょう。ロードバランサやCDNがhttpsを終端している環境では、Apacheに届く時点でHTTPSがoffのままになり、条件がいつまでも成立し続けてしまいます。その場合はHTTPSではなくHTTP:X-Forwarded-Protoの値を見る形に書き換えてください。
ページ単位の301リダイレクト
移転元と移転先を1対1で指定する場合は、mod_rewriteを使わないRedirectディレクティブのほうが記述が短く、読み違いも起きにくいでしょう。
Redirect 301 /old-page.html https://example.com/new-page/ディレクトリごとまとめて移すなら、RedirectMatchで前方一致を使います。
RedirectMatch 301 ^/old/(.*)$ https://example.com/new/$1左側はドメインを含まないパス、右側は移転先の絶対URLで書きます。ここを取り違えると転送先が入れ子になり、URLが延々と伸び続ける動きになります。
BASIC認証とIPアドレス制限
公開前のテストサイトを保護するならBASIC認証です。.htaccessと、パスワードを保存する.htpasswdの2つを用意します。
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/example/.htpasswd
Require valid-userAuthUserFileにはサーバー上の絶対パスを書きます。.htpasswd自体は、公開ディレクトリの外に置いておくと安全でしょう。接続元のIPアドレスで絞る場合はRequireを使い、次の例では指定した1つのアドレスだけを通します。
<RequireAll>
Require all denied
Require ip 192.0.2.10
</RequireAll>192.0.2.10の部分を、通したい接続元のアドレスへ置き換えて使います。許可先が複数ある場合はRequire ipの行を並べて書き、社内の回線のように範囲で指定するなら192.0.2.0/24のような書き方も可能です。
OrderやAllow、DenyはApache 2.2までの書式です。2.4以降では互換モジュールが有効な環境でしか動かず、無効な場合は500エラーになります。古い解説記事から記述を持ってくるときは、サーバーのApacheのバージョンを先に確認してください。
エラーページとファイル一覧の指定
独自の404ページを表示する記述と、ディレクトリの中身の一覧表示を止める記述です。2行とも単独で機能します。
ErrorDocument 404 /404.html
Options -IndexesErrorDocumentの右側は、サイトルートからのパスで書いてください。ここにhttpsから始まる絶対URLを書くと、Apacheは404ではなく別ページへの転送として処理するため、検索エンジンには「そのページは存在しない」と伝わらなくなります。せっかく用意した404ページが、検索結果からページを消す働きをしないわけです。
移転後のURLが、1回の転送で新しいページに届いていますか
転送を2段3段と重ねてしまう、旧URLへの内部リンクが本文に残ったままになる。公開直後は画面上の表示に問題が出ないため、こうした状態は気づかれないまま数か月が過ぎることがあります。弊社では記事の制作とあわせてURLの構造と転送の設定を確認し、検索結果での見え方まで含めて整えています。
置く階層で変わる.htaccessの効き方
.htaccessでもっとも誤解が多いのが、設定の届く範囲です。書いた内容が効くのは、ファイルを置いたディレクトリと、その下にあるすべてのディレクトリだと考えてください。サイト全体に効かせたいならドメイン直下、特定のフォルダだけならそのフォルダに置く、という使い分けです。
では、上と下の両方に置かれている場合はどうなるか。原則として、.htaccessは深い階層にあるものほど優先されます。上位の設定は引き継がれたうえで、同じ項目については下位の記述が勝つ、と考えてください。
ただし、この「引き継がれる」には大きな例外があります。
mod_rewriteのルールは、下位のディレクトリに引き継がれません。サブディレクトリ側の.htaccessにRewriteRuleを1行でも書くと、上位で設定した転送や正規化は、そのディレクトリの中では無効になります。上位の内容も使いたい場合は、下位のファイルにRewriteOptions Inheritを書き添える必要があります。
WordPressをサブディレクトリに入れているサイトで、ルートに書いたhttpsへの転送だけが効かない。そうした相談を受けたときは、まずサブディレクトリ側の.htaccessを開きます。原因の大半はここにあり、記述そのものは正しいまま放置されているケースがほとんどです。
設定が反映されないときの切り分け順
書いたはずの設定が効かない。.htaccessで相談が集中するのがこの場面です。原因の候補は多いのですが、確認する順番を決めておけば、たいていは数分で見当がつきます。
最初に見るのは、エラーが出ているかどうかです。原因の切り分けは、500エラーが出ているかどうかから始めます。500が出ていれば記述の文法か、対応していないディレクティブが原因ですから、直前に追加した行を消せば復旧します。500が出ずに設定だけ効かない場合は、ファイルそのものが読まれていない可能性から潰していきます。
サーバー上での実際の名前が.htaccessになっているかを見ます。htaccess.txtや.htaccess.txtになっていれば、この時点で解決します。
効かせたいURLに対応するディレクトリに置かれているかを確認します。ドメイン直下のつもりが、公開ディレクトリの1つ上に置かれていたという取り違えは珍しくありません。
対象より深い階層に別の.htaccessがあると、そちらの記述が優先されます。とくにRewriteRuleが書かれていれば、上位の転送は無効になっています。
サーバー全体で.htaccessが許可されているかどうかです。VPSや専用サーバーならhttpd.confを、共用サーバーなら提供元のマニュアルを見ます。
RewriteRuleにはmod_rewriteが、BASIC認証には認証系のモジュールが必要です。サーバーの管理画面やphpinfoの出力から確認できます。
301リダイレクトはブラウザに強く保存されます。修正が反映されないときは、シークレットウィンドウか別のブラウザで開き直してください。
最後の項目を軽く見る方は多いのですが、実務でいちばん多い誤診はここです。試しに設定した301を消したあと、自分のブラウザだけが古い転送を覚えていて「消えていない」と判断してしまう。作業のたびにシークレットウィンドウで確認する習慣を持てば、無駄な調査をまるごと省けます。
そして、切り分けよりも先に用意しておきたいのが戻す手段です。.htaccessの誤りでサイトが落ちると、WordPressの管理画面にも入れなくなります。編集の前に元のファイルを手元へ保存し、FTPとサーバーの管理画面という2つの経路で接続できることを確かめておく。この2つさえ済ませておけば、何が起きても数分で元の状態に戻せます。
.htaccessを使わないほうがよい場面
できることが多い分、なんでも.htaccessに書きたくなります。ただ、httpd.confを編集できる環境なら、そちらに書いたほうが速くなります。Apacheは.htaccessが許可されている限り、リクエストのたびにドメイン直下から対象のディレクトリまで、各階層でファイルの有無を確認しに行くからです。ファイルが存在しない階層でも、探しに行く動作そのものは発生します。
Apache公式のドキュメントでも、可能であれば.htaccessの使用は避け、メインの設定ファイルに書くよう案内されています。
※ Apache HTTP Server 2.4 チュートリアル「.htaccess ファイル」
次のような条件に当てはまる場合は、別の手段を検討したほうが管理しやすくなるはずです。
- httpd.confを自分で編集できるVPSや専用サーバーで、管理者が自分だけの場合
- Webサーバーがnginxで、.htaccessに相当する仕組みがそもそも存在しない場合
- サーバーの管理画面やWordPressのプラグインに、同じ設定が用意されている場合
- リダイレクトの対象が数百件を超え、1件ずつ書き並べると管理しきれない場合
- 社内に記述を読める人がおらず、誤りに気づける状態が保てない場合
とくに3つ目は見落とされがちです。管理画面とプラグインと.htaccessの3か所に同じ種類の設定が散らばると、表示がおかしくなったときに原因の場所を特定できません。設定を書く場所は、サイトごとに1つへ決めておくのが安全だと考えています。
.htaccessのよくある質問
最後に、実際に寄せられることの多い質問をまとめました。
「ドットエイチティーアクセス」と読むのが一般的です。頭のドットを省いて「エイチティーアクセス」と呼ぶ場合もあり、どちらでも通じます。公式に定められた読み方はありません。
不要です。「.htaccess」という文字列そのものがファイル名になります。htaccess.txtのように拡張子が付いていると読み込まれません。
隠しファイルが非表示になっているか、まだ作られていないかのどちらかです。FTPソフトの表示設定を確認し、それでも無ければ新規に作成して問題ありません。
深い階層にあるものが優先されます。上位の設定は引き継がれますが、同じ項目が書かれていれば下位の記述で上書きされます。mod_rewriteのルールだけは引き継がれません。
追加した行を削除して保存し直せば戻ります。保存した瞬間に反映されるため、Apacheの再起動は要りません。編集前のファイルを手元に残しておけば、丸ごと差し替えるだけで済みます。
読み方や置き場所は調べれば分かります。運用で困るのは、その先にある管理の部分です。
設定を書き換えられる人が社内にいない状態が続いていませんか
.htaccessの記述そのものは、手順に沿えば扱えます。実際に困るのは、前任者が何をどこに書いたのか分からないまま引き継いだ場面ではないでしょうか。弊社ではサイトの検索対策と記事制作を支援する中で、設定を置く場所と記録の残し方から一緒に整理しています。
まとめ｜.htaccessは書き方より置き場所
.htaccessは、Apacheのサーバー設定をディレクトリ単位で上書きするファイルです。リダイレクトや認証、エラーページの指定まで幅広く扱えますが、記述例を探して貼るだけの作業として扱うと、置き場所の取り違えと、戻せない状態の2つでつまずきます。
- 効くのは置いたディレクトリと、その配下すべて
- 同じ項目は深い階層の記述が優先され、mod_rewriteのルールだけは引き継がれない
- 保存した瞬間に反映され、文法の誤りは配下すべての500エラーになる
- 編集前に元のファイルを保存し、FTPと管理画面の2経路で入れることを確かめる
- httpd.confを編集できる環境なら、そちらに書いたほうがサーバーの負荷は軽い
私たち合同会社Writers-hubは、SEO記事の制作と検索対策の支援を通じて、サイトの移転やURL構造の変更にも数多く立ち会ってきました。転送や正規化の設定は、書いた直後よりも、数か月後に検索結果へどう表れるかで良し悪しが分かれます。設定を書き換える前に、公開後どこを見て結果を確かめるかまで決めておくと、後戻りの少ない運用になるはずです。
