Lightsail 上で長年動かしていた WordPress を、新インスタンスへ移して PHP を 8.3 まで上げたときのメモです。きれいな手順書というより、「こんなメッセージが出て → こう直した」寄りです。
きっかけ：管理画面に「PHP の更新が必要です」
旧環境は Bitnami 由来で、サイトヘルス／更新まわりにだいたいこんな感じが出ていました。
- 「PHP の更新が必要です」
- 「古いバージョンの PHP (7.4.13)」
意味: WordPress やプラグインが推奨する PHP より古い、という警告です。見た目は動いていても、更新が止まったり、将来のメジャー更新で一気に詰みやすい状態。
やったこと: 旧機の中で PHP だけ無理に上げるより、同リージョンに新しい Lightsail WordPress を立てて移す方針にしました。切り戻し用にスナップショットも先に取ります。
Lightsail：「Bitnami ブループリント廃止」と previous-generation hardware
コンソールや FAQ まわりで、だいたい次のようなニュアンスの案内が出ていました。
- Bitnami ブループリント（WordPress 等）がカタログから順次消える／新規作成できなくなる、という案内
- インスタンス側の「previous-generation hardware」→ newer-generation に追加料金なしで移れる、という Tips
意味: 既存インスタンスはすぐ死なない一方、新規の Bitnami 系統は選択肢から消えていく。ハードだけ新世代にしても、PHP 7.4 や古い構成そのものは残りがち。
やったこと: 移設先は Lightsail のパッケージ版 WordPress（Debian 12 系）にしました。新インスタンス作成でハード世代も乗り換わるので、「ハード更新だけ」はしませんでした。参考: Lightsail FAQ（Bitnami ブループリント）。
方針（短く）
- 本番いじる前にスナップショット
- 新機へ DB と
wp-contentを入れて、動的 IP のまま並行確認 - カットオーバーは静的 IP の付け替え（Route53 の A が静的 IP 直指定なら、DNS を触らずに済むことが多い）
- HTTPS・www・SMTP・Analytics は別枠。ここで一気にやると切り分けが死ぬ
ハマったところ（出た文言 → 意味 → やったこと）
SMTP: Sender address rejected: Incorrect country code US / 554 5.7.1
新機で WP Mail SMTP のテスト送信をしたら、だいたいこんなログでした。
554 5.7.1 Sender address rejected: Incorrect country code US意味: パスワード間違いではなく、お名前メール側の「SMTP認証 国外アクセス制限」が、接続元 IP を US 扱いして弾いている、というパターンです。公開 GeoIP では JP でも、プロバイダ側 DB がずれることがあります。
やったこと: カットオーバー前はコントロールパネルで国外制限を一時オフにして確認。本命は静的 IP を新機へ付け替えて、出口 IP を旧と同じにすること。付け替え後にテスト再送。通ったら制限は戻した方が安心です。
CF7:「新バージョンが利用可能ですが、お使いの PHP バージョンでは動作しません」
プラグイン画面に、だいたい次のような表示が出ました（Contact Form 7）。
「新バージョンの Contact Form 7 が利用可能ですが、お使いの PHP バージョンでは動作しません」（更新先 6.2.3 は PHP 8.3+ 要求）
意味: キャッシュや別 PHP の誤認ではなく、本当に PHP が足りない。移設直後の新機は PHP 8.2 系のままだったので、6.2.3 は更新ボタンが押せない状態が正しい挙動でした。
やったこと: スナップショット後、Sury（packages.sury.org）から PHP 8.3 を入れ、既存どおり mod_php で切替。その後 CF7 を 6.2.3 へ更新。問い合わせページの表示と送信テストまで見ました。
ブラウザ「保護されていません」なのに「証明書は有効」
見た目はサイトが出るのに、ブラウザはこう言ってきます。
- 「このサイトへの接続は保護されていません」
- 同時に「証明書は有効です」（Let’s Encrypt など）
意味: 証明書不良ではなく、混在コンテンツ／http の siteurl 側のことが多いです。今回は WP_HOME / WP_SITEURL が http:// 固定のままだったせいで、メニュー等に http が残っていました。
やったこと: wp-config のホーム／サイト URL を https に固定し、DB 内の http → https（必要なら www 正規化）を search-replace。シークレットウィンドウで南京錠を再確認。
突然アクセス不能 → Apache MaxRequestWorkers 枯渇
カットオーバー直後、「突然つながらない」状態になりました。DNS やファイアウォールは問題なく、Apache 側でワーカーがほぼ満杯。
意味: micro 相当（メモリ約 1GB）だと、既定の MaxRequestWorkers がかなり小さめのことがあります。張り付いた接続で枯渇すると、HTTPS がタイムアウトし、HTTP→HTTPS の 301 経由でも「全滅した」ように見えます。
やったこと: いったん apache2 を再起動して疎通回復 → mpm_prefork の MaxRequestWorkers / ServerLimit を現実的な値へ上げて reload。数値は環境依存なので、ここでは「極端に小さい既定値を疑う」程度に留めます。
SSH: REMOTE HOST IDENTIFICATION HAS CHANGED / User が bitnami のまま失敗
静的 IP を付け替えたあとに、ローカルからこう出ることがあります。
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!あわせて、旧 Bitnami 時代の ~/.ssh/config で User bitnami のままだと、新機（パッケージ版はだいたい admin）では入れません。
意味: 同じ IP でも中身（ホスト鍵・OS ユーザー）が変わった、というサイン。攻撃というより、付け替え直後の想定どおりの警告です。
やったこと: 該当 IP の旧鍵を known_hosts から外して再登録。User を新機のユーザー（今回は admin）に直し、IdentitiesOnly yes も指定。
GA4「ウェブサイトから受信したデータはまだありません」
Site Kit で Search Console / Analytics をつなぎ直した直後、GA4 側に次のような表示が出ることがあります。
「ウェブサイトから受信したデータはまだありません」（設定は済んでいるのに）
意味: 計測タグ未設置とは限らず、新規プロパティ直後は収集待ちで空なのが普通です。旧タグ（GTM / 別の測定 ID）が残っていると、別プロパティに飛んで「空」に見えることもあります。
やったこと: 公開 HTML に出ているタグが今の測定 ID だけか確認。旧スニペットやテーマ側の古い ID をオフ／クリア。リアルタイムで自アクセスを見て、数分〜十数分待つ。
PHP 8.3 への上げ方（Debian 12 系・ざっくり）
新機の公式リポジトリは PHP 8.2 のままなので、今回は Sury から 8.3 を入れ、Apache の mod_php を 8.2 → 8.3 に切り替えました（FPM への全面移行はしていません）。
注意だけ:
- 第三者リポジトリ依存（鍵・供給継続）
- 上げる前にスナップショット
- mysql / gd / mbstring / xml / zip / opcache などを 8.3 側でも揃える
- 切替後は
php -v・管理画面・問い合わせまで一気に見る
確認チェック（最低限）
- トップ・ログイン・主要固定ページが 200
php -vと管理画面の PHP が一致- 問い合わせが Fatal なく描画・送信できる
- www / apex のリダイレクトと証明書 SAN
- SMTP テスト（国制限・出口 IP あり）
- ブラウザの南京錠（証明書有効なのに「保護されていません」が出ないか）
まとめ
古い Lightsail WordPress は「その場で PHP だけ上げる」より、新インスタンスへ移してから PHP・プラグインを整える方が切り戻しやすい、というのが実感です。静的 IP・スナップショット・公開確認を先に固めておくと、当日の判断がかなり楽になります。
いちばん時間を食ったのは「正しい手順」より、エラーメッセージの意味を取り違えないこと（SMTP の国コード、証明書有効なのに未保護、ワーカー枯渇など）でした。同じ文言で止まっている人の手がかりになれば十分です。
サイトの位置づけは概要にもまとめています。
