「WordPressテーマを削除したいけど不安で踏み切れない……」──そんな声をよく聞きます。
例えば、次のような悩みです。
「今のテーマを消してもサイトが壊れませんか?」
「子テーマやカスタマイズはどうなるの?」
「管理画面で削除ボタンが出てこないんだけど…」
「万が一間違って消しちゃったら復元できるの?」
「FTPやWP-CLIでの削除は難しくないですか?」
この導入では、初心者でも安心して実行できる「安全な手順」と「ケース別の判断基準」をわかりやすく示します。
この記事を読めば、ただ削除するだけでなく「なぜ削除するのか」「削除すべきでない場合」「削除前に必ずやるべき準備(バックアップ/ステージング)」がはっきりわかります。
さらに、管理画面/FTP/WP-CLI/ホスティング管理画面それぞれの手順をステップごとに説明し、トラブル時の対処や復旧方法も実務的にカバーします。
この記事のゴールはシンプルです:
「安全に」「確実に」「最小限のリスクで」テーマを整理できるようになること。
まずは、あなたが今抱えている疑問をひとつずつ解消していきましょう。
まずはどんなときにテーマを削除するか(判断基準)
初心者でも判断しやすいように、「削除してよいか」を決めるための明確な条件を示します。
以下は削除を検討する典型的な場面です — あいまいさを避け、実務で役立つ基準だけを書いています。
使っていないテーマを片付けたい場面
削除を検討すべき具体例(すぐ判断できるサイン)
- 数か月または数年まったく有効化していないテーマがある。
- テーマが更新されておらず脆弱性の心配がある(開発が停止している、最終更新日が古い等)。
- サイト移行やクリーンアップで不要なファイルを減らしたい(容量節約やバックアップ軽量化)。
- テストやデモ用に一時的にインストールしていたが、もう使わないことが確定した。
確認してから削除する一連の流れ(簡単チェックリスト)
- 現在の有効テーマか確認(有効中なら削除不可)。
- 子テーマの有無を確認(子テーマがある場合は親テーマは残すべきか検討)。
- バックアップを取得(念のため)。
- ステージングまたはローカルで削除テスト(可能なら)。
ワンポイント:使っていない=即削除、ではありません。依存関係や将来の利用予定がないかを必ず確認しましょう。
テーマを残すべきケース(テスト用・親テーマなど)
削除してはいけない、または残しておいた方が良い代表的ケースです。ここは削除しない理由を明確に示します。
- 親テーマ(Parent theme)
- 子テーマ(Child theme)が存在する場合、子テーマは親テーマのテンプレートや関数を参照します。親テーマを消すと子テーマが機能しなくなります。
- 子テーマ(Child theme)
- 子テーマ自体を消すのはレイアウトやカスタマイズを失うリスクがあるため慎重に。
- テスト用 / 開発用テーマ
- 本番サイトで即座に切り替えるためのテストテーマは残しておくと便利(ただし古くなったら更新や入れ替えを検討)。
- デフォルト系のテーマ(例:Twenty系)を1つだけ残すことの利点
- トラブル時に素早く切り替えられるので、最低1つは安定したデフォルトテーマを残すのが安全策。
- プラグインやカスタムコードで依存しているテーマ
- 特定の機能がそのテーマに依存している場合、削除すると機能が停止する可能性があるため確認が必要。
判断ルール:
- 「サイト運用に必要」または「他に代替がない」ものは残す。
- 「不要で代替がある」ものは削除検討。
マルチサイトや特別設定で注意が必要な場合
マルチサイト(Network/マルチサイト)やホスティング特有の設定がある環境では、通常の単一サイトとルールが異なります。ここでは必ず気を付けるポイントだけを整理します。
マルチサイト特有の注意点
- テーマはネットワーク管理者の権限で管理されるため、サイト個別で勝手に削除できない場合があります。
- あるテーマを「ネットワーク有効化」していると、複数サイトが同じテーマを参照している可能性がある。削除前にどのサイトがそのテーマを使っているか確認しましょう。
- 子サイトでカスタマイズがある場合、親テーマを消すと複数サイトに一斉に影響が出ます。必ず影響範囲を洗い出すこと。
ホスティング/環境に依存するケース
- 一部のホスティングでは管理画面でテーマファイルを直接編集・削除できないことがあります(コントロールパネル経由やサポート依頼が必要)。
- 自動デプロイやバージョン管理(Gitなど)でテーマを管理している場合は、単純にコントロールパネルで消すとリポジトリとの差分が生じるため、運用ルールに従って削除すること。
マルチサイトでの安全手順(推奨)
- ネットワーク管理画面でテーマの利用状況を確認(どのサイトで有効化されているか)。
- 影響を受けるサイトの管理者に通知(少なくとも事前連絡)。
- ステージングで削除テスト(マルチサイト環境がある場合は必須)。
- ネットワーク管理者権限で削除するか、削除不可ならテーマを非表示(ネットワーク有効化解除)する。
- 削除後に各サイトの表示・機能を確認する。
判断を助ける短い早見表(条件 → 推奨アクション)
| 条件(見た目で判断) | 推奨アクション | 補足 |
|---|---|---|
| まったく使っていない、更新も停止 | 削除を検討 | バックアップ必須 ✅ |
| 子テーマがある親テーマ | 残す(要確認) | 子テーマ依存に注意 ⚠️ |
| テスト用で再利用予定あり | 保留または非表示 | 削除は最後の手段 |
| マルチサイトで複数サイトが使用 | ネットワーク管理者と調整 | 事前通知とステージング推奨 |
| デフォルトテーマが複数残っている | 1つは残す | トラブル復旧用に便利 🛠️ |
最後に(初心者向けアドバイス)
- まずは「本当に不要か」を冷静に確認しましょう。思い付きで削除すると復旧が面倒です。
- バックアップとステージングが最も重要:これだけは省かないでください。
- 削除後の確認項目(表示、ウィジェット、メニュー、プラグイン連携)は忘れずにチェックしましょう。✔️
削除しておいたほうが望ましい理由(メリット)
テーマを整理して不要なものを削除することには、ただ見た目がすっきりする以上の実務的な利点があります。
以下は初心者にもわかりやすく整理したメリットの説明です。
セキュリティリスクの低減
- 攻撃対象が減る:使っていないテーマにも古いファイルや脆弱性が残っている可能性があります。不要なテーマを放置すると、管理画面や公開側のファイル経由で攻撃者に狙われるリスクが増えます。削除することで攻撃対象(=エントリポイント)を減らせます。 🔒
- アップデート漏れの懸念を減らす:多数のテーマを置いていると「どれを更新すべきか」の管理が煩雑になり、結果として更新忘れ→脆弱性放置、という流れになりがちです。不要なテーマを削除すれば管理対象が減り、セキュリティ対策が確実になります。
- 運用上の注意:親テーマや復旧用に残す1つは別ですが、本当に不要なものは削除しておきましょう。
更新や管理の手間を減らす利点
- メンテナンス作業がシンプルに:テーマごとに「更新の有無」「互換性」「バグ情報」をチェックする必要があると、作業が膨らみます。不要テーマを削ることで、日常の管理作業(更新確認・テスト・互換チェック)が少なくなります。✨
- 誤操作や混同のリスク低下:テーマが大量にあると、誤って別のテーマを編集したり、間違ったテーマを有効化してしまう可能性があります。テーマ数を絞ればヒューマンエラーも減ります。
- 管理者画面の負担軽減:テーマ一覧が短くなるため目的のテーマを見つけやすく、操作時間が短くなります。
サイトの動作やサーバー容量への好影響
- ストレージ節約になる:使わないテーマフォルダ(テンプレート、画像、スクリプトなど)はサーバー容量を消費します。削除すればディスク使用量が減り、バックアップやスナップショットも軽くなります。💾
- バックアップ/復元が速く・確実に:バックアップ対象が少ないほど処理が速く、復元時の失敗リスクも少なくなります。
- スキャンや保守処理の負荷軽減:ウイルススキャンやセキュリティスキャン、ファイル差分チェックなどは対象ファイル数に依存します。不要ファイルを減らせばこれらの処理も効率化します。
- 表示速度への直接効果は限定的だが間接効果はある:通常、使っていないテーマのファイルはフロントエンドのリクエストで読み込まれません(したがって直接の表示速度改善は限定的)が、不要ファイルを減らすことでバックエンド処理や運用負荷が下がり、結果としてサイト管理全体の健全性が高まります。
まとめ(短いチェックリスト)
- 不要テーマは削除:セキュリティと管理コストの削減に直結。
- ただし親テーマや復旧用の1つは確保:万一のために安定したデフォルトテーマは残しておく。
- 削除前にバックアップを必ず取る:作業ミスや予期せぬ不具合に備えて。✔️
表:メリットの要約
| メリット | 期待できる効果 |
|---|---|
| セキュリティ向上 | 攻撃対象減少、脆弱性放置の防止 |
| 管理負荷低減 | 更新管理・誤操作のリスク低下 |
| サーバー負荷軽減 | ディスク節約・バックアップ高速化 |
削除前に必ず行う準備(安全対策)
テーマを削除する前の準備は「失敗したときに元に戻せること」を確実にするための作業です。
ここでは初心者でも実行しやすい手順とチェックリストをわかりやすくまとめます。
各項目ごとに実行手順と注意点を示します。
事前にデータを保全する(バックアップ)
目的:削除で問題が起きたときに、すぐに復旧できるようにする。
推奨する基本手順(初心者向け)
- ファイルのバックアップを取得する
wp-contentフォルダ(特にthemes、uploads)を丸ごとダウンロードする。- 方法:FTP/SFTP クライアントでダウンロード、またはホスティングのファイルマネージャーで圧縮して取得。
- データベースをエクスポートする
- phpMyAdmin やホスティングの DB 管理ツールで SQL をエクスポート。
- エクスポートオプションは「構造とデータ」の両方を選ぶ。
- バックアップの検証
- ダウンロードしたファイルが開けるか、SQL ファイルをエディタで確認する(サイズ・無効文字など)。
- バックアップを安全な場所に保管
- ローカルとクラウド(外部ストレージ)の2箇所以上に保存する。
- 復旧フローを用意する
- 「復元手順」をメモしておく(どのファイルをどの場所に置くか、DBのインポート手順など)。
バックアップ方法の比較
| 方法 | 長所 | 短所 |
|---|---|---|
| プラグイン(例:バックアップ系) | ワンクリックで簡単、自動化できる | プラグイン依存・一部有料機能あり |
| FTP + phpMyAdmin(手動) | 細かく制御できる、学習になる | 手間がかかる・操作ミスのリスク |
| ホスティングのバックアップ機能 | 簡単で速い、復元が容易 | ホスト依存・無料帯は履歴が短い場合あり |
ワンポイント:バックアップは「取って終わり」ではなく、復元できるかをテストしておくと安心です。🔁
ステージング環境での事前検証
目的:本番サイトに影響を与えずに、テーマ削除後の挙動を確認する。
選べる方法(初心者向け)
- ホスティングのステージング機能:ほとんどのレンタル型ホスティングは1クリックで複製できる。
- ローカル環境でのテスト:Local、XAMPP などを使い、本番と同じデータをローカルに復元して試す。
- 一時クローンサイトを作る:別サブドメインやサブフォルダにコピーして検証する。
検証でやるべきチェック項目(必須)
- サイトの主要ページ(トップ、代表ページ、投稿、固定ページ)が正常表示されるか。
- ヘッダー/フッター/サイドバーの表示崩れがないか。
- ウィジェット、メニュー、ショートコード、カスタム投稿の挙動確認。
- フォームや決済など重要な機能が動くか。
- レスポンシブ(スマホ表示)で崩れがないか。
- キャッシュ系やセキュリティプラグインの動作に影響がないか。
ステージング後の反映手順
- ステージングでテーマ削除 → 全チェックを通す。
- 問題なければ本番で同操作(またはホスティングの「ステージング→本番反映」機能を使う)。
- 本番で再度最終チェック。✅
ワンポイント:本番で直接作業するのは避け、必ずステージングで確認するのが安全です。🛡️
親子テーマやカスタマイズの有無を確認する
目的:親テーマを誤って削除して子テーマやカスタマイズを壊さないようにする。
確認すべきポイントと手順
- 子テーマの存在確認
- 管理画面の「外観 > テーマ」で子テーマがあるか確認。
- 子テーマの
style.cssにTemplate:(親テーマ名)が書かれていることが多い。
- カスタマイズ保存場所の特定
- カスタマイザー(外観 > カスタマイズ)で加えたカスタムCSSや追加コードは、テーマ側に保存されている場合がある。エクスポート/メモを取る。
- functions.php や独自テンプレートのチェック
- テーマにある
functions.phpやテンプレートファイルに重要なコードがないか確認(例:ショートコード定義、カスタム投稿の登録など)。必要ならコードをコピーして別の場所にバックアップ。
- テーマにある
- プラグイン依存の確認
- 一部のテーマは専用プラグインやテーマ独自の設定を必要とする場合がある。テーマ依存のプラグインが存在するか確認し、必要なデータをエクスポートする。
- ウィジェットやメニューのエクスポート
- ウィジェットの設定はテーマ切替で消えることがある。ウィジェットエクスポートプラグインやスクリーンショット、設定メモを残すと復旧が速い。
注意ルール:
- 子テーマがある場合、親テーマは消さない(または慎重に対応)。
- カスタマイズ済みのコードは必ず別保存する。
SEOやプラグイン連携の影響確認(チェックリスト)
目的:テーマ削除が SEO やプラグインの設定・出力に悪影響を与えないようにする。
確認すべき項目(チェックリスト)
- サイトマップ(sitemap.xml):SEO プラグインが生成している場合、テーマによる差分がないか確認。
- メタデータ・構造化データ(schema):テーマが追加しているスキーマがあると、削除で出力が消える可能性あり。
- SNSカード(OGタグ)・Twitterカード:テーマが OG を出力していないか、削除後に SNS シェア表示が崩れないかチェック。
- パーマリンク・canonical・リダイレクト:テーマ固有のリダイレクト設定や canonical がないか確認。
- ページビルダーのテンプレート(Elementor、Beaver 等):テーマがテンプレートを保持している場合、削除でテンプレートが消える可能性がある。
- プラグイン連携(フォーム、Eコマース等):テーマ依存のテンプレート(商品ページテンプレート等)があると影響範囲が広い。
- robots.txt / .htaccess:テーマで生成や推奨が行われている場合は内容を記録しておく。
実務的な対策
- SEOプラグインの設定をエクスポート(可能なら)。
- 構造化データの出力箇所を特定(テーマかプラグインか)。テーマ由来なら、削除前に同等の出力をプラグインで準備する。
- ページごとの重要なメタ(タイトル/ディスクリプション)を確認:カスタムフィールドなどで出力している場合は注意。
- リダイレクト一覧・重要なURL を記録しておく。
- 削除後に Search Console 等でクロールエラーを監視する(削除直後〜数日間は注視)。
チェック表
- [ ] sitemap.xml が正常に生成される
- [ ] 主要ページの OG / Twitter カードが表示される
- [ ] 重要なプラグイン(フォーム・EC・SEO)が動作する
- [ ] pagebuilder テンプレートが消えない/移行済みである
- [ ] リダイレクト設定を記録した
最後に(作業前の短いまとめ)
- バックアップ(ファイル+DB)を必ず取り、復元方法を確認する。
- ステージング環境で必ずテストしてから本番で作業する。
- 親子テーマやカスタマイズの依存関係を洗い出す(親テーマを誤って削除しない)。
- SEO・プラグイン連携を事前にチェックして、必要なら代替措置を準備する。
実際の削除方法(手順別)
ここでは初心者でも安全に実行できる具体的手順をわかりやすく説明します。
各方法の長所・短所も表で比較するので、自分の環境に合った方法を選んでください。
作業前は必ずバックアップを取ってください。⚠️
管理画面(ダッシュボード)から取り除く手順
概要:最も簡単で安全な方法。WordPress管理画面からテーマ詳細を開き、削除ボタンでアンインストールします。
手順(初心者向け)
- 管理画面にログインする。
- サイドメニューから「外観」→「テーマ」を開く。
- 現在有効なテーマ以外(削除したいテーマ)にマウスを合わせてクリック → 「テーマの詳細」を開く。
- 右下にある「削除」ボタンをクリックする。確認ダイアログが出たら同意して削除。
- 注意:有効化中のテーマはこの方法で削除できません。別のテーマを先に有効化してください(後述の「新しいテーマの有効化や切替え」参照)。
- 削除後、サイト表示(トップページ・代表ページ)を確認し、問題がないかチェックする。
- キャッシュ系プラグインを使っている場合はキャッシュをクリアする。
よくある問題と対処
- 「削除」ボタンが見当たらない:そのテーマがネットワーク有効化(マルチサイト)されているか、またはファイル権限が原因の可能性があります。ホスティング管理者に確認するか、別の方法(FTPなど)を使います。
FTP / SFTP を使ってテーマフォルダを削除する方法
概要:管理画面が使えない・削除ボタンが出ない時の方法。テーマフォルダを直接削除します。ややリスクがあるため、まずはフォルダをリネームして動作確認することを推奨します。
準備:FTP/SFTPクライアント(FileZillaなど)/サーバー接続情報(ホスト・ユーザー名・パスワード/鍵)
手順
- FTP/SFTPでサーバーに接続。
- WordPressのルートディレクトリへ移動(
wp-config.phpがある場所)。 wp-content/themes/フォルダを開く。- 削除したいテーマのフォルダ名を一旦リネームする(例:
twentytwentyone→twentytwentyone_backup)。- これで本番サイトに表示影響がないか確認。問題なければ次へ。
- 安全が確認できたら、リネームしたフォルダを削除する(クライアントの右クリック→削除)。
- 注意:削除前に必ずローカルへダウンロードしてバックアップを残す。
- 削除後、サイトの表示・機能をチェックし、キャッシュをクリアする。
安全ワンポイント:いきなり rm -rf などで削除するより、まずリネームして様子を見ると復旧が楽です。🛟
ホスティングのファイルマネージャ(コントロールパネル)での削除
概要:ホスティングの管理画面(cPanel、Plesk、さくら/ConoHa等のファイルマネージャ)から操作する方法。FTPよりGUIで簡単な場合が多いです。
手順
- ホスティングの管理画面にログイン。
- ファイルマネージャーを開き、WordPressのルートディレクトリへ移動。
wp-content/themes/を開く。- 削除したいテーマフォルダを選択し、まず圧縮(zip)してダウンロードしておく(バックアップ)。
- 圧縮を確認したらフォルダを削除する。
- サイトを確認、必要ならキャッシュクリア。
注意点:一部ホスティングはファイル権限や保護機能で削除を制限していることがあります。削除できない場合はサポートに相談してください。
WP-CLI を使ったコマンド操作で削除する方法
概要:コマンドラインから素早く安全にテーマ管理ができる方法。サーバーにSSHアクセスとWP-CLIがある環境で有効。慣れている人向けですが、手順通りにやれば初心者でも使えます。
事前確認:SSHでサーバーに接続可能で、WP-CLIがインストールされていること。作業前に必ずバックアップ。
基本コマンド例
# インストールされているテーマ一覧を確認
wp theme list
# テーマを削除(例: twentytwentyone を削除)
wp theme delete twentytwentyone
安全な流れ(推奨)
- SSHでサーバーにログインし、WordPressのルートディレクトリへ移動。
wp theme listで現在のテーマ一覧・状態(active/inactive)を確認。- 削除するテーマが inactive(非有効) であることを確認。もし
activeなら別のテーマを有効化する:
wp theme activate twentynineteen
- 削除コマンドを実行:
wp theme delete <theme-slug>
- 削除後、
wp cache flushやウェブキャッシュをクリアして動作確認。
ワンポイント:WP-CLIはログに残るため、作業履歴を追跡しやすいです。自信がなければまずは wp theme status <slug> などで情報を確認してください。
新しいテーマの有効化や切替えを先に行う手順
概要:現在使用中のテーマは削除できません。削除前に安全な別テーマを有効化する必要があります。ここでは管理画面・WP-CLIそれぞれの手順を説明します。
管理画面での切替手順
- 「外観」→「テーマ」を開く。
- 削除予定のテーマ以外のテーマ(例:デフォルトのTwenty系)を選び、「有効化」をクリック。
- 切り替え後にトップページなどを確認して、大きな崩れがないかをチェック。問題なければ古いテーマを削除。
WP-CLIでの切替手順
# 切替可能なテーマ一覧確認
wp theme list
# テーマを有効化(例: twentynineteen を有効化)
wp theme activate twentynineteen
切替え時のチェックポイント
- 有効化直後に表示崩れ・ウィジェット欠損・ショートコードのエラーなどがないか確認する。
- 切替えで機能が壊れた場合は、ステージング環境で事前に検証するか、バックアップから復元できるようにしておく。
- 切替え用に軽量で互換性の高いデフォルトテーマ(例:Twenty系)を準備しておくと安心。
各方法の比較(早見表)
| 方法 | 必要な権限・環境 | 初心者向け度 | 安全性 | 備考 |
|---|---|---|---|---|
| 管理画面 | WP管理者権限 | ★★★★★ | ★★★★★ | 最も簡単、安全。 |
| FTP/SFTP | サーバー接続情報 | ★★★★☆ | ★★★★☆ | GUIで手動操作、リネーム→確認推奨。 |
| ファイルマネージャ | ホスティング管理画面 | ★★★★☆ | ★★★★☆ | ホスティング依存。圧縮してから削除推奨。 |
| WP-CLI | SSH + WP-CLI | ★★★☆☆ | ★★★★★ | コマンド慣れがあれば最速で安全。 |
削除後に行うべき最低限のチェックリスト
- [ ] サイトの代表ページ(トップ・投稿・固定ページ)を表示確認
- [ ] ウィジェット・メニューの崩れを確認
- [ ] フォーム・EC・ログイン等の重要機能を確認
- [ ] キャッシュ(ブラウザ/プラグイン/CDN)をクリア
- [ ] 必要ならバックアップからの復旧手順をメモしておく
最後に(安全のための一言)
まずはバックアップ → ステージングでテスト → 本番で削除の順で作業するのが最も安全です。
どの方法を使うか迷ったら管理画面での削除(+事前に別テーマへ切替)を推奨します。
削除後に必ず確認すべき項目(検証と復旧)
テーマを削除したら「見た目が崩れていないか」「機能が壊れていないか」をページ単位で確実に確認し、必要なら速やかに復旧できる準備をします。
表示崩れや機能不具合の検証(ページ単位でチェック)
やること(順番に)
- 主要ページを優先確認
- トップページ、代表的なカテゴリページ、製品/サービスページ、問い合わせページ、投稿ページをまず見る。
- ページ単位でのチェック項目
- ページが正常に読み込まれるか(500/404 エラーが出ていないか)
- レイアウト崩れ(ヘッダー/フッターやカラム崩れ)
- 画像やアイコンが表示されるか
- JavaScript エラー(ブラウザのデベロッパーツールで確認)
- フォーム・検索・カートなどのインタラクティブ機能が動作するか
- スマホ・タブレット表示の確認
- ブラウザのレスポンシブ表示機能でスマホ表示も確認する。
- 速度とキャッシュ確認
- キャッシュをクリアして再確認(キャッシュが古いと誤検知するため)。
- ログとエラーメッセージの確認
- サーバーのエラーログや WordPress のデバッグログ(
WP_DEBUG)を短時間有効にして異常がないか確認する。
- サーバーのエラーログや WordPress のデバッグログ(
チェックのコツ:ひとつのページで問題が見つかったら、そのページに使われているテンプレート(single.php / page.php / header.php など)を中心に原因を辿ると効率的です。🔍
カスタマイズ設定・ウィジェット・メニューの復元確認
確認項目と復元方法(具体的)
- ウィジェット
- 確認:サイドバー・フッターのウィジェットが消えていないか。
- 復元:ウィジェットはテーマ切替で位置が変わることが多い。ウィジェットの設定をプラグインでエクスポートしていればインポートするか、手動で再配置する。
- メニュー
- 確認:ヘッダーナビやフッターナビの配置・リンクが正しいか。
- 復元:外観 → メニューで表示位置を再設定し、リンクが壊れていないか確認。
- カスタマイザーの設定(外観 → カスタマイズ)
- 確認:ロゴ、カラースキーム、追加CSS、ヘッダー設定等が消えていないか。
- 復元:カスタマイザーのエクスポート機能(プラグイン)や、カスタムCSSを手元に保管している場合は貼り付ける。
- テーマ固有のオプション
- 確認:テーマオプションページに設定が残っているか(多くはテーマフォルダ内に保存)。
- 復元:必要ならテーマを再インストールしてオプションを再適用、あるいは手元バックアップから設定ファイルを戻す。
短いワンポイント:ウィジェットやメニューは「テーマ依存の位置」を参照しているだけでデータ自体はデータベースに残ることが多いです。位置を再割当てすれば復元できる場合が多いです。🔁
画像やダミーコンテンツ、不要ファイルの整理
目的:不要ファイルを削除してディスクを節約し、本当に必要な画像だけ残す。だが間違って必要なファイルを消さないことが最優先。
手順(推奨)
- uploads フォルダを確認(
wp-content/uploads/)- ここにある画像はテーマに直接依存しないことが多い。日時やフォルダ名で不要なものを特定する。
- ダミーコンテンツの検索
- テーマ付属のデモ画像やサンプル記事は
themes/<theme>/内にあることがある。テーマ削除で不要になっているなら削除してよい。
- テーマ付属のデモ画像やサンプル記事は
- 未使用メディアの特定
- プラグイン(メディア管理系)を使うか、手動で HTML ソースと uploads を突き合わせて未使用ファイルを特定する。
- バックアップを取りながら削除
- 削除は一括で消すのではなく、まず圧縮して別場所へ保存 → 一週間程度問題なければ完全削除する方法が安全。
- キャッシュ/CDN のファイル確認
- CDN を使っている場合、CDN 上に残る古いファイルは別途 purge(消去)する必要がある。
注意点:画像は記事内で参照されていないように見えても、プラグインやテーマの設定で使われている場合があります。削除は慎重に。🗂️
削除したテーマを戻す(復元)方法:バックアップからの復旧/再インストール
A. バックアップから完全復旧(ファイル+DBがある場合)
手順(手動)
- ファイルを戻す
- FTP/SFTP またはホスティングのファイルマネージャで、
wp-content/themes/にテーマフォルダをアップロード(または復元)。
- FTP/SFTP またはホスティングのファイルマネージャで、
- データベースを戻す(必要なら)
- phpMyAdmin などで SQL をインポート、または
wp db import backup.sql(WP-CLI)を実行。 - ※DBを丸ごと戻すと、その時点以降の投稿等が失われる可能性があるので注意。
- phpMyAdmin などで SQL をインポート、または
- 権限とキャッシュのクリア
- ファイル権限を確認し、キャッシュをクリア。
- テーマを有効化(管理画面または
wp theme activate <slug>) - 最終確認:表示・機能をチェック。問題なければ復旧完了。
B. テーマを再インストールして設定を復元(ファイルのみ/DB不可)
- テーマファイルを入手(手元の zip か配布パッケージ)
- 管理画面から再インストール:外観 → テーマ → 新規追加 → テーマのアップロード → インストール → 有効化。
- または FTP で
wp-content/themes/に展開。
- または FTP で
- カスタマイザーやテーマオプションの再設定(バックアップがあればインポート)。
- ウィジェット/メニューの再配置(必要に応じて復元)。
C. WP-CLIを使った復元(上級だが速い)
# ローカルにあるテーマzipをインストール
wp theme install /path/to/theme.zip --activate
# またはテーマをダウンロードしてインストール
wp theme install twentytwentyone --activate
ワンポイント:完全復旧(ファイル+DB)が可能ならそれが最も確実。ただしDBを戻す場合は最新投稿の損失等を考慮して、必要部分だけを復旧する方法(テーブル単位のインポートや差分復元)を検討する。🔧
最後に:作業を安全に終えるための短いチェックリスト
- [ ] 主要ページ(PC/スマホ)を確認して表示崩れなしを確認した
- [ ] 重要機能(フォーム・EC・ログイン等)が正常に動作することを確認した
- [ ] ウィジェット・メニュー・カスタマイズが期待通りに復元されていることを確認した
- [ ] 不要な画像やデモファイルをバックアップ後に整理した(すぐ消さない)
- [ ] 復元方法(バックアップの場所・手順)をメモしておいた
一言アドバイス:復旧は「焦ってやると二重に手間が増える」ことが多いです。まずは冷静に影響範囲を特定 → バックアップ → 復元の順を守ってください。
テーマに関連するコンテンツの整理(削除すべきもの)
テーマを削除する前後に、テーマ固有で残りがちな「コンテンツ」や「ファイル」を整理すると安全です。
ここではそれぞれの項目を「何を確認するか」「実際の手順」「注意点」の順でわかりやすく解説します。
ウィジェットの整理・削除
何を確認するか
ウィジェットはテーマによって表示場所やスタイルが変わります。テーマを消すとウィジェットの位置(サイドバーやフッター)がリセットされることがあるため、設定内容そのものが消えるわけではないが配置が変わる点を確認します。
実際の手順(安全な流れ)
- 管理画面 → 外観 → ウィジェット を開く。
- 各ウィジェットの内容(タイトル、テキスト、ショートコード、カスタムHTML)をスクリーンショットかテキストで保存する。
- 使わないウィジェットは削除、必要だが位置を変えたくないものはカスタムHTMLとしてエクスポート(コピー)しておく。
- テーマを切り替えた後、ウィジェット配置が崩れたら保存済みの内容を再配置する。
注意点・ワンポイント
- ウィジェットの設定はデータベースに残るケースが多いですが、表示領域(ウィジェットエリア名)がテーマ固有だと「どこに表示するか」が無くなります。配置情報を控えておくと復旧が速いです。🧩
ナビゲーション(メニュー)の見直し
何を確認するか
メニュー(外観 → メニュー)はテーマが登録する「表示位置」に依存します。テーマを削除すると、表示位置が変わりメニューが出なくなることがあります。
実際の手順
- 管理画面 → 外観 → メニュー を開き、現在のメニュー構成を確認。
- 主要メニュー(ヘッダー・フッター等)のリンク一覧をエクスポート(コピー)しておく。
- 新テーマに切り替えたら、メニューの「表示位置」を再割当てする。
- メニュー内のリンク先(カスタムリンク、カテゴリ、固定ページ)が壊れていないか確認する。
注意点・ワンポイント
- メニューはテーマ間で互換性が高いですが、表示位置名が異なると手動で再割当が必要になります。移行時は順番や階層(ドロップダウン)が崩れていないかも確認しましょう。📋
サイトに残るダミー記事やサンプルデータの削除
何を確認するか
テーマのデモインストールで追加された「サンプル記事」「サンプルページ」「テスト用投稿」「例のカスタム投稿タイプ」が残っているとSEO上の冗長や混乱を招きます。
実際の手順
- 投稿一覧・固定ページ・カスタム投稿を一覧で確認し、明らかにデモ用とわかるものをピックアップ。
- 各記事の公開ステータス(公開/下書き)と公開日を確認して、本当に不要か判断する。
- 不要なら「ゴミ箱」へ移動。大量にある場合は一括操作で削除。
- 削除後、サイトマップや内部リンクに残骸がないかチェック(リダイレクトが必要なら設定)。
注意点・ワンポイント
- デモコンテンツは画像やカスタムフィールドを大量に含むことがあります。先にバックアップを取り、重要なコンテンツを誤って消さないようにしてください。⚠️
テーマに紐づく画像や不要ファイルの削除
何を確認するか
テーマフォルダ内にあるデモ画像、アイコン、フォント、JS/CSS(テーマ独自のライブラリ)や、wp-content/uploads/ に残った使われていないメディアを整理します。
実際の手順(安全な順番)
- テーマフォルダの確認(FTP またはホスティングのファイルマネージャ)
wp-content/themes/<theme>/内のassetsやimagesフォルダにデモ画像が残っていれば、テーマ削除で同時に消えます。必要なファイルがないか先にチェック。
- メディアライブラリで未使用を探す
- 管理画面 → メディアライブラリ で「未添付( unattached )」や日付で絞って確認。
- 安全に削除する手順
- 1. 未使用と判断したファイルは一旦別フォルダへ移動/圧縮保存(バックアップ)
- 2. サイトに問題が出ないことを数日確認後、完全削除する
- CDN/キャッシュのクリア
- CDNを利用している場合は、削除後にキャッシュをパージして古いファイル参照を消す。
ツールの活用(一般的な提案)
- 未使用メディアの特定は手動でも可能ですが、数が多い場合は専用のメディア整理ツールを使うと効率的です(プラグインを使う場合は動作やバックアップ機能を確認してから)。
注意点・ワンポイント
- 画像が記事内で使用されている場合、ファイル名やパスが同じでもテーマ変更で表示方式が変わることがあります。まずはバックアップ → 移動→検証→削除の流れを守ってください。🗂️
まとめと実務チェックリスト
先にやること(準備):バックアップ(ファイル+DB)を必ず取る。
整理の順序(推奨):ウィジェット → メニュー → ダミー記事 → 画像・不要ファイル。
短いチェックリスト
- [ ] ウィジェット内容を保存(スクショやテキスト)した
- [ ] メニュー構成をコピーして保管した
- [ ] デモ・ダミー記事を識別してゴミ箱に移した
- [ ] 未使用メディアをバックアップしてから移動/削除した
- [ ] CDN/キャッシュをクリアし、表示を最終確認した
最後に一言:
整理作業は「削除する前の確認」と「削除後の検証」を丁寧に行えば安全です。時間がある場合は一つずつ小さく進める(小さな単位でバックアップ→削除→確認)と復旧が楽になります。
削除できない・失敗する場合の原因と対策(トラブルシューティング)
テーマ削除でつまずいたとき、原因を素早く切り分けて対処すれば被害を最小化できます。
ここでは原因→確認方法→具体的対策の順で、初心者にも実行しやすい手順だけをまとめます。
削除ボタンが表示されないときの原因と解決策
主な原因(チェック項目)
- そのテーマが現在有効化されている
- マルチサイトでネットワーク有効化されている(削除不可)
- ファイル/ディレクトリのパーミッション(権限)や所有者が不適切で、WordPressがファイル操作できない
- セキュリティプラグインやカスタムコードがUIを隠している
- テーマのフォルダがサーバ側で読み取り専用になっている
確認方法
- 管理画面でそのテーマが active(有効) か確認。
- マルチサイトならネットワーク管理画面で ネットワーク有効化 の状態を確認。
- FTP/ファイルマネージャで
wp-content/themes/<theme-folder>の所有者(owner)・パーミッションを確認。 - セキュリティ系プラグイン(Wordfence 等)を一時無効化してUIが回復するか試す。
具体的解決策
- 有効テーマなら別テーマを有効化する(管理画面 or WP-CLI)。
wp theme activate twentytwentyone
- マルチサイト:ネットワーク管理者でログインし、ネットワーク有効化を解除するか、削除はネットワーク管理画面から行う。
- 権限問題:FTPまたはSSHでファイル権限を適切に戻す(ホスティングの仕様に合わせて実行)。一般的には:
# 例:WordPress の所有者が www-data の場合
sudo chown -R www-data:www-data /path/to/wordpress/wp-content/themes/<theme-folder>
sudo find /path/to/wordpress/wp-content/themes/<theme-folder> -type d -exec chmod 755 {} ;
sudo find /path/to/wordpress/wp-content/themes/<theme-folder> -type f -exec chmod 644 {} ;
※ コマンドはホストによって適切な所有者名が異なります。実行前にホスティング指示を確認してください。
- UI を隠しているプラグインが疑わしい場合:セキュリティ/カスタム管理プラグインを一時停止して確認。
- 代替手段:管理画面で無理なら FTP / ホスティングのファイルマネージャ / WP-CLI で直接削除する。
「削除に失敗しました」等のエラー対応手順
一般的な原因
- サーバーのディスク容量不足
- ファイルがロックされている(プロセスが使用中)
- ファイルシステムが読み取り専用に切り替わっている
- 権限不足(Web サーバー側のユーザーに削除権限がない)
- WP-CLI / 管理画面のタイムアウトや PHP 制限(メモリ/実行時間)
対処フロー(優先度順)
- ディスク容量を確認(ホスティング管理画面や
df -h)- 空き容量が少ない場合、不要ファイルを一時削除して容量を確保。
- 権限と所有者の確認(上記の chown/chmod を参照)
- プロセスまたはロックの確認(可能ならサーバーサポートへ依頼)
- プラグイン干渉の切り分け:セキュリティ系を一時停止して再試行。
- タイムアウト/メモリ不足:PHP の
max_execution_timeやmemory_limitを一時的に緩めるか、WP-CLI で実行(CLI なら PHP 制限に影響されにくい)。 - 別ルートで削除:FTP でダウンロード→ローカルに保管→フォルダをリネーム→削除。WP-CLI が使えるなら
wp theme delete <slug>を試す。
wp theme delete twentytwentyone
- ホスティングサポートへ連絡:上記で解決しない場合は、ログ確認や権限修正を依頼する。
エラー例と対処(早見表)
| 表示される文言 | 可能性の高い原因 | 対処 |
|---|---|---|
| 「削除に失敗しました」 | 権限・ロック・ディスク不足 | ディスク/権限確認 → FTP/WP-CLI で削除 |
| パーミッションエラー | 所有者違い・読み取り専用 | chown/chmod またはホスト依頼 |
| タイムアウト系エラー | PHP実行時間不足 | WP-CLI で実行 or PHP設定を調整 |
削除しても画面が変わらない場合のチェックポイント
考えられる理由
- 削除は成功しているがキャッシュ(ブラウザ/プラグイン/CDN)が古いファイルを返している
- 実際に削除されていない(操作が失敗している)ためサーバー上にテーマファイルが残っている
- 別のテーマ/プラグインが同じテンプレートや CSS を出力している(見た目が維持される)
- サイトは子テーマやページビルダー(Elementor等)でテンプレートを保持していて見た目が変わらない
- 負荷分散環境や複数サーバーのうち一部だけ操作したため不整合が発生している
確認手順(順序立てて)
- ブラウザキャッシュをクリア(Ctrl+F5 等)および、管理画面のキャッシュ系プラグインをクリア。
- CDN を利用している場合は purge(キャッシュ消去)。
- FTP/ホスティングで該当テーマフォルダが本当に消えているか確認。
- サイトの HTML ソース(ブラウザで右クリック → ソース表示)を見て、読み込まれている CSS/JS のパスがどこから来ているか確認(
/wp-content/themes/<theme>/が無いか)。 - プラグインによる出力を疑う:一時的にページビルダーやキャッシュ系以外のプラグインを無効化して変化を確認。
- 複数サーバー運用なら全サーバーで同じ操作が行われたか確認(デプロイ方式や同期方法に依存)。
ワンポイント:見た目が変わらないのは必ずしも「削除が効いている」ことを意味しません。ファイル存在確認 → キャッシュクリア → ソース確認の順で原因を潰していきましょう。🔎
使用中/親テーマを誤って消さないための注意点
危険なミス
- 子テーマ(child)を使っているのに親テーマ(parent)を削除してしまうと、子テーマが壊れてサイトが表示不能になる。
- マルチサイト環境で親テーマを消すと複数サイトで大規模障害になる。
事前チェック(必須)
- 子テーマがあるかを確認:管理画面の「外観 > テーマ」で child theme を探す。
- またはテーマフォルダの
style.cssを開き、Template: parent-theme-slugがあるか確認。
- またはテーマフォルダの
- テーマの使用状況を確認:
wp theme list(WP-CLI)や管理画面でどのサイト/ユーザーがそのテーマを使用しているかをチェック。 - マルチサイトなら影響範囲を洗い出す:ネットワーク管理で使用中のサイト一覧を確認。
安全に削除する手順
- 子テーマが存在する場合は親テーマを削除しない。もし親テーマのセキュリティ問題で置き換えが必要なら、次の段取りを踏む:
- 子テーマが動作する新しい親テーマ(互換)を事前に用意する(難しい場合は子テーマのコードを親なしでも動くよう修正が必要)。
- ステージング環境で子テーマを新しい親で動かして問題ないか検証。
- 本番で切り替え→確認→旧親テーマを削除。
- 万が一削除してしまった場合:速やかにバックアップから復元、またはテーマファイルを再インストールする(下の復旧手順参照)。
チェック用コマンド(WP-CLI)
# テーマ一覧とステータス確認
wp theme list
# 子テーマかどうか確認(子テーマの style.css に Template があるかを手動確認)
注意ルール:
- 子テーマがある → 親テーマは触らない。
- マルチサイト → ネットワーク管理者と調整してから実行。
まとめ(トラブル対処のシンプルな流れ)
- 状況把握:削除ボタンが無い/エラー/削除しても変わらない、どれかを特定。
- ログと存在確認:サーバー上に該当テーマフォルダが存在するか確認。
- 権限・容量のチェック:ディスク空き容量・ファイル権限を確認。
- 代替ルートで削除:管理画面でダメなら WP-CLI / FTP / ホスティングのファイルマネージャ を使う。
- 影響範囲の確認:子テーマ・マルチサイト・プラグイン依存を洗い出す。
- 復旧手順を準備:バックアップから復元できるようにしておく。
短いチェックリスト
- [ ] 該当テーマが active でないかを確認した
- [ ] マルチサイトでネットワーク有効化されていないか確認した
- [ ] ディスク容量とファイル権限をチェックした
- [ ] キャッシュ(ブラウザ/CDN/プラグイン)をクリアした
- [ ] 代替手段(FTP/WP-CLI)での削除を試した
- [ ] 復旧(バックアップ/再インストール)手順をメモした
特別扱いすべきテーマ・状況(例外とおすすめ処置)
テーマを整理する際、普通は削除して問題ないものと残すべき・慎重に扱うべきものが混在します。
ここでは「親テーマ」「マルチサイト」「テスト用/デフォルトテーマ」に絞って、なぜ特別扱いが必要かと実務的な対処法(初心者でもできる)を丁寧に説明します。
すぐに使えるチェックリストや手順も載せます。
親テーマ(ベース)を残す理由と扱い方
なぜ残すべきか
子テーマは親テーマのテンプレート・関数を参照して動作します。親テーマを削除すると子テーマが機能不全になり、サイトが壊れる可能性があります。つまり、子テーマが存在する場合は親テーマを基本的に削除しないのが原則です。
実務的な確認手順
- 管理画面で子テーマが有効か確認する(外観 → テーマ)。
- FTPで子テーマの
style.cssを開き、Template: <parent-slug>があるか確認。 - WP-CLI が使えるなら一覧で確認:
wp theme list
→ status 列で active / inactive を確認。子テーマがあるかどうかは手動で style.css を見るのが確実。
親テーマを“残す”以外の選択肢(代替案)
- 親テーマを更新(patch)する:脆弱性が理由ならまずは最新バージョンへ更新。
- 機能をプラグイン化する:子テーマで機能追加している場合、可能なら機能をプラグイン(機能プラグイン)へ移行して依存度を下げる。
- 子テーマを親フリーに改修する(上級): 子テーマ内の必要なテンプレートを直接組み込み、親に依存しない構造に変える。ただし作業負荷と検証が必要。
短いチェックリスト
- [ ] 子テーマの存在を確認した
- [ ] 親テーマを削除しても影響が出ないことをステージングで確認した
- [ ] 親テーマにセキュリティ問題がある場合は更新または代替策を検討した
マルチサイト環境での最適な運用ルール
マルチサイトならではの注意点(要点)
- テーマ管理はネットワーク管理者(Network Admin)の権限で行われる。個別サイト管理者が勝手に削除できない場合がある。
- あるテーマを「ネットワーク有効化」すると、複数サイトで使われる可能性が高く、削除は大規模障害につながる恐れがある。
- 各サイトでカスタマイズや独自テンプレートを持っていることが多いため、影響範囲の事前確認が必須。
推奨ルール(組織で運用する場合)
- テーマの登録・削除はネットワーク管理者のみが実施する(権限運用)。
- テーマ登録ポリシーを作る(承認フロー、テスト手順、保守責任者の指定)。
- 「ネットワーク有効化」は慎重に使用。基本は「テーマを登録しておき、必要なサイトだけで有効化する」運用が安全。
- 事前通知とステージング:削除や大きなアップデートは関係サイト管理者へ周知し、ステージングで検証する。
- 監査ログを残す:誰がいつテーマを有効化/削除したかの履歴を残すとトラブル時に役立つ。
実務的ワークフローの例
- テーマを削除する前に:
- ネットワーク管理画面で「どのサイトが該当テーマを使っているか」一覧化。
- 影響を受けるサイト管理者に通知・テスト日程を調整。
- ステージング環境で削除検証。
- 削除 → 全サイトの最重要ページをチェック → 問題なければ完了。
表:マルチサイトでの簡易対応表
| 状況 | 推奨対応 |
|---|---|
| テーマが複数サイトで有効化されている | 削除禁止/運用ルールで承認を必須に |
| テスト用テーマのみで利用 | ステージングへ移動、ネットワーク登録は維持 |
| セキュリティ問題があるテーマ | まずはネットワークで非表示にして検証 → 代替テーマへ移行 |
テスト用テーマやデフォルト(標準)テーマの取り扱い方針
テスト用テーマ(開発用)
- 何故残すか:本番でテーマ切替や修正を速やかに試すため。
- 扱い方:本番サイトからは非表示(管理者のみのアクセス)にする、またはステージングへ移す。不要になったら削除。
デフォルトテーマ(例:Twenty系)
- 何故1つは残すか:トラブル時に即座に切り替えてサイトを復旧するため。複数のデフォルトテーマを残す必要は基本的にないが、最低1つは常備することを推奨。
- 扱い方:最新版へ更新し、常に稼働可能な状態にしておく。
推奨ポリシー
- 本番環境には「テスト用テーマ」は置かない(または役割を明確に):誤って有効化されるリスクを下げる。
- デフォルトテーマは1つだけ保持し、定期的に更新しておく。
- テストはステージングで行う:可能ならテスト用テーマはステージング環境へ移して、管理画面上での誤操作リスクを減らす。
短い運用チェックリスト
- [ ] 本番にテスト用テーマを置いているか確認(置いているなら非表示化を検討)
- [ ] デフォルトテーマを1つは保持し、最新化しているか確認
- [ ] テーマ切替の手順を管理者向けにドキュメント化(誰が何をするか明確化)
最後に:初心者でもすぐ実行できる簡単まとめ
- 子テーマがある → 親テーマは消さない(まず確認)。
- マルチサイトはネットワーク管理者ルールを作る(削除は慎重に)。
- テスト用はステージングへ/デフォルトは1つ残す(即時復旧用)。
- 操作前は必ずバックアップ、可能ならステージングで検証すること。
簡易早見表
| テーマの種類 | その扱い |
|---|---|
| 親テーマ(子あり) | 削除禁止(またはステージングで検証後に代替を用意) |
| マルチサイトで使用中 | ネットワーク管理者と調整、慎重に削除 |
| テスト用テーマ | ステージングへ移動、または管理者のみ非表示 |
| デフォルト(救済用) | 1つは残し最新版に更新しておく |
間違えたときの復旧・よくあるQ&A
初心者でもすぐ対処できるように、「削除を戻す方法」「デフォルトテーマの扱い」「削除と無効化の違い」をわかりやすくまとめます。
各項目に手順・注意点・短いチェックリストを載せています。
削除を元に戻す基本手順(バックアップ復元/再インストール)
概要:
削除したテーマを元に戻す際は、まず「どのレベルで戻すか」を決めます。(A)テーマファイルだけ戻す、(B)ファイル+DBを丸ごと復元するの2パターンが主流です。後者は強力ですが副作用(投稿や設定の上書き)があるため注意が必要です。
A. テーマファイルだけを復元する(最も安全)
- 手元にあるバックアップ(ZIPやフォルダ)を用意する。ない場合はテーマ配布元から同じバージョンを入手。
- 管理画面 → 外観 → テーマ → 新規追加 → テーマのアップロード で ZIP をインストールして有効化する。
- または FTP で
wp-content/themes/にフォルダをアップロード。
- または FTP で
- 有効化して表示確認。ウィジェットやメニュー位置が崩れていれば再割当てする。
利点:投稿やユーザーデータは触らない。
注意:テーマ固有の設定(テーマオプション)がデータベースに残っていない場合は再設定が必要。
B. ファイル+データベースを復元する(完全復旧)
- 復元する日時のフルバックアップ(ファイル+DB)を用意する。
- DB復元は最新投稿の消失リスクがあることを理解する(必要なら差分バックアップを使う)。
- ホスティングのリストア機能を使うか、phpMyAdmin / WP-CLI で SQL をインポートする。
- WP-CLI 例:
wp db import backup.sql
- WP-CLI 例:
- ファイルを FTP で上書きアップロード(
wp-content/themes/)。 - キャッシュをクリアして動作確認。
利点:テーマの設定やウィジェット配置などを完全に元に戻せる。
注意:DB を丸ごと戻すと、そのバックアップ以降の投稿やコメントが失われる可能性がある。必要な差分はエクスポート/インポートで対応する。
もしバックアップがない場合の代替手段
- テーマ配布元から同バージョンをダウンロードして再インストール → 手動でカスタマイズを復元。
- 子テーマやカスタムCSS等の個別コードを別途保管していれば、それを再適用する。
短い復旧チェックリスト
- [ ] テーマファイル(ZIP or フォルダ)を準備した
- [ ] (DBを戻す場合)最新投稿の喪失リスクを確認した
- [ ] 管理画面で再インストール → 有効化 → 表示確認した
- [ ] ウィジェット/メニュー/カスタマイズをチェックした
標準テーマは全部消しても良いか?(推奨対応)
結論(簡潔):全部消すべきではない。最低でも1つは動作確認用(復旧用)のデフォルトテーマを残しておくことを推奨します。
理由(要点)
- デフォルトテーマ(例:Twenty系)はテーマに起因する表示障害の切り分けに役立つ(問題発生時に有効にして素早く復旧できる)。
- サイトヘルスや一部の自動診断では、デフォルトテーマがあることを前提に動く機能がある場合がある。
- マルチサイトや特定のプラグインで「デフォルトテーマが必要」なケースがある。
推奨ポリシー(初心者向け)
- 最低1つ、公式の軽量デフォルトテーマを残す(常に最新版に更新)。
- デフォルトテーマは「有効化はしないがインストール済みで保管」しておく(緊急時に切替える)。
- デフォルトテーマを削除したい場合は、まずローカルにZIPで保管してから削除する(本当に不要なら保管後に削除しても可)。
運用チェックリスト
- [ ] デフォルトテーマを1つはローカルまたはサーバーに保管している
- [ ] デフォルトテーマは常に最新バージョンである(更新を怠らない)
- [ ] 緊急切替手順(誰が何をするか)を管理者向けにメモしている
削除と無効化(アンインストールと停止)の違い
定義
- 無効化(停止/switch):現在のテーマを「使用しない状態」にすること。別のテーマを有効化すると自動で無効化される。テーマファイルはそのままサーバーに残る。
- 削除(アンインストール):テーマフォルダを完全に削除して、ファイルをサーバーから消すこと。元に戻すには再インストールが必要。
実務的な違いと影響
| 操作 | ファイル | データ(ウィジェット等) | 復旧の手間 |
|---|---|---|---|
| 無効化 | 残る | 多くはDBに残る(配置は変わることあり) | 低(再有効化で元に戻ることが多い) |
| 削除 | 消える | テーマ固有の設定はDBに残る場合と残らない場合がある | 高(再インストールやDB復元が必要) |
いつ無効化を使うか
- 新しいテーマに切り替えてテストしたいが、すぐ戻せるようにしたい場合。
- テーマを一時的に停止して原因切り分け(表示崩れのデバッグ)したいとき。
いつ削除を使うか
- テーマが不要で今後使う予定がない、またはセキュリティ・容量の観点から完全に消したいとき。
- 古いデモコンテンツや不要なファイルを完全に取り除きたいとき。
注意点(具体例)
- 「無効化」→ 別テーマに切り替えるだけで フォントやウィジェットの位置が変わることがある(見た目が崩れる可能性はあるが復旧は容易)。
- 「削除」→ ファイル自体が消えるので、バックアップがない状態で削除すると復旧が面倒。
短い操作フロー(安全)
- まずは無効化(別テーマへ切替)で動作確認。
- 問題なければ、不要テーマは管理画面から削除(またはバックアップしてFTPで削除)。
- 削除前に必ずバックアップ(ファイル+DB)を取得する。
最後に(緊急時のワンポイントまとめ)
- 焦らないこと:誤って削除しても、冷静にバックアップや配布パッケージから復旧できます。
- 最初の対処:まずブラウザキャッシュのクリア → 管理画面でテーマ一覧の確認 → 手元にバックアップがあるか確認。
- 推奨の安全策:本番では「無効化(切替)→確認→削除」の順を守る。デフォルトテーマは最低1つ残す。
- 緊急コマンド例(WP-CLI)
# テーマ一覧確認
wp theme list
# テーマを有効化(例)
wp theme activate twentynineteen
# テーマを削除(例)
wp theme delete twentytwentyone
まとめ:作業後に覚えておきたいポイント
この記事の核心は次の3つに集約できます。
- 準備がすべて:バックアップ(ファイル+DB)とステージングでの検証は必須。これを省くと復旧が大変になります。
- 状況に応じた手段を選ぶ:管理画面で安全に削除できるならそれが一番簡単。管理画面でできない・権限がない場合はFTP・ホスティング管理画面、慣れているならWP-CLIが速く確実です。
- 影響範囲を必ず確認する:子テーマ、ウィジェット、メニュー、ページビルダーやマルチサイトの依存関係は事前に洗い出しておくこと。
最後に作業チェックリスト(コピペして使える短縮版)
- [ ] ファイルとデータベースのバックアップを取得した
- [ ] ステージング環境で削除の検証を完了した
- [ ] 子テーマ・ウィジェット・メニュー依存を確認した
- [ ] 削除後に主要ページ(PC/スマホ)を確認する手順を用意した
安全に作業すれば、テーマ整理はサイトの健全性を高める大事なメンテナンス作業です。

