WordPressの更新ボタンを押す前に。「戻せる状態」のつくり方。

01 / 05

バックアップは「ある」だけで安心しない

WordPressの公式資料は、サイトのバックアップをファイルとデータベースに分けて説明しています。投稿のエクスポートだけを保存して、テーマ、画像、設定まで元通りにできると思い込まないことが大切です。 ^[1]

サーバーの自動バックアップを使っているなら、保存される対象、保存期間、復元する方法を確認します。担当者が管理画面へ入れるか、復元にどのくらい時間がかかるかも、作業前に把握しておきます。「制作した会社が持っているはず」という状態なら、先に確認する方が確実です。

02 / 05

戻す時点によって、失う更新が変わる

昨日のバックアップに戻せば、昨日の状態に近づけられます。ただし、その後に追加された投稿や注文などのデータも、復元方法によっては巻き戻る可能性があります。バックアップ時刻だけでなく、その後にサイトへ入った情報をどう扱うかが問題になります。

予約や注文を受け付けるサイトは、一般的な会社案内と同じ段取りでは扱えません。受付を続けながら試すのか、作業時間を設けるのか。自社で判断しにくい場合は、復元とデータ保全の方法まで、運用担当者に確認してから進めます。

03 / 05

変更を分けると、原因を追いやすい

WordPress本体、テーマ、複数のプラグインを同時に更新して不具合が出ると、何が関係しているかを絞り込みにくくなります。作業の対象と更新前後のバージョンを残し、確認できる単位で進める方法を提案します。 ^[2]

大きな更新や独自の改修があるサイトでは、検証用の環境で先に確認することも選択肢です。検証環境でも、外部へメールが送られたり決済につながったりしないよう、本番との接続を確認する必要があります。単にサイトをコピーしただけで、安全な試験環境ができるとは限りません。

04 / 05

更新後は「見える」と「使える」を確かめる

フォームは送信完了の画面だけでなく、担当者に届いていることまで確かめます。実際に送信する試験は、受信側と内容を決めてから。不要な注文や通知を発生させないようにします。

ブラウザーに古い表示が残っている場合もあります。キャッシュの影響を確認しつつ、正常に見える端末が一台あるだけで完了にしないことがポイントです。

05 / 05

引き継ぎのために、短い作業メモを残す

作業日時：
担当者：
更新した対象／更新前→更新後：
作業前バックアップの時点・保存先：
確認したページ・機能：
残っている問題：
問題が起きたときの連絡先・復元担当：

細かい報告書でなくても、次に不具合が出たときに「いつから変わったか」をたどれれば役に立ちます。担当者が変わっても、サイトの状態がわかること。更新は、その記録を残すところまでを一つの仕事にしておくと続けやすくなります。