変換の品質は、ほとんどの場合、入力するHTMLで決まります。コンバーターに何かを貼り付ける前に、ぜひ確認しておきたいチェックリストを紹介します。
1. セマンティックなタグを使う
見出しには <h1>–<h6>、本文には <p>、行動喚起（CTA）には <button> または <a class="button">、リストには <ul> を使います。ネイティブタグはネイティブウィジェットに対応します。スタイルを付けた <div> で見出しを装っても検出はできますが、本来のタグなら曖昧になることがありません。
2. DOMを浅く保つ
ラッパーはセクションごとに1つにします。ネストが1段深くなるたびに、エディターでクリックしてたどらなければならないコンテナが1つ増えます。スタイルを持たない純粋に装飾目的のラッパーは自動的に折りたたまれますが、パディングや背景を持つラッパーは、削除するとレイアウトが変わってしまうため残されます。
3. CSSを自己完結させる
インラインスタイルか1つの <style> ブロックが最もきれいに変換されます。コンバーターはブラウザーが実際に計算したスタイルを読み取るためです。外部フレームワークのスタイルシートが読み込まれないと、ページはスタイルなしで表示され、まさにそのスタイルなしの状態が変換されてしまいます。
4. 画像を先に整理する
最善なのは、メディアライブラリにアップロードして実際の https:// URLを使うことです。それができない場合は、「画像」を「空の画像プレースホルダー」に切り替え、あとから画像を入れます。各スロットには alt がキャプションとして残ります。Base64画像やローカルのファイルパスは、WordPressに確実にインポートできないため、仕様としてプレースホルダーに置き換えられます。
5. インラインSVGよりFont Awesomeのクラスを優先する
編集可能なアイコンとしてElementorのアイコンライブラリに入れられるのは、クラスベースのアイコンだけです。インラインSVGはアイコンコントロールに入れられず、ページのCSSで指定されていたサイズや線の色も失われます。
6. 子要素ごとのマージンではなくgapを使う
フレックスやグリッドの親要素に設定したgapは、Elementorの1つのギャップコントロールに対応します。子要素ごとに指定したマージンはウィジェットごとに引き継がれるため、あとで調整するのがはるかに面倒になります。
7. max-widthと自動マージンで中央揃えにする
max-width + margin:0 auto のパターンは認識され、幅が「ボックス」のコンテナになります。これはどの画面サイズでもネイティブに中央揃えされます。
8. 持ち込みたくないものは取り除いておく
スクリプト、トラッキングタグ、Cookieバナー、サードパーティの埋め込みは、安全のために削除または無効化されます。フォームは送信アクションを失うため、Elementorのフォームウィジェットをサイト上の実際の送信先に接続し直す必要があります。ナビゲーションメニューは、実際のWordPressメニューを指すように設定し直す必要があります。
9. セクションごとに変換する
大きなページでは、ビジュアルピッカーを使うか、構造マップでコピールートを設定して、1セクションずつ取り込みます。小さな単位のほうがはるかに確認しやすく、サイトのヘッダーやフッターをうっかりインポートしてしまうことも防げます。
10. エクスポート前に構造マップを確認する
コンポーネント数、最大ネスト階層、信頼度の内訳を確認してください。緑の行は直接変換されたもの、赤の行はHTMLのまま残されたもので、見直す価値があるのは赤の行です。ソースを修正して再変換するほうが、Elementor内で結果を手直しするより、たいていは速く済みます。
11. まず各ブレークポイントでソースを開いてみる
このリストで最も価値が高く、そして最も省かれがちな項目です。レイアウトはブレークポイントの幅ごとに測り直され、そこでブラウザーが計算した結果がそのまま保存されます。うまく整えてくれる解釈の層はありません。
そのため、変換する前に、ブラウザーでソースを約820pxと390pxの幅にリサイズしてみてください。390pxですでに崩れているレイアウトは、崩れたままのモバイルレイアウトとして忠実に変換されます。最初からソースにあった問題を変換のせいにして、1時間を無駄にしてしまうのはよくあることです。2分ほどリサイズしてみれば、正常に動くものを変換しようとしているのかどうかがわかります。
12. 気づかないうちに変換されない細部を確認する
ソースでは問題なく見えるのに、変換後にはただ消えているものが4つあります。事前にチェックしておけば、それぞれが原因不明の問題ではなく、想定済みの作業になります。
- 擬似要素による装飾。
::beforeや::afterで描かれたもの（引用符、アクセントバー、グラデーションのオーバーレイ、下線の装飾など）はDOMノードではないため、ウィジェットにはなりません。デザインの細部が消えたら、まずこれを疑ってください。 - インラインブロックのリンクではない、角の尖ったボタン。 本物の
<button>要素と、インラインブロックのリンクやbtn/buttonクラスを持つリンクは、必ず変換されます。それ以外（フレックスでスタイルを付けたリンク、クリック可能なdivなど）は、3px以上の角丸を条件に含む形状テストを通過する必要があるため、角の尖ったものはスタイル付きテキストのまま残ります。リンクにbtnクラスを付ければ、まとめて解決できます。 - 手元にないフォント。 ファミリー名は引き継がれますが、フォントファイルは引き継がれません。変換前にWordPressサイトにフォントをインストールしておいてください。そうしないと、代替フォントで表示された結果を評価することになり、実際には存在しない違いを追いかける羽目になります。
- ホバーとフォーカスの状態。 計算済みスタイルから読み取れるのは通常時の状態だけです。ホバー時のカラーはすべてインポート後の作業になるため、作業を始める前に、ページにインタラクティブな要素がいくつあるかを把握しておくとよいでしょう。
良いソースとは
ここまでの内容は、1つの段落にまとめられます。最もきれいに変換されるHTMLは、セマンティックで、浅く、自己完結しています。本来の見出しタグと段落タグを使い、ラッパーはセクションごとに1つ、レイアウトはフレックスやグリッドと gap で組み、アイコンはFont Awesomeのクラス、画像は実際にホストされたURL、CSSはすべて1つのstyleブロックにまとめ、スクリプトは含めません。
これは偶然ではなく、そもそもよく書かれたHTMLの姿でもあります。既存のソースを引き継ぐのではなく自分で生成するのであれば、プロンプトに1文加えるだけでこれらの特性を指定でき、このチェックリストの大半が不要になります。
インポート後
ボタンのリンクを設定し直し、フォームとメニューを接続し直し、3つのデバイス表示を順に確認し、プレースホルダーの画像をアップロードし直します。そうすれば、ごく普通のElementorページになります。完全に編集可能で、あなたとコンテンツの間にHTMLウィジェットが挟まることもありません。