こんにちは、Webデザイナーでエンジニアのふみやまです！
みなさん、ホームページ制作のテスト環境（テストサイト）はどのように準備していますか？
私は6年以上WordPressでホームページを作ってきたのですが、8割以上のプロジェクトはローカル環境（自分のパソコンでつくる）⇒テスト環境（ここでクライアントに確認してもらう）⇒本番環境という流れでチェックを進めます。
つまり、テスト環境では、WordPress化が完了してて、オンラインでクライアントが見れる状態じゃないといけないわけですね。ところが、オンラインでいつでも見れる状態だと「間違ってテストサイトがインデックスされちゃって、ググれちゃうかもしれない…。」という不安に押しつぶされながら泣く泣く開発することになります。（正しくやればなりません！）
そこで、この記事では、テストサイトがインデックスされない状態でクライアント確認を終えられるようにする方法を紹介したいと思います。これで、もうクライアントから「おいおい、間違ってテストサイトが検索トップに来てるじゃねーか」と言われることがなくなりますね。
さあ、素晴らしい開発体験があなたを待っています。
結論、テストサイトをインデックスさせない方法とは？
テストサイトをインデックスさせない方法は、robots.txtを使って、クローラーに対してテストサイトをクロールしないよう指示することです。
やり方は<head>タグ内に<meta name="robots" content="noindex, nofollow">というメタタグを追加するだけです。
ただし、それだけだと、直接テストサイトのURLを叩けば、誰でも中身が見えてしまいます。もし、非公開の情報が載っているサイトだったとしたら…、考えるだけで恐ろしいですね。そこでBasic認証という仕組みを使って、ユーザー名とパスワードを知っている人だけがテストサイトにアクセスできるようにします。
Basic認証（ベーシック認証）とは？
Basic認証（ベーシック認証）は、開発中のサイトなどに外部の人がアクセスしてしまうことを防ぐために、ウェブサイトの入り口にカギをかけるようなものです。
Basic認証のメリットは、簡単に設定できることと、最低限のセキュリティ対策として効果的なことです。
Basic認証（ベーシック認証）の設定方法
それでは、実際にBasic認証を設定する手順を説明します。
1. .htaccess ファイルの作成・編集
ドメインのルートディレクトリに .htaccess ファイルを作成、もしくは既存の .htaccess ファイルに以下のコードを追加します。
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /full/path/to/.htpasswd
Require valid-user- AuthType Basic：ベーシック認証を利用することを指定します。
- AuthName：認証のプロンプトで表示する名前を設定します。
- AuthUserFile：認証情報が記録された
.htpasswdファイルの絶対パスを指定します。
2. .htpasswd ファイルの作成
次に、認証情報を記載した .htpasswd ファイルを作成します。このファイルにはユーザー名とパスワードを格納します。
例えば、以下のように「ユーザー名:ハッシュ化したパスワード」の形で記述します。
username1:$apr1$5d4f7
username2:$apr1$9f8e3username の部分を自分の任意のユーザー名に変更しましょう。パスワードは平文でも設定できますが、必ずハッシュ化された形式で保存するのが安全です。
入力されたデータがサーバに送信されないように、ブラウザ上でハッシュ値の計算するツールがあるのでこちらを使うと良いでしょう。（MD5、SHA256を使うと良い）
3. サーバの設定に反映
作成した .htaccess と .htpasswd ファイルをサーバーにアップロードし、設定が反映されているか確認します。ブラウザでドメインにアクセスし、ユーザー名とパスワードを求められたら設定は完了です。
上記のように、robots.txtとBasic認証を設定すれば、テストサイトが間違ってインデックスされちゃった！なんて事態を防ぐことができます。また、外部の人に開発中のサイトの中身が知られる心配もなくなります。
さらにオンラインでテスト環境を構築するときに注意すると良いこと
ここからは、上級者向けというか、必要ならば、という情報になります。
セキュリティ強化策
より強くセキュリティを高めたいときには、特定のIPアドレスからのみアクセス可能にすることで、セキュリティを強化する方法があります。覚えておくと役に立つかもしれません。
テストデータの使用
出来る限り実際のユーザーデータや機密情報を使用せず、ダミーデータでテストを行うようにすると良いです。
データベースの分離
本番環境と異なるデータベースを使用し、データの混在を防ぎましょう。
定期的なセキュリティアップデート
テスト環境であっても、WordPressやプラグインは最新のバージョンを適用しておきましょう。
サブドメインの命名問題
最後に、テストサイトのドメインどうするか？ということにも触れておきます。
本番環境のドメインが準備できるのが遅く、テストサイトのチェックのほうが先に来ることはあるあるです。
なので、テストサイトのドメインは基本的には制作側で一つ持っておいて、そのドメインでサブドメインを作れば、無料でテスト環境を量産することができます。
つまり、etto.holdingsというドメインがあれば、sub.etto.holdingsやtest.etto.holdingsというサブドメインはサーバ側で無限に量産できるということです。同時にいくつもサイト制作をしていると10個くらいはサブドメインが必要になりますが、命名どうしよう、という悩みますよね。
基本的には、クライアント名.etto.holdingsとしておくと良いです。覚えやすいですしね。
ただ、sub.etto.holdingsやtest.etto.holdingsみたいに汎用的な名前を付けておいて、プロジェクトが終わるたびに中身のデータを消して使えば初期設定とか面倒なことをしなくてよくなるので、さらに効率化できます。
そういう名前の例を紹介しておくので、良かったら使ってみてください。
ネーミング例
- play.：試験的な実装用
- mirror.：本番に近い環境（ミラーリング環境）
- lab.：実験や新機能テスト専用（Lab）
- incubator.：新規機能の育成・試験環境
- forge.：新しいアイデアやプロトタイプの鍛錬場
- arena.：テストや検証が活発に行われる環境
- vault.：重要な機能を安全にテストするための環境
- holo.：仮想的なシナリオを想定してのテスト
- zen.：落ち着いて検証したいときの環境
- void.：削除や実験に使える、何も残らない環境
- sandbox.：すでに使われることも多いですが、実験的なテスト用
- preview.：リリース前の内容確認用
- review.：コードや機能のレビュー用
- hotfix.：ホットフィックスの検証環境
- legacy.：旧バージョンのテスト用
まとめ
サブドメインを使ったWordPressのテスト環境にベーシック認証を設定することで、外部からの不正アクセスを防ぎ、安全に開発を進めることができます。手順も非常にシンプルで、サーバーの設定ファイルを少し編集するだけで導入可能です。ぜひ、セキュリティを向上させるために試してみてください。
