WordPress本体、テーマ、プラグインを更新した直後に、文字の大きさが変わった、画像が横にはみ出した、メニューが開かない、トップページだけ真っ白になった。このような表示崩れが起きると、すぐに元へ戻そうとして複数の設定を一度に変更したくなるかもしれません。
しかし、更新後のトラブルで大切なのは、慌てて操作を重ねることではなく、いま何が起きているかを記録し、影響範囲を確かめ、原因候補を一つずつ切り分けることです。変更を重ねるほど、最初の原因と途中で加えた変更の影響が混ざり、復旧が難しくなります。
この記事では、WordPressの更新後に表示が崩れたときの確認順、比較的安全に自分で試せる対処、バックアップから戻す前の判断、制作会社・保守会社・レンタルサーバー会社へ依頼する目安を初心者向けに整理します。単なる操作手順ではなく、サイトを悪化させずに復旧へ近づくための考え方を身につけることが目的です。
更新後の表示崩れは最初の行動で復旧しやすさが変わる
表示崩れに気づいた直後は、原因究明より先に被害を広げないことを優先します。特に、管理画面へ入れるからといって、別の更新、テーマ変更、プラグインの削除、設定の初期化を続けて行うのは避けましょう。原因候補が増え、元の状態を再現できなくなるからです。
まず、サイトが完全に停止しているのか、一部のページだけ崩れているのか、見た目だけの問題なのか、購入・問い合わせ・ログインなどの機能も止まっているのかを確認します。事業サイトでは、デザインのずれよりも、フォーム送信や注文処理の失敗のほうが影響は大きい場合があります。
公開サイトで利用者に誤操作や誤送信が起こりそうな場合は、保守中の案内や一時的な受付停止を検討します。ただし、仕組みが分からないままメンテナンス用プラグインを新しく追加するのは、原因候補を増やす行為でもあります。既存の運用手段がある場合に限り使い、なければ担当者へ相談するほうが安全です。
症状を記録してから操作する
次に、崩れている画面のスクリーンショット、対象URL、発生に気づいた時刻、直前に更新した対象、管理画面に表示されたメッセージを記録します。スマートフォンだけで崩れる場合は機種名とブラウザー名、ログイン中だけ崩れる場合はその条件も残します。
更新履歴が分かるなら、WordPress本体、テーマ、子テーマ、各プラグインの更新前後のバージョンも控えます。正確な数字が確認できないときは推測で埋めず、「更新通知から一括更新した」「自動更新のメールが届いた」など事実だけを記録してください。
記録は、後で自分が比較するときだけでなく、外部へ相談するときにも役立ちます。「更新したら壊れた」だけでは調査範囲が広すぎますが、「この時刻以降、商品ページのモバイル表示だけでボタンが押せない」と分かれば、確認の優先順位を付けやすくなります。
表示崩れの原因を大きく分類する
更新後に見た目が変わっても、原因が更新ファイルそのものとは限りません。古いキャッシュが残り、新旧のCSSやJavaScriptが混ざっているだけのこともあります。一方で、テーマとプラグインの互換性、PHPのエラー、独自カスタマイズの上書きなど、ファイルやプログラムに関わる問題もあります。
原因候補を大きく分類すると、ブラウザーやキャッシュの問題、テーマの問題、プラグインの問題、WordPress本体やサーバー環境の問題、独自カスタマイズの問題に分けられます。この順番を意識すると、危険度の低い確認から始められます。
ブラウザーや各種キャッシュの不整合
更新後のCSSやJavaScriptは新しくなっているのに、ブラウザー、キャッシュプラグイン、サーバー、CDNのどこかに古いファイルが残ると、画面の部品だけが古い状態で読み込まれることがあります。その結果、余白、色、メニュー、スライダーなどが不自然に見えます。
この場合、サイトのデータが壊れているとは限りません。別のブラウザーやシークレットウィンドウで同じURLを確認し、端末や回線を変えたときにも再現するかを比較します。自分のブラウザーだけで起きるなら、サイト全体の障害ではない可能性が高まります。
ただし、キャッシュ削除ボタンを片端から押すのではなく、どの層のキャッシュを消したか記録しましょう。CDNやサーバーキャッシュの全削除はアクセス増加を招くこともあるため、管理方法が不明な場合は契約先の手順を確認します。
テーマと子テーマの問題
テーマ更新でテンプレート、CSS、JavaScriptの構造が変わると、子テーマや追加CSS、独自コードとの組み合わせで表示が崩れることがあります。親テーマのファイルを直接編集していた場合、更新によって編集内容が上書きされることもあります。
WordPress公式のトラブルシューティング資料でも、既定テーマのファイルへ直接加えた変更は、更新で失われる可能性があると説明されています。独自変更を守るために子テーマを使う考え方が重要です。更新前にどこをカスタマイズしたか分からないサイトでは、むやみにテーマを入れ直す前にファイル差分を確認する必要があります。
ブロックテーマでは、サイトエディターに保存したテンプレートやスタイルがデータベース側に残っている場合もあります。ファイルだけを戻せば完全に元通りになるとは限りません。クラシックテーマとブロックテーマでは調査箇所が異なるため、使っているテーマの種類を把握することが大切です。
プラグイン同士やテーマとの競合
プラグインの更新で読み込むCSSやJavaScript、PHP処理が変わり、他のプラグインやテーマと競合することがあります。最適化、キャッシュ、セキュリティ、ページビルダー、フォームなど、画面や読み込み方法に関わるプラグインは、見た目や操作へ影響しやすい領域です。
WordPress公式のプラグイン管理資料では、問題の原因が分かる場合は対象プラグインを停止し、原因が分からない場合は一つずつ停止して切り分ける方法が案内されています。ただし、本番サイトで無計画に停止すると、フォーム、決済、会員機能、SEO設定などが一時的に機能しなくなることがあります。
事業に関わる機能を持つサイトでは、可能ならステージング環境や複製環境で再現し、公開サイトでの停止時間を短くします。ステージング環境がない場合は、影響の小さい時間帯、連絡手段、戻し方を決めてから行います。
PHPエラーやサーバー環境の不一致
見た目のずれではなく、真っ白な画面、重大なエラー、500系エラーが出る場合は、PHPの致命的なエラーやメモリ不足、互換性の問題も考えられます。WordPressには致命的なエラーが起きた際のリカバリーモードがあり、管理者メールに復旧用の案内が届くことがあります。
更新対象が求めるPHPバージョンや拡張機能とサーバー環境が合っていないこともあります。だからといって、原因確認前にPHPバージョンを何度も切り替えるのは危険です。別のプラグインまで動かなくなる可能性があるため、現在値、変更前の値、戻す方法を確認してから扱います。
エラーログは重要な手掛かりですが、公開画面へエラーを表示すると、ファイルパスなど内部情報が利用者に見えることがあります。公式のデバッグ資料も、本番環境でのログや表示の扱いには注意を促しています。設定ファイルの編集に慣れていなければ、サーバー会社や制作者へ依頼してください。
安全性の高い順に確認する
原因を切り分けるときは、サイトを変更しない確認から始め、次に戻しやすい変更、最後にファイルやデータベースへ触れる作業へ進みます。最初から復元や再インストールを選ぶと、必要な最新データまで巻き戻すおそれがあります。
影響範囲を複数の条件で比べる
トップページだけか全ページか、パソコンだけかスマートフォンも同じか、ログイン中だけかログアウト中も同じかを比べます。特定ページだけなら、そのページ固有のブロック、ショートコード、テンプレートが原因候補です。全ページなら、共通ヘッダー、テーマ全体、キャッシュなどの可能性が高まります。
表示だけでなく機能も確かめます。問い合わせフォームは送信できるか、確認メールは届くか、ECサイトならカートや決済前まで正しく進めるか、会員サイトならログインできるかを、安全なテスト方法で確認します。本番で実決済や実在顧客データを不用意に使わないでください。
別ブラウザーとシークレットウィンドウで確認する
同じ端末でも通常ウィンドウとシークレットウィンドウで差があるなら、ブラウザーキャッシュや拡張機能の影響を疑えます。別端末でも同じなら、サイト側や配信側の問題である可能性が上がります。
この確認はサイトへ変更を加えないため、最初に行いやすい方法です。ただし、シークレットウィンドウでもDNSやCDNのキャッシュは共有されることがあります。「別ブラウザーで直ったから解決」と決めつけず、利用者側でも再現しないか確認します。
管理画面と更新通知を確認する
管理画面へ入れる場合は、サイトヘルス、更新画面、プラグイン一覧、テーマ一覧にエラーや必要条件の案内がないかを読みます。警告が出ていても、理解できないまま一括修正はしません。文面を保存し、公式ドキュメントや提供元の案内と照合します。
自動更新の通知メールが届いているなら、更新対象と時刻を確認します。複数の更新が同時に実行されていると、最後に更新されたものが原因とは限りません。更新順と症状発生の時系列を作ると、調査対象を絞りやすくなります。
キャッシュを層ごとに確認する
ブラウザー、WordPressのキャッシュプラグイン、レンタルサーバー、CDNの順に、利用中の仕組みを洗い出します。全部を同時に消すより、一層ずつ確認して表示の変化を見たほうが、原因を特定しやすくなります。
最適化プラグインでは、CSSやJavaScriptの結合、圧縮、遅延読み込みが更新後のファイルと合わない場合があります。一時停止で改善した場合も、そのまま放置せず、除外設定や互換性情報を確認します。停止によって速度や表示が変わるため、必ず元の設定を記録しておきます。
プラグインとテーマを切り分ける方法
キャッシュを確認しても複数環境で再現するなら、プラグインやテーマの競合を調べます。ここからは公開サイトへ影響を与える可能性があるため、バックアップの有無、戻し方、作業時間、連絡先を確認してから進めます。
ステージング環境を優先する
ステージング環境とは、本番サイトに近い状態を複製して試す場所です。公開利用者へ影響を与えずに、プラグイン停止、テーマ変更、再更新などを試せます。レンタルサーバーに複製機能があっても、公開サイトからステージングへのコピー方向と、逆方向の反映範囲を必ず確認してください。
ステージングから本番へデータベース全体を上書きすると、テスト中に本番へ届いた問い合わせ、注文、投稿などを失う可能性があります。原因調査にステージングを使うことと、ステージングの状態を本番へ反映することは別の判断です。
直前に更新した対象から確認する
直前に一つだけ更新したプラグインが分かっており、その停止による事業影響も小さいなら、対象を一時停止して表示を確認します。改善した場合は、更新版と現在の環境の組み合わせに問題がある可能性があります。
改善しない場合は、すぐ次々に削除せず、停止した対象を戻すか、そのままにするかを記録します。プラグインを削除すると設定やデータを消す製品もあるため、「停止」と「削除」は同じではありません。切り分けではまず停止を使い、削除は提供元の仕様を確認してから判断します。
原因不明なら一つずつ有効化して再現を見る
公式資料には、プラグインを一つずつ停止して原因を探す考え方があります。実務では、全停止した状態で問題が消えるかを確認し、必要なものを一つずつ有効化して再発点を探す方法もあります。ただし、どちらが安全かはサイト機能によって異なります。
フォーム、決済、会員、予約、セキュリティなどを止めると影響が大きいため、公開サイトで安易に全停止しないでください。作業中に外部から入力が入るサイトは、ステージング環境か保守担当者による対応が適しています。
標準テーマへの切り替えは影響を理解して行う
標準テーマへ一時的に切り替えて改善するなら、現在のテーマや子テーマとの関係が疑われます。ただし、テーマ変更はメニュー、ウィジェット、テンプレート、追加機能の見え方を大きく変えます。公開中に行うと、それ自体が表示崩れのように見えることがあります。
WordPress公式のテーマ資料は、プレビューが空白なら原因を調べずに有効化しないよう案内しています。テーマ切り替えは、まずプレビューやステージングで確認し、本番で行う場合は短時間で元に戻せる準備を整えます。
バックアップから戻す前に確認したいこと
表示崩れが起きると、すぐバックアップ復元を考えがちです。しかし、バックアップは「以前の状態に戻す」操作であり、「表示だけを直す」操作ではありません。取得後に追加された投稿、問い合わせ、注文、会員情報、設定変更まで戻る可能性があります。
復元対象と取得時刻を確認する
バックアップがファイルだけか、データベースだけか、両方かを確認します。テーマやプラグインのファイルだけが原因なら、サイト全体のデータベースまで戻す必要がないこともあります。逆に、サイトエディターの設定やプラグイン設定はデータベースに保存され、ファイル復元だけでは直らないことがあります。
取得時刻と障害発生時刻を比べ、バックアップが正常だった時点のものかを確認します。崩れた後に自動取得されたバックアップでは、問題のある状態も保存されている可能性があります。世代が複数ある場合は、どれを使うか根拠を残します。
復元前の現状も保存する
現在の状態に調査の手掛かりが残っていることがあります。復元で上書きする前に、可能なら現状のファイル、データベース、ログを別に保存します。これにより、復元後に原因を調べたり、必要な最新データだけを取り出したりできる可能性があります。
空き容量が不足しているとバックアップや復元が途中で失敗することもあります。保存先、容量、処理中のタイムアウト、復元手順を確認し、自信がなければサーバー会社や担当者へ相談します。
本番へ戻す前に復元テストを行う
理想は、別環境でバックアップを復元し、管理画面へのログイン、主要ページ、フォーム、画像、内部リンクなどを確認することです。「復元処理が完了した」という表示だけでは、サイト全体が正常とは限りません。
テスト環境を用意できない場合は、復元後の確認項目と、復元自体が失敗した場合の連絡先を先に決めます。営業時間中の本番復元は、停止時間やデータ損失の影響を考慮して判断します。
エラー情報を安全に集める
見た目だけでは原因が分からない場合、ブラウザーの開発者ツール、サーバーのエラーログ、WordPressのデバッグログが手掛かりになります。ただし、ログにはサーバー内部のパス、プラグイン名、場合によっては個人情報に関わるデータが含まれる可能性があります。
公開画面へエラーを表示しない
WordPressのデバッグ設定には、エラーを画面へ表示する設定と、ログへ記録する設定があります。本番サイトで画面表示を有効にすると、利用者に内部情報が見える危険があります。公式のデバッグ資料を確認し、目的と保存先を理解してから設定します。
調査が終わったら、追加したデバッグ設定を元へ戻します。設定変更日、担当者、対象ファイルを記録しておくと、後で常時デバッグ状態のまま残ることを防げます。
相談用の情報から秘密情報を除く
制作会社やサポート窓口へエラー内容を送るときは、パスワード、APIキー、Cookie、顧客情報、データベース接続情報を含めないでください。スクリーンショットのブラウザー上部や管理画面内に、個人名やメールアドレスが映っていないかも確認します。
管理者アカウントを共有する必要がある場合は、既存の個人アカウントを渡すのではなく、必要最小限の権限を持つ一時アカウントを作成し、作業後に削除または無効化する運用が安全です。権限の範囲は作業内容に合わせます。
自分で直すか専門家へ依頼するかの判断基準
自分で対処できるかは、症状の難しさだけでなく、失敗したときの事業影響、戻せる準備、扱うデータの重要性で決まります。手順が検索で見つかっても、自社サイトの構成にそのまま当てはまるとは限りません。
自分で進めやすいケース
別ブラウザーでは正常で、個人端末のキャッシュだけが原因と考えられる場合、変更を加えずに解決しやすいでしょう。直前に更新した対象が一つで、ステージング環境があり、停止しても事業機能へ影響せず、確実に元へ戻せる場合も、自分で切り分けやすいケースです。
それでも、作業記録とバックアップは必要です。軽い症状だからといって複数の設定を同時に変えると、再発時に原因が分からなくなります。
早めに依頼したいケース
管理画面へ入れない、公開サイトが真っ白、注文・予約・問い合わせが止まっている、個人情報を扱う機能に異常がある、バックアップの正常性が分からない場合は、早めの相談が適しています。また、独自テーマ、独自プラグイン、複雑なページビルダー、会員・決済機能を使っているサイトも影響範囲が広くなります。
エラーにデータベースやPHPファイルの編集が必要と書かれていても、その意味が分からないままコピーしたコードを実行しないでください。編集ミスで管理画面にも入れなくなることがあります。
依頼先を症状に合わせて選ぶ
レンタルサーバー会社は、サーバー障害、PHP環境、バックアップ機能、アクセスログなど契約基盤の確認に向いています。ただし、テーマやプラグインのコード修正まではサポート範囲外の場合があります。
テーマ・プラグイン提供元は、自社製品の既知の不具合、互換性、更新版の案内に適しています。サイト全体の組み合わせまでは調査できないこともあります。制作会社やWordPress保守会社は、サイト固有の構成、独自カスタマイズ、複数製品の競合を横断して調べる役割に向いています。
どこへ依頼するか迷うときは、「更新した対象」「症状の範囲」「管理画面へ入れるか」「事業機能への影響」「バックアップの有無」を伝え、対応範囲と着手前の確認事項を聞きましょう。
依頼前に用意すると調査が進みやすい情報
外部へ依頼するときは、情報が多ければよいのではなく、事実が整理されていることが重要です。推測と確認済みの事実を分けると、誤った前提で調査が進むのを防げます。
- 問題が起きているURLと正常なURL
- 発生に気づいた日時と直前の作業
- 更新したWordPress本体・テーマ・プラグイン
- パソコンとスマートフォン、別ブラウザーでの再現結果
- 表示だけか、フォームや決済など機能も止まっているか
- 管理画面へログインできるか
- 画面のスクリーンショットとエラーメッセージ
- バックアップの取得方法、対象、取得時刻
- 自分で試した操作と、その前後で変わったこと
アクセス情報は最初からメール本文へ書かず、安全な共有方法を確認してから渡します。緊急対応でも、作業範囲、バックアップ、復旧後の確認、再発防止の提案が含まれるかを確認すると、単に一時的に見えるようにしただけで終わりにくくなります。
復旧後に行う確認
トップページが元に戻っただけで復旧完了と判断しないでください。ヘッダー、フッター、固定ページ、投稿、カテゴリ一覧、検索、スマートフォン表示を確認します。サイトの目的に応じて、問い合わせ、予約、会員ログイン、カートなど重要な導線もテストします。
キャッシュを削除した場合は、キャッシュが再生成された後も正常かを確認します。一時的にプラグインや最適化機能を止めたなら、現在の運用状態と速度・安全性への影響を記録します。
原因が特定できたら、「どの更新とどの環境の組み合わせで起きたか」「どの操作で復旧したか」「再度更新するために何が必要か」を残します。単に古いバージョンへ戻しただけなら、将来のセキュリティ更新を永遠に止めるわけにはいきません。検証環境で互換版を試す、提供元へ問い合わせる、代替製品を検討するなど次の対応が必要です。
更新トラブルを減らす運用へ見直す
表示崩れを完全になくすことは難しくても、復旧しやすい運用にはできます。更新を溜め込むのではなく、更新前のバックアップ、変更履歴、ステージング確認、更新後の動作確認を一つの流れとして定着させます。
一度に更新する対象を絞る
複数の重要なテーマやプラグインを同時に更新すると、問題が起きたとき原因を絞りにくくなります。サイトへの影響が大きいものは、一つずつ更新して主要ページを確認する運用が有効です。
ただし、セキュリティ修正を理由なく長期間遅らせるべきではありません。緊急性、互換性情報、サイトの重要度を見て、検証と更新の時間を確保します。
バックアップを取得するだけで終わらせない
バックアップは、正常に完了したか、必要なファイルとデータベースが含まれるか、保存先へアクセスできるか、復元手順が分かるかまで確認します。復元テストをしたことがないバックアップは、緊急時に初めて問題が分かることがあります。
独自カスタマイズの所在を残す
追加CSS、子テーマ、コードスニペット、テーマ設定、外部タグなど、標準以外の変更箇所を一覧にします。誰が、いつ、なぜ変更したかが分かれば、更新時に影響を受ける場所を先に確認できます。
制作会社へ依頼したサイトでは、保守契約の有無だけでなく、更新作業、障害一次対応、バックアップ復元、外部サービス連携のどこまでが対象かを確認しておくと安心です。
定期保守を依頼していない場合でも、緊急時の連絡先候補と、サイトの管理に必要な契約情報の保管場所を決めておきましょう。ドメイン、サーバー、WordPress管理者、CDNなどの契約主体が別々だと、障害時に誰がどこまで操作できるかの確認だけで時間がかかります。契約名義、更新期限、二段階認証の受け取り先を社内で把握し、退職者や以前の制作会社だけが管理できる状態を避けます。
また、更新後の確認を担当者の記憶だけに頼らず、主要URL、フォーム、スマートフォン表示、計測タグなどをチェックリストにします。サイトに新しい機能を追加したときは確認項目も更新してください。毎回同じ観点で比べることで、小さな異常を早く見つけやすくなります。
公式情報を確認するときのポイント
WordPressの操作方法は、バージョン、テーマ、プラグイン、レンタルサーバーによって異なります。検索結果の古い記事をそのまま実行せず、まずWordPress公式のトラブルシューティングFAQ、プラグイン管理資料、デバッグ資料を確認します。
プラグインやテーマ固有の問題は、公式ディレクトリのサポート欄、提供元の変更履歴、既知の不具合、対応するWordPress・PHPバージョンを確認します。サーバー操作は契約中のサーバー会社の公式手順を優先してください。
解決策を選ぶときは、「同じエラーメッセージがある」だけでなく、自分の環境、対象バージョン、症状、公開時期が一致しているかを見ます。確認できない情報を根拠に、本番サイトのファイルやデータベースを変更しないことが大切です。
表示崩れは原因を一つずつ減らして安全に復旧する
WordPress更新後の表示崩れでは、最初に症状と影響範囲を記録し、サイトへ変更を加えない確認から始めます。別ブラウザー、端末、ログイン状態、対象ページを比べ、キャッシュ、プラグイン、テーマ、PHP・サーバー環境、独自カスタマイズの順に原因候補を整理します。
バックアップ復元は有力な手段ですが、最新データまで巻き戻す可能性があります。復元対象と取得時刻を確認し、できれば別環境でテストしてください。管理画面へ入れない、重要機能が止まった、バックアップが不明、ファイルやデータベースの編集が必要な場合は、自分だけで操作を重ねず、症状に合う依頼先へ早めに相談するほうが安全です。
復旧後は、更新履歴、バックアップ、検証環境、確認項目を見直します。原因を記録し、次回の更新手順へ反映することで、同じトラブルが起きても短時間で判断しやすいサイト運用へ近づけます。
