Login
Menu

What Is [vc_row]? WPBakery (Visual Composer) Shortcodes Explained

If you have ever opened a WordPress page and seen blocks of text like `

`, `
`, or `

` sitting in the middle of your content, you have run into one of the most common and confusing symptoms in WordPress maintenance. The page that once looked polished now displays raw, bracketed code where your layout used to be.

The short answer: `

` is a shortcode generated by the WPBakery Page Builder plugin (formerly known as Visual Composer). When you see it as literal text rather than a rendered layout, it almost always means the plugin that interprets that code is no longer active on your site. This guide explains exactly what these shortcodes are, where they come from, why they suddenly appear as plain text, and how to fix them properly.

Key Takeaways
• `

`, `
`, and `
` are WPBakery Page Builder (Visual Composer) shortcodes.
• Shortcodes are bracketed codes that a plugin or theme converts into HTML output at render time.
• You see raw shortcode text when WPBakery is deactivated, deleted, or unavailable — nothing is left to translate the brackets into a layout.
• The fix is either to reactivate WPBakery or, if migrating away, to rebuild the content in your new builder and remove the orphaned shortcodes.
• Page-builder shortcodes are plugin-specific — this is page-builder lock-in, and it matters when you change tools.

What is a shortcode in WordPress?

Before tackling `

` specifically, it helps to understand the underlying mechanism. A shortcode is a small, bracketed code that WordPress recognizes as a placeholder for dynamic output. Instead of writing out a block of HTML, JavaScript, or PHP directly inside your content, you insert a short tag, and a plugin or theme expands it into the full output when the page loads.

WordPress ships with this system built in. A plugin registers a shortcode by associating a tag (the word inside the brackets) with a function. When WordPress renders a post or page, it scans the content for registered tags and replaces each one with whatever that function returns.

A simple, native example looks like this:

“`

“`

While the plugin or core feature that defines `` is active, WordPress swaps that tag for a fully rendered image gallery. The key detail to remember is this: a shortcode only works while the code that defines it is present and active. Remove that code, and WordPress no longer knows what the tag means — so it leaves the raw text on the page.

Where does
come from?

`

` and its companion tags come from the WPBakery Page Builder plugin. This is a popular drag-and-drop page builder that was originally sold and widely bundled under the name Visual Composer. (The `vc` prefix in every tag is short for *Visual Composer*, which is why the legacy name still appears in the code long after the rebrand.)

When you design a page with WPBakery, you are not writing HTML directly. Instead, every time you drop a row, a column, or a text element onto the canvas, the builder inserts a corresponding shortcode into the post content stored in your database. The visual editor is essentially a friendly interface that writes shortcodes for you.

So a layout you built by dragging elements around is saved as something like this:

“`

Your left-column text goes here.

“`

When the page loads and WPBakery is active, the plugin reads those tags and renders them into a real two-column layout with text on the left and an image on the right. The visitor never sees the brackets — they see the finished design.

Here is the critical insight most troubleshooting guides skip: seeing raw `

` or `
` text on your live site is a definitive signal that the WPBakery plugin is deactivated, deleted, or otherwise unavailable. These shortcodes are not a WordPress core feature and they are not part of your theme’s HTML — they are plugin-specific instructions that *only* mean something while WPBakery is running. The brackets are not broken code; they are perfectly intact instructions waiting for an interpreter that is no longer there. This is page-builder lock-in in its rawest form: your content is stored in a private dialect that exactly one plugin can read.

Why do I see raw
text on my site?

When the brackets appear as plain text, it is because WordPress reached your content, found tags it does not recognize, and printed them verbatim. The cause is almost always one of these:

  • WPBakery was deactivated. Someone disabled the plugin from the Plugins screen, and with it went the code that translates the tags.
  • WPBakery was deleted. The plugin was removed entirely, often during a cleanup or a migration.
  • A theme switch broke the bundle. Many premium themes bundle WPBakery. If you switch to a theme that does not include it, the builder disappears along with the old theme.
  • A license lapsed. Bundled or licensed copies can stop functioning when a license expires, leaving the shortcodes unrendered.
  • You moved to a new builder. Switching to the WordPress block editor (Gutenberg) or another page builder leaves the old WPBakery tags orphaned in your content.

In every case, the root issue is the same: the renderer is missing. The shortcodes themselves are still sitting in your database exactly as they were saved. WordPress simply has nothing left to hand them to, so it falls back to showing the literal text.

What do the common WPBakery shortcodes do?

WPBakery uses dozens of shortcodes, but a small set forms the backbone of almost every layout. Recognizing them helps you understand what a page was *supposed* to look like before the builder went missing.

Shortcode What it does
`
`		 Defines a horizontal row — the top-level container for a section.
`
`		 Creates a column inside a row; the `width` attribute sets its size.
`
`		 Holds a block of rich text (paragraphs, headings, links).
`
`		 Inserts a single image with sizing and link options.
`
`		 Renders a styled button.
`
` / `
`		 Nested rows and columns for layouts inside columns.
`
`		 Adds a horizontal divider line.
`
`		 Builds an accordion or toggle section.
`
`		 Embeds a video from a URL.
`
`		 Inserts vertical spacing between elements.

Notice the pattern: rows wrap columns, columns wrap content elements, and attributes inside each tag control sizing and behavior. When WPBakery is active, this nesting becomes your visible grid.

How do I fix raw shortcodes showing on my site?

There are two correct paths, and the right one depends on whether you want to keep using WPBakery or move on from it.

Option 1 — Reactivate WPBakery (you want to keep the builder).

If the layout was working fine and you simply want it back, restore the plugin that renders it:

  1. Go to Plugins → Installed Plugins in your WordPress dashboard.
  2. Find WPBakery Page Builder (it may also be listed under a theme-bundled name). If it is present but inactive, click Activate.
  3. If it is missing entirely, reinstall it — and if it was bundled with your theme, make sure the theme that includes it is active or that you have a valid standalone license.
  4. Reload the affected page. The shortcodes should render back into your designed layout.

This is the fastest fix and is the right move when the deactivation was accidental.

Option 2 — Rebuild and remove the shortcodes (you are migrating away).

If you are deliberately leaving WPBakery for the block editor or a different builder, do not just delete the plugin and walk away — that is what left the orphaned tags in the first place. Instead:

  1. Recreate the affected pages in your new builder or in Gutenberg blocks.
  2. Replace the old WPBakery content with the rebuilt version.
  3. Once each page is rebuilt and verified, remove the leftover `[vc_*]` shortcodes so no orphaned tags remain.
  4. Only after the content is migrated should you deactivate and delete WPBakery.

There is no automatic, lossless converter that turns WPBakery shortcodes into native blocks — the two systems store layout differently. Migration is genuine rebuilding work, which is exactly why testing it safely before going live matters so much.

What is the page-builder lock-in lesson here?

The deeper takeaway goes beyond a single plugin. Page-builder shortcodes are proprietary to the builder that created them. Content you build in WPBakery is stored as WPBakery tags; content built in another shortcode-based builder is stored in *that* builder’s tags. Remove the builder, and its content reverts to raw code.

This is page-builder lock-in. It does not make any one builder bad — WPBakery is a capable tool used on a huge number of sites. But it does mean that switching builders is never a clean swap. Your content is coupled to the tool that wrote it, and breaking that coupling means rebuilding, not just uninstalling.

Knowing this changes how you should plan changes. Before you deactivate a builder, switch themes, or experiment with the block editor, you want a way to see what breaks before your visitors do — and a way to undo it if something goes wrong.

Test builder and theme changes safely with DarazHost

This is exactly the kind of change that should never be made directly on a live site. DarazHost WordPress-friendly hosting includes one-click staging environments, so you can clone your site, deactivate WPBakery or switch to a new builder, and watch for orphaned `

` shortcodes in a private copy — long before any visitor sees a broken page. When you are confident, you push the rebuilt version live.

If something still slips through, automatic backups let you roll back to the previous working state in moments rather than rebuilding from memory. Paired with fast SSD storage for snappy editor performance and 24/7 support when a migration gets tricky, DarazHost gives you room to experiment with page builders and themes without gambling on your production site.

How do I prevent this from happening again?

The best defense is a small change in workflow. Treat any builder, theme, or major plugin change as a deployment, not a casual edit:

  • Stage first. Make builder and theme changes on a staging copy, never directly on production.
  • Back up before you touch the plugin. A current backup turns a broken migration into a quick rollback.
  • Inventory your shortcodes. Before removing a builder, search your content for its tags (for WPBakery, the `vc_` prefix) so you know exactly which pages need rebuilding.
  • Migrate, then delete. Rebuild affected pages in the new system, verify them, and only then remove the old plugin.

Follow that sequence and you will never again be surprised by a wall of brackets where your homepage used to be.

Frequently asked questions

What plugin uses the

shortcode? The `
` shortcode is generated by the WPBakery Page Builder plugin, formerly known as Visual Composer. The `vc` prefix stands for Visual Composer. Every `[vc_*]` tag on your site was written by that builder and is only rendered while it is active.

Why is

showing as text instead of a layout? Because WPBakery — the plugin that interprets those tags — is deactivated, deleted, or otherwise unavailable. The shortcodes are still saved in your content, but with no plugin to render them, WordPress prints the raw bracketed text instead of building the row-and-column layout.

Can I just delete the

shortcodes to clean up my page? You can, but only after you have rebuilt that content in another builder or in Gutenberg blocks. Deleting the shortcodes without rebuilding removes the layout and content they represented. If you still want the WPBakery layout, reactivate the plugin instead of deleting the tags.

Is there an automatic way to convert WPBakery shortcodes to Gutenberg blocks? There is no reliable, lossless automatic converter, because WPBakery and the block editor store layouts in fundamentally different ways. Migrating away from WPBakery means rebuilding the affected pages in your new system rather than running a one-click conversion.

Will reactivating WPBakery bring my old layout back? Usually yes. Because the shortcodes are still stored in your content exactly as they were saved, reactivating WPBakery restores the renderer and the page returns to its designed layout. This is the fastest fix when a plugin was deactivated by accident.

About the Author
Priya Nair

Leave a Reply