WordPressのデフォルト.htaccessファイル：内容と復元方法

WordPressのデフォルト.htaccessファイルは、/2026/10/投稿名/のようなパーマリンクが404にならずに解決されるように、ソフトウェアがサイトのルートにある.htaccessに書き込む短いRewriteEngineブロックです。次のような内容です。

# 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

これはApache HTTP ServerについてのWordPress公式ガイドと、きれいなパーマリンクについてのHelpHubページで説明されているrewriteロジックから転載した正確なブロックです。RewriteBaseが/でない場合——例えばWordPressがサブフォルダにインストールされている場合——代わりにそのパスに一致しますが、これも同様に正常であり、WordPress自身によって生成されます。

重要なポイント

• WordPressはファイルが書き込み可能で、設定 > パーマリンクを保存するたびに、ApacheとLiteSpeed上でのみ、このブロックを自動的に生成します。
• ファイルが欠落または破損している場合、ホームページ以外のすべてのパーマリンクが404を返します。なぜならrewriteルールがなければホームページだけが見つけられるからです。
• あなたやプラグインが追加するものはすべて# BEGIN WordPressの上に置く必要があり、マーカーの内側に置いてはいけません——WordPressはパーマリンクが保存されるたびに、その間のすべてを上書きします。

実際のパスと追加のルールでファイルを再構築する必要がありますか？WordPress .htaccessジェネレーターがブラウザ上で直接正しいファイルを組み立てます。

各行が何をしているか

RewriteEngine Onは、このディレクトリに対してApacheのmod_rewriteモジュールを有効にします。この行がなければ、以降のすべては無効です。

RewriteBase /は、書き換えられたパスがサイトのルートからの相対パスであることをApacheに伝えます。WordPressはサイトが実際にどこにあるかに応じてこれを設定します——サブフォルダへのインストールでは、/ではなくRewriteBase /blog/になります。

RewriteRule ^index\.php$ - [L]は効果のないガードです：リクエストが既にindex.phpであれば、rewriteは停止し、リクエストは変更されずに通過します。

2つのRewriteCond行が実際のロジックです。%{REQUEST_FILENAME} !-fと!-dは「このリクエストは実際のファイルに一致しない、かつ実際のディレクトリにも一致しないか？」を問います。最後のルールが発火するにはどちらも真である必要があります——これにより、実際の画像、CSSファイル、アップロードされたPDFは直接提供され、WordPressのルーティングに一切触れることはありません。

RewriteRule . /index.php [L]がパーマリンクを機能させているものです：前の2つの条件を通過したもの——つまり実際のファイルやフォルダではないもの——はindex.phpに送られ、WordPress自身のルーティング（WP_Query、rewriteタグ）がそのURLが実際にどの投稿、ページ、アーカイブを意味するかを決定します。

WordPressがこのファイルを再生成するタイミングと、できないタイミング

WordPressは、画面上で何も変更されていなくても、設定 > パーマリンクを開いて変更を保存をクリックするたびに、自分で.htaccessを書き込もうとします。この保存操作はflush_rewrite_rules()をトリガーし、これは.htaccessを書き込み用に開き、現在のブロックをマーカーの間に挿入しようとします。

この試みは、ファイルが欠落または古いままになる形で静かに失敗することがあります。それは次のような場合です。

• ファイルまたはその親フォルダが、PHPが実行されているユーザーに対して書き込み可能でない場合。 多くの共有ホスティングでは、PHPはFTPでファイルをアップロードしたユーザーとは異なるシステムユーザーとして実行されるため、FTPクライアント上で正しく見える権限でも、WordPressの書き込みをブロックすることがあります。
• nginxを使用している場合。 .htaccessはApacheとLiteSpeed専用のメカニズムです（AllowOverrideに関するApacheのドキュメント自体がその理由を説明しています：nginxにはリクエストごとに再読み込みするディレクトリ単位の設定ファイルがありません）。nginxでの同等物は、サーバーへのアクセス権を持つ人だけが編集できるserverブロック内のtry_filesディレクティブです。WordPressは決してあなたのためにそれを書き込むことはできません。
• **メインのApache設定で、サイトのディレクトリに対してAllowOverrideがNone**に設定されている場合。これは、そもそも.htaccessが何かを上書きすることを許可する設定です。Apacheのドキュメントは明確です：AllowOverride Noneでは「.htaccessファイルは完全に無視される」——WordPressは完璧なファイルを書き込めますが、その設定がサーバーレベルで変更されるまで、効果は一切ありません。
• ファイルが削除されたか、もともと存在しなかった場合で、保存時に何かが再生成をトリガーしなかった——最も一般的なのは、パーマリンク構造が既に同じだったため、WordPressが書き直すべき変更を認識しなかったケースです。

手動で復元する方法

投稿やページが404になる一方でホームページは機能し続けている場合、それは.htaccessが欠落または壊れていることの典型的な特徴です。2つのステップで修正しましょう。

1. まずワンクリックの修正を試す。 WordPressダッシュボードで設定 > パーマリンクに移動し、何も変更せずに変更を保存をクリックします。ファイルが書き込み可能であれば、これだけで再生成され、問題は解決します。

2. それで解決しない場合は、ファイルを手動で作成する。 FTP/SFTPまたはホストのファイルマネージャーで接続し、WordPressがインストールされているフォルダ（wp-config.phpを含むフォルダ）に移動して、.htaccessがそもそも存在するかを確認します——これは隠しファイルであり、一部のファイルマネージャーはデフォルトでそれを隠しています。「隠しファイルを表示」を有効にしてください。

• 欠落している場合は、正確に.htaccessという名前の新しいファイルを作成します（.txtではなく、ドットの前には何もありません）。
• 上記のデフォルトブロックを貼り付け、WordPressがサブフォルダにある場合はRewriteBaseを調整します。
• 保存して、投稿のパーマリンクを再読み込みして動作することを確認します。

それでも404が出る場合、原因は「.htaccessが欠落している」から「.htaccessが無視されている」に変わっています——ホストにAllowOverrideについて確認してください。Apacheがそれを無視するように指示されているディレクトリ内の正しいファイルは、ファイルが存在しない場合と全く同じように動作するからです。

WordPressのブロックに対する自分自身のルール

プラグインや手動編集は、リダイレクト、ホットリンク対策、キャッシュヘッダーなど、独自のルールを追加することがあります。これはWordPressが生成するブロックとは別の、独立したブロックであり、両者が重なることは決してあってはなりません。

# あなたやプラグインが追加したルール — WordPressのマーカーの上に
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # 例：ホットリンク対策、キャッシュルールなど
</FilesMatch>

# 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はその部分全体を自分のものとして扱い、完全に書き直すためです。これが「自分で追加したルールが消えた」という不満の最も一般的な原因です——意図的に削除されたことは一度もなく、WordPressが自分のものと見なすブロックの内側にあっただけです。リダイレクトについては特に、正しく作られたWordPress .htaccessリダイレクトルールを参照して、それらがどこに置かれるべきか、ループを避ける方法を確認してください。

これはまた、ファイルを編集した直後に突然500 Internal Server Errorが出る最も一般的な原因でもあります：別のApacheバージョン用に書かれたフォーラムの投稿からコピーされたルール（2.2のOrder/Deny構文と2.4のRequire構文が混在したもの）は、下にあるWordPressのブロックを含むファイル全体のパースを壊し、触った部分だけでなくサイト全体がダウンします。

デフォルトブロックを超えて

デフォルトブロックはパーマリンクのルーティングのみを処理します。機密ファイルへのアクセスを強化したい場合や、本当に攻撃対象領域を減らす一握りの.htaccessルール——/uploadsでのPHP実行をブロックする、wp-config.phpへの直接リクエストを拒否する——を追加したい場合は、本当に役立つWordPress .htaccessセキュリティルールを参照してください。また、パーマリンクが別の理由で404になる場合——間違ったパーマリンク構造、古いルールを提供するキャッシュレイヤー、サブディレクトリでのマルチサイトの競合——機能しないWordPressパーマリンクが他の原因を取り上げています。

よくある質問

WordPressのデフォルト.htaccessファイルとは何ですか？ WordPressが# BEGIN WordPressと# END WordPressの間に書き込むRewriteEngineブロックで、パーマリンクが404にならずにindex.phpに解決されるようにするものです。

WordPressの正確なデフォルト.htaccessコードは何ですか？ RewriteEngine On、RewriteBase /、index.php用のパススルールール、リクエストが実際のファイルやディレクトリでないことを確認する2つの条件、そして残りすべてをindex.phpに送る最後のルールです。完全なブロックはこのガイドの先頭に示されています。

ホームページ以外のすべての投稿が404になるのはなぜですか？ ホームページはrewriteルールがなくても見つけられますが、他のパーマリンクはすべてそれを必要とします。Apache上で.htaccessが欠落または破損していると、まさにこのパターンが生じます。

WordPressは.htaccessを自動的に再生成しますか？ ファイルが書き込み可能な場合のみです——設定 > パーマリンクを再保存するとこれがトリガーされます。ファイルが書き込み可能でない、自動生成しないホストで欠落している、またはAllowOverrideが無効になっている場合、WordPressはあなたのためにそれを修正できず、ファイルを手動で作成または修正する必要があります。

nginxにWordPressの.htaccessファイルがないのはなぜですか？ .htaccessはApacheとLiteSpeedでのみ機能します。nginxにはディレクトリごとの設定ファイルがなく、.htaccessを完全に無視します。同じルーティングは、nginxのserverブロック内のtry_filesルールとして記述されます。

パーマリンクを保存した後に.htaccessが壊れたのはなぜですか？ 独自のルールが# BEGIN WordPress/# END WordPressマーカーの上ではなく内側に置かれ、WordPressが次のパーマリンク保存時にその部分全体を上書きしました。

---

本当に必要なセキュリティやリダイレクトのルールを加えた、クリーンで正しい.htaccessを構築しましょう——無料のWordPress .htaccessジェネレーターで。