How FigWP decides which Essential Addons widget a section becomes

The difference between a page you can edit and a page you have to rebuild is whether the sections are real widgets. A hero that is a Dual Color Heading has two text fields and a layout picker; a hero that is twelve nested containers has twelve things to click through. FigWP’s whole job is to land on the first kind without losing anything on the way, and that comes down to three steps.

Step one: the app proposes

Before converting, your AI app reads the frame’s layer tree and proposes a mapping: for each top-level section, one Essential Addons widget, or an Elementor widget when no Essential Addons one fits, or plainly “container” with a reason. For a widget it also says which layers fill which parts. For a card grid, that means the card frames are the items and each card’s icon, title and paragraph are an item’s image, title and content.

This is the step where the AI earns its place. Recognising that a quote with an avatar and three dots is a slider, or that six photos with captions are not an Image Accordion, is a judgement about what the design means, and a language model is good at that. Writing the Elementor settings is not a judgement, so the app does not do it.

Step two: FigWP checks

Every proposal is validated against the widget catalog: the widget must exist, the layer must be in the frame, the parts must be parts that widget has, and a layout value must be one the widget offers. The catalog is a design map of every Essential Addons widget, Free and Pro, written from the widgets themselves: what each looks like in a design, its parts, its layouts and skins, and the quirks the converter knows about. The app can read a widget’s full guide before it decides, and often does for the ambiguous ones.

Accepted choices are kept for two hours per frame. A conversion without a mapping is refused, so sections are never guessed into widgets from their layer names unless you ask for exactly that. A section left out of the mapping is a decision too: it becomes containers, text and images.

Step three: the gate

After the plugin builds a widget, FigWP compares the text the widget captured with the text in the section. Below 70%, the widget is dropped and the section is rebuilt from containers. The idea is that a wrong choice should degrade to a plain layout, never to a missing paragraph.

The sample in the widget explorer shows it: a photo grid proposed as an Image Accordion captures the six images but neither the captions nor the store details, 38% of the text, so it is demoted and the page keeps everything. The FAQ, proposed as an Advanced Accordion, captures 96% and stays.

Every dropped widget is reported with the reason, so the app can tell you and, if you want, try another widget for that section.

What this means when you ask

A few habits make the mapping better:

• Name your sections. “Hero”, “Pricing”, “FAQ” in the layer name is a strong hint.
• Keep repeated items in frames of the same shape. That is how repeater widgets are recognised.
• Say what you want when you know. “The testimonial should be a slider” goes straight into the mapping.
• Ask what was dropped. The conversion’s warnings name every widget the converter could not build and every one the gate demoted.

And after import, a section is never final. Ask the app to rebuild one section with a different widget; on a page you have paid for, that is free.