WordPressの本文を直したのに表示が変わらないとき｜ページビルダーのページは「本文」を見ていない

WordPressの編集画面で本文を修正し、更新ボタンを押した。管理画面上は確かに直っている。それなのに、実際のページを開くと古い文章のまま変わらない。

このとき多くの人がキャッシュを疑います。ブラウザのスーパーリロード、キャッシュプラグインの削除、サーバーキャッシュの設定確認。しかし、キャッシュを消しても待っても直らないケースがあります。

結論から書きます。Elementorなどのページビルダーで作られたページは、表示に使われるデータが「本文」とは別の場所に保存されています。本文（データベース上の post_content）をいくら直しても、表示は1文字も変わりません。キャッシュ対応に時間を使う前に、まず「そのページはビルダー製かどうか」を確認するのが正しい順番です。

この記事では、ビルダー製ページの見分け方、キャッシュかどうかを1発で判定する方法、そしてビルダーのデータを安全に書き換える手順をまとめます。制作会社や保守担当に依頼する立場の方向けに、「何を伝えれば早く直るか」も最後に書きます。

なお、変わらないのが本文ではなくCSS・デザインの場合は、配信元ファイルの食い違いという別の原因が先に疑われます。そちらの切り分けはWordPressでCSSを直したのに反映されないとき｜キャッシュより先に確かめる配信元にまとめています。この記事が扱うのは、本文・テキストを直したのに変わらないケースです。

結論：表示のデータは2か所ある。直すべきは「本文」ではない方

WordPressの通常のページは、編集画面の本文欄（データベースでは post_content という領域）に入っている内容がそのまま表示されます。本文を直せば表示が変わる。これが前提です。

ところが、Elementorをはじめとするページビルダーでページを作ると、この前提が崩れます。ビルダーは自前のレイアウトデータを postmeta という別領域（Elementorの場合は _elementor_data）にJSON形式で保存し、表示のHTMLはそちらから組み立てます。本文欄にも一見それらしい内容が残っていることがあるため、「本文を直したのに変わらない」という状態が生まれます。

これはElementorの不具合ではなく、ビルダーという仕組みの設計です。Divi、WPBakeryなど他のページビルダーにも同型の構造があります。編集の自由度と引き換えに、データが二重に見える状態になる。これを知らないまま修正作業に入ると、存在しない原因（キャッシュ）を追いかけることになります。

そのページがビルダー製かを最初に確認する

修正作業の前に見るべきはここです。確認は1分で終わります。

管理画面で見る場合：固定ページ・投稿の一覧または編集画面に「Elementorで編集」というボタンがあれば、そのページはビルダー製の可能性が高いです。通常のブロックエディタとは別の、専用編集画面が開きます。

コマンドで確認する場合（サーバーにSSH接続でき、wp-cliが使える環境）：

wp post meta list <ページID> --keys=_elementor_edit_mode,_elementor_data --fields=meta_key

_elementor_edit_mode が返ってくれば、そのページの表示は _elementor_data から描画されています。触るべきは本文ではなくこちらです。

キャッシュかどうかは「サイズが変わるか」で1発で分かる

ビルダーの確認と並行して、キャッシュ説を機械的に潰す方法があります。

時間を置いて配信HTMLのサイズが1バイトも変わらないなら、キャッシュではありません。

サーバーキャッシュの保持時間は、一般に分単位です。たとえばエックスサーバーのサーバーキャッシュは、公式マニュアル上CSS・JS・画像で2分、その他は1分。つまり数分待って取り直せば、キャッシュ起因なら中身が入れ替わるはずです。

curl -so /dev/null -w "%{size_download}\n" https://example.com/page/

このコマンドで配信されているHTMLのバイト数が取れます。30分後、1時間後に同じコマンドを打って完全に同一のバイト数が返り続けるなら、キャッシュが古いのではなく「大元のデータが変わっていない」と判断できます。

実際にあった例では、複数店舗を展開する美容サロンチェーンのサイトで、閉店した店舗の記載を一覧ページから削除する作業中に「データベースは直っているのに配信HTMLが古い」という状態が6時間続きました。時間単位で1バイトも変わらない時点でキャッシュ説は捨てるべきサインだったのですが、切り分けの手掛かりを持っていないと「キャッシュだから待てば直る」と結論してしまう。こうした誤診はどのサイトでも起こり得ます。

誤診が起きる理由：確認がすべて「正しく見えて」しまう

このケースの怖いところは、途中の確認作業が全部それらしい結果を返すことです。起こりやすい思考の流れを整理しておきます。

やりがちな確認	出る結果	なぜ根拠にならないか
データベースの本文を直接見る	直っている	表示に使われていないデータを見ている
WP内部で本文をレンダリングして確認	直っている	ビルダーは本文の表示経路（the_contentフィルタ）と別経路でHTMLを組む
CDNを迂回してサーバーへ直接アクセス	古いまま	外部CDNの否定にはなるが、サーバー内キャッシュの証明にはならない

「データは正しい」「CDNではない」→「残るはサーバーキャッシュしかない」。一見筋の通った消去法ですが、そもそも見ていたデータが表示に使われていないという可能性が抜けています。消去法の前提に穴があると、残った結論も間違います。

ビルダーのデータを安全に書き換える手順

ビルダー製と分かったら、修正は専用編集画面から行うのが基本です。Elementorの編集画面で該当箇所を直せば、正しいデータ（_elementor_data）が更新されます。通常の修正はこれで完結します。

一方、店舗一覧から1店舗分を削除するような定型的な一括修正や、編集画面で探しにくい細かいテキストの修正は、データを直接書き換えた方が確実な場合があります。その場合は以下の型を守ってください。順番に意味があります。

1. バックアップを取る。wp post meta get <ID> _elementor_data > before.json で書き換え前のデータをファイルに残す
2. JSONの構造を確認する。_elementor_data の中身は入れ子のJSONですが、テキストエディタウィジェットの settings.editor にHTMLがまとまって入っていることが多く、その場合は本文を直すのと同じ文字列処理で対応できます
3. 書き換え後に件数を検証してから適用する。前述のサロンサイトの例では「店舗ブロックが21個から20個になっているか」「削除対象の店舗名が0件か」を確認してから本番に書き出しました。処理してすぐ適用、はやらない
4. update_post_meta には wp_slash() を通して渡す。WordPressは保存時にエスケープを1段階外すため、これを忘れるとJSON内の \/ や \uXXXX が壊れ、Elementorのデータ自体が破損します。ここがこの作業の最大の事故ポイントです
5. CSSキャッシュを再生成する。wp elementor flush-css を実行
6. 本番ページを実測する。管理画面ではなく、実際に配信されているHTMLを取得して、修正が反映されているかを確認する

補足：JSONの中の日本語は検索で見つからない

データを直接扱うときのもう一つの罠です。_elementor_data の中では、日本語が \u540d\u53e4\u5c4b（＝「名古屋」）のようなUnicodeエスケープ形式で保存されていることがあります。つまり日本語のまま検索すると、実際には存在するのに0件と返ってくる。

「検索して0件だから、このデータには含まれていない」と即断すると、修正漏れや誤った判断につながります。店舗名などを探すときは、日本語と併せてURLやスラッグなどのASCII文字列（例：店舗ページのURL断片）でも検索してください。

発注者・経営者の立場では何を確認すればいいか

自分で直さず制作会社や保守担当に依頼する場合も、この構造を知っているだけで話が早くなります。

• 修正を依頼するとき、「そのページはページビルダーで作られていますか」と一言確認する。ビルダー製なら通常の本文修正とは作業が違うため、担当者の見積りと段取りが正確になります
• 完了報告は「管理画面で直しました」ではなく、「実際のページで反映を確認しました」までを依頼する。この記事で書いた通り、データを直しても表示が変わらない構造があるからです
• 「キャッシュのせいなのでしばらく待ってください」という説明を受けたら、何分待てば切れるキャッシュなのかを聞いてみる。サーバーキャッシュは通常分単位です。数時間・数日単位の「待ち」を提示されたら、キャッシュ以外の原因が疑われます

ページビルダー自体は、専門知識なしでレイアウトを編集できる便利な仕組みです。避けるべきものではなく、「データの置き場所が通常と違う」という一点だけを、直す側と頼む側の双方が知っておけば十分です。

まとめ

• 本文を直しても表示が変わらないときは、キャッシュより先にページビルダーの有無を確認する。ビルダー製ページの表示は本文（post_content）ではなくpostmeta（Elementorなら _elementor_data）から描画される
• キャッシュかどうかは時間を置いてサイズが変わるかで判定できる。サーバーキャッシュは分単位。数時間バイト単位で同一なら、キャッシュ説は捨てる
• データを直接書き換えるなら、バックアップ→JSON検証→件数チェック→wp_slash()→flush-css→本番実測の順を崩さない
• 検索0件は「存在しない」の証明にならない。JSON内の日本語はエスケープされる
• 依頼する側は「ビルダー製かどうか」を確認し、完了報告は実ページでの反映確認までを求める

「正しく作業しているのに結果だけ変わらない」ときは、作業が間違っているのではなく、見ている場所が違うことを疑ってください。切り分けの順番さえ持っていれば、6時間悩む問題は10分で特定できます。