Ameba OwndからWordPressへ本番切り替え｜エックスサーバーのDNS・hosts・SSL手順

独自ドメインを使っているAmeba Owndを、エックスサーバー上のWordPressへ移したい。新しいサイトは作れても、「いつDNSを変えるのか」「hostsは何のために使うのか」「SSLが失敗したらどうするのか」で手が止まりやすい作業です。

結論は、WordPressを先に用意し、本番ドメインでの事前確認とSSLの準備を済ませてから公開先を切り替えること。DNS、暗号化通信、画面表示は分けて確認します。

この記事は、WEB先案内が2026年11月に対応した移行の作業記録をもとに、独自ドメインを引き継ぐ公開切り替えへ絞った実務ガイドです。記事データの取得・取り込み全般はAmeba Ownd移行の全体ガイドをご覧ください。

情報確認日：2026年11月12日。コマンド中のドメインとIPは説明用です。お客様の実ドメイン・IP・アカウント名は掲載していません。

執筆：WEB先案内。WordPressの復旧・保守の現場で確認した手順をもとに整理しています。運営者の経歴・記事の検証方針／復旧・不具合対応の公開事例。公開事例はAmeba Owndの移行実績件数を示すものではありません。

この記事が対象とする構成

• 移行元：独自ドメインで公開しているAmeba Ownd。Amebaブログ（アメブロ）とは別サービスです。
• 移行先：エックスサーバーのWordPress。テストサイトと本番用サイトを同じサーバー内に用意します。
• ドメイン契約：ムームードメインで継続。ドメインを他社へ移管する手順ではありません。
• 操作端末：Mac。Windowsでのhosts編集操作は対象外です。

Ownd提供のサブドメインを使っている場合や、メールを別サービスで利用する場合は、切り替え方が異なります。契約先を問わず同じ設定を入れるのではなく、最初に構成を確認してください。

自分のサイトで必要な作業を知りたい方へ

現在のサイトURLと「残したい内容」「任せたい作業」を、分かる範囲でお知らせください。通常の相談・見積もりは無料、実環境の調査や移行作業は内容と費用を確認してから進めます。

相談後の進め方と引き渡し内容を先に知りたい方は、WEB先案内に任せられることへ進めます。自分で作業する方は、以下のSTEPから確認してください。

必要な手順から読む

• STEP 1　移行対象と新サイトの準備
• STEP 2　ドメイン・DNS・SSLの準備
• STEP 3　本番ドメインへのコピー
• STEP 4　Macのhostsで事前確認
• STEP 5　ネームサーバーの変更
• STEP 6　digによるDNS確認
• STEP 7　hosts解除・通常接続の確認
• STEP 8　SSL・HTTPSの確認
• STEP 9　記事・機能・公開設定の点検
• 困ったとき：止める・戻す・相談する判断

まずは切り替えの全体像を確認する

一般の訪問者には旧サイトを見てもらいながら、別の環境でWordPressを準備します。本番ドメインへコピーした後は、作業用Macのhostsで新サーバーを指定して確認。問題がないこととSSLの準備方法を確認してから、DNSを変更します。

Ameba Ownd公式の予定と、この記事の位置づけ

2026年11月12日時点の公式案内では、エクスポート機能は11月18日提供予定、サービス終了は2027年3月31日11時頃です。公式のWordPress用ZIPには画像本体ではなくURLが含まれるため、終了前に移行先への画像取り込みまで済ませる必要があります。対応しないブロックなどの除外も案内されています。

ここで扱う作業記録は公式機能の提供前のものです。公式エクスポートの実操作を検証した記事ではなく、データ移行後の公開切り替えをどう進めるかを説明します。提供予定は公開時にも再確認してください。

参考：Ameba Ownd公式：サービス終了日の延期と今後の対応

ドメイン・DNS・Webサーバーを混同しない

ムームードメインは独自ドメインの契約先として残し、DNSとWebサイトの公開先を変更できます。NSはDNSの管理先を、Aレコードはホスト名とIPv4アドレスの対応を表します。Aレコード自体が記事や画像を運ぶわけではありません。

STEP 1：新しいWordPressと、移行対象を準備する

テスト用URLにWordPressを用意し、記事・画像・固定ページを取り込んで、テーマやメニューを整えます。今回の構成ではエックスサーバーの初期ドメインをテスト用に使いました。データの移行とデザイン調整はDNS変更より先に行います。

• 記事・ページ数だけでなく、本文、画像、Googleマップなどの埋め込みを確認する。
• 画像が見えるだけでなく、新環境へ保存されているか、旧サービスの画像URLに依存していないか調べる。
• 旧記事URLと移行後URLを対応づける。同じ独自ドメインでも、URL末尾が変われば別途対応が必要。
• メール、問い合わせ、予約・決済などの外部サービスの利用有無と担当範囲を整理する。

テストサイトはアクセス制限を検討し、検索エンジンへ公開しない設定にします。noindexは閲覧を制限する機能ではありません。本番へコピーした後に、必要な制限だけを解除することも忘れないでください。

STEP 2：本番ドメインを登録し、DNS・SSLの準備方法を決める

エックスサーバーのサーバーパネルで、本番の独自ドメインを追加します。初期の「反映待ち」と、旧DNSを利用中の「NS相違」は別の状態です。切り替え前は一般公開先を変えず、サーバー側の準備を進めます。

DNSを変更する前に確認すること

• 現在のNSとDNSレコードを記録し、新しいDNSにも必要なレコードを用意する。
• メール利用があればMX・SPF・DKIM・DMARCなど、実際の契約に必要な設定を確認する。
• wwwあり・なし、サブドメイン、AAAA、CAA、DNSSECの利用有無を確認し、不明な設定を機械的に削除しない。
• WordPressのファイル・データベースのバックアップと、問題時に戻すための情報を確保する。

用語の補足：MXはメールの配送先、SPF・DKIM・DMARCは送信元の認証などに関わる設定です。AAAAはIPv6の宛先、CAAは証明書を発行してよい認証局の指定、DNSSECはDNS応答の真正性を検証する仕組みです。意味が分からないレコードを削除するのではなく、利用状況を確認します。

ムームーメールなど複数サービスで同じドメインを使う場合、ムームードメイン公式はムームーDNSのレコード設定を案内しています。本記事はNSをXserverへ変更する構成です。そのまま適用できない環境では、設定変更前に作業を止めて整理してください。

参考：ムームードメイン：Xserverと接続する方法

SSLは「切り替えてから考える」にしない

エックスサーバーにはDNS変更前に証明書を設定するWeb認証・DNS認証の手順があります。移行元で認証用ファイルを設置できるか、現在の権威DNSへ認証レコードを登録できるかを確認します。Ameba Owndで任意の認証ファイルを置けるとは限りません。

先にNSを変えてからSSLを設定すると、一時的にHTTPSで正常表示できない可能性があります。事前取得できない場合は、影響の可能性と作業時間帯を関係者と確認します。本記事で扱う実例の「切り替え後にSSLを有効化した経過」を、無停止で移行できる手順として一般化しないでください。

参考：エックスサーバー：無料独自SSL設定

STEP 3：WordPressを本番ドメインへコピーする

今回のように同じエックスサーバー内で移す場合、サーバーパネルの「WordPress簡単インストール」からコピー元の「詳細」→「コピー」へ進みます。コピー対象は記事・画像を含む「全て」、コピー先は本番ドメインです。ドメイン直下へ置く場合は末尾のディレクトリを空欄にします。

コピー先に既存データがないか確認してから実行します。別サーバーへの移行は、この同一サーバー内コピーの説明とは分けて考えてください。

コピー機能でも一部ファイルのURLが置換されない場合があります。本文、画像、CSS、メニューのリンク、WordPressのURL設定を点検します。データベースを直接一括置換するのではなく、対象データの形式を扱える方法で調整します。

参考：エックスサーバー：WordPressのサイトコピー

STEP 4：Macのhostsを設定し、本番用WordPressを事前確認する

WordPressを本番用の領域へコピーしてから、hostsを設定します。Macの通常の名前解決で本番ドメインを新サーバーへ向け、一般訪問者の公開DNSはそのままにして確認する方法です。

設定前の準備

本記事のexample.comと203.0.113.10は説明用で、そのまま使う値ではありません。契約中のXserverのIPと、対象ドメインに置き換えます。元からあるhostsの行は変更せず、今回の対象だけを追加してください。

追加の安全策として、編集前にhostsのコピーを残します。以下のバックアップコマンドは記事用に補足したもので、今回の実行ログを示すものではありません。

sudo cp -p /etc/hosts "/etc/hosts.webnav-backup-$(date +%Y%m%d-%H%M%S)"

hostsを開いて追記する

sudo nano /etc/hosts

203.0.113.10 example.com
203.0.113.10 www.example.com

保存はControl + O、ファイル名の確認でEnter、終了はControl + Xです。Commandキーではありません。sudoのパスワード入力は画面に文字が表示されません。

MacのDNSキャッシュをクリアする

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

ブラウザを終了して開き直し、対象ドメインを確認します。証明書が準備できている場合はHTTPSで検証します。警告が出たまま管理者パスワードを入力したり、証明書の検証を無効化して合格扱いにしたりしないでください。

• トップページだけでなく、代表的な記事・固定ページ・画像・埋め込みを確認する。
• wwwの有無、テストURLへの転送やリンク残りがないか確認する。
• フォームは送信操作だけでなく受信まで確認する。ただしサーバー側からの通信は作業用Macのhostsには従わない点に注意する。

hostsで変わるのは作業用端末の参照先です。証明書発行側のDNS認証や、外部サービスからサイトへ戻る通知・呼び出しまで切り替わるわけではありません。公開前に確認できなかった項目は、公開後の再検証対象に残します。

参考：エックスサーバー：動作確認とhostsファイル

DNSを変更する前に、確認を任せたい方へ

記事・画像の移行に加え、ドメイン・メール・SSLの切り替えや、旧URLの扱いを確認したい場合もご相談ください。担当する作業と検証範囲を整理し、費用をご案内します。

STEP 5：ムームードメインのネームサーバーを変更する

新WordPressの確認、必要なDNSレコード、SSLの準備方法、バックアップが揃った段階で切り替えます。メール設定が不明な場合や、SSLの取得方法・切り替え中の影響が未確定の場合は、先へ進まず確認してください。SSLを切り替え後に取得する場合は、HTTPSの一時的な不通があり得ることを合意したうえで進める構成です。

ムームードメインの「ドメイン管理」→「ネームサーバー設定変更」で対象を選び、「GMOペパボ以外のネームサーバーを使用する」に次の5件を登録します。

ns1.xserver.jp
ns2.xserver.jp
ns3.xserver.jp
ns4.xserver.jp
ns5.xserver.jp

管理画面へはIPアドレスではなくサーバー名を入力し、末尾のドットは付けません。DNS確認コマンドの出力に末尾のドットがあることとは別です。

NS変更は利用者の接続環境によって反映に時間差が生じます。公式には2〜3日かかる場合があると案内されています。「自分の画面が変わったから全員切り替わった」とは判断せず、旧サイトをすぐ削除しないでください。

参考：ムームードメイン：Xserverと接続する方法

STEP 6：digでNSと接続先IPを分けて確認する

NS：DNSの管理先を確認する

dig +short NS example.com

今回共有された実行結果では、ns1.xserver.jp.〜ns5.xserver.jp.の5件が確認できました。表示順は問いません。ただし、問い合わせ先のDNSリゾルバーの回答であり、世界中のキャッシュの更新を証明するものではありません。

A：wwwあり・なしのIPv4を確認する

dig +short A example.com
dig +short A www.example.com

返されたアドレスを、契約中サーバーのIPと照合します。2つの結果が同じだけでは不十分で、そのIPが意図した宛先かどうかが重要です。wwwにCNAMEを使う構成では別名も表示される場合があります。

digはDNSサーバーに質問するコマンドなので、Macのhostsは参照しません。ブラウザが新サイトを表示することと、公開DNSが新IPを返すことは分けて確認できます。

結果が食い違うときだけ追加で調べる

次は補足の検証例で、今回の実行済み記録ではありません。権威DNSはドメインの正式なDNS情報を提供するサーバー、リゾルバーは利用者に代わって問い合わせやキャッシュを扱う仕組みです。両者の回答を分け、IPv6用のAAAAが意図せず旧環境を向いていないか確認します。AAAAが空でも、IPv6を提供しない構成なら直ちに異常ではありません。

dig @ns1.xserver.jp example.com A +noall +answer
dig +short AAAA example.com
dig +short AAAA www.example.com

参考：ISC BIND：digのマニュアル

OSI参照モデルで見る、コマンドの確認範囲

項目	今回の意味	これだけでは分からないこと
dig	アプリケーション層のDNS情報を照会する	WordPressの画面、証明書、フォーム受信
hosts	Macのローカルな名前解決設定を変える	一般訪問者や外部認証サーバーからの接続
TLS（通称SSL）	通信の暗号化とサーバー証明書の検証	記事の欠落、メールや予約の業務動作
curl／ブラウザ	名前解決・接続・TLS・HTTPをまたいで確認する	サイト全機能や、全利用者の反映状況

TLSを第6層に示すのは、暗号化という機能を理解するための簡易な対応です。実際のTCP/IPの実装を厳密に7層へ割り当てた図ではありません。また、Aレコードの値がIPアドレスでも、dig AはDNSの照会であり、IP到達性そのものを測定しているわけではありません。

ここまでで参考になったらシェアしてください

同じ症状で困っている方に届くと、調査時間を短縮できます。

X でシェア Facebook

STEP 7：hostsを元に戻し、通常の接続で確認する

切り替え後の検証では、事前確認用に追加した2行を削除するか、先頭に#を付けます。関係ない行や別案件の設定は変更しません。

sudo nano /etc/hosts

# 203.0.113.10 example.com
# 203.0.113.10 www.example.com

Control + O → Enter → Control + Xで保存・終了し、必要に応じてMacのDNSキャッシュをクリアします。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

今回もhostsを戻し忘れていたことに気づき、固定指定を解除しました。この状態で初めて、通常の名前解決を使った表示確認へ戻せます。Macのキャッシュ削除は、他人の端末やインターネット全体のDNSを更新する操作ではありません。

ブラウザを開き直して確認し、さらにWi-Fiを切ったスマートフォンなど別回線でも確認します。プライベートブラウズだけでは、OSのhostsやすべてのDNSキャッシュを回避した検証にはなりません。

STEP 8：SSLの反映とHTTPSを確認する

今回起きたエラーと、確認できた状態

切り替え前のSSL設定時に、管理画面で「NS相違」と「Let’s Encrypt証明書の発行に失敗しました」という表示が出ました。その後、NSの変更と接続先の確認を経てSSLをONにし、「正常／ON／反映待ち」の表示を確認しています。この表示の組み合わせだけから、発行失敗の原因を一つに断定することはできません。

その後、作業者からSSLの反映完了が報告されました。ただし、管理画面の「ON／反映待ち」と反映完了、HTTPS・転送・フォーム受信の個別確認は別の記録です。本記事では個別の試験ログがない項目を成功扱いにせず、次の確認手順として示します。

まだSSLがOFFの場合の操作

サーバーパネルの「SSL設定」で対象ドメインを選び、ONへの変更操作を進めます。事前取得が済んでいる場合は、むやみにOFFへ戻して再発行しません。認証方法の選択が出た場合はSTEP 2で決めた構成と一致させ、発行失敗時は連続実行せずエラー内容を確認します。

一覧がONになっても反映は別で、公式は最大1時間程度を目安としています。目安を過ぎても警告が残る場合は、待つだけでなく接続先・対象ホスト名・証明書を確認してください。

証明書とHTTP転送は別々に点検する

• httpsの本番URLで、証明書のドメイン・有効期限・信頼性に問題がないことを確認する。
• wwwあり・なしの扱いと正規URLを揃え、どちらの入口でも証明書エラーや転送ループがないか確かめる。
• HTTPSで正常表示できることを確認してから、HTTP→HTTPSの転送を設定・点検する。SSLのONだけで転送設定も完了するわけではない。
• ブラウザで画像・CSS等が読み込まれ、混在コンテンツの警告がないか確認する。

新サーバーパネルでは「.htaccess編集」→対象ドメインの詳細→HTTPS転送設定の「HTTPSに転送する」から設定します。証明書の設定が前提です。すでに別の箇所で転送している場合は設定を確認し、重複やループを避けてください。旧パネルを利用している場合は、下記公式マニュアルの旧パネル用手順を参照します。

WordPress側も「設定」→「一般」でWordPressアドレスとサイトアドレスのHTTPSを確認します。ドメインや設置パスを誤って変えるとアクセスへ影響するため、既存の構成を記録し、不明な場合は変更前に確認してください。

参考：エックスサーバー：無料独自SSL設定／エックスサーバー：Webサイトの常時SSL化

追加の確認例：curlで最終URLとHTTP応答を見る

以下は記事用に追加した検証例です。本文は保存せず、転送後のHTTPステータスとURLを表示します。TLSの検証を無効化する-kは付けません。

curl --silent --show-error --location --max-time 20 \
  --output /dev/null \
  --write-out 'HTTP=%{http_code}\nURL=%{url_effective}\n' \
  https://www.example.com/

意図した最終URLでHTTP=200になることは確認材料の一つですが、記事内容やフォームが正常という証明にはなりません。HTTPの入口も調べる場合は、最後のURLをhttp://www.example.com/に替えて転送先を確認します。

参考：curl：コマンドマニュアル

STEP 9：記事・フォーム・検索からの入口まで点検する

• 記事・固定ページ：代表ページを旧内容と見比べ、本文・画像・埋め込みの欠落を確認する。
• 画像：旧OwndのURL参照だけで表示していないか、保存先まで点検する。
• 問い合わせ：フォームの完了表示に加え、管理者メールと自動返信の実受信を確認する。
• 外部サービス：予約・決済・SNS等の導線を、合意した作業範囲で確認する。不要な本番注文は発生させない。
• 公開設定：本番だけアクセス制限・noindex等を見直し、テスト環境の制限は維持する。
• URL：旧記事URLとの対応、正規URL、内部リンク、テストドメインの残りを確認する。
• 検索：サイトマップとSearch ConsoleのURL検査・インデックス状況を確認する。

記事のURL末尾を変えた場合は、管理できる旧URLから対応する新URLへの恒久転送を検討します。無関係なページまでトップへ一括転送しないでください。同じドメイン・同じURLのまま置き場所だけを変える作業では、Search Consoleのアドレス変更を必須工程にしません。

公開後もアクセスエラー・画像の欠落・受信状況を観察し、旧環境は必要な確認が済むまで維持します。検索順位やアクセス数が必ず維持されると約束できるものではありません。

参考：Google：URLが変わるサイト移転／Google：URLを変えずにホスティングを変更する

うまくいかないときの切り分け

症状	最初に確認すること	注意点
NS相違が残る	選んだDNS方式と実際のNS回答	他社DNSを使い続ける構成ならNS相違自体を解消目標にしない
digとブラウザが食い違う	hosts、DNS・ブラウザキャッシュ、AAAA、リダイレクト	digだけ／ブラウザだけで切り替え完了を判断しない
SSL発行に失敗する	wwwあり・なしの参照先、認証方法、画面のエラー詳細	連打や証明書警告の無視で進めず、公式手順へ戻る
ページは見えるが画像が欠ける	画像の保存先URL、HTTPS、旧サービス依存	DNSを戻せば直るとは限らない
フォーム送信後にメールが来ない	実受信、送信経路、迷惑メール、メール用DNS	送信完了表示だけを成功条件にしない

戻す必要があるときも、NSの差し戻しは即時に全員へ反映されません。旧サイト・新サイトの状態と保存した設定を確認し、Web、DNS、TLS、メールのどこを直すべきか切り分けます。原因が分からないまま設定を続けて変えると、元の状態を追いにくくなります。

止める・戻す・相談する判断

ここは一律の復旧コマンドではなく、切り替え前にサイト所有者と決めておく判断の枠組みです。作業責任者、連絡先、作業時間帯、許容できる影響・中断時刻を記録します。DNSの差し戻しにも時間差があるため、「数分で全員元通り」を前提にしません。

• 止める：別サイトが表示される、証明書警告、重要な問い合わせ・メールの停止を見つけたら、完了扱いを止めます。証明書警告下でログイン情報を入力せず、発生時刻・URL・エラーと直前の変更を控えます。
• 範囲を絞って修正する：原因と修正対象が特定でき、事前に合意した時間・影響の範囲内なら、変更を一つずつ記録して再確認します。分からない設定をまとめて変えません。
• 戻すことを検討する：許容した影響・作業時間を超えたときは、所有者と対応を判断します。旧サイトが稼働し、変更前のNS・DNSレコード等があり、新環境で受け付けた情報を保全できることを確認してから、戻す対象を決めます。
• 相談へ切り替える：原因・管理権限・変更前設定のいずれかが不明な場合や、メール等へ影響が広がる場合は、追加変更を止めて管理会社または担当者へ記録を共有します。

戻した後も、hostsを外した端末と別回線で、表示・証明書・メールやフォームの受信を再確認します。旧・新の両方へアクセスが届く期間には、問い合わせの確認漏れにも注意してください。

よくある質問

Ameba Owndを表示したままWordPressを作れますか？

独自ドメインの公開先をまだ変えず、別のテストURLで新サイトを準備できます。公開前のアクセス制限や検索公開設定も合わせて管理してください。

ムームードメインを解約・移管する必要はありますか？

今回の構成では不要です。ドメインの契約は継続し、DNSの管理先を変更しました。ドメインの更新を止める操作とは違います。

NSを変更すれば記事と画像も引っ越しますか？

いいえ。記事・画像の移行は先に行います。DNS変更は名前から接続先を調べる仕組みの切り替えで、コンテンツをコピーする操作ではありません。

hostsを変えればSSLの発行にも使えますか？

Macのhostsを変えても、認証局や他の端末の参照先は変わりません。証明書発行にはサーバー会社が案内する認証手順が必要です。

digで新しいIPが出れば全員の切り替えは完了ですか？

いいえ。その問い合わせ先が新しい値を返したという結果です。別回線の表示やHTTPSの状態なども確認します。

SSLがONなのにHTTPSのエラーが出るのはなぜですか？

管理画面の反映待ち、接続先、対象ホスト名などを分けて確認します。「ON」だけでは実際に利用者へ提示される証明書の正常性までは確認できません。

記事の取り込みだけ、または切り替えだけでも相談できますか？

WEB先案内では、現在の状態と任せたい範囲から作業内容を整理します。実施可否・作業範囲・費用はサイトを確認してご案内します。移行サービスの対応範囲を見る。

WEB先案内へ相談すると、何が整理できるか

WEB先案内では、記事・画像の移行結果と、未対応箇所・残る作業を整理して共有します。画像が画面に出るだけでなく、新環境の保存先や旧サービスへの参照残りまで点検します。本記事で分けた「DNSの回答」「HTTPS」「画面表示」「送受信」も、合意した依頼範囲に合わせて確認します。

依頼前に決めること・引き渡しで確認すること

• 移す対象と、取得できない内容・追加対応の扱い。
• 管理できる旧URLと新URLの対応、画像の保存先と参照残り。
• 合意した動作確認の結果と、未確認・未対応として残る作業。
• 更新手順、データの保管先、管理権限などの引き継ぎ。

これらを一律の無料サービスや全件保証として含めるのではなく、検証項目・引き渡す資料・修正対応の範囲を見積もり時に決めます。詳しい対応範囲は移行サービス案内、担当者については経歴と検証方針をご確認ください。

相談から作業までの流れ

1. サイトURL・困っていること・希望時期を、分かる範囲で送る。パスワードや認証コードは初回に送らない。
2. 現在の状況と任せたい範囲を整理し、作業内容・費用・検証項目・日程を確認する。
3. 範囲と費用へ合意してから、必要な調査・移行・確認へ進む。

通常の相談・見積もりは無料、実環境の調査・作業は有料です。受付は24時間、対応は平日10:00〜17:00です。まずは部分的な相談でも構いません。移行の可否や日程はサイトの状態を確認してご案内します。

まとめ：切り替えは「設定した」ではなく「確認できた」で判断する

公開前は新サイト・DNS・SSLを準備し、公開後はhostsを解除した通常の接続で確認します。NS、接続先IP、証明書、画面、フォーム受信を分けて見ることで、途中の不具合も切り分けやすくなります。

自分で進められるところと、環境を調べないと判断できないところを分けておくと、相談時にも作業範囲を伝えやすくなります。

大切な記事や、お客様からの問い合わせを次のサイトへ

WEB先案内では、記事・画像の移行からWordPressの整備、DNS・SSLの切り替えまで、必要な範囲を整理して対応します。まずはサイトURL、現在困っていること、希望時期をお知らせください。パスワードやAPIキーは初回の相談文に書かないでください。

通常の相談・見積もりは無料です。実環境の調査・作業は有料となり、範囲と費用をご案内します。公開後の保守は任意です。サービス内容・見積もり項目を確認する。

参考にした一次情報

• Ameba Ownd公式：サービス終了日の延期と今後の対応
• エックスサーバー：WordPressのサイトコピー
• エックスサーバー：動作確認とhostsファイル
• エックスサーバー：無料独自SSL設定
• エックスサーバー：Webサイトの常時SSL化
• ムームードメイン：Xserverと接続する方法
• ISC BIND：digのマニュアル
• curl：コマンドマニュアル
• Google：URLが変わるサイト移転
• Google：URLを変えずにホスティングを変更する

実作業の経過と、追加した検証例を区別して記載しています。サーバーパネルの表記・公式機能の提供状況は変更されるため、操作時点の公式案内も確認してください。

相談前に整理したい方へ（任意）