You can use Claude to edit Elementor pages, but the how matters way more than people make it sound. Four real workflows exist today: write content in Gutenberg and open in Elementor, hand-build the layout and let AI draft the copy, clone an existing page and customize the variant, or use a build-from-scratch MCP. This guide covers each, with concrete cases for when to reach for which.
The Question That Won't Go Away
If you're in any WordPress or AI subreddit lately, you've seen the question. “Can Claude just build me an Elementor page?” Variants: “How do I get AI to design pages in Elementor?” “What's the best MCP server for Elementor?”
The honest answer is: yes, you can use Claude to edit Elementor pages — but the how matters way more than people make it sound. There are four real workflows that work today. Each is good at a different thing. Picking the wrong one is what leads to most of the “AI page generation is broken” frustration you see on Twitter.
This guide covers all four, with concrete cases for when to reach for each.
Workflow 1 — Write in Gutenberg, Open in Elementor
The simplest path, and the one most people skip because it doesn't sound impressive.
What it looks like: You ask Claude to draft your blog post or service-page content. Claude writes it directly into WordPress using the standard block editor (Gutenberg) via an MCP server. You open the post in Elementor. Elementor wraps each block as a widget. You're done — Claude wrote the content, Elementor handled the layout.
What this is good for
- Blog posts where the layout is template-driven anyway
- Service pages that follow a consistent pattern across your site
- Long-form content where the design is mostly typography
- Bulk content updates across many existing pages
Why this works: AI is great at writing. AI is currently not great at making pixel-level layout decisions on a marketing page. This workflow plays to AI's strength and skips its weakness entirely. The Elementor editor still does the visual work — you're just letting Claude handle the words.
This only works for posts where Gutenberg block content is what's stored. If your Elementor page is built widget-by-widget in the Elementor editor (which is most marketing pages), the post content is empty and AI has nothing to write to. Check your post's “Edit with WordPress” view — if it looks empty, your page is Elementor-native and this workflow won't help.
Workflow 2 — Manual Build, AI Content Separately
The “let the human handle layout” approach.
What it looks like: You build the page in Elementor yourself — ideally with the Container model (Elementor 3.20+) or atomic widgets (Elementor 4.0+). You ask Claude separately for content drafts: headlines, body copy, CTA text, FAQ answers. You paste into widgets.
What this is good for
- Marketing pages where every pixel matters
- New page designs without a working precedent
- Pages with custom widgets, animations, or scroll effects
- A/B testing variants where you want fine control
Why this works: Humans still do better than AI at layout decisions when the layout is non-trivial — visual hierarchy, white space, responsive breakpoints, brand consistency. Letting Claude do what it's good at (drafting compelling copy) while you do what you're good at (composing visually) is a sane division of labor.
It's the most labor-intensive of the four. If you're spinning up landing pages weekly, this won't scale. Use it for tentpole pages, not for the long tail.
Workflow 3 — Clone-and-Customize (Royal MCP 1.4.19)
The workflow we built our own MCP plugin around — and the one we think is the most reliable for production sites.
What it looks like: You have a working Elementor page that ships. Maybe it's your services page. Maybe it's a city-specific landing page for one location. You ask Claude to clone it and customize the variant. Claude:
- Reads the page outline (sections, widgets, current copy)
- Duplicates the page with fresh element IDs (so the duplicate opens in Elementor cleanly)
- Replaces text across heading, button, text-editor, testimonial, FAQ, and other widget types
- Swaps image URLs (hero background, gallery, image cards)
- Saves as a draft for your review
- You open it in Elementor, tweak anything that needs it, publish
Concrete example
Your /services/web-design-new-york page works and converts. You want a Los Angeles variant. You ask Claude:
“Clone the New York services page. Replace 'New York' with 'Los Angeles' everywhere. Change the hero image to the Los Angeles skyline photo I uploaded last week. Save as a draft.”
Claude calls elementor_clone_page, then elementor_replace_text ('New York' → 'Los Angeles'), then elementor_replace_image (old URL → new URL). You get a new draft page in under a minute. The Container structure is preserved. Widget IDs are regenerated so there's no editor collision. The design system is intact because you never asked AI to invent it — you asked it to swap content in a design that already works.
demo.royalplugins.com.Why this is the path we picked
This is the workflow that survives:
- Elementor schema changes — we never decode page-builder JSON from scratch
- Atomic widget evolution — Editor V4 widgets pass through opaque, no decoding required
- Pro version drift — we don't touch Pro-only widget internals
- Brand consistency — you defined the brand once with your designer; AI just reuses it
It's also the workflow that doesn't fail dramatically. If clone-and-replace can't find a widget to write into, it returns 0 replacements and tells Claude. There's no “page generated, but it's broken” mystery — either the operation worked or it didn't, and you know which.
What it's not for: brand-new page designs. If you don't have an existing page to clone, this workflow has nothing to start from. Reach for Workflow 2 or Workflow 4 for greenfield design.
Royal MCP 1.4.19 ships elementor_clone_page, elementor_replace_text, elementor_replace_image, elementor_get_page_outline, elementor_list_local_templates, and elementor_import_template. They auto-register when Elementor (free or Pro) is active. Free on wp.org with OAuth 2.1, audit logging, and capability gating.
Workflow 4 — “Build From Scratch” MCPs
The aspirational pitch you see in YouTube demos: Claude describes a page, an MCP server generates the Elementor JSON, the page exists. No clone. No template. Just AI → page.
The reality is more nuanced. There are a few projects in this space, and they're all in active development with real edge cases.
The contenders
Angie (wp.org/plugins/angie) — Elementor's own first-party MCP plugin. Officially from the Elementor team. Currently rated 2.4 stars on wp.org with users reporting reliability issues across the most common workflows. The framing on our side: a first-party MCP plugin from Elementor is interesting and worth tracking, but the early-days user experience suggests it isn't production-ready yet. Worth checking back on as the team iterates.
msrbuilds/elementor-mcp (GitHub) — the leading community implementation. ~316 GitHub stars, 79 forks, active maintenance (releases roughly every 2–3 weeks). 110 tools across query, page management, layout, widgets, templates, theme builder, global settings, and stock images. Recently added atomic widget support (April 2026). It's the most ambitious build-from-scratch toolset we've seen.
There are several other GitHub implementations (aguaitech, Ph0enixHan, blibbers, bvisible) at varying stages of maturity — most are personal or experimental.
What works well in build-from-scratch MCPs
- Simple pages with standard widgets and good hand-crafted prompts
- Demo content where pixel-perfect output isn't required
- Layouts that map cleanly to common patterns Claude has seen before
- Tinkering, experimentation, prototyping
What's harder
- Atomic widgets (Editor V4) — schema is new, edges still being smoothed
- Pro-only features — coverage is incomplete; some widgets need conditional handling
- Complex layouts with custom CSS — JSON generation isn't always pixel-accurate
- Production sites where a broken page generation costs real money
Things worth knowing before installing one on a live site
For msrbuilds specifically (the most-installed of the community implementations):
- Distribution. GitHub releases only, not on the wp.org plugin directory. That means no formal plugin review before installation, no auto-update through WP admin, and no wp.org reviews surface for problem reports. Update yourself by checking the GitHub releases page periodically.
- Auth model. HTTP Basic with WordPress Application Passwords. Your credentials are Base64-encoded in every request. Over HTTPS this is fine for development; the consideration is that the same credentials work for all WordPress REST routes, not just MCP — so a leaked key is a broader trust problem than a scoped MCP-only token. (For comparison: token-based MCP servers narrow the trust surface to MCP calls only, and OAuth-based servers add per-session credentials with scoped access.)
- Open issues. Skim the issues tab before installing on a production site. Most are minor and the maintenance is active, but a couple of recent ones touch atomic widget edge cases that are still being worked out.
For Angie: read the wp.org reviews before installing. The current 2.4-star average reflects real user friction — read the negative reviews to understand which specific workflows are problematic, and check whether your use case is one of them.
None of this is meant to dissuade you from trying these. We're laying out the trade-offs people don't always see in the YouTube demos. If you want the flashy “AI built this page” experience, build-from-scratch is the path — go in eyes open.
When to Use Which
| Task | Best workflow |
|---|---|
| Drafting content for an existing Gutenberg post | #1 — Gutenberg + Elementor |
| One-off marketing page where pixels matter | #2 — Manual build, AI content |
| Spinning up variants of a working page (different city, industry, audience) | #3 — Clone-and-customize |
| Building bulk landing pages from a working template | #3 — Clone-and-customize |
| Experimental “AI builds it from a prompt” demos | #4 — Build from scratch |
| Brand-new page design with no precedent | #2 or #4 |
The pattern, generally: start with what already works unless you specifically need greenfield design. AI is at its best when it's customizing something that exists, not when it's inventing from blank canvas.
What We Built and Why
Royal MCP is the plugin we built for Workflow #3. We picked clone-and-customize because:
- It survives Elementor's roadmap. Elementor is actively reshaping how widgets work (Container model, atomic elements, Editor V4). Any build-from-scratch MCP has to keep chasing the schema. Clone-and-customize doesn't decode the schema at all — it copies whatever's there, swaps text and images, leaves widget internals untouched.
- It doesn't fail dramatically. Either the clone happens or it doesn't. Either the replace finds a match or it returns 0. There's no “AI hallucinated a widget that doesn't exist” failure mode.
- It plays to AI's strengths. Claude is excellent at “take this existing thing and make a variant of it.” That's exactly what clone-and-customize asks for.
- It's secure by default. Every tool is capability-gated (
edit_posts+edit_postper-post). The plugin runs through wp.org's security review before each release. Auth is OAuth 2.1 or scoped API key — no Base64 credentials in every request.
1.4.19 ships the six Elementor tools alongside the existing 116 WordPress + plugin integration tools. Free on the WordPress plugin directory. No upsell — pay for the design once (yourself or your designer), reuse it forever via AI.
Try It
- Install Royal MCP from the WordPress plugin directory.
- Royal MCP → Settings → generate an API key.
- In Claude.ai web → Settings → Connectors → Add Custom Connector → URL:
https://yoursite.com/wp-json/royal-mcp/v1/mcp. Approve the OAuth consent screen. - Ask Claude: “Clone my [pick a working page] page. Change [whatever]. Save as a draft for me to review.”
For step-by-step setup including Claude Desktop, ChatGPT, and custom HTTP clients, see the Royal MCP setup guide.
Disclaimer: Royal MCP is developed by Royal Plugins. We've tried to honestly reflect each project's current state in this guide. Tool counts, ratings, and feature data were gathered in May 2026 from each plugin's official listing on wp.org or GitHub. Project status changes — please verify on each plugin's official page before making a decision.