差分は確認できました。でも、どの順番で本番へ送ればよいか分かりません。
確認済みリストにあるファイルだけを、一つずつ反映しよう。
作業フォルダごと上書きする方が早くないですか？
練習ページや設定まで混ざるよ。今回は限定したファイルと管理画面操作を分けるんだ。
ローカルで確認した変更を本番へ反映する時は、作業フォルダ全体ではなく、承認済みの公開対象だけを送ります。 この記事では、ファイル変更とDB側の変更を分け、バックアップ、アップロード、確認、復旧まで進めます。
最初に公開対象表を完成させる
| 種類 | 例 | 反映方法 |
|---|---|---|
| テーマファイル | 子テーマのfront-page.php | FTP等で同じ相対パスへ |
| CSS | 子テーマのhome.css | ファイル転送 |
| 固定ページ | ホーム本文 | WordPress管理画面 |
| 練習用データ | ローカル練習ページ | 本番へ送らない |
| 秘密・バックアップ | wp-config.php、SQL | 本番公開対象外 |
変更差分の確認 が終わっていなければ先へ進みません。公開リストにないものは送らない、と決めます。
反映直前にファイルとDBをバックアップする
WordPress公式は、通常のサイトを完全に戻すにはファイルとDBの両方が必要だと説明しています。同じ時点の一組として保管し、復元担当と保管場所を記録します。
- 対象テーマ・プラグインファイルをダウンロードする。
- DBをホストの手順でバックアップする。
- バックアップが存在し、サイズが0ではないと確認する。
- 公開用フォルダやCodex作業フォルダの外へ保管する。
- 復旧に使う本番URLと対象パスを記録する。
CSS一枚の変更でもDBバックアップが必要ですか？
ファイルだけなら対象ファイルの退避が最低限。ただし同時に管理画面も変えるならDBも必要だよ。
昨日の自動バックアップがあれば十分ですか？
昨日から記事や問い合わせが増えているかもしれない。直前状態を戻せる方法を確認しよう。
接続先を三つの証拠で確認する
| 確認 | 合格 | 停止 |
|---|---|---|
| ドメイン | 公開対象URLと一致 | 別ドメイン・検証環境 |
| サーバーパス | 対象ドメインのpublic_html配下 | 階層が不明 |
| 現行ファイル | 公開画面の固有文字と対応 | 候補が複数 |
XServerではメインFTP接続後、対象ドメインのフォルダ内にあるpublic_htmlが公開場所です。複数ドメインを持つ場合は、名前が似たフォルダへ送らないようにします。
本番反映前の読み取り確認だけをしてください。
公開URL：【https://example.com/】
接続先候補：【対象ドメイン/public_html/】
公開対象：【子テーマ/front-page.php、assets/css/home.css】
ドメイン、サーバーパス、現行ファイルの固有文字が一致するか報告してください。
まだアップロード、上書き、削除、名前変更、DB操作は行わないでください。
パスを一つに確定できなければ停止してください。
ファイルマネージャーとFTPの違い
| 方法 | 向く作業 | 注意 |
|---|---|---|
| ファイルマネージャー | 少数ファイルの確認・転送 | 上書き先を画面で確認 |
| FTPS/SFTPクライアント | 複数ファイル・階層の転送 | 左右と転送方向を確認 |
| WordPress管理画面 | 固定ページ・メニュー・設定 | ファイル転送とは別 |
| Git配備 | 構築済みの運用 | 仕組みがないサイトへ即席導入しない |
WordPress公式も、オフライン編集したファイルはFTPクライアント等でアップロードし、結果をブラウザで確認するよう案内しています。管理画面のテーマファイルエディターで本番を直接試行錯誤しません。
FTP画面の左右を取り違えそうです。
最初の一件はローカル側とサーバー側のパス、ファイル名を声に出せる状態で確認しよう。
サーバーからPCへ送ると、せっかくの変更が消えますね。
そう。変更後をローカル、変更前を本番として、送信方向を操作直前に再確認するよ。
一度に一つの単位だけ反映する
- 対象ファイルの本番版を別名ではなく安全なバックアップ場所へ保存する。
- 公開リストの一件だけを同じ相対パスへ転送する。
- 転送完了と更新時刻を確認する。
- 公開URLをキャッシュ回避して開く。
- エラー、見出し、表示崩れを確認する。
- 合格後に次のファイルへ進む。
承認済み公開リストの順番で、反映計画を作ってください。
1件目：【子テーマ/front-page.php】
2件目：【子テーマ/assets/css/home.css】
DB側：【固定ページ「ホーム」の本文】
各工程に、反映前確認、操作、確認URL、合格条件、失敗時の復旧を付けてください。
計画を提示するだけで、まだ本番操作は行わないでください。
DB側は通常のWordPress画面から反映する
固定ページやメニューは、ファイルを送っても変わりません。本番の管理画面で対象名とURLを再確認し、ローカルで合格した文章・設定だけを反映します。
本番DBを直接置換せず、まず通常の編集画面を使います。シリアライズデータやページビルダーを含む大規模移行は別の移行手順が必要です。
CSSを送ったのに見出し文が変わらないのは、本文がDB側だからですね。
その通り。公開表でファイルと管理画面操作を分けた理由だよ。
ローカルDBを丸ごと本番へ入れれば早そうです。
問い合わせや新着記事を消す危険がある。小さな本文変更なら通常画面から対象だけ変えよう。
公開直後の五分で見ること
- トップと変更対象ページが200で開く。
- 管理画面へログインできる。
- PCと390pxで横はみ出しがない。
- 画像、CSS、メニュー、ボタン到着先が正しい。
- フォームは表示だけでなく、許可されたテスト方法で確認する。
- PHPエラーやデバッグ文字が出ていない。
- 対象外ページが変わっていない。
キャッシュで新旧を取り違えない
変更が見えない時に同じファイルを何度も上書きしません。ブラウザ、WordPressプラグイン、サーバー、CDNのどこにキャッシュがあるか確認し、安全な更新手順を使います。別端末やプライベート表示だけを唯一の証拠にせず、HTMLや更新時刻も確認します。
不合格なら次を送らず復旧する
| 症状 | 最初の対応 | 復旧 |
|---|---|---|
| 白画面・500 | 追加反映を停止 | 直前ファイルをバックアップ版へ戻す |
| 見た目だけ崩れる | CSSとキャッシュを確認 | 直前CSSを戻す |
| 本文が違う | 対象固定ページを確認 | DBバックアップまたは変更前本文 |
| 管理画面に入れない | 本番操作を停止 | ホスト側の復旧手順・担当へ連絡 |
公開後に不合格が出ました。追加変更は行わず、復旧手順だけ整理してください。
症状：【例 トップページが500エラー】
直前操作：【front-page.phpを一件上書き】
バックアップ：【上書き直前の同ファイルあり】
原因を推測して別ファイルを変更せず、直前操作を戻す手順、確認URL、復旧合格条件を示してください。
一件反映して確認し、次へ進めました。全部を一度に送るより原因が分かります。
いい公開だね。成功だけでなく、不合格時に直前へ戻れる。
最後は何を記録しますか？
本番反映済みのファイルとDB操作、確認URL、時刻、残課題を記録しよう。
完了報告に残す内容
- 公開日時と担当者
- 反映したファイルとDB操作
- 反映しなかった練習物・秘密情報
- 確認したURLとPC・スマホ結果
- キャッシュ更新の有無
- バックアップ場所と復旧手順
- 未実施事項
よくある質問
作業フォルダを丸ごと上書きしてよいですか？
練習物、秘密情報、キャッシュが混ざるため行いません。承認済み公開リストだけを反映します。
ファイルだけバックアップすればよいですか？
DB側を変更するならDBも必要です。通常のWordPressは完全復旧に両方が必要です。
FTPとファイルマネージャーのどちらが安全ですか？
件数と運用によります。どちらも対象パス、転送方向、バックアップを確認します。
ローカルDBを丸ごと本番へ入れますか？
小さな変更では行いません。本番の新しい投稿や問い合わせを失う危険があります。
変更が見えないので再上書きしますか？
先にキャッシュと公開パスを確認します。原因不明の再上書きはしません。
500エラーでも次のCSSを送ってよいですか？
停止し、直前操作を戻して復旧を確認します。
本番反映後にローカルを消しますか？
差分、公開版、復旧に必要な情報を安全に保管してから判断します。
公開完了とローカル合格は同じですか？
違います。本番URLで確認し、初めて本番反映済みと記録します。
バックアップ、接続先、一件反映、確認、復旧まで一周できました。
この単位を守れば、次のページも同じ考え方で公開できるよ。
公開したら終わりですか？
次はSearch Consoleやアクセス、エラーを見て、読者が実際に使えるか確かめよう。
次は公開後の確認へ
公開前チェック と PC・スマホ表示確認 も合わせ、公開前後の状態を混ぜないでください。