HTML を
編集可能な Elementor ページに

よくある 2 つの方法の問題点

完成した HTML ページがすでに手元にあり、それを WordPress に入れたいとき、普通は 2 つの選択肢しかなく、どちらも良くありません。1 つ目はマークアップを丸ごと 1 つの HTML ウィジェットに貼り付ける方法です。表示は正しくても、Elementor はそれを不透明な 1 つの塊として扱います。見出しをクリックしてサイズを変えることも、アイコンを差し替えることもできず、クライアントはコードを開かなければ一文すら直せません。ページは Elementor の中にあるのに、その一部にはなっていないのです。

2 つ目の選択肢は、すべてのセクションを手作業で作り直すことです。結果は Elementor らしく完全に編集可能ですが、長いマーケティングページなら何時間もかかり、元の余白やタイポグラフィを正確に合わせる作業は退屈でミスも起きやすいものです。

変換は第三の道です。マークアップをそのまま保持するのでも手作業で作り直すのでもなく、ブラウザがページを読むのと同じ方法——実際の計算済みスタイル——でページを読み取り、各部分を最も適した Elementor ウィジェットへマッピングします。

なぜスタイルシートではなく計算済みスタイルなのか

コンバーターはあなたの CSS を解析しようとはしません。ページは隔離されたフレーム内で実際にレンダリングされ、各要素はブラウザが実際に解決した値で測定されます。この違いは、聞こえる以上に重要です。

つまり、クラスベースの CSS、カスケード、継承、カスタムプロパティ、ショートハンドがすべてそのまま機能します。読み取られる値が最終値だからです。CSS 変数で書かれた色は、解決後の色として届きます。clamp で書かれたフォントサイズは、実際に適用されたサイズとして届きます。あなたのブラウザと意見が食い違う CSS パーサーは存在しません。

同時に、理解しておくべき問題も 1 つ生まれます。以下で説明する慎重な処理の大半は、これが理由です。ブラウザは相対値を絶対ピクセルに解決します。幅 100% はピクセル数として報告されます。auto の左右マージンは、その瞬間に要素を中央に置いていたピクセル数として報告されます。分数で書かれたグリッド列はピクセル幅として報告されます。これらの数値をそのまま写せば、レイアウトは変換を実行したときの幅で凍結されてしまいます。

そのため、相対的な意図はコピーではなく再構築されます。画像はコンテナに対するパーセンテージで表現され、全幅画像には固定幅を一切書きません。max-width と左右対称の auto マージンを持つブロックは中央配置と認識され、Boxed コンテナになり、どの画面サイズでもネイティブに中央配置されます。等しいグリッドトラックはサブピクセルの丸めを許容しつつ数値比較され、分数単位で書き戻されるため、グリッドは引き続きリフローします。

構造:コンテナと、作らない判断

マークアップ内のすべてのブロックレベルのラッパーは Elementor コンテナになり、そのパディング、背景、境界線、角丸、影、flex や grid の設定を引き継ぎます。忠実なマッピングですが、文字どおりに実行すると深いツリーになります。section の中に wrapper、その中に row、その中に column——見出しに到達する前にコンテナが 4 つです。

それを軽減する仕組みが 2 つあります。視覚的にもレイアウト的にも一切効果のないラッパー——背景、境界線、パディング、影、最大幅、最小高さがなく、flex や grid でもない——は折りたたまれます。取り除いても何も変わらないからです。そして、実質的に 1 つのコンテンツを囲む装飾枠にすぎないカードは丸ごと平坦化され、枠はウィジェット自体に移されます。

この 2 つ目のルールがあるからこそ、5 枚の画像カードの行は「5 つの Image Box ウィジェットを持つグリッド」になり、「それぞれ 1 つのウィジェットを持つ 5 つのコンテナを持つグリッド」にはなりません。これは経験豊富な Elementor ユーザーが手作業で組む構造であり、後からスタイルを変えるのもずっと簡単です。

タグだけでなくパターンを認識する

見出しを Heading ウィジェットにマッピングするのは当たり前です。有用な仕事は形状の認識にあります。アイコン 1 つ、見出し 1 つ、短い段落 1 つを含むコンテナは Icon Box。画像 1 枚、見出し 1 つ、段落 1 つを含むコンテナは Image Box。各行にアイコン 1 つとテキストを含む繰り返し行のリストは Icon List になり、行ごとに編集可能な項目になります。

これらの検出は意図的に厳格です。カードに見出しと段落以外のテキスト——ステップ番号、バッジ、価格——が含まれる場合、パターンは適用されず、ブロックは通常のコンテナのままです。そのテキストを失うことは、ツリーが少し深くなることよりずっと悪いからです。信頼できる保守的な検出は、毎回確認が必要な積極的な検出より価値があります。

ボタンも同じ仕組みです。実際のコールトゥアクションの多くは button 要素ではなく CSS を当てたアンカーなので、複数のシグナルが一致したときにだけリンクをボタンとして扱います。短いテキスト、ブロックレベルの子がない、背景または境界線がある、角丸がある、実際のパディングがある、ブロック的な display である——どれか 1 つだけでは誤検出になります。

アイコンと画像:判断が必要な 2 つのこと

アイコンは Elementor アイコンライブラリの実際の項目になり、後からアイコンピッカーで差し替えられます。これはソースがアイコンフォントのクラスを使っている場合に機能します。手描きのインライン SVG の場合、そのグラフィックはアイコンコントロールに一切入れられず、サイズや線をページの CSS に頼っていた SVG は、ページから切り出された時点でそのスタイルも失います。名前で照合できないアイコンは、間違った推測で埋めるのではなく、意図的に空欄のままにされます。

画像はもう 1 つの判断です。data-URL の画像やローカルファイルパスは WordPress のメディア添付にはなれないため、空のスロットになります。各スロットは元の alt テキストをキャプションとして保持するので、どの画像がどこに入るのか分かります。ソースが実際にアップロード済みの画像 URL を参照していれば、手作業は一切不要でそのまま取り込まれます。先に画像をアップロードしておくことが、取り込み後の作業を最も減らす 1 つの変更です。

変換できないもの——正直に

スクリプトは削除されるため、カスタム JavaScript で動いていたものはすべて静的なマークアップとして届き、対応するネイティブウィジェットで再構築する必要があります。フォームの送信アクションは取り除かれます。エンドポイントを持ち込めば、訪問者のデータがあなたの選んでいない場所へ送られてしまうからです。ナビゲーションメニューは実際の WordPress メニューに向ける必要があります。ホバーやフォーカスの状態は静止したページからは読み取れないため、後から設定します。アニメーション、トランジション、スティッキー動作は Elementor 自身のコントロールで再適用する方が良い結果になります。

疑似要素は特筆に値します。人を驚かせるからです。before や after で描かれた装飾図形、引用符、下線のアクセントはそもそも DOM ノードではないため、ウィジェットにはなれません。変換後にデザインのディテールが欠けていたら、まずここを確認してください。

最もきれいな結果を得るために

変換の品質は、与えるマークアップでほぼ決まります。セマンティックなタグは曖昧さなくマッピングされます。セクションごとにラッパー 1 つの浅い DOM なら、ツリーは編集しやすいままです。インラインまたは単一の style ブロックにある CSS は実際に測定できますが、読み込まれないフレームワークのスタイルシートでは、スタイルのないページを変換することになります。gap で設定した間隔は、多数ではなく 1 つのコントロールになります。

エクスポート前に、毎回 15 秒だけ構造マップを見る価値があります。コンポーネント数、最大ネスト深度、信頼度の内訳が表示され、ツリーと連動するライブプレビューも付いています。深度が高い、あるいは複数の行が HTML のまま残っている場合、ソースを直して再変換する方が、Elementor 内で出力を修繕するより常に速いのです。

長いページは、1 セクションずつ持ち込みましょう。目的のブロックにコピールートを設定すれば、そのサブツリーだけがエクスポートされ、ページの外側ラッパーやヘッダー、フッターは置き去りにできます。小さな単位の方が検証がずっと簡単で、また使うものはその場でテンプレートライブラリに保存できます。