AI tools such as Claude and Codex can design a convincing web page in minutes. The result is usually HTML: code that looks right in a browser but can't be opened in Elementor, edited by a client or handed over as a working WordPress website. Until recently, getting from that HTML to a usable Elementor page meant rebuilding it by hand.
Elementor's MCP webinar on 15 October 2026, HTML to Elementor: turn AI designs into Elementor pages, tackled that gap directly. Roi from Elementor and Elli, Elementor's MCP Product Manager, took a website from first idea to a finished Elementor build. They used AI to brainstorm ideas, design the page in HTML and set up a design system. The AI tool then used Elementor MCP to rebuild it all as editable Elementor elements.
At Nivo, we design Elementor websites every day, and we've already rebuilt our own website using Elementor MCP and Claude. So, here's what we learnt and how you can convert HTML to editable Elementor pages.
Quick answer
To convert HTML to Elementor with AI, start by designing the page in HTML with a tool such as Claude or Codex, where changes take a prompt rather than a rebuild. Next, define a design system for colours, typography, spacing, buttons and classes. Your AI tool can then use Elementor MCP to rebuild the design as native Elementor elements you can edit like any other page.
Check the first sections carefully before letting AI build the rest, and test the finished site by hand. AI speeds up the build, but it doesn't replace design judgement, quality checks, and human input on the things that really matter.
What the webinar showed
The webinar followed one project from start to finish. Elli began with an idea for a travel agency website, then switched to a space tourism website once a stronger creative direction emerged. That site became the running example for the rest of the session: an HTML version first, then a design system, then a native Elementor build with responsive settings, interactions and a custom widget.
The HTML page in the webinar was created with Codex. We use Claude for the same kind of work, and Elementor MCP supports both, along with other tools such as Cursor. As we said in our guide on 'how Elementor MCP is changing the way we build websites', your choice of AI tool matters far less than how well the finished website meets the brief.
What made this session useful for us wasn't the speed of any single step. It was the order of the steps, and how much of the important work happens before Elementor is opened at all.
You can watch the webinar on YouTube to see the process for yourself.
How the HTML-to-Elementor workflow works
The full approach from HTML to Elementor breaks down into five stages. None of them are complicated on their own, but the order affects how much rework is needed later.
Step 1: Brainstorm with AI before designing anything
Rather than starting with a wireframe or a homepage, the webinar began with ideas. Elli used AI-generated images to try out different visual styles before settling on a direction. The switch from travel agency to space tourism happened at this stage, when changing course cost almost nothing.
This is where we see the most immediate value for client projects. Exploring several creative routes with Claude before committing to a design gives us more options to discuss with a client, and makes it easier to spot a weak idea early.
The brief still decides which route is right, though. A striking concept only works if it suits the business, its customers and what the website needs to achieve.
Step 2: Build and refine the design in HTML
This was the biggest takeaway from the session: you don't have to start building directly in Elementor.
Instead, the AI creates an HTML version of the page first. Layouts, animations, styling and content can all be changed quickly at this stage, because each change is a prompt rather than a round of edits inside WordPress. Once the design is right, the AI tool rebuilds it as native Elementor elements through Elementor MCP.
For us, this could cut down the repeated design changes that tend to happen once a build is underway. Agreeing the layout in HTML first means fewer revisions in WordPress and a clearer starting point for the build itself. We've already worked this way on our own website: our new header and footer, and five different homepage hero concepts, were prototyped and reviewed in HTML before we chose a direction.
Step 3: Set up a design system before building pages
Before any pages are built, the AI is given a design system: colours, typography, spacing, button styles and reusable classes.
Elli explained that this gives the AI a clear reference to work from. Without one, as Roi pointed out, the AI decides its own approach. In our experience, that's when small inconsistencies in spacing, buttons or text styles start to creep in from page to page.
A design system also makes the finished website easier to look after. When styles are defined once as global classes and variables, a brand update can be made in one place rather than on every page. That consistency makes ongoing Elementor maintenance more straightforward too.
Step 4: Check the first sections before letting AI continue
Once the design system was in place, Elementor MCP began building the website in Elementor. Elli explained that the first sections it creates always need to be checked carefully. Some questions to consider whilst you check them are:
Are the right classes applied?
Does the styling match the design?
Does everything work?
Are the responsive settings correct?
Only once those first sections are right is more of the website handed over to AI.
It's a simple principle, and it echoes what we found when rebuilding our own site, where each page was checked and signed off before we moved on. A mistake in the first section tends to repeat in every section built after it. Spotting a wrong class on the homepage is a quick fix; spotting it after twenty pages have been built is a much bigger and longer job.
Step 5: Keep the project organised so AI understands it
The presenters recommended keeping each website project organised within Claude or Codex, including design references, instructions and decisions already made.
With that context saved, Claude or Codex can follow how the project should be built without having everything explained again in every prompt. This matters most on larger websites with several page templates, such as service pages, location pages and blog posts, where small differences between templates are easy to miss.
Custom widgets and interactive features
The webinar also showed a custom interactive widget built for the space tourism website, using Elementor MCP alongside Angie, Elementor's free agentic AI plugin for WordPress, which Elementor MCP needs for custom widgets. The idea was brainstormed, the functionality refined, and the widget built specifically for that site rather than taken from an existing library.
This opens up more creative options for client websites. Interactive features have usually meant adding another plugin, and every add-on is another thing to update, maintain and check for conflicts. In some cases, a bespoke widget built for one specific job could do the same work with fewer dependencies.
Whether a bespoke widget is the better choice depends on what the plugin was doing. Swapping out a simple slider or tabbed section is a very different job from replacing a complex filtering system, and anything custom still needs testing and looking after like any other part of a website. We look at this in more detail in our guide to what Elementor MCP means for add-on plugins.
What AI still can't replace
Elementor's presenters were clear that MCP isn't magic: you still need to be "a professional that drives this whole project". That matches what we found when rebuilding our own website. AI took on much of the build work, but there was still a back-and-forth of inspecting the result, spotting issues and asking for adjustments. Sometimes a quick manual edit in Elementor was simply the fastest fix.
Responsiveness and functionality
Every page still needs checking on phones, tablets and desktops. Forms, buttons, interactions and custom widgets need testing to make sure they work as intended, not just that they look right.
When we rebuilt our own site, every page was checked at desktop, tablet and phone sizes before it was approved. Those checks caught problems the AI hadn't flagged, including images sitting at uneven heights in a grid and screenshots of client websites being cropped at the sides. A full check of our internal links also found links pointing to pages that had moved or were no longer being built. None of these would have been spotted without someone looking.
Content, spacing and overall quality
A page can be built quickly and still be wrong for the business. Content needs to be accurate and useful, spacing consistent, and the design suited to the people using the website. Those decisions depend on understanding the client, not just the tools.
Our own rebuild showed this clearly. The first pages Claude built were tidy and consistent, but side by side they looked too alike. We set a rule that there is no single page template, and built a library of section layouts so a case study, a guide and a service page each look like what they are.
Content needed the same attention. In one older article, several images didn't match the websites they were meant to show, and a client's website address had been assumed and was wrong. Both were corrected, and we now work to fixed content rules: real screenshots only, client reviews quoted exactly as written, and nothing stated that we can't back up.
What changes is where the time goes. With AI taking on more of the repetitive development work, more of a project can be spent refining the design and checking the finished website properly. We've written more about where AI speeds up a redesign and where people still matter.
What we're taking into our own projects
Our biggest takeaway is that the preparation before a website is built matters just as much as the build itself.
Using Claude to brainstorm, building an HTML version first, setting up a design system and carefully reviewing the first sections could make our whole development process more efficient. But efficiency is only part of it. The bigger opportunity is producing more creative, consistent websites while keeping everything editable in Elementor, so clients can still update their own text and images afterwards.
We're testing this workflow and refining it as we go. We won't claim it makes every project faster or that it suits every website we build. What it gives us is a more structured way to explore ideas, agree on designs earlier and keep quality consistent from the first page to the last.
Which websites could benefit from this approach?
Based on the webinar and our own work with Elementor MCP, an HTML-first approach looks particularly useful if:
You're starting a new website from scratch. There's no existing design to work from, so exploring several creative directions early helps you settle on the right one before any Elementor website design work begins.
Your current website looks dated. If you're planning a website redesign, trying new layouts in HTML first lets you compare different directions before anything changes on your live site.
Your website has lots of page templates. A design system and well-organised project context help keep service pages, location pages and blog posts consistent. If your site still uses older sections and columns, an Elementor V4 upgrade brings the classes and variables this approach relies on. It also matters for Elementor MCP itself, which currently builds with Elementor V4 (Atomic) elements; Elementor lists support for older V3 widget layouts as coming soon.
You want interactive features without a pile of plugins. A bespoke widget may be an option, assessed case by case. Fewer add-ons also means less to keep updated as part of your website care plan.
Some websites only need targeted improvements rather than a new design process, and our Elementor support and fixes service covers exactly that. If you're not sure which applies to yours, book a discovery call, and we'll help you work it out.
What this means for your website
AI is changing how Elementor websites can be designed and built, but it isn't changing what makes a good website.
The HTML-to-Elementor workflow puts more effort into the early stages, where ideas are cheap to test, and design decisions are easy to change. It then leaves experienced people to check that the finished website works properly for the business and the people using it.
For a business planning a new website, that could mean seeing more design options earlier, agreeing on the look and feel before the build starts, and still ending up with a site you can manage yourself in Elementor.
Planning a new Elementor website?
If you're thinking about a new website or a redesign, we can help you work out the right approach. As Elementor specialists, we design and build websites in Elementor and look after them afterwards with website care plans that include hosting.
Book a discovery call, and we'll talk you through where we'd start.
Frequently asked questions
Can you convert HTML to Elementor?
Yes, with an AI tool connected through Elementor MCP. The AI rebuilds the HTML design as native Elementor V4 elements, such as containers, headings, buttons and images. The result is a standard Elementor page you can open and edit in the editor, rather than code placed inside an HTML widget.
Why design in HTML before building in Elementor?
Changes are quicker to make in HTML, because each one is a prompt rather than a round of edits inside WordPress. Settling the layout, styling and content before the build starts usually means fewer revisions once the Elementor pages exist.
Which AI tools work with Elementor MCP?
Elementor MCP supports tools including Claude Code, Claude Desktop, Codex and Cursor, with an option for other MCP-compatible tools. The webinar used Codex to create the HTML page; at Nivo, we use Claude, and we can set up Claude with Elementor MCP for you.
What is a design system in Elementor?
A design system is a set of shared rules for a website: colours, typography, spacing, button styles and reusable classes. Giving one to AI before building means every page follows the same rules, and future style changes can be made in one place.
Do I need Elementor Pro to use Elementor MCP?
No. Elementor MCP needs Elementor 4.3.0 or later and WordPress 6.8 or later, and connecting it is free. Elementor's help centre lists Elementor Pro 4.3.0 or later for more advanced building tools, including forms, popups, loops, reusable components, headers and footers. You'll also need your own AI tool, such as Claude or Codex.
Can I still edit a website built this way?
Yes. Because the final pages are native Elementor elements, you can update text, images and layouts in Elementor without using Claude, Codex or any other AI tool.
