0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

WordPressのアップデート前後に確認すること【チェックリスト付き】

0
Posted at

WordPressを更新したあと、どこまで動作確認していますか?
トップページは開けても、記事を保存できなかったり、問い合わせが届かなくなっていたりすると困ります。

WordPress本体・テーマ・プラグインのアップデート前後に確認することをまとめました。
更新操作や投稿の基本は分かるけれど、確認項目を整理しておきたい制作者・保守担当者向けです。

確認する内容を、次の4つに分けました。

分類 確認すること
動作環境・互換性 更新先のバージョンを、今の環境・組み合わせで使えるか
更新結果・構成 予定した更新が適用され、必要なテーマ・プラグイン・設定が維持されているか
機能・操作 閲覧者や更新担当者が、必要な操作を完了できるか
表示・公開状態 内容が正しく表示され、意図した状態で公開されているか

ブログや企業サイトで共通する確認に加え、EC・会員機能などを使っている場合の確認も載せています。
自分のサイトにない機能は対象外にし、独自に実装した機能があれば追加してください。
チェックリストだけ使いたい方は、末尾の一覧へどうぞ。

更新前:動作環境・互換性を確認する

現在の環境と、更新先の条件を照合する

最初に、現在のバージョンと、どのバージョンへ更新するかを控えます。

  • WordPress本体
  • 有効なテーマと、子テーマを使っている場合は親テーマ
  • プラグイン
  • PHP
  • MySQLまたはMariaDB

環境情報は、管理画面の「ツール → サイトヘルス → 情報」で確認できます。
テーマ・プラグイン、サーバー、データベースなどに分かれて表示されます。

次に、更新先のWordPress・テーマ・プラグインの動作要件と変更履歴を見ます。
最低要件と推奨環境は分けて読み、PHPの追加モジュールや、依存するプラグインの指定があれば、それも確認します。

プラグインの「検証済みの最新バージョン」は、開発元がテストしたWordPressのバージョンです。
自分のサイトのテーマ・他プラグインとの組み合わせまで保証する表示ではありません。

大きなバージョンをまたぐ更新や、独自コードがあるサイトでは、廃止されたAPI・設定方法の変更・既知の問題も確認します。
たとえば「フォームの送信処理が変わる」更新なら、表示確認だけで済ませず、受信や外部連携まで試験対象に入れます。

なお、MySQL・MariaDBのバージョン確認と、更新時に案内される「データベースの更新」は別の話です。
後者の案内が出たからといって、DBサーバー自体のバージョンを変更するわけではありません。

戻せる状態と、比較できる状態を用意する

更新前の準備は、次のとおりです。

  • ファイルとデータベースのバックアップを取り、取得日時・保存先・復元方法を確認する
  • 検証環境を用意し、本番と異なるPHP・設定・データなどを把握する
  • 主要ページの画面、重要な設定値、既存のエラーを控える
  • テスト用の記事・アカウント・送信先を用意する
  • 本番作業の時間、連絡先、不具合時に更新を中止・復旧する条件を決める

確認ページは、トップだけでなく、一覧・詳細・固定ページ・フォームなど、作りが違うページを選びます。
同じ記事テンプレートでも、独自ブロックや埋め込みを使うページは追加しましょう。
購入や申し込みにつながる重要なページも外せません。

検証環境では、顧客へのメール、実決済、外部サービスの本番データ更新を発生させないようにします。
フォームの通知先だけでなく、自動返信・Cc/Bcc・連携先も対象です。

バックアップは、取れたことだけでなく、必要なときに戻せることが大切です。

更新後:更新結果・構成を確認する

まず、更新そのものの結果を確認します。

  • WordPress・テーマ・プラグインが、予定したバージョンになっている
  • 必要なテーマ・プラグインが有効になっている
  • 更新失敗の表示や、意図しないメンテナンス画面が残っていない
  • DB更新やデータ移行の案内がある場合、開発元の手順どおりに処理が完了している
  • 重要な設定、有料製品のライセンス認証、外部サービスとの接続が維持されている
  • 自動更新やバックアップの設定が、運用方針から変わっていない

プラグインは、通常の一覧に出るものだけとは限りません。
必須プラグイン(MUプラグイン)や、キャッシュ用のドロップインを導入しているサイトでは、それらも構成に含めて確認します。

続いてサイトヘルスを開き、更新前になかった問題が増えていないか確認します。
REST APIやループバックの問題が出ていれば、投稿操作や予約処理の確認にもつなげます。
サイトヘルスが良好でも、個々のフォームや購入処理が正常とは限らないので、次の操作確認は別に行います。

更新後:機能・操作を確認する

使っている機能について、画面を開くだけでなく、結果が出るところまで試します。
投稿の作成・公開、登録、送信など、データを書き込む試験はまず検証環境で行ってください。

閲覧者が使う機能

  • メニュー・リンク:メニューの開閉、内部リンク、アンカー、ダウンロード先へ移動できる
  • 検索・絞り込み:掲載済みの語句で期待する記事が出る。該当なしの場合も正しく表示される
  • 一覧・ページ送り:2ページ目以降へ進めて、そこから詳細ページを開ける
  • タブ・アコーディオン・スライダー:操作に反応し、内容が切り替わる
  • ログイン・ログアウト:利用する認証方法でログインでき、ログアウト後は制限された内容を見られない
  • コメント:投稿・承認・表示・通知が、設定した運用どおりに動く

検索やログインなど、別の画面に移った後の結果も見てください。
「ボタンを押せた」と「目的の操作が完了した」は別です。

更新担当者が使う機能

  • 投稿・固定ページ・カスタム投稿を作成、編集、保存できる
  • 本文、カテゴリ、独自入力欄などの値が、編集画面を開き直しても残っている
  • プレビューと公開後のページに、保存した内容が反映される
  • 画像・ファイルをアップロードし、記事へ挿入できる。サムネイルも表示される
  • 使用しているブロック、ショートコード、ページビルダーを編集できる
  • メニュー、ウィジェット、サイトエディターなど、普段使う設定を保存できる
  • 必要な場合はリビジョンから戻せる

ここは管理者だけでなく、普段の担当者と同じ権限のテストアカウントでも確認します。
編集を許可した記事を操作できることと、許可していない記事や設定へアクセスできないことの両方を見ます。

たとえば独自の「開催日」欄なら、日付を変えて保存し、編集画面を開き直します。
さらに検証環境で公開し、ログアウトした画面にも変更が出るかを確認します。
入力欄に値が残ることと、サイトに表示されることを分けて確かめるわけです。

フォーム・メール・外部連携

フォームは次の順に確認します。

  1. 必須項目の未入力や不正な形式に対して、入力エラーが表示される
  2. 正しいテストデータで送信すると、完了表示まで進む
  3. 通知メールが届き、本文・選択項目・添付が意図した内容になっている
  4. 自動返信を使っていれば、テスト用アドレスに届く
  5. 問い合わせ保存や外部連携を使っていれば、保存先にも内容が反映される

フォームごとに設定や送信先が違うなら、それぞれ試します。
「代表の1つが送れた」だけでは、別のフォームの設定は確認できません。

また、送信完了とメール受信は分けて確認してください。
Contact Form 7の公式FAQにも、送信成功と表示されたのにメールが届かないケースが載っています。

予約処理・サイト固有の機能

以下は、導入している場合に確認します。

機能 確認する結果
予約投稿・定期処理 予定後に公開・処理される。バックアップなら新しいファイルと完了記録が残る
EC・決済 商品選択、カート、金額・送料・税、注文、決済結果、在庫、通知が整合する
会員・購読 登録、確認メール、パスワード再設定、契約状態に応じた閲覧制限が機能する
予約・申し込み 空き枠、受付、確認通知、変更・キャンセルが意図どおりに反映される
多言語 言語を切り替えられ、対応ページ・メニューへ移動できる
外部API・計測 連携先へ必要なデータが届く。計測は同意設定に沿って発火・抑止される
マルチサイト 対象の子サイトとネットワーク管理で、利用機能が動く

決済や契約を伴う試験は、サービスのテストモードとテストデータを使います。
継続課金・返金などが業務に必要なら、その経路も追加してください。

予約処理は、設定が保存されただけでは確認完了にしません。
通常のWP-Cronはページ読み込みを契機に動くため、予定時刻ぴったりに実行されるとは限りません。
実行結果がまだ出ていないものは「未確認」とし、普段使っている起動方法と許容する遅延に合わせて後から確認します。

更新後:表示・公開状態を確認する

レイアウトと端末・ブラウザの違い

  • 主要ページで、文字・画像・余白・ヘッダー・フッターが更新前の意図した表示から崩れていない
  • 独自ブロック、ショートコード、埋め込み、遅延読み込みの内容が表示される
  • PC・スマートフォンで、横にはみ出したり、ボタンが隠れたりしない
  • サイトが対応対象としているブラウザで、表示と操作に問題がない
  • キーボードでも主要なリンクやフォームへ移動でき、フォーカスが見える
  • 同じ条件で更新前と比べ、表示や操作が著しく遅くなっていない

ブラウザの幅を狭める確認と、スマートフォン実機での確認は分けます。
重要な操作は実機でも試し、タップや入力時の表示を確認しましょう。

キャッシュを使う画面

ログイン中の表示だけで終わらせず、ログアウトした画面も見ます。
たとえばWP Super Cacheには、ログインしているユーザーにはキャッシュを使わない設定があります。

キャッシュ削除が必要な更新では、ブラウザだけでなく、プラグイン・サーバー・CDNなど、使っている機能の手順も確認します。
削除後の最初の表示と、その後の表示・操作を確認し、古い内容や崩れが残っていないか見てください。
別のブラウザを開くだけでは、サーバーやCDNのキャッシュは消えません。

公開範囲・URL・検索エンジン向けの出力

  • 公開ページをログアウト状態で開ける。下書き・非公開・会員限定の内容は、権限のない人に見えない
  • 一覧・詳細のURLに意図しない404や転送がない。存在しないURLは404として返る
  • HTTPSで開けて、画像やスクリプトの読み込みがブロックされていない
  • ページタイトル、description、canonicalが、意図した内容・URLになっている
  • robots.txtやnoindexの設定が、公開方針どおりになっている
  • XMLサイトマップを取得でき、掲載対象のURLが正しい
  • 構造化データを出している場合は、その内容を確認し、対象に応じた検証ツールを通す
  • 検証環境のURL、アクセス制限、デバッグ表示、決済のテスト設定が本番に残っていない

SEOプラグインの設定画面だけでなく、実際のページのHTMLやHTTP応答も確認します。
canonicalは正規URLを示す情報なので、検証環境や無関係なページを指していないか見てください。

なお、robots.txtでのクロール制御と、noindexでのインデックス制御は別です。
robots.txtは非公開ページを守るアクセス制限の代わりにはなりません。

不具合が見つかったときの確認先

問題があれば、起きたページ・操作・時刻と、期待した結果を控えます。
最初に調べる場所の目安は次のとおりです。

症状 最初に見るところ
真っ白になる、500エラーが出る サーバーのPHPエラーログ、直前の更新内容
ボタンが動かない、保存に失敗する 開発者ツールのConsoleとNetwork、失敗した通信の応答
CSS・画像が読み込まれない Networkの読み込み結果、URL・キャッシュ・HTTPS
メールが届かない 送信先、迷惑メール、送信ログ、連携サービス側の結果
予約処理が動かない 実行履歴、予定時刻・タイムゾーン、WP-Cronやサーバー側の起動設定

ChromeのNetworkでは、操作時のリクエストやステータス、応答を確認できます。
ただし、エラー表示だけで原因を決めず、更新前にも起きていたかを比べます。
公開画面にデバッグ情報を表示したり、認証情報・個人情報を含むログをそのまま共有したりしないようにしてください。

重大な不具合があれば、本番への適用は止めます。
本番で発生した場合は運用担当者へ共有し、決めておいた復旧手順で対応します。
DBを戻すと更新後の注文や投稿まで失う場合があるため、バックアップを無条件に上書きするのは避けてください。

検証環境で通った項目も、本番反映後に主要な表示・操作を再確認します。
メール配送・決済・外部連携など、本番でしか確かめられない点は、確認方法・担当者・予定を決めて記録します。
確認が終わったテスト投稿・アカウント・注文などは、必要な記録を残したうえで片付けましょう。

コピーして使うチェックリスト

以下をコピーし、対象ページや機能に合わせて使ってください。
各行の [ ] に、結果を OK / NG / 未確認 / 対象外 で記入します。
検証と本番は別々に記録し、予約処理などの確認待ちには確認予定も添えます。

サイト:
確認日・担当者:
環境:検証 / 本番
更新対象と変更前 → 変更後のバージョン:
確認するURL・端末・ブラウザ・権限:
結果:OK / NG / 未確認 / 対象外

【更新前:動作環境・互換性と準備】
[ ] PHP・MySQL/MariaDBと、更新対象の動作要件を照合した
[ ] 本体・親子テーマ・プラグインのバージョンと依存関係を確認した
[ ] 変更履歴・既知の問題・独自コードへの影響を確認した
[ ] ファイルとDBのバックアップ・保存先・復元方法を確認した
[ ] 検証と本番の違い、比較用の画面・設定・既存エラーを記録した
[ ] テストデータ・送信先・決済・外部連携を安全に試せる状態にした
[ ] 本番作業の時間・連絡先・中止と復旧の条件を決めた

【更新後:更新結果・構成】
[ ] 予定したバージョンへ更新され、失敗やメンテナンス表示が残っていない
[ ] 必要なテーマ・プラグインが有効(MU・ドロップインも該当時に確認)
[ ] 必要なDB更新・データ移行が完了している
[ ] 重要な設定・ライセンス認証・外部接続が維持されている
[ ] 自動更新・バックアップ設定が運用方針どおりである
[ ] サイトヘルスで新しく出た問題を確認した

【更新後:機能・操作】
[ ] メニュー・リンク・タブ等を操作し、目的の内容へ到達できる
[ ] 検索・絞り込みで期待する結果と該当なしの表示を確認した
[ ] 一覧の2ページ目以降からも詳細へ移動できる
[ ] ログイン・ログアウト・利用する認証方法が動く
[ ] 担当者の権限で許可された操作ができ、禁止された操作はできない
[ ] 投稿等を保存・再読込し、本文・分類・独自入力欄の値が残っている
[ ] プレビューと公開画面に保存内容が反映される
[ ] 画像・ファイルのアップロード、挿入、サムネイル表示ができる
[ ] 使用するブロック・ページビルダー・設定画面・リビジョンが使える
[ ] 使用するコメントの投稿・承認・表示・通知が動く
[ ] 各フォームで入力エラー・正常送信・通知・自動返信を確認した
[ ] 問い合わせ保存や外部連携の送信先にも結果が反映される
[ ] 予約投稿・定期処理・バックアップの実行結果を確認した
[ ] EC・会員・予約・多言語・マルチサイトの利用機能を確認した
[ ] 決済・契約・在庫・変更や取消など、該当する業務処理が整合する
[ ] 計測と外部APIが、同意設定を含めて意図どおりに動く

【更新後:表示・公開状態】
[ ] 主要ページと独自要素の表示が更新前の意図から崩れていない
[ ] 対応端末・ブラウザで表示、タップ、入力、主要なキーボード操作ができる
[ ] 更新前と同じ条件で、表示や操作が著しく遅くなっていない
[ ] ログイン中とログアウト中、キャッシュ処理後の表示・操作を確認した
[ ] 公開・非公開・会員限定などの閲覧範囲が正しい
[ ] URL・転送・404・HTTPSと必要なファイルの読み込みが正常である
[ ] title・description・canonical・robots・noindexが意図どおりである
[ ] XMLサイトマップと、使用する構造化データの出力を確認した
[ ] 本番に検証用URL・アクセス制限・デバッグ表示・テスト設定が残っていない

【確認を終える前に】
[ ] 不具合の症状・再現手順・時刻・対応を記録した
[ ] 本番反映後の再確認と、本番固有の確認を実施した
[ ] 未確認の項目には担当者・確認予定・影響を記載した
[ ] テスト投稿・アカウント・注文等を、必要な記録を残して片付けた

サイト固有の追加項目:
不具合・未確認・対象外の理由:
後日の確認予定と担当者:

「フォームがある」「会員機能がある」と分かっていても、更新時に毎回思い出して確認するのは大変です。
最初の一度で自分のサイト用に項目を整えておくと、次回はその一覧から始められます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?