WordPressの手動更新で「wp-content」を上書きしてはいけない理由と、wp-admin・wp-includesを“削除せず上書き”する正しい更新手順を解説。Fatal errorからの復旧経験をもとに、SD-01環境で壊れないWordPress運用法をまとめています。
WordPress手動更新でサイトが壊れた原因はこれだった
wp-contentを触らない理由と、安全に復旧する手順
■ WordPressが突然真っ白になった日
ある日、WordPressの管理画面にアクセスすると――
画面いっぱいに Fatal error。
Interface "WordPress\AiClientDependencies\Psr\SimpleCache\CacheInterface" not found
サイトは真っ白。管理画面にも入れない。
「何が起きた…？」
最初は原因が分かりませんでしたが、Copilotに訊いたらすぐに判明しました。こんな時はAIなら素早く原因がわかり復旧のしかたも指示してくれ安心ですね。
更新途中でファイルの整合性が崩れていた可能性が高いと分かりました。
この経験から、WordPressの手動更新には
“壊れにくくするための基本ルール”があることを実感しました。
■ 手動更新で押さえておきたい基本ルール
結論から言うと、この2つがかなり重要です。
- wp-content は基本的に上書きしない
- wp-admin / wp-includes は「削除せず上書き」が無難
どちらも「絶対」ではありませんが、
トラブルを避けるうえで実用的な考え方です。
■ wp-content をむやみに触らないほうがいい理由
wp-content の中には、
- テーマ
- プラグイン
- 画像（uploads）
- 各種設定データ
など、サイト固有のデータが入っています。
そのため、誤って上書きすると
- カスタムテーマが消える
- プラグインの状態が崩れる
- 画像や設定が失われる
といったリスクがあります。
なお、通常のWordPress本体更新では
wp-contentは更新対象に含まれていません。
つまり、
👉「触らないのが基本」
👉「触るときは意図を持って」
これが安全です。
■ wp-admin / wp-includes は「上書き」が無難な理由
WordPress本体の中核ファイルは
- wp-admin
- wp-includes
に入っています。
これらは更新時に入れ替える必要がありますが、
よくある2パターン
① 削除してからアップロード
- 途中で止まるとサイトが完全停止するリスクあり
② 上書きアップロード
- 不足ファイルだけ補われる
- 途中停止しても復旧しやすい
特に共用サーバーなどでは、
👉 上書きのほうが安全に運用しやすいケースが多い
スポンサーリンク
【▲上記の記事からの続き▼】
と感じました。
■ 「更新成功なのに壊れる」ことは普通にある
今回いちばん厄介だったのがこれです。
更新後に
👉「成功しました」と表示されたのに、実際は壊れている
原因としては、
- ファイル転送の途中停止
- タイムアウト
- プラグインの更新失敗
などが考えられます。
特に、
- ファイル数が多いプラグイン（例：Jetpackなど）
- 転送速度が遅い共用サーバー
では起きやすい印象です。
■ 安全寄りの手動更新手順（実用版）
トラブルを減らすなら、この手順が現実的です。
① WordPress公式から最新版をダウンロード
② ZIPを解凍
③ FTPでアップロード
– wp-admin → 上書き
– wp-includes → 上書き
④ wp-content は基本そのまま
※「既存ファイルを置き換える」を選択
■ 手動更新と自動更新、どちらが安全か
一般的には
👉 管理画面からの自動更新が推奨
です。
ただし、
- 更新が途中で止まりやすい環境
- プラグイン更新でトラブルが多い
こういった場合は、
👉 手動更新のほうが安定するケースもある
と感じました。
■ まとめ：壊れにくい運用の考え方
今回の経験から、重要だと感じたのはこの3つです。
- wp-content は基本触らない
- wp-admin / wp-includes は上書きが無難
- 「成功表示」を過信しない
WordPressは便利ですが、
更新まわりは意外と“壊れポイント”が多いです。
だからこそ、
👉「安全側に寄せた運用」をしておくと安心です。
■ おわりに
今回のトラブルは焦りましたが、
仕組みを理解する良いきっかけにもなりました。
もし同じように
- 更新後に真っ白になった
- 管理画面に入れない
という状況になった方のヒントになれば幸いです。
 |
 |
スポンサーリンク
スポンサーリンク