諸君。WordPressの更新が終わった。トップページも開いた。では、これで完了だろうか。
更新後は「表示」「操作」「送信」「編集・保存」を確認する。独自テーマでは、記事や固定ページごとの表示に加え、CSS・JavaScriptの読み込み条件、フォーム、管理画面の更新作業まで確かめたい。
わたしがこの記事で提案するのは、代表ページを選び、更新前と同じ操作をたどり、結果を記録する進め方だ。「なんとなく大丈夫」を、確認できたことに変えていこう。
対象は、PHPテンプレートを使う独自テーマを運用するWeb制作者。WordPress本体の更新を中心に扱うが、テーマやプラグインを更新したときにも応用できる。EC・会員サイトでは、購入・ログインなど、そのサイト固有の確認を追加してほしい。
Contents
まず押さえる、更新前後の確認一覧
- 更新前：データベースとファイルのバックアップ、復元手順、更新対象と確認ページをそろえる。
- 表示：トップだけでなく、記事・固定ページ・一覧をPCとスマホで開く。
- 操作：メニュー、モーダル、検索など、クリックしたあとの動きを見る。
- 送信：フォームの入力・確認・完了に加え、管理者宛と自動返信のメールを確かめる。
- 管理画面：テスト用の下書きで、編集・保存・プレビュー・画像の挿入を試す。
- 完了判断：不具合の有無、未確認の項目、確認した環境を残す。
2026年10月6日には、WordPress 7.1.3のメンテナンス・セキュリティ更新が公開された。更新の必要性を確認しながら、サイトごとの動作確認もセットで進めたい。WordPress公式のリリース情報
この記事は特定のバージョンの互換性を保証するものではなく、更新後の確認手順を整理したものだ。掲載情報は2026年10月21日に確認している。
1．更新前に「戻せる状態」と「比べる基準」を用意する
更新後の確認は、更新前から始まっている。
WordPress公式では、更新前のバックアップが案内されている。記事などを持つデータベースと、テーマ・プラグイン・画像などのファイルは別物だ。片方だけで必要な状態に戻せるとは限らない。公式のバックアップ解説
バックアップの取得日時、対象、保存先、復元手順を確認する。可能なら検証環境で復元まで試しておくと、問題が起きたときの判断がしやすくなる。
次に、更新するものを整理する。
- WordPress本体・プラグイン・テーマ・PHPの、更新前と更新後のバージョン。
- 更新の目的と、公式の変更情報。
- 作業する順番と、各段階で確かめる操作。
- 問題が起きた場合の連絡先と復旧の判断基準。
一度に多くを変えると、どの変更が影響したか追いにくくなる。依存関係や更新の緊急性を確認し、検証環境で段階的に進めよう。セキュリティ更新を、検証の準備を理由に放置することは避けたい。
比べるための代表ページも決める。トップ、記事詳細、固定ページ、カテゴリーなどの一覧、検索結果、お問い合わせ。長いタイトル・画像なし・表やコードを含む記事も入れると、見落としを減らせる。
更新前のスクリーンショットと「こう動けば正常」というメモを残そう。基準があれば、担当者が変わっても確認を引き継ぎやすい。
2．表示は「ページの種類」と「画面幅」で確認する
独自テーマでは、ページによって異なるテンプレートや読み込み処理を使うことがある。トップが正常でも、記事やフォームまで正常とは限らない。
確認する順番は、代表ページを一巡してから、そのサイトで重要な画面を深く見る形がおすすめだ。
- トップ：見出し、画像、カード、ヘッダー、フッター。
- 記事詳細：見出しの階層、本文、リンク、画像、表、コード、埋め込み。
- 固定ページ：ページ固有のレイアウトとフォーム。
- 一覧・検索：記事リンク、ページ送り、結果がない場合の表示。
- 404：存在しないURLから、記事やトップへ戻れるか。
同じページを、PCとスマホの幅で確認する。長い見出しがボタンに重ならないか。横に長い表でページ全体がはみ出さないか。画像がない記事にも、不自然な空白が残らないか。
「スマホで開いた」から、もう一歩。スマホで読み、押し、入力できるところまで見よう。
3．独自テーマのCSS・JavaScriptは、読み込み条件まで見る
表示や操作がおかしいとき、すぐにCSSを書き足す前に、必要なファイルが読み込まれているか確認したい。
例として、この基地のテーマには「お問い合わせページだけで使うCSS」がある。もし読み込み条件からそのページが漏れれば、フォームのHTMLがあっても、入力欄は意図した見た目にならない。
これは条件分岐を点検するための例で、WordPress更新によってこの不具合が起きたという報告ではない。
ブラウザの開発者ツールでは、次の順で見る。
- Networkで、該当のCSS・JavaScriptへのリクエストと内容を確認する。
- Consoleで、操作時のJavaScriptエラーを確認する。
- ファイルが読まれているなら、適用されるスタイル、上書き、初期化の対象を調べる。
- 読まれていないなら、ページ条件・ファイルのパス・依存関係を調べる。
WordPressには、テーマのCSS・JavaScriptを登録して読み込むための仕組みがある。独自テーマでは、その仕組みに沿って登録しているかも見直したい。公式のアセット読み込み解説
キャッシュも確認対象だ。ただし、最初から設定を全部変更するのではなく、ブラウザ・サイト・CDNなど、どこに古い内容が残っていそうかを分けて考える。必要な範囲を更新したあと、普段のアクセスでも正しく表示されるか確かめよう。
ログイン中とログアウト中で、配信内容やキャッシュが異なる場合もある。自分の管理画面から見える景色だけで、確認を終えないことだ。
4．お問い合わせフォームは「送信できた画面」の先まで
フォームの確認は、見た目とメール配送を分けると整理しやすい。
まずは入力。文字が読めるか、スマホで入力しやすいか。必須の未入力やメール形式の誤りを、どのように知らせるか。エラーが出たあとも、入力済みの内容を保てるかを確認する。
確認画面があるフォームなら、入力内容の表示、戻る操作、戻ったあとの保持、再送信までたどる。確認画面がないフォームでは、そのサイトの送信フローに合わせればいい。
次に、完了画面とメールを照合する。
- 管理者宛の通知が、想定した宛先に届く。
- 自動返信を設定している場合、入力したテスト用アドレスに届く。
- 件名・本文・改行・日本語の表示に問題がない。
- 想定外の重複送信が起きていない。
完了画面が出たことと、メールが届いたことは、別の確認だ。
テスト送信は、確認可能な宛先とテスト用の内容で行う。外部の通知や業務システムにつながる場合は、先に関係者とテスト方法を決めておこう。検証環境では、実運用の宛先へ誤送信しない設定も必要になる。
メールが届かなければ、フォーム処理、送信基盤、受信側の迷惑メール判定などを順番に調べる。見た目が正常だからといって、原因をテーマだけに絞らない。
5．管理画面は、下書きを使って「編集・保存・表示」を一巡する
公開ページは正常でも、更新する人の作業が止まっていたら困る。
テスト用の下書きを作り、文章を編集して保存する。画像を挿入し、サイトで使っているブロックやカスタムフィールドも試す。そのうえで、プレビューと編集画面を見比べる。
- 保存が完了し、開き直しても変更が残っている。
- 画像のアップロード・選択・挿入ができる。
- 使用しているブロックや入力項目が表示される。
- 入力した内容が、公開側の想定した場所へ反映される。
- 更新担当者の権限で、普段の作業ができる。
管理者アカウントだけで確認を済ませると、担当者の権限で起きる問題を見落とすことがある。実際の運用に合わせて、必要な範囲を確かめよう。
独自テーマの力は、公開画面だけで決まらない。更新する人が迷わず扱えることも、設計の一部だ。
6．不具合が出たら、変更を増やす前に記録する
崩れを見つけると、すぐ直したくなる。その前に、次の情報を残してほしい。
- 発生したページと、再現する操作。
- 期待した結果と、実際に起きたこと。
- 端末、ブラウザ、ログイン状態。
- 更新した対象とバージョン。
- Consoleやログで確認できたエラー。
PHPの調査には、WordPressのデバッグ機能も使える。本番の画面へ詳細なエラーを出すのではなく、検証環境や適切に管理したログで調べたい。ログには機密情報が含まれる場合があるため、公開や共有の範囲にも気をつけよう。公式のデバッグ解説
プラグイン停止やテーマ切替による切り分けは、影響を管理できる検証環境で行う。本番で一斉に止めると、別の機能まで使えなくなるおそれがある。
AIに相談するときも、いきなり「全部直して」と渡す必要はない。例えば、こう頼める。
まだコードを変更しないでください。更新後に起きた症状と再現手順から、原因候補と確認する順番を整理してください。不足している情報があれば示してください。
添えるのは、必要な範囲の情報だ。個人情報、接続情報、鍵やパスワードをそのまま渡さない。原因を絞り、一つ変え、同じ操作で再確認する。変更が小さければ、結果を判断しやすい。
復旧を優先する場合も、バックアップ以降に増えた記事や問い合わせなどのデータを確認する。データベースまで戻す操作は、新しいデータを失う可能性がある。戻す範囲と影響を整理して判断しよう。
更新完了の条件を、先に決めておこう
わたしは「更新しました」という報告に、確認結果も添えたい。
代表ページを表示した。重要な操作を試した。フォームの通知を受信した。下書きを編集して保存した。そして、残っている確認事項を記録した。
例えば、作業メモはこれだけでも役に立つ。
確認ページ：トップ／記事／一覧／お問い合わせ。確認環境：PC・スマホ、ログイン・ログアウト。フォーム：管理者通知と自動返信を受信。編集：下書きの保存とプレビューを確認。残課題：対象のない項目は理由付きで記録。
これは記録方法の例で、このサイトの実施結果を示したものではない。
すべてを一度に完璧にしようとしなくていい。まず、そのサイトで止まると困ることを選び、確かめられる形にする。
更新ボタンを押したあとまで、諸君の技術が人を支える。ひとつずつ、確認して進もう🔥
あわせて読む
参考にした公式情報
- WordPress 7.1.3 Maintenance and Security Release（2026年10月6日公開）
- Updating WordPress
- Backups
- Including Assets
- Debugging in WordPress
公式情報の確認日：2026年10月21日。確認手順や具体例は、これらを踏まえた団長の提案として整理している。