Elementor MCP in Production: 7 Service Pages in 2 Working Days

My Elementor MCP field report from Spartan Sistemi: the build process, eight problems and fixes, page checks, and what business owners should expect.

November 5, 2026 14 min read Development
Elementor MCP in Production: 7 Service Pages in 2 Working Days

Elementor MCP connects an AI agent to WordPress so it can create and edit pages inside Elementor. I used the official connector on Spartan Sistemi’s website, then reviewed and corrected the output before it reached visitors. It proved useful for repeated page assembly, with a developer responsible for investigating failures and accepting the finished work.

What Elementor MCP actually does

MCP stands for Model Context Protocol, but the useful explanation is simpler: it gives an AI assistant a way to work with a website’s editing tools. Instead of asking the assistant to describe a page, I can have it create the page’s structure through the connection WordPress and Elementor expose.

The official connector requires the site owner to switch on Elementor’s Atomic editor, also called V4. That prerequisite belongs in the initial assessment, before anyone commits to a build method or delivery schedule.

The resulting content uses native Elementor elements. For someone maintaining the website, that means working with individual page components instead of a block of generated HTML pasted into a widget.

For a business owner, the practical question is whether the build leaves a manageable website. For an IT or digital leader, the assessment should also cover how the connector behaves alongside the existing theme and what checks stand between an automated edit and publication.

The project: service pages for cities and property types

Spartan Sistemi is a security systems company in Belgrade, Serbia, offering alarm systems, video surveillance, and protection for business premises. Its website uses WordPress, Elementor, and a custom child theme, with Serbian content throughout.

The pages covered specific cities or types of property. Someone looking for surveillance in Novi Sad has a different starting point from someone researching security for a warehouse, even when both enquiries concern the same company.

These are SEO service pages within the main website. They carry its full menu and footer, giving visitors a route between the relevant service information and the rest of the business.

I added footer blocks labelled “LOKACIJE” for cities and “PO VRSTI OBJEKTA” for property types. That connected the new destinations to every page, rather than leaving them accessible only to someone who already knew their addresses.

I have no measured traffic, ranking, lead, or conversion results for these pages yet. This Elementor MCP review documents delivery and implementation, so the evidence here concerns what was built and how it was checked.

How I organised the build

The design and the copy had different jobs

Each page started with a design image and a Word document containing the final Serbian copy. The image guided the layout, while the document determined the text that belonged on the page.

That distinction became important on the first location page, Alarm systems Belgrade. I retained all 75 paragraphs from the Word document instead of substituting the shorter text shown in the design image.

A layout can look convincing while omitting material it was meant to present. Before an agent begins assembling sections, I recommend establishing which source controls content, particularly when a visual mockup uses abbreviated wording.

The first location page became the pattern

The Belgrade page contained 179 native V4 elements and seven native FAQ items, with no HTML widgets. It became the pattern for subsequent location work after the earlier pricing page had served as the first official connector reference build.

I wrote a reusable build brief after establishing that pattern. Later city pages started from short Trello cards pointing to the brief, avoiding a fresh explanation of the entire approach for each assignment.

The first example deserves careful attention because its unresolved details can become repeated decisions on subsequent pages. For a similar project, I would agree on that example before estimating the remaining collection.

Agents handled assembly, and I handled review

Claude and Codex agents worked unattended from those instructions. I reviewed and fixed every page, keeping the automated work inside a development process with a named person accountable for the result.

Every build began on staging, passed checks there, and was then pushed live. That sequence applied even when the next page closely resembled one already completed.

For a marketing director, the useful milestone is a page that can be assessed against its brief. An agent reporting that its task is finished does not establish whether the content, layout, or interactions are acceptable.

The complete delivery timeline

The official connector was used to build 11 pages between 26 September and 12 October 2026. The record below includes the pricing reference, location pages, and property pages, with recorded times where available.

The headline groups the three location builds on 2 October with the four property builds on the morning of 12 October. Those were separate working dates, not consecutive calendar days, and the property group took under an hour.

That pace followed the reference work and the establishment of a reusable approach. It is not a delivery estimate for an unfamiliar website whose design, content, theme, and review requirements have yet to be examined.

Eight problems I found and how I handled them

1. Global theme rules overrode the new elements

The theme’s global CSS forced headings and paragraphs to use fixed sizes and colours. The new elements therefore could not display the styling assigned to them, even though their individual settings suggested otherwise.

I changed two global rules so they skipped the new elements. Adjusting each heading independently would have left the controlling conflict in place and made the page harder to reason about.

Before changing local settings, I check which stylesheet actually controls an element. When the page ignores a styling instruction, identifying the rule that takes precedence is more useful than repeatedly issuing the same request.

2. The stylesheet needed an edit before it appeared

The page stylesheet was rebuilt after an edit, rather than immediately after the initial build. A small edit call following creation made the expected styling appear.

Without recognising that behaviour, an apparently unfinished page could send the investigation toward the wrong part of the system. A developer might spend time changing a design that had already been specified correctly.

My build process includes that follow-up edit before inspecting the rendered result. A successful creation call is an intermediate event, so I avoid treating its response as visual confirmation.

3. Partial padding changes reset other sides

Changing one side of an element’s padding reset the other sides. A request to improve one gap could therefore disturb spacing that had already been set correctly elsewhere on the same element.

The fix was to resend the complete style whenever making a style change. That preserved the intended state instead of relying on the connector to retain unspecified values.

For subsequent spacing adjustments, I provide the complete set of style instructions. Even a small visual correction then gets another look in context, because its effect may extend beyond the gap being discussed.

4. Some styling disappeared without an error

Certain details were silently dropped, including colour on part of a heading, decorative CSS lines, and a class assigned to an inline span. The instruction could appear to have been accepted while the visible result remained incomplete.

I used separate small elements and a few page-scoped CSS rules to produce those details. This let me preserve the intended appearance without assuming every styling feature behaved the same way through the connector.

The review therefore covers distinctive visual treatments individually. When one detail is missing, I investigate that feature and its implementation rather than accepting a simplified design as the unavoidable result.

5. Simultaneous edits could overwrite each other

Two edits sent at the same moment could each read the whole page, apply their own change, and save it. The later save could overwrite the other edit, losing part of the intended work.

I changed the process so page edits run one at a time. This was a coordination problem with a concrete consequence, and repeating the lost instruction would not resolve the underlying cause.

Each page mutation must finish before the next begins. Anyone commissioning AI-assisted development should ask how the developer prevents overlapping writes to the same content, especially when several agents are involved.

6. A draft preview led to a mistaken diagnosis

Preview links expired after five minutes, and an early draft appeared unstyled. I initially suspected the cache plugin, but after publication the normal page displayed correctly, so that suspicion was not evidence of a plugin fault.

A misleading preview can prompt unnecessary changes to an otherwise working site. It also makes screenshots harder to interpret when their URL and publication state are unknown.

I capture previews promptly when they are useful, then verify the actual published URL with normal optimisation before attributing a styling failure to any plugin. Any proposed configuration change needs a reproducible problem and an identified responsible setting.

7. The fixed header covered the hero

The fixed site header overlapped the top of the first hero section. A page could have the right content and still present its opening section incorrectly because of the surrounding site layout.

Page-scoped offsets corrected the overlap. The Belgrade hero was later made full width to match the site’s other video page, bringing that part of the layout into line with its context.

At the top of each page, I review the opening section with the real header present. A design image cannot establish whether existing navigation will cover content when the page is rendered inside the website.

8. Page-specific CSS accumulated in a shared file

Styling intended for individual pages was initially held in one shared file. As the collection developed, that organisation meant a page could receive rules belonging to other pages.

I moved 249 rules into per-page files so each page loaded only its own styles. That made the ownership of those rules clearer, although I have no loading-speed measurements to attach to the change.

For ongoing maintenance, I distinguish common presentation rules from styles attached to a particular page. That gives a future developer a more specific place to investigate when one section needs adjustment.

How I check every page

My baseline inspection covered widths of 375, 820, 1200, 1440, and 1920 pixels. These checks examined the page in its actual website context, including the surrounding navigation and the space available to the content.

I checked that every copy block was present, every FAQ opened and closed, and the page had no sideways scroll. I also checked for JavaScript errors, since an attractive screenshot cannot demonstrate that the page behaves correctly.

Later pages received additional checks across 19 screen sizes in Chrome and Safari’s WebKit engine. Those included tapping the mobile menu, testing an interaction that a desktop screenshot would leave unexamined.

For a buyer, visual approval, content approval, and interaction approval deserve separate attention. A page can pass one of those assessments while still needing work in another.

Ask a developer to describe the conditions of their checks. “Tested on mobile” is difficult to assess without the screen sizes, browser coverage, and actions actually examined.

What the client’s team inherits

The handover matters after the novelty of the build method has passed. The question for Spartan Sistemi’s team is how comfortably the delivered structure supports the changes they need to make afterward.

Before accepting similar work, open a section in the editor and examine how its content is organised. A developer’s familiarity with the build does not establish whether the person maintaining it will understand the arrangement.

I recommend using a realistic future change as the handover test. Ask the intended editor to update a service description or revise a question, then observe where the process needs explanation.

This is particularly relevant when marketing staff maintain content while technical staff oversee the platform. Agree on responsibility for routine edits and structural changes before assuming everyone has the same understanding of the handoff.

When I would use this approach

I would consider Elementor MCP when a business has several related pages to build, a settled design direction, and approved copy. A clear pattern gives the agent something specific to follow and gives the reviewer a consistent basis for assessing its output.

The intended editing environment also matters. A business planning to continue using Elementor has a different handover requirement from one considering a change of platform.

For a digital leader, the initial page can serve as a practical evaluation of the existing site. Theme behaviour, editing constraints, and the required visual details should be understood before estimating a larger collection.

The strongest candidate is a project where the repeated work is already well defined. Automation can then be evaluated against a specific assembly task, with decisions about content and acceptance made explicitly.

When I would choose a different route

I would pause if the site owner cannot enable the required editor or if the project depends on unresolved design decisions. Those conditions call for addressing the prerequisite or completing the brief before commissioning automated assembly.

A single unusual page also deserves a comparison with a direct build. Establishing a reusable process has an associated effort, and the project may have little subsequent work over which to spread it.

For an existing website, a small initial assignment can expose compatibility questions before a wider commitment. I would make further scope conditional on what that first build reveals.

The amount of specialist styling deserves attention too. If the design requires many exceptions, the estimate should account for implementing and maintaining those details instead of assuming that every instruction will transfer unchanged.

Frequently asked questions

Is Elementor MCP free?

Elementor’s own MCP page says the connector can create and edit pages, sections and theme parts with only Elementor installed. You still pay for the AI tool you connect, such as Claude or Codex, and for the developer time to review the output. Source: https://elementor.com/mcp/

Does Elementor MCP require Elementor Pro?

Not for basic pages. Elementor says paid plans add features to the MCP, such as forms, popups, loops and ecommerce widgets. As of November 2026 the MCP works with Atomic (V4) elements, and Elementor says support for older V3 widget layouts is coming.

Can my team edit pages built this way?

Yes, the delivered pages can be edited in Elementor through its native elements. An MCP connection is the route used to build them, while ordinary content maintenance belongs in the page editor.

Does this replace an Elementor developer?

A build tool does not decide which trade-offs a business should accept. An Elementor developer still has to judge whether a proposed fix fits the site, explain its maintenance implications, and take responsibility for that decision.

How long does an Elementor MCP page take?

Request an estimate that separates the first page from later pages following an established pattern. Ask whether it includes preparation, corrections, checking, and release, since a build timestamp does not describe all those activities.

Can I use Elementor MCP with Claude?

Claude can work through the official connector, as can Codex. If you are searching for “Elementor MCP Claude” guidance, start with the connection offered by Elementor and confirm its prerequisites for the site you intend to use.

Planning your own page build

Before commissioning a similar project, bring the proposed page list, approved content, design reference, and details of the existing WordPress site to the conversation. Those inputs make it possible to discuss a useful scope and a review process someone can be accountable for.

My setup service covers the connection itself, while the automation service is relevant to a broader content or operational workflow. The portfolio entry presents this work from the client delivery perspective.

HYPESTUDIO, my agency, builds campaign landing pages using the same approach. Explore that service for a campaign-specific brief: https://hypestudio.org/landing-page-design/

If you have a page collection in mind, I can review the requirements with you and discuss whether this method fits the site. Start with a conversation: https://dejanmarkovic.com/lets-talk/

You May Also Like