Shortcodes vs Blocks vs Page-Builder Widgets in WordPress

On this page

1. The three options at a glance
2. Shortcodes: small tags that run code
3. Why shortcodes break or leave [brackets] behind
4. Blocks: the native WordPress format
5. Page-builder widgets
6. Migrating shortcodes to blocks
7. What to choose for a new build

Open an old WordPress page in the editor and you might find text like [contact-form-7 id="123"] or [vc_row] in the content. Those are shortcodes, the original way of putting dynamic features into WordPress pages. Today there are three options: shortcodes, blocks in the built-in block editor (Gutenberg), and widgets inside page builders such as Elementor. Each stores your content differently, which decides what happens when a plugin is removed or the site is redesigned.

The three options at a glance

	Shortcode	Block	Page-builder widget
What editors see	A tag in square brackets	A visual preview in the editor	A visual element in the builder
How it's stored	Plain text in the page content	HTML in the page content, with labels marking each block	Usually in the builder's own data format
If its plugin is removed	Raw [brackets] appear on the page	Saved HTML usually remains; dynamic blocks can vanish	The element, and often its styling, disappears
Best for	Small dynamic bits and older plugins	Most content on modern sites	Visually designed pages edited without code

Shortcodes: small tags that run code

A shortcode is a word in square brackets that WordPress swaps for something else when the page is displayed: a form, a gallery, a button, a pricing table. WordPress itself includes a few, such as [gallery] and [caption], and plugins and themes have added thousands more.

For developers, registering one takes a few lines:

add_shortcode( 'current_year', function () {
    return wp_date( 'Y' );
} );

Typing [current_year] in a page now shows the current year, handy for a footer copyright line. Note that the function returns its output. Echoing it instead makes the output appear in the wrong place on the page, a classic beginner mistake.

The weakness is the editing experience. Editors see a cryptic tag rather than what visitors will see, attributes like id="123" are easy to mistype, and nothing warns you when the code behind a tag has gone.

Why shortcodes break or leave [brackets] behind

A shortcode is only text stored in your page. WordPress replaces it at display time if, and only if, an active plugin or theme has registered that tag. Remove the plugin, or switch away from a theme that bundled its own shortcodes for buttons, columns or tabs, and WordPress no longer recognises the tag, so visitors see the raw text. This is why features like shortcodes are generally best kept in plugins rather than themes.

It gets worse with some older page builders. WPBakery and classic versions of Divi, for example, store whole layouts as nested shortcodes. Deactivate the builder and pages turn into walls of [vc_row] and [vc_column] tags wrapped around your text.

If brackets are already showing, the proper fix is to find every affected page (a developer can search the database for the tag name) and replace each shortcode with a block or fresh content. As a temporary stopgap, the old tag can be registered again so it outputs only the text inside it, hiding the brackets while pages are rebuilt:

add_shortcode( 'old_button', function ( $atts, $content = '' ) {
    return do_shortcode( $content );
} );

Blocks: the native WordPress format

Since WordPress 5.0, the default editor has been the block editor. Every paragraph, image, button or form is a block that you edit visually. Behind the scenes, blocks are stored as ordinary HTML with comment labels telling the editor where each block starts and ends:

<!-- wp:paragraph -->
<p>Call or WhatsApp us for a free quote.</p>
<!-- /wp:paragraph -->

That format is why blocks age well. Most blocks save their finished HTML into the page, so if the plugin that provided a block is removed, the content usually still displays; the editor warns that the block isn't supported and offers to keep it as HTML. The exception is dynamic blocks, such as a plugin's product grid or events list, which are generated fresh on every page load. Without their plugin they show nothing, though at least they don't leave brackets behind.

For components designed around your brand, such as service cards or testimonial sliders, developers can build blocks of their own; see custom Gutenberg blocks.

Page-builder widgets

Page builders such as Elementor have their own building pieces, usually called widgets: headings, carousels, forms, pricing tables and more, often extended by third-party add-on packs. They give non-technical teams plenty of visual control, which is why they're popular for marketing pages.

The trade-off is lock-in. Builders like Elementor keep layouts in their own data rather than as standard content, so if the builder is switched off, pages lose their layout and styling. Remove an add-on pack and every widget it supplied disappears from your pages. Moving from one builder to another, or to blocks, is effectively a rebuild. For the wider comparison, see Elementor vs Gutenberg.

Migrating shortcodes to blocks

1. Make an inventory: list every shortcode in use, which plugin or theme provides it, and which pages contain it
2. Check for a block version: many form, gallery, slider and booking plugins now offer their own blocks, so the swap may take minutes
3. Rebuild simple ones with core blocks: Buttons, Columns, Table and Details (a simple accordion) replace many old theme shortcodes; save repeated layouts as patterns
4. Build custom blocks for anything specific to your business that has no equivalent
5. Convert classic content: older posts open inside a Classic block with a "Convert to blocks" option, and any remaining shortcodes can sit in the core Shortcode block until they're replaced
6. Work on a staging copy and check every page, especially enquiry and high-traffic pages, before going live; see staging sites explained

Sites built entirely with a shortcode-based builder are a different job: the pages need rebuilding rather than converting, so treat it like a redesign and plan content, redirects and SEO checks accordingly; see redesigning without losing rankings.

What to choose for a new build

• Blocks by default: core blocks and patterns for normal content and blog posts, with custom blocks for branded components. This keeps content in standard WordPress format and is the most future-proof option.
• A page builder when a non-technical team needs to design and rearrange marketing pages themselves, accepting some lock-in. Keep add-on packs to a minimum.
• Shortcodes only where needed: for a plugin that offers nothing else, or a small dynamic snippet in a place blocks can't reach, registered in a plugin rather than the theme.

Whatever you choose, keep a simple list of which plugins provide which blocks, widgets or shortcodes, so nobody removes one without knowing which pages depend on it.

Stuck with a site full of old shortcodes, or planning a rebuild in blocks or Elementor? See Elementor development or my WordPress website development service.