公開前のテストサイトや作りかけのページを、検索エンジンにも人にも見せたくないことがあります。
そんなときに手早く使えるのが、ブラウザーでユーザー名とパスワードを聞く「ベーシック認証」です。
この記事では、必要な2つのファイルの作り方と、WordPressで起きやすい不具合の避け方を紹介します。
この記事で使う.htpasswd生成は、当サイトと同じMOTOKI合同会社が作った「WEBツール箱」の1つです。
無料で、会員登録なしで使えます。
最終確認日：2026年9月28日
この記事で分かること
- ベーシック認証に必要な2つのファイルの役割
- .htpasswdと.htaccessの中身を作る手順
- .htpasswdを置く場所
- 管理画面だけにかけるときの注意
先に結論｜ファイルは2つ、置き場所に気をつける
| ファイル | 中身 | 置く場所 |
|---|---|---|
| .htpasswd | ユーザー名と、ハッシュ化したパスワード | 公開ディレクトリ（public_htmlなど）の外 |
| .htaccess | 「このフォルダーは.htpasswdの人だけ通す」という指示 | 認証をかけたいフォルダー |
サーバーの管理画面にアクセス制限の機能がある場合は、そちらを使うほうが簡単です。
エックスサーバーやConoHa WINGなど、多くのレンタルサーバーに専用の設定項目があります。
管理画面の機能が無いサーバーや、細かく設定したいときに、この記事の方法を使います。
ツールで2つのファイルの中身を作る
- .htpasswd生成を開く
- ユーザー名とパスワードを入れる
- ツールがSHA-1を推奨表示していても、そのまま採用せず、サーバー管理画面の認証設定またはbcrypt対応のhtpasswdを優先する
- 「.htpasswd の設置パス」に、サーバー上の置き場所を「/」から始まるフルパスで入れる
- 「生成する」を押す
撮影用の使い捨てパスワードで作った結果です。
上の枠が.htpasswdに書く1行、下の枠が.htaccessに書く4行です。
「.htpasswd として保存」を押すと、そのままファイルとして保存できます。
パスワードはブラウザーの中で暗号化され、サーバーには送られません。
2026年9月28日に、入力から生成までの間にページが外へ通信していないことを確かめました。
生成された「{SHA}」の値が、opensslで同じパスワードから計算した値と一致することも確かめています。
パスワードは、推測されにくいものを別に用意してください。
パスワード生成を使えば、ランダムな文字列をブラウザーの中で作れます。
長さと文字の選び方は、「安全なパスワードの作り方」で比べています。
サーバーに置く
.htpasswdは公開ディレクトリの外に置く
.htpasswdは、ブラウザーから開けない場所に置くのが原則です。
public_htmlのように、URLで開ける場所の1つ上の階層がよく使われます。
ツールの「設置パス」の初期値は「/home/username/.htpasswd」で、public_htmlの外に置く形の例になっています。
「username」の部分などを、実際のサーバーのパスに合わせて書き換えてください。
.htaccessの「AuthUserFile」にはURLではなく、サーバー上のフルパスを書きます。
フルパスは、レンタルサーバーのファイルマネージャーやFTPソフトで確かめられます。
.htaccessは認証をかけたいフォルダーに置く
サイト全体にかけるなら、WordPressが入っているフォルダーの.htaccessに4行を足します。
WordPressが書き換える「# BEGIN WordPress」から「# END WordPress」までの外、ファイルの先頭に書くのが安全です。
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/username/.htpasswd
Require valid-user「/home/username/.htpasswd」の部分は、実際の置き場所に置き換えます。
「AuthName」の文字は、ブラウザーによってはログインの画面に表示されます。
WordPressで起きやすい不具合
| 症状 | 原因 | 対処 |
|---|---|---|
| 管理画面にだけかけたら、公開ページの一部の機能が動かない | 公開ページからも呼ばれる admin-ajax.php に認証がかかる | 公開アクセスが必要な場合だけadmin-ajax.phpを除外する |
| ブロックエディターで保存できない、プラグインが動かない | 管理画面の裏側の通信やREST APIが認証で止まる | どの層が401を返しているか確認し、認証対象とクライアントの方式を見直す |
| サイトヘルスに「ループバックリクエスト」の問題が出る | サーバーが自分のサイトを呼び出すときに、認証を通れない | 予約投稿や更新確認などへの影響を調べ、必要なサーバー内通信だけを認証できるようにする |
管理画面だけに認証をかけ、公開ページがadmin-ajax.phpへアクセスする必要がある場合に限り、次の除外例を検討します。
<Files admin-ajax.php>
Require all granted
</Files>この3行は、wp-adminのフォルダーに置く.htaccessの、認証の4行の下に足します。
Apache 2.4の書き方で、古いサーバーでは書き方が異なります。
かかったかを確かめる
ブラウザーの新しいシークレットウィンドウで、認証対象のURLを開いて確認します。
未認証の要求が401とWWW-Authenticateヘッダーを返すことを確認します。
正しい認証では目的のページへ到達し、誤った認証では401になることも必要です。
認証情報がブラウザーに保存される場合があります。
認証ダイアログの有無だけで判断せず、未認証のHTTP要求でも確認してください。
コマンドで確かめる場合は、curlを使います。
curl -sS -D - -o /dev/null https://example.com/上のコマンドはGET要求の応答ヘッダーを表示します。
macOS/Linuxでは/dev/null、Windowsではcurl.exeを使って/dev/nullをNULに置き換えます。
未認証では401とWWW-Authenticateを確認します。
正しい認証の確認にはcurlの-uへユーザー名だけを指定し、パスワードを対話入力します。
上のGET確認と同じ指定を使い、パスワードを引数へ直接書きません。
トップ以外のページや静的ファイルも、意図した認証範囲になっているか確認します。
ベーシック認証でできないこと
ベーシック認証は、公開前のサイトを隠すための簡単な仕組みです。
HTTPSでないサイトでは、ユーザー名とパスワードが通信の途中で読み取られます。
顧客情報のような大事な情報を守る目的には、ベーシック認証ではなく本来のログイン機能を使ってください。
Apache公式はSHA-1方式を現在の基準で安全ではないと説明しています。対応形式はサーバー次第で、すべての環境で動く保証もありません。
サーバーでhtpasswdコマンドが使えるなら、「htpasswd -B」でbcrypt方式にするとより強固になります。
よくある質問
Q. 検索エンジンに載せたくないだけなら、noindexで足りますか？
公開前のテストサイトなら、ベーシック認証のほうが確実です。
noindexやrobots.txtは検索エンジンへのお願いで、ページの中身は誰でも見られます。
ベーシック認証をかければ、検索エンジンも中身を読めません。
Q. 「暗号化なし」はいつ使いますか？
暗号化なしの形式を受け付けるのは、一部のサーバーだけです。
平文やSHA-1を新規設定の既定にはしません。サーバーが対応する安全なハッシュ方式を確認してください。
Q. Nginxのサーバーでも使えますか？
Nginxだけで動くサーバーでは.htaccessは読まれません。
サーバーの設定に「auth_basic」と「auth_basic_user_file」を書きます。
認証ファイルのハッシュ形式が、そのサーバーの認証機能に対応しているか確認します。
Q. 公開するときはどうしますか？
今回追加した認証設定をバックアップと照合して外し、未認証のGET要求で目的のページへ到達するか確認します。
親ディレクトリやホスト側にも制限がある場合は、その設定も確認します。
認証ファイルを他の設定が使っていないか確認してから整理します。
まとめ
- 2つのファイルの中身は.htpasswd生成で作れる
- .htpasswdは公開ディレクトリの外に置く
- .htaccessの「AuthUserFile」にはサーバー上のフルパスを書く
- admin-ajax.phpの除外は公開アクセスを許す必要がある場合だけに限定する
- かかったかは、シークレットウィンドウかcurlで確かめる
公開前にほかに確かめておく設定は、「WordPressの初期設定チェックリスト」にまとめています。
ほかの項目もまとめて点検するなら、「WordPressサイトを自分で点検する手順」で順番と使い分けを解説しています。
ツールの一覧はWEBツール箱にあります。
bcryptの行を作る方法
Apacheのhtpasswdが使える端末では、次のコマンドでパスワードを対話入力します。生成されたユーザー名とハッシュの1行を、非公開の.htpasswdへ保存します。-nは結果の出力のみで、既存ファイルを上書きしません。パスワードをコマンド引数や履歴へ残さないため、-bは使いません。対象サーバーのbcrypt対応を先に確認してください。
htpasswd -nB exampleuser設定前に.htaccessをバックアップし、500エラーや認証不能になった場合は追加した部分を戻します。HTTPSを先に有効にし、認証ファイルをブラウザーから取得できないことも確認してください。ここで示した認証設定は本番サイトへ適用していません。
Apacheで確認した認証の結果
2026年10月3日、隔離したApache 2.4.69のHTTPS環境で掲載の設定を確認しました。
未認証・誤ったパスワードは401、bcryptの正しい認証は200でした。
認証ファイルのパスを存在しない場所へ変えると500になり、元のパスへ戻すと認証要求が復旧しました。
htpasswdのbcrypt生成は、試験では-iで標準入力から使い捨てパスワードを渡し、-nで既存ファイルを変更せずに出力しました。
生成したハッシュをApacheが認証できることを確認しています。
記事の-nBは端末で対話入力する指定です。
admin-ajax.phpの除外例では、該当ファイルだけ200、ほかの管理画面用ファイルは401でした。
公開領域外の認証ファイルはURLから取得できず、認証設定を戻した後の200も確認しました。
これらは隔離したHTTP試験用ファイルの結果であり、実際のWordPressの保存・REST API・サイトヘルスの統合検証は含みません。
ベーシック認証とREST API認証が重なる場合
2026年10月3日、隔離したApache 2.4.69・PHP CGI 8.2.29・WordPress 7.1.2で、実際の公開記事とログイン画面、REST APIを確認しました。
ベーシック認証はPHPより前に未認証の要求を401にし、正しい認証では記事本文とログインフォームへ到達できました。
サーバーのベーシック認証とWordPressのApplication Passwordは、どちらもAuthorizationヘッダーを使う場合があります。
異なるパスワードを設定した今回の試験では、Application Passwordを送るとApacheで401になり、サーバー用の認証を送るとWordPressのREST認証で401になりました。
サーバー側の認証を外した試験では、Application PasswordでREST APIの自分のユーザー情報を200で取得できました。
401にWWW-Authenticateがあるか、WordPressのJSONエラーが返っているかを読むと、止まった層を切り分ける助けになります。
両方に同じAuthorizationを送れば通るとは判断せず、認証の対象範囲と接続方法を設計します。
対処としてREST API全体を無条件に公開する設定は追加しないでください。
CGIでAuthorizationをPHPへ渡すための設定も、検証用のApacheで確認しました。
実際のホストではサーバー側の受け渡し設定を確認します。
編集画面の保存、ループバック、ツールのコピー操作、PC・スマホとキーボード操作は今回のHTTP試験に含みません。
