AIが直したWordPressを公開してよいか迷うなら、「コードが壊れていない」「サイトとして使える」「本番で変更が反映された」の三つを別々に確認してください。テストが一つ通っただけでは、残りの二つは分かりません。
ここでは「トップページの上段を購入ガイド、下段を新着記事に変える」という例で説明します。数字や画面幅は編集部が提案する確認例であり、WordPress公式の一律な合格基準ではありません。
第1段階：変更ファイルだけを確かめる
最初に、何を変えたかを一覧にします。今回ならトップページのテンプレート、記事選定の設定、必要なCSSが候補です。広告計測やログイン処理まで変わっていたら、その理由を確認するまで進めません。
PHPとJavaScriptの構文を検査し、対象の機能に既存テストがあれば実行します。記事を選ぶ処理なら「指定記事がない場合」「非公開になった場合」も確認します。番号を六つ並べるコードが動いても、実際には四記事しか表示されないことがあるからです。
第2段階：本番と切り離したWordPressで使ってみる
HTMLの見本だけでなく、実際のテーマと記事データで表示します。ローカル環境や検証用サイトに、本番に近い長いタイトル・画像なしの記事・幅の広い比較表を用意してください。個人情報や不要な認証情報はコピーしません。
| 見る場所 | 今回の合格例 |
|---|---|
| 上段 | 購入ガイドと人気記事を区別でき、タイトルを最後まで読める |
| 下段 | 最新記事が欠けず、日付順に並ぶ |
| スマホ | 画面全体には横スクロールが出ず、カードと画像が重ならない |
| 記事画面 | 本文、比較表、購入ボタンが読め、操作できる |
390・768・1440pxなど複数の幅で確認し、実際に指で操作するつもりでスクロールします。購入リンクは検証中に自動クリックせず、リンクの文字列や設定を照合します。広告の表示・クリックを発生させない検証環境にしておくと、自分の確認を成果と取り違えずに済みます。
WordPress Playgroundは、WordPressの変更を試す選択肢です。ただし本番のキャッシュ、メール配送、サーバー設定まで同じになるわけではありません。Playgroundで通った項目と、本番相当の環境で追加確認する項目を分けます。
第3段階：承認した変更だけを反映し、同じ項目を読み直す
本番では、承認済みの変更ファイルと旧版を対応させ、対象を限定して反映します。反映後は管理画面の成功表示だけで終えず、ログアウト状態の公開URLで確認します。キャッシュが残る場合は、配備された版と表示された版を分けて調べ、同じファイルを何度も送り直さないようにします。
「トップは新しくなったが、記事ページだけ古い」「スマホの購入ボタンが隠れた」なら不合格です。復旧先を決めておき、戻した後にも表示を確認します。WordPress公式のバックアップ案内も参照し、ファイルとデータベースのどちらが必要かを整理してください。
結果は短くても、未確認を残さない
報告は「第1段階：構文と対象テスト合格。第2段階：ホームと代表記事を3幅で合格。第3段階：未実施、本番保留」のように書きます。「全部OK」と丸めないことが大事です。公開を止めているときでも第2段階まで完成させられれば、再開後に何をすべきかが明確になります。
まず、今回直したい画面を一つ選び、合格条件を三行で書いてみてください。条件を説明できないほど変更が大きいなら、作業を分けるタイミングです。
