本文へスキップ
WEBのチカラ オフィス向け 不動産向け 学習塾向け 小売店向け 飲食店向け

テストサイトとは?作るメリットや作り方、注意点を初心者向けに解説

更新

執筆 中小企業のチカラ編集部 監修 東 直樹 (Webコンサルタント)

この記事の内容について相談する

専門スタッフが無料でお答えします。オンライン相談も可能です。

今すぐ無料相談する

 

Webサイトを更新するとき、本番サイトを直接編集すると、表示崩れや機能停止などのトラブルがそのままユーザーに影響する可能性があります。

 

そこで利用されるのが「テストサイト」です。

 

テストサイトとは、本番サイトへ変更を反映する前に、デザインや機能、WordPressの更新などを確認するための環境です。

 

「テスト環境」や「ステージング環境」と呼ばれることもあります。

 

本番サイトに近い環境を用意しておけば、更新や修正を事前に試せます。

 

問題が見つかっても、本番サイトには影響しません。

 

一方で、テストサイトの設定が不十分だと、検索エンジンに登録されたり、一般ユーザーから閲覧されたりする可能性があります。

 

テストサイトは、作るだけでなく安全に管理することも重要です。

 

ここでは、テストサイトとは何か、作るメリットや必要性、基本的な作り方、運用時の注意点まで初心者向けにわかりやすく解説します。

 

ホームページ制作に関するお悩みはお気軽にご相談ください。

 

今すぐ無料相談

 

テストサイトとは

 

テストサイトとは、本番サイトに変更を反映する前に、表示や動作を確認するためのWebサイトです。

 

本番と同じ、またはできるだけ近い環境を作り、その中で更新や修正を試します。

 

たとえば、次のような作業に利用できます。

 

  • ページのデザイン変更
  • WordPress本体の更新
  • テーマやプラグインの更新
  • フォームの変更
  • 新機能の追加
  • サーバー設定の変更

 

本番サイトへ直接変更を加えるのではなく、まずテストサイトで動作を確認します。

 

問題がないことを確認してから、本番環境へ反映しましょう。

 

本番サイトへ反映する前に変更内容を確認する環境

Webサイトの修正では、コードを少し変更しただけでも予期しない場所へ影響が出ることがあります。

 

たとえば、CSSを変更した結果、パソコンでは正常でもスマートフォンでレイアウトが崩れるケースです。

 

WordPressのプラグインを更新したことで、問い合わせフォームが送信できなくなる場合もあります。

 

本番サイトで直接作業すると、その状態を実際のユーザーに見られる可能性があります。

 

テストサイトがあれば、次の流れで作業を進められます。

 

  1. 修正する
  2. テストサイトで確認する
  3. 問題を修正する
  4. 本番へ反映する

 

変更内容を公開前に確認できるため、トラブルを減らしやすくなります。

 

本番サイトとは目的が異なる

本番サイトとテストサイトは、見た目がほぼ同じでも目的が違います。

 

本番サイトは、一般ユーザーへ情報やサービスを提供するためのサイトです。

 

一方、テストサイトは、運営者や制作担当者が確認作業をするために使います。

 

そのため、テストサイトは通常、次の状態で管理します。

 

  • 検索結果へ表示させない
  • 一般ユーザーへ公開しない
  • 本番とは別のURLで管理する

 

テストサイトは、本番サイトの単なるコピーではありません。

 

「安全に変更を試すための場所」と考えると分かりやすいでしょう。

 

テストサイトを作るメリット・必要な理由

テストサイトを用意する最大のメリットは、本番サイトに影響を与えず変更を試せることです。

 

特にWordPressでは、テーマやプラグイン、PHPなど複数の要素が関係しています。

 

一つを更新しただけでも、別の機能に不具合が発生する可能性があります。

 

公開前に問題を見つけるためにも、テストサイトが役立ちます。

 

本番サイトへ影響を与えず修正を確認できる

Webサイトでは、日常的に細かな修正が発生します。

 

たとえば、次のようなケースが挙げられます。

 

  • 文字サイズを変更する
  • ボタンの色を変える
  • 画像を差し替える
  • フォーム項目を追加する
  • ページ構成を変更する

 

小さな変更に見えても、記述ミスや設定ミスによって別の部分へ影響することがあります。

 

本番サイトを直接変更すると、その不具合がすぐユーザーへ表示されます。

 

テストサイトなら、完成するまで何度でも修正できます。

 

作業途中の状態を公開する必要もありません。

 

特に、大きなデザイン変更や複数ページに影響する修正では便利です。

 

WordPressやシステムの更新による不具合を事前に確認できる

WordPressでは、定期的なアップデートが必要です。

 

主な更新対象は次のとおりです。

 

  • WordPress本体
  • テーマ
  • プラグイン
  • PHP

 

ただし、更新後に必ず正常動作するとは限りません。

 

新しいWordPressのバージョンに古いプラグインが対応していなければ、エラーが発生することがあります。

 

PHPを更新したことで、一部の機能が動かなくなる場合もあります。

 

テスト環境で先にアップデートすると、次の点を確認できます。

 

  • ページが正常に表示されるか
  • 管理画面を操作できるか
  • フォームが送信できるか
  • ログインできるか
  • 決済や会員機能が正常か

 

問題があれば、本番環境への反映を止められます。

 

新しいデザインや機能を試せる

テストサイトでは、新しいアイデアを本番に影響させず試すこともできます。

 

たとえば、次のようなケースが挙げられます。

 

  • トップページをリニューアルする
  • 新しいナビゲーションを導入する
  • 新しい問い合わせフォームを作る
  • WordPressテーマを変更する
  • 新機能を追加する

 

実際の画面で確認すると、設計段階では気づかなかった問題が見つかることがあります。

 

たとえば、「スマートフォンではボタンが押しにくい」「メニューが分かりにくい」「既存のプラグインと競合する」といった問題です。

 

こうした問題を、公開前に見つけられます。

 

テストサイトなら、納得できるまで修正できます。

 

社内確認やクライアント確認にも利用しやすいでしょう。

 

トラブル時の対応を事前に確認できる

テストサイトは、更新確認だけでなく、トラブル対応を練習する場所としても利用できます。

 

代表的なのが、バックアップからの復元です。

 

バックアップデータを保存していても、実際に復元できなければ意味がありません。

 

テストサイトでは、次の点を確認できます。

 

  • バックアップファイルが正常か
  • 復元手順が正しいか
  • 復元後にページが表示されるか
  • データベースが正常に戻るか

 

本番サイトで障害が起きてから初めて復元方法を確認するより、安全です。

 

ECサイトや予約サイトなど、停止による影響が大きいサイトでは特に重要になります。

 

テストサイトの作り方

 

テストサイトの作成方法は、利用しているサーバーやCMSによって異なります。

 

基本的な考え方は、本番サイトとは別の場所に、本番と近い状態のサイトを用意することです。

 

本番サイトを手動でコピーする方法もあれば、WordPressの機能やプラグイン、レンタルサーバーのステージング機能を利用する方法もあります。

 

本番サイトをコピーして作成する

代表的なのは、本番サイトを複製してテスト環境を作る方法です。

 

WordPressの場合は、次のファイルやデータをコピーします。

 

  • WordPress本体のファイル
  • テーマ
  • プラグイン
  • 画像
  • データベース

 

本番サイトと同じ内容を再現できるため、実際の環境に近い状態でテストできます。

 

たとえば、新しいWordPressテーマへ変更したい場合も、本番と同じ記事や画像が入った状態で確認できます。

 

ただし、本番データをコピーする際は注意が必要です。

 

ECサイトや会員サイトでは、次の情報が含まれている場合があります。

 

  • 顧客情報
  • 注文情報
  • 会員情報
  • 問い合わせ内容

 

テストに不要な個人情報は削除したり、ダミーデータへ置き換えたりするなど、適切に管理しましょう。

 

別のURLや領域にテストサイトを用意する

テストサイトは、本番サイトとは別のURLや領域へ作成します。

 

たとえば、次のようなケースが挙げられます。

 

https://test.example.com

 

このようなサブドメインを使う方法があります。

 

ほかにも、次のような別ディレクトリや、別ドメインに作成する方法があります。

 

https://example.com/test

 

本番サイトと区別しやすいURLを選びましょう。

 

重要なのは、本番とテストを明確に区別することです。

 

URLに加え、次の項目も本番環境と分けます。

 

  • データベース
  • 設定ファイル
  • アップロード先
  • 外部サービスとの接続先

 

特にデータベースの接続先を間違えると、テスト作業が本番データへ影響する可能性があります。

 

作成後は、本番とテストが完全に分離されているか確認しましょう。

 

WordPressではプラグインなどを利用する方法もある

WordPressでは、サイトを複製するためのプラグインを利用する方法もあります。

 

また、レンタルサーバーによっては、ステージング環境を簡単に作成できる機能が提供されています。

 

こうした機能では、次の作業を自動化できる場合があります。

 

  • ファイルのコピー
  • データベースの複製
  • URLの書き換え

 

初心者にとっては、手動でデータベースを操作するより簡単なケースもあります。

 

ただし、テスト環境から本番環境へ戻す際の動作は事前に確認しておきましょう。

 

たとえば、テストサイトを作成した後に、本番サイトで新しい注文が入ったとします。

 

その状態でテスト側のデータベースを本番へ丸ごと上書きすると、新しい注文データが消える可能性があります。

 

「何がコピーされるのか」「どこまで上書きされるのか」を把握したうえで使うことが重要です。

 

 

テストサイトを作るときの注意点

テストサイトは、本番サイトから分けて作るだけでは十分ではありません。

 

設定によっては、検索エンジンに登録されたり、一般ユーザーからアクセスされたりする可能性があります。

 

本番との接続設定を間違えると、テスト操作が実際のデータへ影響する危険もあります。

 

安全に運用するためのポイントを確認しておきましょう。

 

本番環境に近い状態にする

テスト結果を本番環境でも再現するには、テストサイトと本番サイトの条件をできるだけ揃える必要があります。

 

主に確認したい項目は次のとおりです。

 

  • WordPressのバージョン
  • PHPのバージョン
  • テーマ
  • プラグイン
  • データベース
  • サーバー設定

 

たとえば、本番ではPHP 8系を使う予定なのに、テストサイトだけ異なるPHPバージョンを使用しているとします。

 

その状態で正常に動いていても、本番へ反映した後にエラーが発生する可能性があります。

 

テストサイトは「別のサイト」ではなく、「本番環境を再現する場所」と考えるとよいでしょう。

 

本番サイトと混同しないようにする

本番サイトをコピーすると、見た目だけではどちらがテスト環境なのか分からなくなることがあります。

 

たとえば、次のようなミスが考えられます。

 

「本番を更新したつもりがテストサイトだった」というミスです。

 

逆に、「テスト作業のつもりで本番を変更してしまった」というケースもあります。

 

誤操作を防ぐには、次の方法が挙げられます。

 

  • サイト上部へ「TEST」と表示する
  • 管理画面の色を変える
  • サイト名へ「テスト環境」と付ける
  • URLを明確に分ける

 

複数人でサイトを管理する場合は、特に重要です。

 

見ただけで環境を判断できるようにしておきましょう。

 

検索エンジンにインデックスされないようにする

テストサイトは、通常Googleなどの検索結果へ表示させる必要がありません。

 

本番サイトをコピーしたページが検索結果へ登録されると、同じようなコンテンツが複数存在する状態になることがあります。

 

また、公開前の文章や古い情報が検索結果へ出る可能性もあります。

 

そのため、テストサイトでは検索エンジンへ登録されないよう設定します。

 

代表的な方法の一つがnoindexです。

 

ただし、設定したまま本番公開しないよう注意しましょう。

 

本番へテスト環境をコピーすると、noindexも一緒に引き継がれることがあります。

 

公開前には必ず確認が必要です。

 

一般ユーザーがアクセスできないようにする

検索結果へ表示されなければ、テストサイトが安全になるわけではありません。

 

URLを知っている人であれば、直接アクセスできる状態になっている場合があります。

 

テストサイトには、次の情報が含まれることもあります。

 

  • 公開前の商品
  • 新料金
  • 未発表サービス
  • 顧客情報
  • 社内情報

 

そのため、必要に応じて次の方法を利用します。

 

  • Basic認証
  • IPアドレス制限
  • VPN
  • サーバー側のアクセス制限

 

「検索エンジンへ出さない」と「一般ユーザーからアクセスできなくする」は別の対策です。

 

両方を分けて考えましょう。

 

本番環境と同じデータを直接扱わない

テストサイトで特に注意したいのが、本番用データベースをそのまま参照してしまうケースです。

 

テスト環境で商品情報を削除したつもりが、本番データまで消えてしまう可能性があります。

 

ECサイトなら、テスト注文が本物の注文として登録されることも考えられます。

 

そのため、テスト環境では次のようなテスト用の接続先や設定を利用します。

 

  • テスト用データベース
  • テスト用API
  • テスト用決済環境
  • テスト用メールアドレス

 

外部サービスへ接続している場合も注意しましょう。

 

たとえば、問い合わせフォームのテストメールが実際の顧客対応窓口へ大量送信されないよう、送信先を変更する方法があります。

 

テストサイトは、Webページだけでなく接続するシステムまで本番と分離することが重要です。

 

テストサイトはnoindexだけで十分?

 

テストサイトを検索結果へ出さないために、noindexを利用する方法があります。

 

ただし、テストサイトの安全管理という意味では、noindexだけで十分とは限りません。

 

noindexは検索エンジン向けの設定です。

 

一般ユーザーからのアクセスや、公開前データの閲覧を防止する機能ではありません。

 

noindexは検索結果への登録防止に使える

noindexは、検索エンジンへページを検索結果に登録しないよう伝える指定です。

 

テストサイトのように、本番公開を目的としていないページで利用できます。

 

本番サイトをコピーした環境であれば、検索結果へ類似ページを出さないためにも重要です。

 

一方で、設定の解除忘れには注意しなければなりません。

 

テスト環境でnoindexを付けたまま本番へ移行すると、本番ページも検索結果へ登録されなくなる可能性があります。

 

そのため、本番公開前には「noindexが残っていないか」を確認しましょう。

 

robots.txtだけではインデックス防止にならない場合がある

検索エンジン対策として、robots.txtを利用する場合もあります。

 

ただし、robots.txtは主にクローラーのアクセスを制御するための仕組みです。

 

クロールを禁止したからといって、URLが絶対に検索結果へ表示されないとは限りません。

 

外部ページなどからURLが発見されると、検索エンジンがページ内容を取得できない状態でもURLだけ認識する可能性があります。

 

また、robots.txtでクロールを禁止していると、ページ内に設定したnoindex自体を検索エンジンが確認できない場合があります。

 

そのため、robots.txtでブロックすれば完全に検索結果から消せるとは考えないようにしましょう。

 

noindexとrobots.txtは目的が異なります。

 

テスト環境はアクセス制限も組み合わせる

一般公開する必要がないテストサイトでは、検索エンジン向けの設定だけでなく、アクセスそのものを制限する方法があります。

 

たとえばBasic認証を設定すると、IDとパスワードを知っている人だけ閲覧できます。

 

社内からしか使わないのであれば、特定のIPアドレスだけを許可する方法もあります。

 

特に次の場合は、アクセス制限を検討しましょう。

 

  • 公開前の情報がある
  • 顧客データを含んでいる
  • 管理画面やAPIが動作する
  • テスト用機能を外部から触られたくない

 

検索結果へ表示させないだけではなく、「そもそも誰が入れる環境なのか」まで管理することが重要です。

 

本番公開時の解除忘れにも注意する

テストサイトでは、安全のためにさまざまな制限を設定します。

 

しかし、それらを本番サイトへ残したままにすると、公開後のトラブルにつながります。

 

たとえば、次のようなケースが挙げられます。

 

  • noindexが残っている
  • Basic認証を解除していない
  • IP制限が残っている
  • robots.txtでクロールを止めている
  • テスト用URLのままになっている

 

そのため、本番公開時にはチェックリストを作って確認するとよいでしょう。

 

主な確認項目は次のとおりです。

 

  • noindexを解除したか
  • robots.txtを確認したか
  • アクセス制限を解除したか
  • 本番URLへ切り替わっているか
  • 本番データベースへ正しく接続しているか
  • テスト用メール設定が残っていないか
  • フォームを正常に送信できるか
  • 決済や会員機能が正常に動くか

 

テストサイトを作る目的は、安全に本番公開することです。

 

最後の切り替え確認まで含めて管理しましょう。

 

まとめ|テストサイトで本番公開前に安全に確認しよう

 

テストサイトとは、本番サイトへ変更を反映する前に、表示や機能を確認するための環境です。

 

Webサイトの更新やWordPressのアップデート、新機能追加などを本番へ直接反映すると、問題が発生した場合にユーザーへ影響します。

 

テストサイトを用意しておけば、本番環境を止めずに確認や修正ができます。

 

作成方法としては、本番サイトをコピーして別URLや別領域へ配置する方法があります。

 

WordPressでは、プラグインやレンタルサーバーのステージング機能も選択肢になります。

 

重要なのは、本番サイトに近い環境を作ることです。

 

WordPressやPHP、テーマ、プラグインなどの条件が大きく違うと、テスト結果を本番へそのまま当てはめられません。

 

また、テストサイトと本番サイトを見分けやすくすることも重要です。

 

管理画面の表示やURLを変え、誤操作を防ぎましょう。

 

検索エンジンへの対応も必要です。

 

テストサイトを検索結果へ出さないためにnoindexを利用できますが、それだけで一般ユーザーからのアクセスまで防げるわけではありません。

 

公開前情報や重要なデータを扱う場合は、認証やIP制限なども組み合わせます。

 

さらに、テスト環境から本番データを直接操作しないようにすることも大切です。

 

データベースや決済、メール、外部APIなどはテスト用に分離しましょう。

 

本番公開時には、テスト環境で使っていたnoindexやアクセス制限の解除忘れにも注意が必要です。

 

テストサイトは、単に本番サイトをコピーしただけの場所ではありません。

 

本番へ影響を与えず変更を試し、問題を見つけ、安全に公開するための環境です。

 

更新前に確認できる仕組みを整えておくことで、Webサイト運営におけるトラブルを減らしやすくなります。

 

監修者コメント

Webへの投資は、金額の大小より「何をもって成功とするか」を決めているかで結果が変わります。発注前に目的と指標を一枚にまとめておくと、制作会社との認識のズレがほぼなくなります。

東 直樹
SUPERVISOR

東 直樹 あずま なおき

Webコンサルタント

株式会社中小企業のチカラ Web戦略室

制作会社でディレクターを務めたのち、事業会社側のWeb責任者を経て現職。制作費の妥当性や制作会社の選び方など、発注する側…

東 直樹が監修した記事をすべて見る

関連キーワード

    次に読む

    サーバー稼働率とは?99.99%の意味やSLAとの違いをわかりやすく解説

    読む

    あわせて読みたい

    続きは、無料会員登録で全部読めます

    会員登録すると、コスト削減の実額シミュレーションや比較表つきの記事など、 中小企業の経営判断にそのまま使える情報がすべてご覧いただけます。

    会員限定記事が読める比較表・料金シミュレーションつきの実務記事を公開しています。
    気になる記事を保存できる「あとで読む」した記事を、端末をまたいで見返せます。
    専門家に相談できる補助金・採用・Webの困りごとを、無料でご相談いただけます。

    登録は1分・費用は一切かかりません

    DOWNLOAD

    ダウンロード

    補助金カレンダー、固定費チェックリスト、採用KPIテンプレートなど、
    そのまま使える資料をご用意しています。すべて無料です。

    ダウンロードページを見る

    CONTACT

    お問い合わせ

    補助金が使えるか分からない、採用手段を選びきれない、
    といったご相談も承っています。お気軽にお問い合わせください。

    お問い合わせはこちら