WordPressはパワフルで便利な反面、操作した・していないに関わらずサイトにアクセスできない、エラーが出る等の不具合が度々起こります。また、本番サイトへの影響を考えるとちょっとした改修やテスト目的でも慎重な操作が必要となりミスを起こせません。
そんなときのために、本番サイトとは別のテスト用サイトを用意することを推奨します。
- テスト用サイトや検証用サイトとは？
- WordPressのテスト用サイトはなぜ必要なのか？
- テストサイトを作っていれば回避できるリスク
- テストサイト構築の際の注意点
等を本記事ではご紹介します。
テスト環境の作り方を知りたい場合は以下をご参照ください。
同一サーバー上に構築するWordPressのテスト環境の作り方
テスト環境とは
開発環境、テスト環境、検証環境、ステージング環境etc…いろいろな呼び方がありますが、基本的には本番サイトと同様のサイトを複製し、動作確認や変更や改修によるテスト、検証確認用途のためのサイトを指しています。
各サイトや環境で呼び方は異なりますが、ここでは上記の目的を実施するためのサイトとして「テストサイト」と呼びます。
テストサイトはなぜ必要なのか
本番環境しかない場合、変更や改修を加える場合直接本番環境上で実行する必要があり、なにかエラーがあった場合サイト全体に影響があることもあり、稼働中のサイトの場合は非常にリスクが高いです。
そこで、本番サイトを複製した環境を用意することで、まずはテストサイトで実行し、問題ないことを確認したり、関係者に確認をとった上で本番環境に適用する、というようなフローをとることが可能になり、リスクを抑えた運用が可能になります。
WordPressにおいてのテストサイト構築
静的サイトであるHTMLページであれば、ウェブデータ一式をダウンロードしhtmlファイルをEdgeやChromeといったブラウザで開くことにより、ページを表示させることができます。しかしWordPressサイトの場合、実行プログラムのPHPやデータベースであるMySQLを利用できるパソコン上でWordPressを動かすためのサーバー環境（ローカル環境）が必要となり、書籍やネット上のページを参考に構築はできるものの、経験が無い方がサーバー環境を構築することはなかなかハードルの高い作業といえます。
また、ローカル環境を構築したとしても、本番環境とPHPやMySQL等のバージョンが異なると、ローカル環境では不具合はないが本番環境で不具合が起こるといったこともあり、せっかく事前確認したものの本番サイトでエラーが起こってしまうということにもなります。そのため、できる限り本番環境と同様のサーバー環境でテストサイトを構築することがリスクを抑えた運用となります。
テスト環境がないと困ること一例
テストサイトがなく、本番サイトしかない状態だと起こり得る問題やデメリットを一部挙げます。
WordPressのアップデートが怖い
WordPressは本体やプラグインのアップデートが頻繁にあります。アップデートをしないという選択もできますが、セキュリティ対策やバグアップデートを考えると、しないほうがリスクが大きいでしょう。また、アップデートしないことでサイト改ざんなどの被害にあい、別サイトへ遷移されたり、メール送信などされるとユーザーへの二次被害も考えられます。
本番環境でアップデートをした場合、WordPress自体（コア）での不具合や、コアとプラグインとの衝突、コアとテーマの不具合、phpバージョンの致命的エラー・注意・警告などのメッセージ表示といったかたちで本番サイト表示に不具合をもたらす可能性があります。
簡易的な不具合だったり、対応できる知識をもった方がすぐに動けるというのであればいいのですが、そうでない場合、その間もユーザーはアクセスするため、信頼低下や流入減につながります。
こういった問題を防ぐため、テストサイトで一度アップデートを行い、サイト表示が問題ないことを確認した上で本番サイトでもアップデートすることにより、アップデートにまつわる問題を最小限にすることが可能です。
改修や変更においてテストサイトで検証ができない
「サイトを公開したら一切触らない」という場合ではない限り、サイトを公開した後もよりよいサイト運営のために新しいページを追加したり、機能追加のためテンプレートファイルを修正する機会はあると思います。
その際本番サイトしか触れない環境だと、コードに不備がありエラーがでるケースや、サイト全体に影響があって公開前に影響がある場合など、非常に使い勝手が悪くなります。
また、関係者に公開前にページ確認をすることができないため、余裕をもった公開ができません。
もしテストサイトがあれば、改修対応のページをテストサイトで対応し、関係者に確認を取った上で本番サイトへ該当ファイルをアップロードする、といった余裕のある運用が可能です。
新しいプラグインやテーマのテストができない
WordPressの人気の理由の一つにプラグインの存在は大きいでしょう。世界中の開発者が日夜プラグインを開発・機能追加等をしており、今まで使っていたものよりさらに良いプラグインにめぐりあうことも珍しくありません。
また、無料/有料テーマも膨大に存在し、今使っているテーマよりも良いと思えるテーマがあった場合、テーマの変更をしてサイトを確認したりページの調整をする必要があります。
そんなときに本番サイトだけしかないと、プラグインの追加によりプラグイン同士の衝突でエラーとなるケースや、テーマ切り替えでサイト公開中にユーザーを困惑させてしまい、離脱につながる可能性があるなど、適切なサイト運営ができません。
テストサイトでプラグインの追加テストや検証、テーマ切り替えによるサイトチェックやウィジェットの調整など、必要な作業が可能です。
ちなみに、その際の作業量が多く同じ作業を本番作業でも行うのに時間がかかる場合、データベースごと差し替えて本番用に内部文字列を置換することができれば、テストサイトでおこなった反映を一瞬で適用することが可能となり、時間の節約に繋がります。
本番サイトに問題があり復元する必要が出た場合に検証する環境がない
サイトを運営していれば、何かしら問題があることがほとんどです。そんな時、バックアップデータから以前の状態に戻したいという選択肢も出てくるでしょう。
バックアップデータから復元する作業を行うわけですが、慣れない作業のため知識のある方でも間違えることも多く、本番サイト上で直接行うのは慎重に行う必要があり時間やストレスがかかる作業でしょう。
その場合はまずテスト環境でバックアップデータから復元を行います。ミスしても大丈夫。何度でもバックアップデータから作業が可能です。
PHPやデータベースのバージョンを変更したいが何か問題が起こらないか不安
PHPは5.6と7.0のパフォーマンスを比較すると、1秒あたりに処理できるリクエスト数が倍以上違います。
PHP 5.6 vs PHP 7 Performance Comparison Review | GBKSOFT Blog
もし現在PHP5.6や5.2といった昔のバージョンをお使いの場合、7.0や7.1といった新しいバージョンに変更することにより処理できるリクエスト数が増え、ページ表示の高速化が期待できます。
しかし、安易にバージョンを変更したことで、エラーや警告メッセージが表示される可能性があります。これは5.6では非推奨だが使えていた機能が7.0になって廃止になり、エラーとなるケースなどです。
その場合、該当箇所を探して修正する必要がありますが、プラグインが原因による場合、開発者の対応を待つケースもあります。
事前に確認するために、一度テストサイトでバージョン変更を試し確認して問題がないことがわかってから、本番サイトも同様のバージョンに変更する、といった対策がとれます。
※レンタルサーバー会社によってはドメインごとのバージョン選択ができない場合もあります。
テストサイト構築において注意すること
サイトURLはサブディレクトリではなくサブドメイン形式にする
テスト用サイトのURLは任意に決めることが可能です。その際、「サブドメイン」「サブディレクトリ」として決めることになることが多いと思いますが、サブドメイン形式を選択することをおすすめします。
例：
- サブドメイン形式： https://test.example.jp
- サブディレクトリ形式： https://example.jp/test
理由は、サブディレクトリ形式の場合一つ階層が下がるため、WordPressのテンプレートタグの使い方やテーマファイル上のパーマリンクの記述方法によっては画像やリンクのパスがつながらず、画像が表示されない、CSSやJavaScriptがリンクされず崩れたりエラーになったり、リンクがつながらず画面遷移できない、といったことが起こる可能性があります。
基本的にはパスワード保護する
本番サイトがある状態で、テストサイトも公開しだれでも見られる状態の場合、検索インデックスの評価をうけると重複サイトとみなされ本番サイトの検索結果が下落するリスクがあります。
noindex等の対応をすることでインデックス評価を受け付けないよう設定は可能ですが、URLがわかれば誰でもアクセスできる状態というのはいずれにしても好ましくありません。
ID/パスワードで保護するBasic認証等でドメイン全体を保護しておきましょう。
同じサーバー環境で構築する
上でもご紹介した通り、phpやデータベースのバージョンが異なると不具合が起こる可能性があります。ローカル環境にテスト環境を作ったとしても、PHPやMySQLのバージョンが異なり本番サイトでエラーメッセージが出る、プラグインが動かない、といったケースがあります。
リスクを減らすため、できる限りテスト環境と本番環境を同一のサーバー環境にします。レンタルサーバーを契約して運営している場合、契約中のサーバー内にサブドメインを作成し、環境を構築するのがいいでしょう。もしサブドメインが使えない場合は、初期ドメインをテストサイトにあてがう、という方法もとれます。
こうすることにより、テストサイトでは動いていたのに、本番サイトでエラーが起こったというリスクを最小限にできます。
データベースは共有にせず独立して作成する
MySQL等のデータベースは、本番サイトと共有して利用することが可能です。共有することのメリットとして、本番サイトで反映させた最新記事がテスト側にも反映されるため、ほぼ完全に同じサイトの複製として利用できるということです。
しかし、もし間違ってテストサイト側で登録や保存をしてしまったり、新しく追加したプラグインに何か問題があってサイトが表示できなくなってしまったとしたら本末転倒ですよね。
そのため、本番サイトのデータベースは本番用、テストサイトは別のデータベースを作成し、それぞれ別のデータベースを利用する方が安全な運用となります。
また、接頭辞を複数作って1つのデータベース内での運用も可能ですが、バックアップから復元する際やサーバー引っ越しの際に接頭辞の変更は少し手間がかかり、手動で変更しないといけない部分が出てくるため、文字列を一括置換で変更するだけで対応できる方がミスが少なく運用できます。
「簡単インストール」等の機能は使わずに複製して構築する
一般的なレンタルサーバーにはよく「WordPressかんたんインストール」というような機能があります。これは非常に簡単にWordPressをインストールすることができるとても素晴らしい機能です。
しかし、これを利用すると、本番サイトのWordPressで構築したサイトを模倣して再度構築しないといけないため、作業がとても大変となり時間がかかる上、自動的に割り振られるWordPressのIDも異なってしまうため、テンプレートファイル内からIDを起点に呼び出している関数などが動きません。
これらを回避するため、テストサイト作成の際は、既にサイトがある場合は現在のサイトをウェブデータ一式とデータベース一式を複製して作成しましょう。また、現在サイト作成中であれば、公開のタイミングでウェブデータとデータベースを一式複製し、作成するようにしましょう。
こうすることでIDもログインアカウント情報もウィジェットで設定した項目もすべて同じ状態でサイトをコピーすることができ、手間も大幅に減り一石二鳥です。
最後に
以上、WordPressサイトのテストサイトを作る重要性やメリット・デメリットのまとめでした。最初に作成する手間はありますが、一度作ってしまえばその後はずっと利用できるため、ぜひ構築されることをおすすめします。
また、これを機会にWordPressサイトのセキュリティ対策やアップデート、バックアップ体制などを見直し、安心・安全にサイトを運用できる環境を見直すことで、様々な不安から解放されより良いサイト運営ができ、最終的にはサイトを利用するユーザーにとって使いやすいサイトになっていくことに繋がります。
