Converting one page saves an afternoon. Building a library of converted, cleaned-up sections changes how fast you can build everything afterwards.
Save sections, not pages
A whole page is rarely reusable; a section almost always is. After you have converted and cleaned a hero, a feature grid, a pricing row or a testimonial block, save that single container to the template library with a descriptive name. Aim for names that describe the shape rather than the project — “feature grid, 3 columns, icon top” beats “client-x-section-2”.
Two export routes, two use cases
- Copy Elementor data — fastest when you are adding a section into a page you already have open.
- Download a JSON template — better for building a library. The file can be imported on any site, checked into version control, and shared with your team.
For library work, the JSON route is worth the extra click: you end up with portable files rather than clipboard state.
Make blocks site-agnostic before saving
A block that hard-codes colours and fonts will look wrong on the next site you use it on. Before saving to your library, consider converting again with site colours and site typography. Those blocks then adopt whatever palette and fonts the destination site defines — the same block looks native everywhere.
Keep the structure honest
A reusable block should be one top-level Container with a shallow tree inside. Before saving, delete leftover empty wrappers and make sure card rows are a Grid or a flex Container holding widgets directly, rather than each card sitting in its own redundant container. A tidy tree is much easier to restyle six months later.
Global widgets for genuinely shared parts
For something that must stay identical across many pages — a CTA band, a guarantee strip — a global widget is stronger than a template: edit it once and every instance updates. Use templates for starting points and global widgets for things that must not drift.
One caveat worth stating plainly: global widgets are an Elementor Pro feature. On the free version you have saved templates only, which are copies — insert one into five pages and you have five independent copies to update. If you are on free and something genuinely must not drift, keep a single canonical page and link to it rather than duplicating it.
What travels between sites, and what does not
A JSON template is portable, but it is not self-contained. Three things routinely surprise people the first time they import a block onto a different site:
- Images travel as URLs, not as files. The block references images by address. Import it onto a site that cannot reach the original host — or onto a site where those files were later deleted — and you get broken images. For a library you intend to keep, replace photos with your own media or with deliberate placeholders before saving.
- Fonts must already exist. The template stores a family name. If the destination site does not have that family installed, the text silently falls back. Blocks saved in site-typography mode dodge this entirely by carrying no family at all.
- Global colours are references by name. A widget bound to a global colour looks for that global on the destination site. If it is not there, behaviour depends on the Elementor version and it is rarely what you wanted. Either keep library blocks on explicit colours, or standardise your global palette names across the sites you work on — the second is more work up front and much better afterwards.
Name and version them like code
A library stops being useful the moment you cannot find things in it. Two habits carry most of the weight:
- Describe the shape, not the origin. “hero, split, image right” tells you whether to use it. “acme-homepage-v2” does not, and you will open five templates to find the right one.
- Put a date or version in the filename for JSON exports. You will improve a block and want the old one back exactly once — but you will really want it.
If you keep the JSON files in a repository alongside your projects, you get diffs and history for free. It is unusual to treat page sections as versioned artefacts, and it pays off the first time you need to know what changed.
Test a block before you trust it
The test is cheap and catches everything above: import the block onto a scratch site that is not the one you built it on, ideally with a different theme and an empty global palette. Broken image, wrong font and missing-global problems all show up immediately, when fixing them costs a minute — instead of in front of a client, on a page you are about to hand over.
A library worth having
Ten to fifteen well-named, site-agnostic sections covers most of what a marketing site needs: hero, feature grid, split feature, steps, testimonial, logo strip, pricing, FAQ, CTA band, footer. Build it once from converted sources and most future pages become assembly rather than construction.
You do not have to start from nothing, either. The template library on this site has ready-made blocks you can preview, convert and adapt — a reasonable way to fill the gaps in your own set without designing every section from scratch.