Elementor is introducing something that could significantly change how agencies build WordPress websites: an official MCP connection for tools such as Codex, Claude Code and Cursor.
https://github.com/orgs/elementor/discussions/37152
Instead of generating HTML somewhere outside WordPress and then rebuilding it manually, an AI coding agent can now work directly with an Elementor website and create real, editable Elementor structures.
We have been testing the new Elementor MCP on something slightly more interesting than a demo environment: our existing production agency website. This is the example landing page generate via Elementor MCP and chrome extension https://webgate.digital/ai-native-website-agency/
The website already contains years of existing Elementor V3 components, global styles and production content. Our question was simple: Can we introduce an AI-first Elementor development workflow without rebuilding the website or breaking the existing V3 setup?
So far, the answer looks very promising.
Our setup
Our current workflow combines:
- WordPress
- Elementor Pro
- existing Elementor V3 pages and components
- Elementor V4 / Atomic Elements
- Elementor MCP
- Codex
- Claude Code
- Figma
- screenshots and visual references
- browser-based visual QA
- the Elementor visual editor for final adjustments
The important part is that this is not a replacement project. We are not rebuilding webgate.digital in Elementor V4. Instead, we are gradually introducing Atomic Elements and MCP-based development into an existing Elementor V3 website.
That makes the test much closer to what an agency would face with a real client website.
The first production use case
Our first larger test was a new landing page: https://webgate.digital/ai-native-website-agency/
The page itself is also fittingly about our AI-native approach to website development. We wanted to build it using a mix of existing Webgate design patterns and entirely new sections. Instead of starting with an empty Elementor canvas and manually assembling every container, we worked mostly through Codex and Claude Code.
The workflow looked roughly like this: Brief → existing website context → screenshots / Figma → prompts → Elementor MCP → visual QA → refinement
Some parts reuse existing Elementor V3 structures from the website. Other sections were created as new V4 Atomic structures through MCP. Both approaches live on the same production website. That was one of the things we specifically wanted to test.
V3 and V4 can coexist
One of our biggest questions before testing MCP was whether introducing Atomic Elements would force us into an all-or-nothing migration.
So far, that has not been necessary. We can keep existing V3 sections and widgets while creating new sections using V4 Atomic Elements.
This is important for agencies and complex production websites. A typical production Elementor site may contain hundreds of pages built over several years. Rebuilding everything simply to adopt a new development workflow would rarely make commercial sense.
A much more realistic migration path is:
- keep stable V3 structures where there is no reason to touch them
- build new sections and landing pages with Atomic Elements
- replace older structures gradually when they need redesigning
- eventually increase the percentage of the site running on the new system
That is essentially the approach we are taking with Webgate.
Elementor itself currently describes V4 as the Atomic Editor while maintaining V3 functionality alongside it. The Elementor 4.3 beta also expands MCP support and Atomic capabilities rather than requiring an immediate migration of existing pages. Elementor announcement
What Elementor MCP actually does
MCP stands for Model Context Protocol. The important part is not the acronym.
It means tools such as Codex or Claude Code can interact directly with Elementor instead of only giving you instructions or generating code that you manually copy somewhere else.
Elementor MCP exposes Elementor capabilities through the WordPress AI Abilities system.
A connected agent can currently work with things such as:
- creating pages and layouts
- editing existing layouts
- creating and applying classes and variables
- working with responsive settings
- working with components
- connecting dynamic data
- managing Theme Builder templates
- creating popups
- working with Elementor structures directly
The result is still Elementor. You can open the generated page in the Elementor editor and continue editing it normally.
Elementor also saves MCP-generated work as a draft rather than immediately publishing it. Elementor announcement
That last point matters.
For us, the value is not AI generating a website autonomously.
The value is dramatically reducing the amount of mechanical work required to translate a design decision into Elementor structure.
A simple Elementor MCP setup
At the time of writing, Elementor MCP is part of the Elementor 4.3 beta.
For testing, Elementor currently recommends:
- Go to Elementor → Editor → Tools → Version Control
- Enable beta testing.
- Update Elementor to the latest 4.3 beta.
- Go to Elementor → Editor → Settings → Atomic Editor
- Activate the Atomic Editor.
- Then go to Elementor → Elementor MCP.
From the MCP screen you can choose the client you want to connect.
Elementor currently supports setup flows for tools including:
- Claude Code
- Claude Desktop
- Codex
- Cursor
- other MCP-compatible clients
Elementor generates a setup prompt that contains the connection information required by the AI tool.
Under the hood, the connection uses a WordPress Application Password. Elementor can create this automatically during the setup flow. Elementor announcement
Once connected, a simple first test is something like:
“Create a new draft page and add an Atomic hero section with a headline, paragraph and two CTA buttons. Use the existing website design system.”
Then open the page in Elementor and inspect what was generated.
Cloudflare can block the connection
On webgate.digital, Cloudflare initially interfered with authenticated WordPress REST API requests used by Elementor MCP.
We fixed it with a custom WAF rule matching webgate.digital requests starting with /wp-json/ and skipping the specific Cloudflare security check that was blocking them, while leaving the rest of the site protection enabled.
The goal is simple: allow authenticated MCP traffic without weakening protection for the rest of the site.
Wordfence can block the connection
There is one practical issue worth mentioning when connecting MCP to an existing production website. Security plugins and server-level firewalls may block remote authentication or REST requests. In our case, this is something to check when Wordfence is installed.
Elementor MCP relies on WordPress Application Password authentication. If the AI client cannot authenticate even though the credentials are correct, check whether Wordfence, another security plugin, Cloudflare or the hosting firewall is blocking the request.
The practical debugging order is:
- confirm that WordPress Application Passwords are available for the user
- check that the MCP user has the required permissions
- verify that WordPress REST API requests are not blocked
- check Wordfence firewall logs
- allow the required application/API access if Wordfence blocks it
- check hosting or reverse-proxy security rules if authentication still fails
Do not disable the entire firewall permanently just to make MCP work.
Treat the AI connection like any other authenticated integration and allow only the access it actually needs.
Our most useful MCP use cases so far
The interesting part is not asking AI to “build me a website”. It is giving an agent precise development tasks. That distinction makes a huge difference.
Here is an example of the prompts used to build our landing page:
1. Building a new section from a brief
For example:
“Create a services section with six service cards. Follow the visual language of the existing site, use Atomic Elements and reuse our existing variables.”
This removes a lot of repetitive layout work. The developer can focus much more on structure and design decisions instead of clicking through dozens of controls.
2. Building from screenshots
Screenshots are surprisingly useful.
We can show the agent an existing Webgate section or another visual reference and ask it to create a structurally similar section using native Elementor elements.
The screenshot provides visual intent.
MCP handles the actual Elementor implementation.
3. Figma-to-Elementor implementation
This is probably one of the more interesting long-term workflows. The AI tool can have access to the Figma context and Elementor at the same time.
That creates a workflow closer to:
Figma frame → agent interpretation → native Elementor structure
rather than:
Figma → developer manually reconstructs every value inside Elementor
Elementor specifically highlights this type of workflow: an AI client can consume context from systems such as Figma, Drive or Notion and then use that context while building in Elementor. Elementor announcement
Human review is still important, particularly around responsive behavior, spacing, typography and design-system consistency. But the amount of mechanical implementation work can be significantly reduced.
4. Reusing existing V3 structures
Not every section needs to be rebuilt with Atomic Elements. Sometimes the fastest approach is simply to reuse something that already works. On our landing page, we mixed existing V3 modules with newly generated Atomic sections. That is currently one of our favourite aspects of the workflow.
AI does not force us into a new architecture everywhere. We can choose the right implementation for each part of the page.
5. Iterating on structure
MCP becomes even more useful after the first version exists. Instead of manually restructuring containers, we can ask:
“Change this section from three equal columns to an asymmetric 40/60 layout.”
Or:
“Move the visual above the content on mobile and keep the desktop layout unchanged.”
Or:
“Replace these six individual blocks with one reusable component.”
This starts feeling much closer to working with code than working with a traditional page builder.
6. Content and copy iteration
Because Claude or Codex already has the page context, content changes can happen together with structural changes.
For example:
“Shorten all six service descriptions to a maximum of two sentences and make the section easier to scan.”
The agent can update both the content and the underlying Elementor structure during the same workflow.
7. Repetitive landing-page production
This may ultimately be the highest-value use case for marketing teams.
Once a design system and page patterns exist, producing another campaign page should require less manual assembly.
The process becomes closer to giving the agent a specification:
- use this hero pattern
- use this logo section
- add these six benefits
- use this CTA component
- apply the website’s variables
- implement the supplied copy
- create tablet and mobile versions
A developer still reviews the result.
But the starting point can be dramatically further ahead.
Elementor MCP vs browser access
This distinction is important. We use them for different jobs.
Elementor MCP is the hands
MCP is used when the AI needs to actually work with Elementor.
For example:
- inspect Elementor structure
- create a page
- add elements
- restructure containers
- change content
- apply classes
- use design variables
- create or modify components
MCP gives the agent structured access to the system.
The browser is the eyes
Browser access is better for understanding the rendered result.
We use it to:
- open the live page
- inspect how the design actually looks
- compare implementation against a screenshot or Figma design
- identify spacing or alignment problems
- inspect desktop and mobile behaviour
- verify interactions
- run visual QA
This creates a useful loop:
MCP → render → browser inspection → new instructions → MCP
For example:
“Open the page and compare the hero against this reference. The headline is too narrow, there is too much whitespace above the CTA and the image should start approximately 80px higher. Update the Elementor section.”
The browser helps the agent understand the problem.
MCP allows it to make the actual change.
We would not treat a browser extension as a replacement for Elementor MCP.
They solve different parts of the workflow.
Why we still use the Elementor visual editor
The interesting outcome of this experiment is that AI has not made Elementor’s visual editor less useful. It may actually make it more useful.
AI is very good at:
- producing the first implementation
- building structure
- repetitive configuration
- restructuring sections
- applying systematic changes
- translating clear instructions into implementation
Humans are still faster at many micro-decisions.
Moving something by a few pixels, testing a visual balance or quickly adjusting a responsive breakpoint can sometimes be easier directly in Elementor than writing another prompt.
That leads to the workflow we currently find most interesting:
AI-first development + visual editing.
Use Codex or Claude for the heavy implementation work.
Use Elementor for final visual tweaking.
Then go back to the agent when another structural change is needed.
It does not have to be AI versus a visual builder. The combination may be substantially better than either workflow alone.
What surprised us
Before testing the MCP, our assumption was that AI-powered Elementor development would mostly be interesting for generating completely new websites.
After using it on our production site, we see the bigger opportunity elsewhere. It is in existing websites.
An agency can potentially take a website that has been running for five years and start using AI agents for the next landing page without rebuilding the previous 200 pages.
Where the workflow still needs human supervision
We would not currently give an agent unrestricted access to a production website and tell it to redesign everything. Our workflow still includes human review.
Especially for:
- information architecture
- UX decisions
- visual hierarchy
- accessibility
- responsive behaviour
- design-system consistency
- browser testing
- performance
- final publishing
The difference is where the developer spends time.
Less time assembling containers. More time reviewing and improving the result.
That is a much more interesting use of senior development time.
Where we think this is going
Our plan at Webgate is straightforward.
We want to gradually use Elementor MCP for:
- new landing pages
- campaign pages
- page redesigns
- structural website improvements
- Atomic component development
- repetitive site-wide changes
- eventually more complex WordPress development workflows
Elementor is also positioning MCP as a broader entry point into the WordPress ecosystem through WordPress AI Abilities. With additional tooling such as Angie, the same agentic workflow can extend beyond page layouts into areas such as custom widgets, WordPress administration and content management. Elementor announcement
For agencies, that is potentially more significant than AI page generation itself.
We are moving toward a workflow where the developer describes an intended outcome, the agent performs much of the implementation, and the developer reviews, tests and improves it.
The visual editor remains available whenever direct manipulation is simply faster.
That combination feels less like replacing Elementor development and more like giving Elementor developers a much faster interface to the platform.
After our first production tests, we are seriously considering making this our default Elementor development workflow.
And that is probably the strongest signal we can give it.
