先に結論：PC版とスマホ版へ別々のHTMLが自動配信されていたわけではありません。今回の本質は、Elementorに残った複数iframeと、外側・内側で別々に効くキャッシュ、そして開いていたURL自体の違いでした。

何が起きていたのか

ロードマップの固定ページを更新したところ、スマートフォンでは期待していた画面が見える一方、PCでは古いデザインのまま変化しませんでした。さらにPCでは、ロードマップの下にキーワード工場まで続けて表示されていました。

見た目だけを見ると「レスポンシブ設定でPC版とスマホ版が分岐している」ように感じます。しかし、PC用とスマホ用のUser-Agentで取得したHTMLを比較すると、配信内容は同じでした。端末判定より先に、ページの構造とURLを調べる必要があったのです。

図解① ページは「外側」と「内側」の2階建て

ブラウザPCやスマートフォンが最初に開く場所

↓

WordPress固定ページURL・ページ本文・Elementorの保存データを持つ「外側」

↓

iframeの src別のHTMLファイルを読み込むための住所

↓

ロードマップHTMLスライドや図解を動かす「内側」の独立した文書

上下に別素材が出た直接原因

修正前のElementor HTMLウィジェットには、実際に3本のiframeが保存されていました。

図解② 「1つの素材が壊れた」のではなく、複数素材が縦積みだった

非表示 旧Overview

roadmap-hero.html
CSSの display:none で隠れていたが、DOMには残存。

表示 ロードマップ

wordpress-trend-affiliate-roadmap.html
画面上部に表示。

表示 キーワード工場

keyword-factory.html
ロードマップの下に表示。

図解③ 修正前と修正後

修正前

• 非表示の旧素材がDOMに残る
• ロードマップと別素材が同時表示
• 同じバージョンURLを再利用

→

修正後

• ロードマップiframeを1本だけ保存
• 不要素材はCSSではなくDOMから削除
• 未使用のバージョン番号へ更新

なぜスマホのURLをPCへ貼ると直ったのか

ここが今回もっとも重要なポイントです。スマートフォンからPCへキャッシュが移動したわけではありません。

PCでそれまで見ていたのはWordPress固定ページでした。一方、スマートフォンからコピーしたURLは、比較ラボに置かれた候補版HTMLの直URLでした。

固定ページの例
/aiトレンドロードマップ/

コピーした直URLの例
/ai-trend-lab/candidate-YYYYMMDD/ai-trend-universe.html

これは同じページの再読み込みではなく、別のパスにある別ファイルへ移動したことを意味します。WordPressとElementorの外枠を迂回し、目的のHTMLを直接開いたため、固定ページに残っていた複数iframeや外側キャッシュの影響を受けませんでした。

図解④ URLが変わると、参照先とキャッシュキーが変わる

固定ページを開く /fixed-page/

WordPress外枠 → Elementor → iframeの順に読み込む。

外側の旧構造も影響する

HTMLを直接開く /candidate/new.html

WordPress外枠を通らず、目的のHTMLへ直接到達。

別URI・別キャッシュとして取得

キャッシュは1枚ではなく、層になっている

調査では、固定ページと埋め込み先HTMLの双方が Cache-Control: max-age=172800 を返していました。172,800秒は48時間です。

一度取得した応答をブラウザや中間キャッシュが再利用できるため、同じURLのファイルを上書きしても、先に開いていたPCだけ古い内容を見続ける可能性があります。

?v= がしていること

更新後のiframeには、新しいバージョン番号を付けました。

<iframe
  src="/roadmap.html?v=20260715-2"
  loading="eager"
  title="ロードマップ"
></iframe>

?v= はファイルを書き換える命令ではありません。同じ実体を「新しい住所として取りに行かせる」ための目印です。

/roadmap.html?v=20260715
/roadmap.html?v=20260715-2

この2つは通常、異なる対象URIとして別のキャッシュキーになります。ただし、CDNやキャッシュ設定がクエリを無視する構成もあるため、本番環境での確認は必要です。

#5 はキャッシュ破棄に使えない

/roadmap.html#5 のようなハッシュは、取得したHTML内の位置やスライド番号をブラウザ側で指定する情報です。通常はサーバーへのHTTPリクエストに含まれないため、キャッシュ更新用のバージョン番号には使えません。

スーパーリロードで変わらなかった理由

スーパーリロードはブラウザ側キャッシュの影響を切り分けるには有効です。しかし、保存されている元データや参照先そのものを書き換える操作ではありません。

• Elementorの保存データ自体に3本のiframeがあれば、再取得しても3本が表示されます。
• 固定ページが旧いiframe URLを出力していれば、正しく再読み込みしても旧い参照先へ進みます。
• サーバー・CDN・Elementor側が古いHTMLを返していれば、ブラウザだけ更新しても変わりません。
• そもそも別URLを開いている場合、再読み込みはその別URLを忠実に読み直すだけです。

つまりスーパーリロードは「正しい住所にいるが、ブラウザだけが古い」という条件では効きます。一方、「住所や建物の案内板そのものが違う」場合は、構造と参照URLを直す必要があります。

実際に行った修正

1. 固定ページのElementorデータをバックアップ
   本番を触る前に、元へ戻せる状態を確保しました。
2. 本番で使うプレーンHTMLを正本に決定
   全6スライド・STEP 0〜10を持つ56,269バイト版を本番の参照先としました。
3. 不要なiframeをDOMから削除
   旧Overviewとキーワード工場を固定ページから外し、ロードマップ1本に統一しました。
4. 新しいバージョン番号へ変更
   iframeの参照先を ?v=20260715-2 に変更しました。
5. Elementorから公開
   HTML本体だけでなく、それを呼び出す外側の保存データも更新しました。
6. ログアウト状態でも検証
   PC・スマホ幅、iframe数、コンソールエラー、公開HTMLのハッシュを確認しました。

同じ問題が起きたときの診断表

再発防止チェックリスト

• 本番で使うHTMLの正本を1つに決める
• 候補版と本番版の保存場所を分ける
• 固定ページ内のiframe数を公開前に確認する
• display:none の旧素材も不要なら削除する
• 更新ごとに新しいversion queryを付ける
• 外側と内側を別ページとして検証する
• ログアウトまたはシークレット環境で確認する
• PC・スマホで取得URLが同じか確認する
• ElementorのFiles & Dataも必要に応じてクリアする
• 公開ファイルの容量・更新日時・ハッシュを記録する

今後の運用ルール

参考資料

• RFC 9111 — HTTP Caching / Cache Key
• RFC 3986 — URIのQueryとFragment
• MDN — <iframe>: HTMLインラインフレーム要素
• Elementor公式 — My changes do not appear online

まとめ

今回、上下に別素材が出た直接原因はElementorへ保存された複数iframeでした。PCだけ旧版に見えた背景には、最大48時間のキャッシュと、PC・スマホで開いていたURLの違いがありました。

スマホのURLをPCへコピーして直ったのは、キャッシュが同期されたからではありません。WordPressの外枠を迂回し、別URIにある正しいHTMLを直接開いたからです。

WordPressで「更新したのに端末ごとに表示が違う」ときは、レスポンシブ設定だけでなく、外側のページ、iframeの参照先、静的HTML、URLごとのキャッシュを分けて確認することが解決への近道になります。