テスト環境でOLTANAを実装し、All-in-One WP Migrationでクライアントドメインへ反映する手順
Web制作では、まず制作・検証用のテスト環境でサイトを完成させ、その後クライアントの本番環境(公開サイト)へ反映する流れが基本になります。
この記事では、WordPressテーマ「OLTANA」で制作したサイトを、All-in-One WP Migrationを使って「自分のドメイン(テスト環境)→クライアントのドメイン(本番環境)」へ移行する手順をまとめます。
ゴール:テスト環境で完成させたOLTANAサイトを、クライアントのドメインへ安全に反映し、公開前チェックまで完了できる状態にすることです。
この記事で行うのは、次の3つです。
- テスト環境(制作環境)を用意し、OLTANAでサイトを完成させる
- All-in-One WP Migrationで、テスト環境→本番環境へ移行する
- 移行後の調整と、納品前チェックを行う
1. テスト環境→本番反映の全体像について
1-1. この記事で使う言葉の整理
最初に用語を揃えておくと、作業場所を間違えにくくなります。
| 用語 | 意味 | この記事での例 |
|---|---|---|
| テスト環境 | 制作・検証を行う環境 | 制作者のドメイン上に用意したWordPress |
| 本番環境 | 実際に公開する環境 | クライアントのドメインのWordPress |
| マイグレーション | サイトを別環境へ引っ越すこと | All-in-One WP Migrationで移行する |

テスト環境と本番環境って、どこからどこまで別物として考えるべきですか?

「本番に影響を出さない場所」がテスト環境だね。作業はテストで完結させて、最後に本番へ反映する。ここを分けるだけで事故がかなり減るよ。
1-2. 作業フェーズを先に把握する
実作業はフェーズで分けると、抜け漏れが減ります。
| フェーズ | 作業場所 | 主な作業 | 先に知っておくポイント |
|---|---|---|---|
| 制作 | テスト環境 | OLTANA導入、デモ反映、文章・画像差し替え | テスト環境は外部に見せない前提で準備する |
| 本番準備 | 本番環境 | WordPress用意、バックアップ方針確認 | インポートで上書きになるため、既存サイト有無を整理する |
| 移行 | テスト→本番 | エクスポート(.wpress)→インポート | ファイルサイズ制限やサーバー上限に注意する |
| 移行後調整 | 本番環境 | URL・SSL・404・フォーム確認 | パーマリンクの保存し直しが定番の調整になる |
| 納品前チェック | 本番環境 | 表示・導線・送信テスト | 公開前に「見た目」と「動作」の両方を確認する |
2. テスト環境を用意する方法
2-1. テスト環境のURL設計を決める
テスト環境は、運用しやすい形に揃えておくと後工程が安定します。
| 方式 | 例 | 特徴 | この方式が向いているケース |
|---|---|---|---|
| サブドメイン | stg.example.com | 本番に近い形で運用しやすい | 納品後も検証環境として残すことがある |
| サブディレクトリ | example.com/stg | ドメインは同じで分けられる | サーバー契約が同一で、管理をまとめたい |
| 別ドメイン | example-dev.com | 完全分離できる | 既存本番と強く分離したい |
2-2. WordPressを用意し、最低限の初期設定を整える
テスト環境側でWordPressを用意したら、次の設定だけは先に揃えておくと安心です。
| 設定項目 | 操作場所 | 目的 |
|---|---|---|
| サイトタイトル・キャッチフレーズ | 「設定」→「一般」 | 納品前にクライアント情報へ置き換えやすくする |
| パーマリンク | 「設定」→「パーマリンク」 | 後からURLが変わるトラブルを減らす |
| SSL(https) | サーバー側 + 表示確認 | 本番と同じ条件でチェックできるようにする |
2-3. テスト環境を検索結果に出さない設定を行う
テスト環境は公開前の状態が含まれるため、検索結果や第三者の閲覧対象にならないようにしておきます。
| 対応 | 操作場所 | 目的 | 目安 |
|---|---|---|---|
| インデックス制御 | 「設定」→「表示設定」 | 検索結果に出さない意思表示 | チェックを入れて保存する |
| アクセス制限 | サーバー側(ベーシック認証など) | 第三者の閲覧自体を防ぐ | 提案段階や制作中は特に推奨 |

「検索エンジンに出さない設定」だけで大丈夫でしょうか?

設定は大事だけど、見ようと思えば見れるケースもあるんだよね。制作中はアクセス制限もセットにしておくと、安心して進められるよ。
3. テスト環境でOLTANAを実装する方法
3-1. OLTANAをインストールして有効化する
OLTANAのテーマファイルを用意したら、WordPress管理画面でテーマを追加します。
| 手順 | 操作 | 補足 |
|---|---|---|
| 1 | 「外観」→「テーマ」を開く | テーマ一覧画面に移動します |
| 2 | 「新しいテーマを追加」を選ぶ | 画面上部に表示されます |
| 3 | 「テーマのアップロード」からzipを選択してインストールする | zipのままアップロードします |
| 4 | 「有効化」をクリックする | 反映後、トップページで初期デザインを確認します |
3-2. ライセンス認証の方針を決めておく
OLTANAはライセンスキー認証を採用しており、制作フローの中で「どの環境で認証するか」を整理しておくと迷いません。
| 方針 | 進め方 | 向いているケース |
|---|---|---|
| テスト環境で一度認証し、納品前に本番へ移す | テスト環境で制作→納品前にテスト環境の認証を解除→本番で認証 | テスト環境で編集機能をすべて使って完成させたい |
| 最初から本番環境で認証する | 本番にWordPressを用意し、そこで制作する | 本番環境で直接制作して良い案件(既存影響が少ない) |

テスト環境で認証すると、納品時にもう1回購入が必要になりますか?

基本は「1サイトに1認証」だから、同時に両方で認証すると増える可能性があるね。テストで作って、納品前にテスト側を解除して本番で認証し直す運用が案内されているよ。
3-3. DEMOデザインを反映して制作を進める
OLTANAはDEMOデザインを反映できるため、最初に土台を作ってから内容を差し替える流れが進めやすくなります。
| 作業 | 目的 | ここで固めたい理由 |
|---|---|---|
| DEMO反映 | ベースデザインの確定 | 納品後のデザイン変更を減らす |
| 文章・画像差し替え | 実データへの置換 | 本番反映後の差し替え工数を減らす |
| CTA導線調整 | 問い合わせ・予約など | 公開後の成果に直結しやすい |
3-4. OLTANA運用上の注意点を反映しておく
OLTANAは利用案内として、編集環境やパーマリンク設定に関する注意点があります。
制作途中でつまずかないように、テスト環境の時点で条件を揃えておきます。
| 項目 | 事前に確認すること | 理由 |
|---|---|---|
| 編集環境 | 旧エディター(Classic Editor)を前提にしない | 利用条件として非対応の案内があるため |
| パーマリンク | 「基本」以外で設定する | 「基本」の場合に一部動作が安定しない可能性があるため |
4. 本番環境(クライアントドメイン)を準備する方法
4-1. 本番側で必要な情報を整理する
移行作業は「情報不足」で止まりやすいため、先に必要項目を揃えておきます。
| 確認項目 | 例 | なぜ必要か |
|---|---|---|
| WordPress管理画面 | ログインURL、管理者ID | プラグイン導入とインポートで使用する |
| サーバー | 契約先、SSL設定、容量 | インポート上限やhttpsに影響する |
| ドメイン状況 | 既存サイトの有無 | インポートが上書きになるため判断が必要 |
| バックアップ方針 | サーバー自動バックアップの有無 | 万一の切り戻しに備える |
4-2. 既存サイトがある場合は「置き換え方針」を決める
All-in-One WP Migrationのインポートは、基本的に既存データを置き換える想定になります。
そのため、次のどのケースかを整理してから進めます。
| ケース | 推奨方針 | 補足 |
|---|---|---|
| 新規サイト(既存サイトなし) | 空のWordPressへインポート | 最も事故が少ない進め方です |
| 既存サイトを完全置き換え | 事前バックアップ→メンテ案内→インポート | 公開中サイトの場合は影響範囲が大きくなります |
| 一部だけ反映したい | この記事の手順とは別設計 | 部分移行は運用設計が変わります |
4-3. 本番側にWordPressを用意する
本番側は、できれば「空のWordPress」を用意しておくと進めやすくなります。
インポート前に、管理画面にログインできる状態まで整えます。

インポートしたら、クライアントのサイトは今ある内容が消えますか?

基本は「置き換え」になるよ。だから先にバックアップ方針を決めて、作業時間帯も調整しておくのが安全だね。
5. All-in-One WP Migrationで移行する手順
5-1. 移行元・移行先にプラグインをインストールする
移行元(テスト環境)と移行先(本番環境)の両方で、All-in-One WP Migrationをインストールします。
| 手順 | 操作するサイト | 操作内容 |
|---|---|---|
| 1 | テスト環境 | 「プラグイン」→「新規追加」でAll-in-One WP Migrationを検索し、インストールして「有効化」します |
| 2 | 本番環境 | 同様にインストールして「有効化」します |
5-2. テスト環境でエクスポート(.wpress)を作成する
エクスポートは、テスト環境のWordPress管理画面から行います。
| 手順 | 操作 | 補足 |
|---|---|---|
| 1 | テスト環境で「All-in-One WP Migration」→「エクスポート」を開きます | 画面上部に置換機能が表示される場合があります |
| 2 | ドメインが変わる場合は、必要に応じて置換(例:テストのURL→本番のURL)を設定します | インポート後に旧URLが残るのを減らす目的です |
| 3 | 「エクスポート先」で「ファイル」を選びます | 無料版の場合は「ファイル」が基本になります |
| 4 | エクスポート完了後、ダウンロードしてPCへ保存します | 拡張子は.wpressになります |
5-3. 本番環境でインポートし、置き換えを実行する
本番環境のWordPress管理画面で、インポートを行います。
インポートの途中で「データが上書きされる」警告が表示されることがあります。
| 手順 | 操作 | 補足 |
|---|---|---|
| 1 | 本番環境で「All-in-One WP Migration」→「インポート」を開きます | 画面に最大アップロードサイズが表示される場合があります |
| 2 | .wpressファイルを選択(ドラッグ&ドロップできる場合もあります) | 事前にPCへ保存したファイルを使います |
| 3 | 上書きの警告を確認し、進める場合は続行します | 既存サイトがある場合は特に注意します |
| 4 | インポート完了まで待ちます | サイト規模とサーバー性能で時間が変わります |
5-4. インポート後の定番作業(ログイン・パーマリンク)
インポート直後は、ログイン情報やURL周りが変わる場合があります。
作業を仕上げるために、次を確認します。
| 作業 | 操作場所 | 目的 |
|---|---|---|
| ログイン確認 | 本番環境の「/wp-admin」 | インポート元のユーザー情報でログインできるか確認します |
| パーマリンク保存 | 「設定」→「パーマリンク」 | 404対策として、設定を保存し直します |
| 表示確認 | トップ・下層ページ | メニュー、画像、導線の崩れがないか確認します |
5-5. ファイルが大きくてインポートできない場合の考え方
インポートが止まる・アップロードできない場合は、WordPress側やサーバー側の上限が関係していることがあります。
まずは状況を切り分けて、必要に応じて対応します。
| 状況 | 画面に出やすいサイン | 代表的な対応 |
|---|---|---|
| 最大アップロードサイズが小さい | インポート画面に上限が表示される | サーバーのアップロード上限を調整する |
| 512MB超で止まる | 大きいサイトで失敗する | 上限拡張(有料拡張)を検討する |
| 途中でタイムアウト | 進捗が止まる | 実行時間・メモリ設定を見直す、時間帯を変える |

インポートが途中で止まってしまいます…。やり直しても同じです。

まずは「アップロード上限」と「ファイルサイズ」を確認しよう。大きいサイトだと制限に当たりやすいんだ。原因が分かれば、サーバー設定か拡張で解決できることが多いよ。
6. 移行後に必ず行う確認と調整
移行後は「表示される」だけで終わらず、納品できる状態かを確認します。
特にドメインが変わる移行では、URL・SSL・フォームで差が出やすくなります。
6-1. サイトURLとSSLを確認する
WordPress管理画面で「設定」→「一般」を開き、URLが本番ドメインになっているかを確認します。
| 確認項目 | 見る場所 | OKの目安 |
|---|---|---|
| WordPressアドレス | 「設定」→「一般」 | 本番ドメインになっている |
| サイトアドレス | 「設定」→「一般」 | 本番ドメインになっている |
| SSL表示 | ブラウザで表示 | httpsで警告が出ない |
6-2. 404が出る場合はパーマリンクを保存し直す
下層ページが404になる場合は、「設定」→「パーマリンク」を開き、内容を変えずに「変更を保存」します。
6-3. OLTANAのライセンス状態を確認する
テスト環境でライセンス認証していた場合、本番側で認証し直す運用が必要になることがあります。
本番側のWordPressで、OLTANAの認証状態を確認します。
| 確認項目 | 操作 | 目的 |
|---|---|---|
| 認証の状態 | 「カスタマイズ」→「ライセンス認証」 | 本番で編集機能が有効か確認します |
| 認証運用 | テスト環境の認証解除→本番認証 | 1サイト運用に揃えます |
6-4. お問い合わせ・予約などの動作確認を行う
見た目だけでなく、動作確認もセットで行います。
| チェック項目 | 確認方法 | OKの目安 |
|---|---|---|
| フォーム | テスト送信 | 管理者宛に届く、必要なら自動返信も届く |
| 外部リンク | 主要導線をクリック | 予約、LINE、地図、SNSが正しく開く |
| スマホ表示 | 実機または検証ツール | ボタンが押しやすい、文字が読める |
6-5. テスト環境の公開制御が崩れていないか確認する
移行後は、本番が完成してもテスト環境が残ります。
テスト環境側の設定が外れていないかを確認します。
| 確認項目 | 目的 | OKの目安 |
|---|---|---|
| インデックス制御 | 検索結果に出さない | 設定が維持されている |
| アクセス制限 | 第三者に見せない | 認証が維持されている |
7. 公開切り替えと納品前チェックの方法
7-1. ドメイン切り替え(DNS)が必要なケースを整理する
作業によっては、ドメインの向き先を切り替える(DNS変更)作業が発生します。
ただし、すべての案件で必要になるわけではありません。
| 状況 | DNS作業 | 代表例 |
|---|---|---|
| 本番サーバー上でインポートしている | 不要なことが多い | すでにクライアントドメインでWordPressを動かしている |
| サーバー移転を伴う | 必要 | 新サーバーへ移行し、ドメインを向け直す |
7-2. 納品前チェック(最終確認)
最後に、納品前チェックを行います。
| チェック項目 | 確認方法 | OKの目安 |
|---|---|---|
| 表示 | トップ・主要セクション | レイアウト崩れがない |
| 下層ページ | メニューから巡回 | 404が出ない |
| 主要導線 | CTAボタン | 意図したページ・フォームへ遷移する |
| 送信 | フォーム送信 | 管理者宛にメールが届く |
| SSL | https表示 | 警告が出ない |
| 管理画面 | ログイン | クライアント用の管理者アカウントが整理されている |
8. まとめ
テスト環境でOLTANAサイトを完成させ、本番へ反映する作業は「準備」と「移行後チェック」が分かれ目です。
All-in-One WP Migrationを使う場合は、エクスポート→インポートの流れ自体はシンプルですが、インポートが上書きになる点、ファイルサイズ上限、移行後のURL・パーマリンク調整をセットで進めることが大切です。
落ち着いて一つずつ確認しながら進めることで、公開トラブルを減らすことができます。
