How to Create a Global Widget in Elementor

A global widget in Elementor solves one specific, expensive problem: the same styled block sits on fourteen pages, the phone number changes, and you now have fourteen edits to make. Save it once as a global widget and every copy updates together. The feature is alive in 2026 and still Elementor Pro only. It is also no longer the only way to reuse a design, and picking the wrong one costs you an afternoon.

What a global widget actually is

A global widget is a single Elementor widget saved to your template library and then linked wherever you place it. Edit the master and every linked copy changes at once. Elementor’s own documentation for global widgets puts it plainly: editing it in one place instantly updates the rest.

Three things follow from that definition, and they are the three things most tutorials skip.

• It is one widget, not a layout. A heading, a button, a form, a testimonial. Right-click a container and the menu offers Save as template instead, and an open feature request is still asking for container support.
• It is stored as a template. That is why it turns up under Templates rather than in some separate global manager, and why it gets a shortcode you can use elsewhere.
• There is no per-page variation. Every copy is the same copy. The only escape hatch is unlinking, which is permanent.

You need Elementor Pro for this. The free plugin, which sits at 10+ million active installs on its WordPress.org listing, does not include it. On Elementor’s plugin pricing page the entry plan, Essential, is listed at USD 60 per year for one site, with the same figure shown as the renewal rate. The page geo-switches currency, so figures here are the USD ones. Pricing checked August 2026.

Disclosure: the Elementor Pro link below is an affiliate link. It costs you nothing extra, and it has not softened a word of what follows.

Get Elementor Pro

How to create a global widget in Elementor

Screenshots below come from an earlier editor build. The panel styling has changed since; the click path has not. In current documentation the panel tab is labelled Globals.

1. Build the widget properly first

Style it on a real page, at the real width, with the real content. A global widget inherits whatever you saved, and fixing padding later means editing the master and re-checking every page that uses it. This is the step people rush and then pay for twice.

2. Right-click the widget handle and choose Save as a Global

Grab the widget by its handle, right-click, and pick Save as a Global from the context menu. Note where it sits: below Reset Style, above Navigator. If you are seeing Save as template instead, you have selected a container, not a widget.

3. Name it so you can find it in six months

The library modal asks for a name. Give it one that says what it is and where it belongs, not what it looks like. Homepage Enquiry CTA beats Blue Button 2. If you keep variants, version them: Pricing CTA v1, Pricing CTA v2. You are naming this for the person who inherits the site.

4. Place it from the Globals tab

Open the Globals tab in the editor panel, next to Elements, and drag the saved widget onto the canvas. Global widgets carry a folder icon so you can tell them apart from ordinary widgets at a glance.

Select a placed global widget and the panel stops offering the usual style controls. Instead you get two buttons: Edit global widget, which changes every instance on the site, and Unlink from global, which turns this copy into a normal widget forever.

5. Verify the sync before you trust it

This is the step that separates a working setup from a nasty surprise on a client call. Do not skip it.

1. Place the global widget on a second page and publish both pages.
2. Open page one, select the widget, click Edit global widget, change something unmissable such as the button label, and publish.
3. Load page two in a private window while logged out. The change should be there.
4. If it is not, purge your page cache, then go to Elementor, Tools, and run Regenerate CSS and Data. Reload.
5. If page two is still stale, that instance was probably unlinked. Select it: a linked instance shows Unlink from global, an unlinked one shows the normal style controls.

If you run a page cache plugin, add cache purging to your mental checklist for every global widget edit. A stale cached page looks exactly like a broken global widget.

Editing, unlinking and deleting

Editing is covered above. The other two deserve their own warnings.

Unlinking is permanent. There is no relink button. If you unlink by mistake, delete the instance and drag a fresh copy from the Globals tab, then redo any local changes.

Deleting is destructive across the whole site. Global widgets live in WP Admin under Templates, then Saved Templates, on the Global Widget tab. Trashing one removes it from every page that used it, which Elementor’s documentation warns about explicitly. There is no per-page fallback and no orphaned copy left behind.

The practical consequence: never let a tidy-up pass through Saved Templates go unsupervised. A template with a vague name looks like clutter right up to the moment it takes a call-to-action off eleven landing pages.

What breaks, and how to spot it early

Four failure modes account for nearly everything that goes wrong here.

• Stale CSS on the front end. Elementor writes CSS per post, so a global widget edit has to refresh the CSS of every page that uses it. The Elementor Pro changelog carries repeated fixes in exactly this area, including one covering post CSS deletion during a global widget update. If the editor looks right and the live page looks wrong, regenerate CSS before you go blaming your theme.
• Query-driven widgets. Pro 3.25.0 fixed pagination and custom queries failing when the Posts widget was saved as a global widget or used via shortcode. Anything that runs a query is the case to test rather than assume.
• Accidental site-wide edits. Anyone who can edit any page holding that widget can change it everywhere. The only guard is a panel warning that busy people click through.
• Silent divergence. Someone unlinks one instance to tweak a word. Six months later that page is the only one still showing the old phone number, and nothing in the interface flags it.

That last one is the reason to keep the count low. Global widgets have no audit view, no “where is this used” list, and no diff. Discipline is the only tooling you get.

Global widget vs Component vs Template widget vs Theme Builder

This is the part the older tutorials cannot help you with, because two of these did not exist when they were written. Elementor now gives you four reuse mechanisms and they are not interchangeable.

Tool	What it reuses	Per-page overrides	Requires
Global widget	One widget	No, unlink only	Pro, classic v3 widgets
Component	A container and everything inside it	Yes, via component properties	Pro, Atomic v4 elements, admin to edit
Template widget	Any saved template	No	Pro
Theme Builder part	A whole site region such as a header or footer	No, display conditions instead	Pro

Components are the interesting one. Elementor’s Components documentation describes reusable design blocks that stay globally synced while still allowing per-instance customisation: you right-click a container, choose Create component, then mark individual fields as properties that each page can override. That is the thing global widgets have never done. The catch is that Components only work with Atomic elements, need Pro, and can only be created or edited by admin-level users.

The Template widget is the old workaround and still a good one. Per its documentation, it drops a saved template into a page, and editing that template updates every place the widget appears. It is how you get global-widget behaviour for a whole section built with containers. No overrides, but no Atomic requirement either.

Theme Builder parts are for anything that should appear automatically rather than be placed by hand. Headers, footers, single post layouts, archives. If you find yourself dropping the same global widget onto every single page, you wanted a Theme Builder part and a display condition. Our walkthroughs on building a single post layout with Elementor and a blurred sticky header both live in that territory.

The catch nobody writes down: global widgets are in maintenance mode

The feature works. It is documented, the docs were refreshed in August 2026, and nothing in Elementor’s messaging says it is going away. But look at where the development effort is.

Elementor 4, the Atomic Editor, launched in March 2026, and per Elementor’s version 4 FAQ, from April 2026 every new Elementor site runs version 4 by default. The FAQ names Classes, Variables and Components as the reusable design system, and states that Classes and Variables cannot be applied to older widgets at all. Meanwhile the Pro changelog’s last entry mentioning global widgets is version 3.30.0, dated 1 July 2025, with nothing in the entire 4.x line. Changelog read August 2026.

Read that honestly and it says: safe to use today, fine for an existing Elementor 3 site, and not the thing to build a two-hundred-page information architecture on. If you are starting fresh, the hour you spend learning Components is worth more than the hour you spend perfecting global widgets.

The second unwritten catch is smaller and more immediate. Global widgets do not participate in the new styling system. A global widget cannot take a Global Class, so a site that mixes both ends up with two parallel design systems, one of which you have to maintain by hand.

When a global widget is the wrong tool

Five clear cases where you should reach for something else.

• The text changes per page. A CTA whose headline names the service on that page is a Component, not a global widget. Forcing it means unlinking, and an unlinked widget is just a copy with extra steps.
• It is more than one widget. Two widgets in a container is a template. Use the Template widget, or a Component if you are on Atomic elements.
• It belongs on every page. That is a Theme Builder part with a display condition, and it saves you from ever placing it again.
• Non-admin editors touch the site. Anyone editing a page can rewrite a global widget for everyone. If that thought makes you wince, use a Theme Builder part they cannot reach from the page editor.
• You want conditional display. Global widgets have no visibility logic of their own. That is a job for a dynamic visibility plugin or a Theme Builder condition.

One more, less obvious: if the thing you keep repeating is a marketing offer rather than a design, a popup or a Theme Builder part usually converts better than the same block glued into fourteen page bodies.

Which one should you use?

1. Header, footer, single post or archive layout? Theme Builder part. Stop here.
2. More than one widget? Template widget on a v3 site, Component on Atomic elements.
3. Does each page need different text or images inside it? Component. Global widgets cannot do this.
4. One widget, identical everywhere, existing Elementor 3 site? Global widget. This is its job and it does it well.
5. New site started in 2026? Learn Components first and keep global widgets for quick one-offs.

If none of these fit because your build is fighting Elementor rather than using it, that is a different conversation. Our comparison of visual page builders for WordPress covers where the alternatives are genuinely stronger, and a good Elementor addon pack fills most of the remaining gaps without a rebuild.

Frequently Asked Questions

Our call

Use global widgets, and cap them at about twenty. They are the shortest path in Elementor to a real problem: one widget, many pages, one source of truth. The click path takes under a minute, the sync holds once you have verified it, and the only real trap is the delete button in Saved Templates.

But do not let them become your architecture. They have no per-page overrides, no usage audit, no undo on unlink, and no line in the Pro changelog since July 2025. If you are building anything that will grow, put the header and footer in the Theme Builder, put repeated sections in Template widgets, and start learning Components. Global widgets are the right answer to a small question, and the wrong answer to a large one.

Next, if speed is the reason you are consolidating widgets in the first place, the bigger wins are elsewhere: our guide to speeding up a WordPress site and the notes on button widgets for Elementor are better places to spend the next hour.