Bitnami が 2026年5月19日から WordPress 対応をやめるというアナウンスがあり、AWS Lightsail で動かしていた WordPress を Xserver に移行しました。
この記事では、AWS から Xserver にドメインを切り替えて WordPress サイトを移行する方法を、実際にやった手順そのままでまとめています。
- なぜ AWS Lightsail で WordPress が運用しづらくなったのか
- 移行先に Xserver を選んだ理由（フラットに比較）
- All-in-One WP Migration を使ったエクスポート→インポートの全手順
- DNS の A レコード切り替え・SSL 発行・ネームサーバー変更の実画面
- 「Xserver のデフォルトページが出る」ハマりどころの正体
AWSのWordPressは「Bitnami廃止」で困る → Xserver移行が現実解
結論を1行で書くと、「AWS Lightsail で Bitnami の WordPress を動かしてる人は、いまのうちに Xserver みたいな国内レンタルサーバーに引っ越したほうがラク」という話です。
理由はシンプルで、AWS Lightsail の WordPress イメージを長らく提供していた Bitnami が、2026年に入って「もう新規イメージのメンテナンスはやらないよ」というアナウンスを出したからなんですよね。これによって、放っておくとセキュリティパッチが当たらなくなる可能性があります。
正直、僕も最初は「いや、まだ動いてるしいいでしょ」と思ってました。でもよく考えたら、自分のポートフォリオサイトが古いまま放置されて、ある日突然乗っ取られるとか普通にあり得るんですよね。
AWSってなんかカッコいいから残しておきたいんだけど、ダメ？
気持ちはわかるんだけど、でもサーバーは「動かし続けられるかどうか」をだいじにしないとね！見栄より運用コストだよ！
なぜ AWS（Lightsail）でWordPressが置けなくなったのか
Bitnami廃止通知の背景
そもそも AWS Lightsail で WordPress を立てると、ほとんどの人は Bitnami の「WordPress Certified by Bitnami and Automattic」というイメージを使っていたはずです。ワンクリックで PHP・MySQL・WordPress 一式が立ち上がる、あの便利なやつですね。
ところが Bitnami（VMware傘下）は、無償の Marketplace 向けスタックの提供方針を見直してきていて、新しいバージョンのイメージが出にくくなっているとのこと。Lightsail のコンソールから新規でWordPressを選んでも、中身のWordPressやPHPバージョンが古いままという現象が起きやすくなっているんですよね。
パッチ停止のリスク
WordPress自体はテーマ・プラグインも含めて毎月のように脆弱性が見つかります。サーバーOSや PHP も同じで、誰かが面倒を見続けてくれないと、どんどん「穴の空いた家」みたいな状態になっていきます。
個人ブログだから狙われない、ということもなくて、むしろ自動巡回ボットに片っ端から舐められて、踏み台にされる事例が普通にあるらしいです。Web制作で「サーバー触ったことあります」と言いたい身としては、自分のサイトが踏み台になるのは一番恥ずかしいパターンなので、ここで重い腰を上げました。
移行先に Xserver を選んだ理由
移行先はいくつか候補がありました。さくらのレンタルサーバ、ConoHa WING、ロリポップ、mixhost あたりですね。どれも一長一短で、絶対これ！という答えはないと思います。
僕が Xserver を選んだ理由はざっくり3つです。
- クライアント案件でも使うことが多くて、管理画面に慣れている
- WordPress簡単インストール・無料独自SSL・自動バックアップが標準装備
- サーバー会社としての歴が長くて、急に「サービス終了します」みたいなリスクが低そう
ちなみに ConoHa WING も候補に残っていて、表示速度重視の人にはそっちの方が合うこともありそうです。コスト重視なら mixhost、サポート問い合わせの安心感なら Xserver、みたいな住み分けで選べばいいと思います。
| 項目 | Xserver | ConoHa WING | さくらのレンタルサーバ |
|---|---|---|---|
| WordPress簡単インストール | あり | あり | あり |
| 無料独自SSL | あり | あり | あり |
| 自動バックアップ | 無料で標準 | 無料で標準 | プランによる |
| 管理画面の慣れ | クラシック寄り | モダン寄り | シンプル寄り |
表にまとめると差は小さく見えますが、結局は「自分が触ったことがあって安心できるか」が一番大事だと思いました。
【先にやっておきたい】AWS取得ドメインをXserverに移管する
ここ、僕は今回やっていません。Route 53 にドメインを置いたまま、サーバーだけ Xserver に切り替えました。
ただ、振り返ると「最初にドメイン移管までやっておけば、あとが圧倒的にラクだったな」と思っているので、これから移行する方は先にやっておくのをおすすめします。手順は実体験ではなく一般的な流れとして書きます。
このセクションは僕が今回実施した内容ではありません。Route 53 と Xserver 公式の案内をもとにした一般的な手順です。実施する前には必ず最新の公式情報を確認してください。
3-1. 移管できる条件
ドメイン移管にはいくつか条件があります。代表的なのはこのあたりです。
- ドメインを取得（または前回の移管）から60日以上経過している
- Whois 代理公開（プライバシー保護）を一時的に解除する必要がある場合がある
- Transfer Lock（移管ロック）が OFF になっている
3-2. AWS Route 53側の準備
Route 53 のコンソール → 「登録済みドメイン」→ 対象ドメインを選択して、Transfer Lock を OFF に。次に Authorization Code（認証鍵）を発行します。これがあとで Xserver 側に入力するパスワードみたいな役割になります。
3-3. Xserver側で移管申請
Xserverドメインの管理画面から「ドメイン移管」を選び、対象ドメインと Authorization Code を入力。料金（1年分の更新料）を支払うと申請が走ります。
3-4. AWSから「Transfer Approval」メール → 承認
申請から数日以内に AWS から「Transfer Approval」のメールが届くらしいので、リンクを開いて移管を承認します。ここで放置すると拒否扱いになって最初からやり直しになるので注意。
3-5. 完了まで5〜7日待機
承認後、レジストリ側の処理が走って完了まで5〜7日くらいかかるとのこと。この間もサイト自体は普通に表示できる状態が保たれるはずです（DNSは生き続けるので）。
3-6. 移管完了後の状態
完了すると、ドメインの管理が Xserver 側に移ります。これ以降は Xserver の管理画面だけで、サーバー・ドメイン・DNS をまとめて触れるようになるので、運用がだいぶ楽になります。
- 移管期間中もサイトは動き続ける（DNSは現状維持）
- Whois 情報が一時的に変わるので、SSL証明書の確認メール等を見落とさない
- 「移管→サーバー切替」の順でやると、ネームサーバー変更が1回で済む
移行前の準備：All-in-One WP Migration を入れる
ここからが実際にやった作業です。最初にやるのは、移行用プラグインの準備です。
WordPressの引っ越しでは「All-in-One WP Migration（オールインワン WP マイグレーション）」というプラグインが定番です。サイトをまるっと1ファイル（.wpress）に固めて、移行先で読み込むだけで全部復元できる、という優れものなんですよね。
- 移行元（Lightsail）に All-in-One WP Migration をインストール
- サイトのファイル容量を確認（無料版は512MBまで）
- バックアップを2箇所に保存(ローカル＋クラウド)
- Xserverの契約・サーバーパネルにログインできるか確認
正直、バックアップは2箇所に取っておいたほうが心が落ち着きます。僕はローカルのMacと、Google Drive に1個ずつコピーを置きました。「.wpress ファイルがあれば、最悪どうにかなる」と思える状態にしておくと、あとの作業中に手が震えにくくなるんですよね。
ステップ① Lightsailからエクスポート
移行元の WordPress 管理画面に入って、All-in-One WP Migration → 「エクスポート」を開きます。エクスポート先は「ファイル」を選択。
左メニュー → All-in-One WP Migration → エクスポート。
「エクスポート先」のボタンを押して、「ファイル」を選択。バーが進んでダウンロードボタンが出ます。
ダウンロードしたファイルは、わかりやすい名前にリネームしておくと安心。例：サイト名-2026-05.wpress
ここで一つ注意点。All-in-One WP Migration の無料版は、インポート時のアップロードサイズが512MBまでに制限されています。サイトが画像・動画モリモリだと簡単に超えるので、その場合は不要なメディアを整理するか、有料の拡張プラグインを入れる必要があります。
僕のサイトはテキスト中心だったので、200MBくらいで収まりました。
ステップ② テスト用ドメインでインポート確認
いきなり本番URLにインポートする勇気はなかったので、Xserver の仮URL（〇〇.xsrv.jp みたいなやつ）にいったんインポートしてみました。
これ、ぶっちゃけ後から「やっておいてよかった」と心底思いました。仮URLで一通り表示確認して、画像が抜けてないか、テーマがちゃんと当たってるかを見られるんですよね。
仮URLでテストするのって面倒じゃない？
正直ちょっと面倒…。でも本番でいきなり崩れたら数時間サイトが止まることになるので、保険として絶対やったほうがいいよ！
ちなみに、この仮URL作業のせいで後で1回ハマります（後述の「Xserverデフォルトページ問題」）。先に言っておくと、仮URLにWordPressをインストールしただけだと、本番URLでアクセスしたときにXserver側がWordPressを認識してくれないんですよね。
ステップ③ DNS切替（Aレコード変更）
ここからが今回の山場の1つ目です。DNSの A レコードを書き換えて、ドメインのリクエストを Lightsail から Xserver に向けます。
まずXserverのIPアドレスを確認
Xserver のサーバーパネルにログインして、「サーバー情報」画面を開きます。ここに「IPアドレス」という項目があるので、それをコピー。
僕の場合は yyy.yy.yyy.yyy でした（人によって違います）。
AWS Route 53 でAレコードを書き換える
AWSマネジメントコンソールにログインします。
https://aws.amazon.com/jp/console/
サービス検索から「Route 53」を開いて、「ホストゾーン」→ 対象ドメイン（僕の場合は 自分のドメイン）をクリック。
レコード一覧が出るので、Aレコード（タイプが A になってるもの）を選んで「レコードを編集」します。
編集画面で、いまの値（僕の場合は xx.xxx.xxx.xxx＝Lightsail のIP）を、Xserver のIPアドレス（yyy.yy.yyy.yyy）に書き換えます。
あわせて TTL を 300 に下げておきます。デフォルトだと 3600（1時間）になってることが多いんですが、TTL を下げておくと「もし切替に失敗したときに、戻すスピードが早くなる」というメリットがあります。
本当はDNS切替の1日前にTTLだけ下げておくのが理想です。世界中のDNSキャッシュが「次は5分後に問い合わせ直す」状態になるので、いざ切り替えたときの反映が早いんですよね。
dig コマンドで反映確認
切替が反映されたかどうかは、ターミナルで dig コマンドを叩くと確認できます。
dig example.comANSWER SECTION に Xserver の IP が出てくれば成功です。Lightsail の IP のままなら、まだキャッシュが残っています。
ステップ④ SSL証明書発行
DNS切替が反映された直後、ブラウザでサイトを開くと「この接続ではプライバシーが保護されません」みたいな赤い警告が出ます。
上記の画面が出るのは、Xserver側にまだ 自分のドメインのSSL証明書が発行されていないからです。Lightsail 側に発行されていた証明書は、Xserver には引き継がれません。
Xserverの無料独自SSLを発行する手順
左サイドメニューの「ドメイン」グループの中にある「SSL設定」をクリック。
自分のドメインの右にある「選択する」ボタンを押す。
サイト欄が 自分のドメインになっていることを確認。www有のチェックボックスがあれば入れておきます。
確認画面を経て、追加ボタンを押すと申請完了。
SSL の発行と反映には、僕の場合10〜20分くらいかかりました。Xserver公式の案内では最大1時間程度らしいので、気長に待ちます。
普通のブラウザだと古いキャッシュで「まだ警告」となることが多いです。シークレットウィンドウ（プライベートブラウジング）で開くとキャッシュなしで確認できるのでおすすめ。
ハマりどころ：Xserverデフォルトページが出る
SSL もついて、いざ 自分のドメインにアクセス。
出てきたのは Xserver の「このドメインは設定されていますが、コンテンツがありません」みたいなデフォルトページでした。
正直、ここが一番焦りました。「あれ、サイト消えた？」って一瞬思ったんですよね。
これ何が起きてるの？
仮URLにだけ WordPress を入れて、本URLには WordPress を入れていない状態だったんだ。Xserver 的には「ドメインの箱はあるけど、中身が空」という扱いなの。
つまり、本URLに対してもう一度「WordPress 簡単インストール」を流してから、.wpress を再インポートする必要があったんですね。
原因は、ステップ②で仮URLにインポートしたまま、本URL用に WordPress をインストールしていなかったことです。
ちなみにこの状態でもう一個ハマりどころがあって、「WordPress簡単インストール」の画面でインストール対象として 自分のドメインが選択肢に出てこないことがあります。これは次のセクションのネームサーバー周りの話と絡んでいて、解決策はNS変更でした。
ステップ⑤ ネームサーバー切替（NS相違の解消）
ここがDNSまわりの最後の山場です。
Xserver のドメイン設定画面を見ると、対象ドメインの横に「NS相違」みたいな警告が出ていることがあります。これの正体は、「このドメインのネームサーバーが Xserver を向いてないよ」というメッセージなんですよね。
僕の場合、ドメインは Route 53 で取ったままだったので、ネームサーバーも Route 53 のもの（ns-xxxx.awsdns-xx.net みたいなやつ）が登録された状態でした。これを Xserver のネームサーバーに変えてあげる必要があります。
Route 53 でネームサーバーを変更する
Route 53 の「登録済みドメイン」を開きます。
対象ドメインを選択して、「アクション」ボタンを押します。
編集画面で、Xserver の5つのネームサーバーを入力します。
ns1.xserver.jp
ns2.xserver.jp
ns3.xserver.jp
ns4.xserver.jp
ns5.xserver.jp
保存すると、しばらくして Xserver 側の「NS相違」警告が消えます。
- ドメインを管轄しているネームサーバーが、Xserver を向いていない状態
- Aレコードを Xserver に向けただけでは消えない
- ネームサーバー（NS）レコードそのものを Xserver のものに書き換える必要がある
NSが切り替わると、Xserver の「WordPress簡単インストール」画面に 自分のドメインがちゃんと選択肢として出るようになります。これが嬉しかったんですよね。
ステップ⑥ 本URLにWordPressインストール → .wpressインポート
NS の切替が終わったら、いよいよ本番です。
サーバーパネル → 「WordPress簡単インストール」→ 自分のドメインを選択 → インストール。サイト名・ユーザー名・パスワードを入力。
https://自分のドメイン/wp-admin/ にアクセスして、新しいWordPressにログイン。
プラグイン新規追加 → All-in-One WP Migration を有効化。
「インポート」→ ステップ①で作った .wpress を選択。完了したら一度ログアウトして、元のIDで再ログイン。
インポートが終わると、Lightsail で動いてたサイトの中身がそっくりそのまま Xserver に乗っかります。テーマも、プラグインも、記事も画像も全部です。これを最初に見たときは、正直ちょっと感動しました。
- トップページ・記事ページが正しく表示されるか
- 画像のリンク切れがないか
- お問い合わせフォームの送信テスト
- パーマリンク設定（「設定」→「パーマリンク」を開いて保存し直すだけでOK）
動作確認とLightsail停止のタイミング
移行できたからといって、すぐに Lightsail を消すのはもったいないです。最低でも1週間〜10日くらいは残しておくのをおすすめします。
理由は3つあります。
- DNSのキャッシュが世界中から完全に消えるまで時間がかかる
- 新サーバーで気付いてない不具合が出たときに、最後の比較対象として使える
- 万が一インポートに漏れた画像があったときに、サーバーから直接拾える
Lightsail は時間課金なので、1週間くらい残しても数百円程度で済むはずです。これは保険料だと思って割り切るのがおすすめ。
ちなみに僕は、しばらく動かして「もう完全に大丈夫」と確信できたタイミングで、Lightsail のスナップショットだけ取って、インスタンスを停止 → 削除しました。スナップショットも数十円で残せるので、最後のお守りとしてしばらく置いてあります。
よくある質問（FAQ）
- 移行作業中、サイトはずっと止まりますか？
-
基本的には止まりません。Aレコードを切り替えた直後の数分〜数十分くらいは「人によって新旧どちらかが見える」状態になりますが、両方サイトが生きていればコンテンツは表示され続けます。
- All-in-One WP Migration の512MB制限を超えそうです。どうすれば？
-
有料の拡張プラグイン（Unlimited Extension）を入れるのが一番ラクです。それ以外だと、メディアフォルダだけFTPで別途移してから、データベースだけ移行する方法もあります。ただ難易度が一気に上がるので、無理せず拡張版を入れる派です。
- ドメイン移管はやらなくても大丈夫ですか？
-
大丈夫です。僕も今回は移管せず、Route 53 にドメインを残したままサーバーだけ Xserver に切り替えました。ただ、管理画面が分かれて運用がちょっと面倒なので、長期的には移管したほうが楽です。
- 移行中にSEO評価は落ちませんか？
-
URL構造（パーマリンク）が変わらず、SSL も維持できていれば、基本的には影響は最小限らしいです。気をつけるとしたら、Search Console で新サーバー側のクロールエラーが出ていないかをこまめに見るくらいだと思います。
まとめ：教訓と注意点
AWS Lightsail から Xserver への移行、最初は身構えていましたが、終わってみれば「もっと早くやればよかった」というのが正直な感想です。
サーバー移行なんて「専門の人がやる魔法みたいな何か」だったんですよね。でも順番に手を動かしていけば、非エンジニアでもちゃんとゴールできるところまでツールが進化していると感じました。
- Bitnami廃止の影響を受ける Lightsail WordPress は早めの移行がラク
- 移行先選びは「自分が触り慣れているか」で選ぶのが一番ストレスがない
- ドメイン移管は先にやっておくと後の作業が一気に楽になる
- 本番URLに切り替える前に、仮URLでテストインポートしておくと安心
- Aレコードだけでなく、ネームサーバー（NS）の切替も忘れない
- Lightsail はすぐ消さず、1週間くらいは保険として残す
「Bitnami廃止のメールが来て、なんとなく不安」という状態のままズルズル放置するのが、たぶん一番リスクが高いです。完璧にやろうとしなくていいので、まずはバックアップを取るところから始めてみると、案外ハードルは低いと感じるはずです。
もしこの記事が、同じように Lightsail から引っ越そうか迷っている方の背中を押せたら嬉しいです。
コメント