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

The problem with the two usual approaches

When you already have a finished HTML page and you need it inside WordPress, there are normally two options, and neither is good. The first is to paste the markup into a single HTML widget. It renders correctly, but Elementor treats it as one opaque block: you cannot click a heading to change its size, you cannot swap an icon, and a client cannot update a sentence without opening code. The page sits inside Elementor without being part of it.

The second option is to rebuild every section by hand. The result is idiomatic and fully editable, but for a long marketing page it is hours of work, and matching the original spacing and typography exactly is tedious and error-prone.

Conversion is the third path. Instead of preserving markup or recreating it manually, the page is read the way a browser reads it — with real computed styles — and each part is mapped to the Elementor widget that fits it best.

Why computed styles, not the stylesheet

The conversion does not try to parse your CSS. Your page is rendered in an isolated frame, and then every element is measured as the browser actually resolved it. That distinction matters more than it sounds.

It means class-based CSS, cascade, inheritance, custom properties and shorthand all just work, because the value being read is the final one. A colour written as a CSS variable arrives as the colour it resolves to. A font size written with clamp arrives as the size it actually is. There is no CSS parser to disagree with your browser.

It also creates one problem worth understanding, because it explains most of the careful handling described below: the browser resolves relative values into absolute pixels. A width of one hundred percent is reported as a pixel number. Auto side margins are reported as whatever pixels centred the element at that moment. Grid columns written as fractions are reported as pixel widths. Copying those numbers directly would freeze your layout at whatever width the conversion happened to run at.

So relative intent is reconstructed rather than copied. Images are expressed as a percentage of their container, and full-width images get no fixed width at all. A block with a max width and symmetric auto margins is recognised as centred and becomes a boxed container, which centres natively at any screen size. Equal grid tracks are compared numerically, with a tolerance for sub-pixel rounding, and written back as fraction units so the grid still reflows.

Structure: containers, and knowing when not to make one

Every block-level wrapper in your markup becomes an Elementor container, carrying its padding, background, border, radius, shadow and its flex or grid settings. That is a faithful mapping, but taken literally it produces deep trees: a section inside a wrapper inside a row inside a column is four containers before you reach a heading.

Two things reduce that. A wrapper with no visual or layout effect at all — no background, border, padding, shadow, max width, min height or flex and grid display — is collapsed, because removing it changes nothing. And a card that is really just a styled frame around one piece of content is flattened entirely: the frame moves onto the widget itself.

That second rule is why a row of five image cards becomes a grid holding five Image Box widgets, rather than a grid holding five containers that each hold one widget. It is the structure an experienced Elementor user would build by hand, and it is much easier to restyle later.

Recognising patterns, not just tags

Mapping a heading to a Heading widget is obvious. The useful work is in recognising shapes. A container holding one icon, one heading and one short paragraph is an Icon Box. A container holding one image, one heading and one paragraph is an Image Box. A list of repeated rows that each contain a single icon and some text is an Icon List, with one editable item per row.

These detections are deliberately strict. If a card contains extra text beyond its heading and paragraph — a step number, a badge, a price — the pattern is not applied and the block stays a plain container, because losing that text would be worse than a slightly deeper tree. Conservative detection you can trust is more valuable than aggressive detection you have to check.

Buttons work the same way. Most real calls to action are anchors with CSS, not button elements, so a link is treated as a button only when several signals agree: short text, no block-level children, a background or border, a corner radius, real padding and a block-like display. Any one of those alone would produce false positives.

Icons and images: the two things that need a decision

Icons can become real entries in the Elementor icon library, which means you can swap them from the icon picker afterwards. That works when the source uses icon font classes. When it uses a hand-drawn inline SVG, the graphic cannot enter the icon control at all, and an SVG that relied on page CSS for its size and stroke will also lose that styling once lifted out of the page. Where an icon cannot be matched by name, the control is left empty on purpose rather than filled with a wrong guess.

Images are the other decision. A data-URL image or a local file path cannot become a WordPress media attachment, so those become empty slots — each keeping its alt text as a caption, so you know which picture belongs where. If the source references real uploaded image URLs, they import with no manual step at all. Uploading your images first is the single change that removes the most post-import work.

What does not convert, honestly

Scripts are removed, so anything driven by custom JavaScript arrives as static markup and should be rebuilt with the matching native widget. Form submit actions are stripped, because carrying an endpoint across would send your visitors data somewhere you did not choose. Navigation menus must be pointed at a real WordPress menu. Hover and focus states cannot be read from a resting page and need setting afterwards. Animations, transitions and sticky behaviour are better re-applied with Elementor own controls.

Pseudo-elements deserve a special mention, because they surprise people. Decorative shapes, quote marks and underline accents drawn with before and after are not DOM nodes at all, so they cannot become widgets. If a design detail is missing after conversion, that is the first thing to check.

Getting the cleanest result

The quality of a conversion is decided mostly by the markup you feed it. Semantic tags map unambiguously. A shallow DOM with one wrapper per section keeps the tree editable. CSS that is inline or in a single style block can actually be measured, whereas a framework stylesheet that never loads leaves an unstyled page to convert. Spacing set with gap becomes one control instead of many.

Before exporting, the structure map is worth fifteen seconds every time. It shows the component count, the maximum nesting depth and a confidence breakdown, with a live preview linked to the tree. If the depth is high or several rows were kept as HTML, fixing the source and converting again is consistently faster than repairing the output inside Elementor.

For a long page, bring it across one section at a time. Set a copy root on the block you want and only that subtree is exported, so the page outer wrappers, header and footer stay behind. Smaller units are far easier to verify, and anything you will use again can be saved to your template library as you go.