Photo by Hanna Pad on Pexels.

A template’s own fonts and colors are only useful if the pages built from it actually keep them. At SimpleWP, that problem sits behind an Elementor AI page builder: pick Elementor as a site’s page builder in the setup wizard, and the product generates real, native Elementor pages that match the chosen template’s own design, reachable from site creation, from the drawer, and from chat. This is how that builder works, end to end.

Building an Elementor AI Page Builder From the Template’s Own Design

When a user picks Elementor as their site’s page builder in SimpleWP’s setup wizard, the product generates the site’s pages as native Elementor pages, built on the Hello theme and matching the chosen template’s own fonts and visual style, rather than a generic layout dropped on top of it.

Reading a template’s declared design for the generated pages comes first from the theme’s own style definitions and its preview page; only if neither is available does the system fall back to analyzing a screenshot of the template. Even then, it will not choose a decorative display or script typeface for body or menu text, so every generated page stays readable no matter which path supplied its design.

That ordering matters more than it looks. A template’s own declared styles are the most reliable source because they are structured data, not a guess; a screenshot is the fallback precisely because interpreting a picture of a design is a less certain way to arrive at the same answer. Keeping the readability rule in place regardless of which source supplied the design means a visually unusual template can never quietly make a generated page harder to actually read.

One Code Path, Reached Three Ways

The same page-generation capability is reachable through one shared code path three separate ways: at initial site creation, from the site’s management drawer, and by asking the chat assistant to rebuild a page with Elementor directly. A user who starts with the wizard and later wants a different page rebuilt does not need to learn a second tool to do it.

Building it this way means a fix or an improvement made once reaches all three entry points at the same time, rather than three separate implementations quietly drifting apart from each other the longer each one runs on its own. Three doorways into the same room only stay reliable if there really is one room behind them, not three rooms built to look alike.

A Deliberate Image Licensing Order

Every generated page needs images, and where those images come from was a deliberate decision rather than an afterthought. Image sourcing follows a specific licensing order: the team’s own theme-licensed photos first, then Pexels stock photography with full photographer credit, and only then a general AI image service.

That order was chosen specifically to avoid using a real person’s photo as a placeholder staff member or testimonial — a risk that gets easier to overlook the faster page generation itself gets, which is exactly why the order is enforced in the code rather than left as a guideline for whoever builds the next image-sourcing path. A guideline is easy to forget under deadline pressure; an order baked into the generation logic itself is not.

Full photographer credit for every Pexels photo is not a footnote either. It is the condition that makes using that stock photography honest in the first place, and it travels with the image wherever the generated page ends up.

Generation as Reversible Steps

The generation process runs as a sequence of individually reversible steps: prepare, apply the design system, compose each page, add a contact form, finish. If any step cannot complete, the site rolls back step by step to its last good state, rather than leaving a site half-built with no clear way back. A page generator that only ever moves forward is simple to write and uncomfortable to run; one built from reversible steps costs more up front and pays that cost back the first time something does not finish cleanly.

Two smaller details round out that same reversibility. If a site has Wordfence’s application-password restriction turned on, the generation process temporarily turns it off only for the duration of building the pages, automatically restores it if the process is rolled back, and records the change in the site’s own activity feed either way — so nothing about the setting’s state is left ambiguous once generation finishes, whichever direction it finished in. And because the tool the generation process runs against has a known, harmless compatibility notice between a specific Elementor and PHP version combination, the process is built to tolerate that notice rather than let it stop the page-generation run from reading its result correctly.

Five Chat Tools for the Elementor AI Page Builder

The feature includes five dedicated chat tools an AI assistant can call directly: applying Elementor to a site, rebuilding a page, listing what a plugin can do, running one of those capabilities, and managing popups. All five run under the product’s existing confirmation rules, the same pattern used everywhere else a chat tool changes something on a live site. Asking an assistant to rebuild one page is a very different request from asking it to apply Elementor to an entire site, and the confirmation step in front of each tool is what keeps that difference visible to the person approving it. These five tools only exist for an AI assistant that is already connected to the site in the first place — see how AI agents connect to a SimpleWP site through MCP and OAuth for how that connection itself gets made.

Underneath those tools, and underneath the wizard and drawer paths too, the page-composition process itself runs on two dedicated, versioned prompts — one for choosing each element’s visual design role from the template, another for composing a full page — both served through the product’s central prompt gateway rather than written as hardcoded text inside the generation code. A prompt that lives in the gateway can be improved once and reach every one of these three entry points the same way the underlying code path already does. Treating a prompt as a versioned, centrally served piece of the product — rather than a string buried in the code that happens to generate pages — is the same discipline the team already applies everywhere else an AI model reads instructions.

Choosing Elementor in the Setup Wizard

The choice between WordPress-style theme pages and Elementor is offered directly as a single step in the setup wizard, letting a user pick the page-building approach that fits how they want to keep editing the site afterward. Surfacing that choice at the moment a site is created, rather than afterward, is what lets the rest of this builder assume from the start which kind of page it is generating.

That step defaults to the ordinary WordPress-template approach rather than Elementor, and picking Elementor surfaces plain-language guidance in the same step about the extra creative freedom it offers, the additional editing work involved, and an honest note about where the page’s visual look actually comes from. A default that has to be deliberately overridden is a quieter way of making sure a choice this consequential is actually a choice, not a setting a user stumbles into.

Proving It on Real Sites

Before shipping, the team ran live generation and drawer-apply proofs against real WordPress sites, not only against a staging fixture built to look like one, and the feature went through the owner’s own review of the resulting pages before it reached anyone else. A generated page that only ever runs against a clean test environment can look finished for reasons that have nothing to do with whether it actually is; running the same generation against real sites is what closes that gap.

What ships today is scoped on purpose: new sites created through the wizard, the drawer’s apply action on a site already using Elementor, and chat-triggered rebuilds on a site that already uses it. An existing, non-Elementor site is not something this generation path reaches into and converts; starting a new site through the wizard is how a user gets to this builder in the first place. If choosing between a template from SimpleWP’s library or working out which theme fits a site comes first, both lead to the same wizard step where this choice lives.