WordPressサイトを保守するうえで、SSHとWP-CLIが使える環境はとても心強いです。
サーバーに直接入り、バックアップを取り、プラグインを1件ずつ更新し、問題があれば原因を切り分ける。
こうした作業ができると、保守の安全性はかなり高めやすくなります。
しかし、すべてのWordPressサイトでSSHが使えるわけではありません。
契約プランの制限。
サーバー会社の仕様。
管理権限の不足。
既存クライアントから引き継いだ古い環境。
さまざまな理由で、管理画面からしか触れないWordPressサイトもあります。
では、SSHが使えないサイトは保守できないのでしょうか。
答えは、できることはあります。
ただし、SSHありの保守と同じつもりで考えると危険です。
大事なのは、できること、できないこと、事前に決めておくべきことを分けて考えることです。
SSHが使えると何が違うのか
まず、SSHが使える環境で何ができるのかを整理しておきます。
SSHが使えると、WordPressの管理画面だけに頼らず、サーバー側から状態を確認できます。
- WP-CLIでWordPress本体やプラグインの状態を確認できる
- 更新前にデータベースバックアップを取りやすい
- プラグインを1件ずつ更新しやすい
- 更新後にHTTPステータスを機械的に確認しやすい
- 問題が起きたときに、特定のプラグインだけ戻しやすい
- 管理画面に入れない状態でも、サーバー側から復旧できる場合がある
もちろん、SSHがあれば何でも安全というわけではありません。
それでも、確認や復旧の選択肢が増えるのは大きいです。
特に、更新後に管理画面やサイトが真っ白になったとき、管理画面だけでは何もできなくなることがあります。
SSHがあると、そこで止まらずに対応できる可能性が上がります。
SSHが使えない場合でも、管理画面でできることはある
SSHが使えない場合でも、WordPress管理画面からできる保守作業はあります。
たとえば、次のような作業です。
- WordPress本体の更新
- プラグイン更新
- テーマ更新
- プラグインの有効化、停止
- 管理画面上でのバックアッププラグイン実行
- サイトヘルスの確認
- エラーメールや通知の確認
- 主要ページの表示確認
- 問い合わせフォームの送信確認
小規模なサイトで、構成がシンプルで、バックアップと復旧方法が決まっていれば、管理画面中心でも一定の保守は可能です。
ただし、管理画面からの更新は、失敗時の切り戻しが弱くなりがちです。
更新ボタンを押したあとにエラーが出た場合、どのプラグインが原因か分かりにくいことがあります。
また、管理画面に入れなくなると、そこから先の操作ができません。
この限界を理解したうえで運用する必要があります。
バックアップは「取った」だけでなく「戻せる」ことが大事
SSHが使えない環境では、バックアップの考え方が特に重要です。
バックアッププラグインを入れているから大丈夫、とは言い切れません。
大事なのは、次の点です。
- データベースとファイルの両方を取れているか
- バックアップの保存先が安全か
- バックアップが自動で古くなりすぎないか
- 復元手順を実際に把握しているか
- 管理画面に入れないときでも復元できる方法があるか
管理画面からしか復元できないバックアップだと、管理画面に入れなくなったときに困ります。
サーバーのコントロールパネル、レンタルサーバーの自動バックアップ、FTP、データベース管理画面など、別経路の復旧手段も確認しておきたいところです。
保守で大事なのは、バックアップを作ることだけではありません。
問題が起きたときに、どこから、誰が、どの手順で戻すのかまで決めておくことです。
更新はまとめて押さない方がよい
SSHが使えない環境ほど、更新は慎重に進めた方がよいです。
プラグイン更新が10件あるからといって、全部をまとめて更新すると、問題が起きたときに原因を特定しにくくなります。
できれば、次のように分けます。
- 更新前にバックアップを確認する
- 重要なページを事前に見ておく
- プラグインを少数ずつ更新する
- 更新後に表示と管理画面を確認する
- フォームなど重要機能を確認する
- 問題が出たら、それ以上の更新を止める
管理画面だけの保守では、WP-CLIのように細かく自動化するのは難しいかもしれません。
それでも、「まとめて全部押す」よりは、段階を分ける方が原因を追いやすくなります。
更新は、終わらせることよりも、問題が起きたときに戻れる形で進めることが大事です。
ブラウザ自動操作は補助にはなるが、万能ではない
SSHが使えない環境では、ブラウザ自動操作を使って管理画面の作業を補助する方法もあります。
ログインして、更新画面を開き、ボタンを押し、表示確認をする。
人間がブラウザで行う作業を、ある程度自動化することはできます。
ただし、これはSSHやWP-CLIの完全な代替ではありません。
管理画面の表示が変われば操作が失敗することがあります。
ログイン認証やセキュリティプラグインの設定によって止まることもあります。
更新後に管理画面へ入れなくなれば、その先の操作は難しくなります。
ブラウザ自動操作は、定型作業の補助としては有効です。
しかし、復旧手段として過信しない方がよいです。
SSHなし環境では、契約範囲を明確にする
SSHが使えないWordPressサイトを保守する場合、契約範囲の説明も大事です。
SSHありのサイトと同じ復旧力を保証するのは難しい場合があります。
たとえば、次のような点は事前に共有しておきたいところです。
- 管理画面からできる保守が中心になること
- サーバー側からの即時復旧が難しい場合があること
- バックアップ復元にはサーバー会社の機能を使う可能性があること
- FTPやコントロールパネルの情報が必要になる場合があること
- 緊急時の対応時間がSSHあり環境より長くなる可能性があること
これは弱気な説明ではありません。
できることとできないことを最初に共有することで、トラブル時の混乱を減らせます。
保守は、技術作業だけでなく、期待値の設計でもあります。
可能なら、将来的にはSSHが使える環境へ寄せる
すでに動いているサイトをすぐ移転するのは簡単ではありません。
ただ、長期的に見ると、SSHやWP-CLIが使える環境の方が、WordPress保守はしやすくなります。
特に、次のようなサイトでは検討する価値があります。
- プラグインが多い
- 問い合わせや予約など重要機能がある
- 更新頻度が高い
- 障害時に止まると事業影響が大きい
- 複数サイトをまとめて管理している
- 保守レポートや証跡を残したい
SSHが使えるから良いサーバー、使えないから悪いサーバー、という単純な話ではありません。
ただ、WordPressを長く安全に運用するなら、保守しやすい環境を選ぶことも大切です。
サーバー選びは、表示速度や料金だけでなく、運用時の復旧しやすさも見ておきたいところです。
まとめ
SSHが使えないWordPressサイトでも、保守できることはあります。
管理画面から更新し、バックアップを確認し、主要ページやフォームをチェックする。
こうした基本を丁寧に行うだけでも、放置するよりずっと安全です。
ただし、SSHありの環境と同じ復旧力を期待するのは危険です。
できること。
できないこと。
問題が起きたときの戻し方。
誰がどこまで対応するのか。
これらを最初に整理しておくことが、SSHなし環境の保守では特に重要です。
WordPress保守では、便利な道具があるかどうかだけでなく、制約の中でどこまで安全に進められるかを考える必要があります。
SSHが使えないなら、その前提で無理のない保守設計をする。
それが現実的なWordPress運用だと思います。
