WordPressでクラシックエディタとブロックエディタを切り替えるには、公式プラグイン「Classic Editor」を入れて、設定画面で既定のエディターを選びます。
ブロックエディタに戻すときは、プラグインを停止します。
エディタの切り替えは投稿の編集画面だけの変更で、テーマを替える必要はありません。
この記事では、切り替えの手順と、クラシックエディタ前提のテーマからブロックエディタ対応テーマへ移行するときの注意点をまとめます。
クラシックエディタとブロックエディタを切り替える手順
以下は、2026年10月31日にWordPress.orgのClassic Editor公式プラグインのページで説明を確認した内容です。
管理画面での実際の操作はこの確認では検証していないため、項目の表示名はお使いの環境で確かめてください。
- 管理画面の「プラグイン」の追加画面でClassic Editorを検索し、インストールして有効化します。
- 「設定」→「投稿設定」を開きます。
- すべてのユーザーの既定のエディターとして、クラシックエディタかブロックエディタを選びます。
- 投稿ごとに使い分けたい場合は、ユーザーにエディターの切り替えを許可する設定を有効にして保存します。
切り替えを許可すると、ユーザーは投稿ごとに使うエディターを選べます。
各投稿は、誰が最後に編集したかに関係なく、最後に使ったエディターで開きます。
ブロックエディタだけに戻すときは、Classic Editorを停止します。
Classic Editorのサポート状況
公式プラグインのページには、少なくとも2024年まで、または必要な間はサポートと保守を続けると書かれています。
2026年10月31日の確認時点で、最新版は1.7.0、最終更新日は2026年5月28日、対応を確認済みのWordPressは7.0.8でした。
終了日は示されていないため、長く使い続ける前提にする場合は、更新が続いているかをプラグインのページで定期的に確認してください。
エディタ変更とテーマ変更を分ける
ブロックエディタは投稿本文を編集する仕組みで、ブロックテーマはヘッダーなどのテンプレートもブロックで構成するテーマです。
ブロックエディタを使うためにブロックテーマへ切り替える必要はなく、SWELLなどのクラシックテーマでも本文をブロックで編集できます。
この記事は、WordPressの移行を実施する制作者向けの技術解説です。
企業サイトの担当者が改修範囲・予算・依頼先を検討する場合は、SHIKUMIのWordPressリニューアルの費用と進め方をご覧ください。
WordPress 5.0以降、標準エディタは「クラシックエディタ」から「ブロックエディタ（Gutenberg）」へと移行しました。
しかし、長年クラシックエディタを使ってきた方にとって、ブロックエディタ対応のテーマへ切り替えるのは簡単ではありません。
この記事では、クラシックエディタ前提のテーマから、ブロックエディタ対応テーマへ移行する際に注意すべきポイントを詳しく解説します。
1. テーマ独自の機能の移植
旧テーマで使っていたウィジェットやカスタム関数などの独自機能は、新テーマに自動では引き継がれません。
特に以下のような機能は要確認です。
- functions.php 内の独自カスタマイズ
- ウィジェット領域の構造
2. テーマ独自ショートコードの変換
クラシックエディタで多用されていた [shortcode] は、新しいテーマでは不要または非対応になることがあります。
ブロックエディタでは同様の機能が「ブロック」として用意されているケースが多いです。
属性や入れ子を含むショートコードは単純な文字置換を避け、複製環境で変換前後の本文と出力を比較してください。
3. プラグインとテーマ機能の重複に注意
新しいテーマには、スライダー・カラム・タブなどのデザイン機能が内蔵されていることが多く、既存のプラグインと機能が競合することがあります。
対策：
- 機能が重複していないかチェック
- どちらか一方を無効化して整理
- CSSの競合を避けるため、テーマとプラグインの読み込み順やスタイル指定も見直す
4. クラシックブロックの変換
クラシックエディタで作成された記事は、ブロックエディタでは「クラシックブロック」として表示されます。
これは編集可能ですが、表示上の問題やマークアップのズレが発生することも。
対策：一括変換はリスクが高いため、記事ごとに「ブロックに変換」→レイアウト確認→修正の手順で対応しましょう。
5. 見た目（デザイン）の修正
ブロックエディタ対応テーマでは、HTML構造やCSSクラスが大きく異なるため、デザインが大きく変わる可能性があります。
- ボタン・見出し・カラムが崩れる
- サイドバーやフッターウィジェットの再配置が必要になることも
対策：エディタ上の見た目と、フロント側の表示が一致しているかを確認しながら、CSSや設定を調整しましょう。
補足：移行時に見落としがちな注意点
- ウィジェットエリアの構造変化（ブロックウィジェット対応かどうか）
- FSE（フルサイト編集）対応テーマの場合のテンプレート構造の違い
- ACF（Advanced Custom Fields）などの互換性
一番作業に時間がかかるのが、記事の見た目の修正です。
まとめ│差分が発生することを意識すること
基本的には複製した仮サイトを作成して、そこで移植作業をいたします。
また数百記事ある場合は完璧に修正するのは時間がかかるので注意しましょう。
もし新規記事を現行サイトで更新してしまうと差分が発生して、把握や更新が大変になります。
本番反映までの更新停止期間は、更新頻度と差分の反映方法を踏まえて決めます。
停止できないサイトでは、移行中に追加・修正された記事を記録し、公開前に反映・確認する担当と日程を決めておきます。
本番サイト反映後、微調整するのがよいでしょう。
移行前に調べること
ここまでに挙げた5つの注意点は、いずれも「事前に量を把握しておけば、工数が見積もれる」ものです。
着手前に次を調べてください。
| 調べること | 調べ方 | なぜ必要か |
|---|---|---|
| 独自ショートコードの使用数 | 管理画面の検索窓で [box などを検索 | 置き換え作業の量が決まる |
| カスタム投稿タイプの定義元 | テーマ側か、プラグイン側か | テーマ側だと、外した瞬間にデータが表示されなくなる |
| クラシックブロックの記事数 | 記事一覧を確認 | 変換対象の本数 |
| 追加CSSの量 | カスタマイザーの追加CSS欄 | 旧テーマの構造に依存した指定は効かなくなる |
| 子テーマの改変内容 | functions.php、テンプレートファイル | 旧テーマ前提の記述は動かない |
| ウィジェットの配置 | 外観 → ウィジェット | 再現するために控えておく |
2行目が最も重要です。
実績や事例を「テーマの機能」で作っていた場合、テーマを外すとデータが表示されなくなります。
この場合はプラグインで定義し直す作業が加わり、工数が大きく変わります。
作業の進め方
| STEP | 作業 |
|---|---|
| 1 | 現状調査（前章） |
| 2 | バックアップ（ファイル＋データベース） |
| 3 | テスト環境を作る |
| 4 | テスト環境でテーマを切り替え、崩れる箇所を洗い出す |
| 5 | カスタマイザー・ウィジェットの設定を再現する |
| 6 | カスタム投稿タイプ・追加CSSを移設する |
| 7 | 記事内の装飾を置き換える |
| 8 | フォーム・プラグインの動作を確認する |
| 9 | 本番へ反映し、全ページを確認する |
STEP3を飛ばさないでください。
本番サイトでテーマを切り替えて確認するのは、訪問者に崩れた状態を見せることになります。
多くのレンタルサーバーがテスト環境の機能を提供しています。
記事数が多い場合の現実的な進め方
STEP7が最も工数のかかる工程です。
記事が数百本ある場合、すべてを直してから公開しようとすると、いつまでも移行できません。
アクセスの多い記事から優先的に修正し、残りは運用のなかで順次対応する——これが実務的な判断です。
記事ごとのアクセスに加えて、料金案内や問い合わせなど業務上の重要性も見て、確認と修正の優先順位を決めます。
優先順位の判断には、アクセス解析のデータを使ってください。
設定方法はGA4・Search Consoleの初期設定と見るべき指標で解説しています。
クラシックブロックの変換について
クラシックエディタで書かれた記事は、ブロックエディタ上では「クラシック」という1つの大きなブロックとして表示されます。
クラシックブロックを必ず変換する必要はありません。
ただし、旧テーマのCSSやショートコードに依存する部分は、未変換でもテーマ変更後に表示が変わるため確認が必要です。
| 変換する | 変換しない | |
|---|---|---|
| 編集のしやすさ | ブロック単位で編集できる | HTMLに近い状態での編集になる |
| 装飾の追加 | 変換した本文をブロック単位で装飾できる | 従来の編集ツールや、クラシックブロックの外への別ブロック追加は使える |
| 崩れるリスク | ある（特に複雑なHTML） | 低い |
| 作業量 | 記事数に比例 | 変換作業は不要。表示確認は必要 |
判断の目安として、「今後も編集する記事だけ変換する」のが合理的です。
過去のお知らせなど、もう触らない記事は変換しなくて構いません。
変換する場合は、1記事ずつ変換して表示を確認してください。
テーブルや独自のHTMLを含む記事は崩れやすいため、特に注意が必要です。
見落とされやすい確認項目
- アクセス解析タグ：旧テーマの設定欄に入れていた場合、切り替えで外れます
- 広告・コンバージョン計測タグ：同上。
設置箇所を事前に控える - お問い合わせフォームの送信テスト：テーマとの組み合わせで不具合が出ることがある
- スマートフォンでの表示：メニューの開閉が動かないことがある
- 構造化データ・OGP設定：テーマ側で出力していた場合は引き継がれない
- 404ページ・検索結果ページ：通常の確認では見落とす
計測タグが外れると、その期間のデータを取得できません。
テーマを切り替える前に、解析・広告タグの設置元を控えてください。
Googleタグマネージャーを使っていても、コンテナコードを旧テーマの設定やテンプレートから出力していれば、テーマ変更で外れます。
コンテナコードの設置箇所と、切り替え後も出力を担当するプラグインやテーマを確認してください。
よくある質問
Q. 記事のデータは消えませんか？
消えません。
記事本文、画像、カテゴリー、投稿日といったデータはそのまま残ります。
変わるのは「見せ方」の部分です。
ただし装飾が崩れるため、その修正作業が発生します。
Q. どのくらいの期間と費用がかかりますか？
費用と期間は、記事の装飾、独自機能、移行対象、デザインを変える範囲によって異なります。
発注前に整理する項目は、SHIKUMIのWordPressリニューアルの費用と進め方をご覧ください。
MOTOKIの最新の料金と対応範囲はリニューアルサービスに掲載しています。
詳しい内訳は他テーマからSWELLへの移行手順と注意点をご覧ください。
Q. 検索順位に影響しますか？
エディタの変更だけで順位への影響を判断することはできません。
テーマや本文も変更する場合は、内部リンク、インデックス設定、表示などを公開前後で比較します。
URLを変更する場合は転送も必要です。
検索順位の維持や回復時期は保証できません。
ただし装飾が壊れたまま公開する、見出しの構造が崩れる、表示速度が落ちるといった場合は影響が出ます。
切り替え後1〜2週間はSearch Consoleでエラーを監視してください。
Q. 今のままクラシックエディタを使い続けてはいけませんか？
WordPressの標準はブロックエディタですが、クラシックエディタを選ぶ場合はClassic Editor公式プラグインと利用するテーマ・プラグインの対応範囲を確認してください。
Classic EditorはブロックテーマとFSEには対応しません。
必要な機能と保守方針を基に、移行する時期を判断します。
まとめ
- 移行は着せ替えではなく、旧テーマ独自機能の置き換え作業
- 工数を決めるのは独自ショートコードの数とカスタム投稿タイプの定義元
- テスト環境で試す。本番での切り替えは避ける
- クラシックブロックは「今後も編集する記事だけ」変換する
- 記事数が多いならアクセス上位から優先して修正する
- 計測タグとタグマネージャーのコンテナコードの設置元を確認し、テーマ変更後も出力される構成にする
テーマ選びの考え方は有料WordPressテーマ比較を、移行の詳細な手順はテーマ移行の手順と注意点をご覧ください。
自社で更新できるサイトへの改修を検討している方へ
ブロックエディタを使っていても、テーマ内に固定された情報が自動的に編集できるようになるわけではありません。
運用者の立場で原因と改善方法を整理する場合は、SHIKUMIのWordPressなのに自社で更新できない原因をご覧ください。
クラシックブロックの基本操作と変換は、WordPress公式のクラシックブロック解説で確認できます。
切り替え前後に同じURLで比較する
複製環境で通常記事・独自ショートコード・カスタム投稿・フォームを含む代表ページを選び、PCとスマホで見出し、画像、内部リンク、送信動作を比較します。
公開本文、添付画像、投稿ID、パーマリンクを変更する必要があるかを個別に判断し、テーマ変更だけを理由にURLを一括変更しません。
切り戻し用にデータベース、uploads、旧テーマと設定を保存し、変換済み本文はテーマを戻すだけでは元に戻らない点を確認してください。
2026年10月11日の確認は、公開本文とWordPress・Googleの公式資料の照合です。
実際のテーマ切り替え、本文の変換、計測タグやフォームの動作はこの確認では検証していません。
利用中のテーマ・プラグインの組み合わせは、複製環境で別途確認してください。
