Shortcodes Left Behind by an Old Page Builder

Brackets where the page used to be

A business changes its WordPress theme. The home page looks fine, and then somebody opens the About page.

At the top: [vc_row][vc_column][vc_column_text]. Then the text, then more brackets, then a code with a number in it where the team photograph used to be.

The two columns are now one long column. The button to book a consultation is a line of code. Every page built with the old page builder looks like this.

Visitors see it, and so does Google, which indexes the brackets as part of the page's text.

What a shortcode is

A shortcode is a word in square brackets that WordPress hands to a plugin or theme to replace with something else when the page is shown: a gallery, a button, a set of columns.

Many page builders save your layout as shortcodes nested inside each other, wrapped around your text, in the page content itself.

When the plugin or theme that understands them is switched off, WordPress has nothing to replace them with. It shows them exactly as stored, brackets and all.

Some builders store layouts separately instead. Removing those leaves different problems, such as pages that fall back to plain text with no layout, but fewer brackets.

How a site ends up here

• A new theme, chosen without checking what the old one bundled.
• A builder switched off to fix a conflict or speed things up.
• Content copied to a new site without the plugins that read it.
• A buttons-and-tabs plugin removed during a tidy-up.
• The old theme's own shortcodes for buttons, columns and boxes.

The last is the one people miss. Many themes add their own shortcodes, separate from any builder, and those break with the theme even on pages nobody built with a builder.

Finding every page affected

Start with the builder's prefix. Visual Composer, now called WPBakery Page Builder, starts its codes with vc_, and Divi starts its codes with et_pb_. Searching the pages list in WordPress for those finds most of them.

Then look beyond pages: blog posts, product descriptions, widgets, custom fields and excerpts can all hold codes. A search of the database finds what the admin screens miss.

Search Google too, with site: and your domain followed by a code such as vc_row. It shows pages where the brackets are already visible to the public.

Keep the results in a spreadsheet: every page, what it uses, and how many visitors it gets.

Why find-and-replace is not a fix

The tempting shortcut is to strip every bracketed code from the database in one go. The text survives. Almost everything else does not.

Columns collapse into a single stack. Images placed through the builder were referenced by a number inside a code, so they vanish with the code. Buttons become plain words or disappear.

Tabs and accordions spill open in a row. Some builder elements store their contents encoded, so stripping the brackets leaves a long string of letters and numbers where a table or form used to be.

Stripping is a reasonable last step on old blog posts nobody reads. For pages that matter, the fix is rebuilding.

Cleaning content properly

Work on a copy of the site, a staging site that visitors never see, with the old builder still active on the live one.

For each page, take the text out, rebuild the layout in the new theme or editor, put the images back from the media library, and turn buttons into proper links.

Use real headings while you are there. Builders often style ordinary text to look like headings, which screen readers and search engines cannot tell apart from paragraphs.

When every page that matters is rebuilt and checked, switch the live site over in one go, so visitors never see the halfway state.

A worked example

A property management company's site had been built on a theme that bundled a page builder. The bundled copy could only be updated when the theme was, and the theme's author had stopped updating it.

Its web company planned a move to a maintained theme and started with an inventory: forty-odd pages built with the builder, and a dozen more using the old theme's own button codes.

Each page was rebuilt on a staging copy, starting with the rental listings and the owners' guide, which had the most visits.

One raw HTML element turned out to hold the code for an embedded listings feed, stored encoded. It had to be recovered from the old site and embedded again.

The switch took one evening. A search the next morning found two old blog posts with a button code still showing, and those were fixed the same day.

Planning a switch before it happens

Most of this work is cheaper before the switch than after it.

Before choosing a new theme or builder, list which pages use the old one, and decide which are worth rebuilding and which can be retired or merged.

Prefer a replacement that stores content as ordinary HTML. A layout that survives without its tool is a layout you can move again later.

Take a full backup first, keep page addresses the same so links and search listings keep working, and budget time per page rather than for the site as a whole.

The new editor on the horizon

WordPress is working on a new editor, Gutenberg, planned for WordPress 5.0 and available now as a plugin for testing. Its date has not been fixed.

It saves most content as ordinary HTML, with small invisible comments marking where each block starts, so pages stay readable even without the editor.

Builders are still working out how they will fit alongside it. A business planning a builder switch this year might reasonably wait to see where that settles, and should not test the plugin on its live site.

The counter-case

A builder that is current, licensed and maintained is no reason to panic. The mess only arrives when it is removed.

A site with only a handful of builder pages can be cleaned in an afternoon, and a site being rewritten from scratch will replace those pages anyway.

So keep the builder until there is a reason to leave it, and when there is, plan the content before touching the theme.

Before switching builders

1. Back up the whole site first.
2. List every page the builder touches.
3. Search for the theme's own codes too.
4. Rebuild pages on a staging copy.
5. Use real headings, not styled text.
6. Switch the live site over in one go.
7. Search again for leftover brackets.

Step two sets the size of the job. Until someone has counted the pages and the codes in them, any estimate for the switch is a guess.

Knowing exactly what each plugin does on a site matters for privacy too, as covered in WordPress adds privacy tools.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.