WPBakery builds pages using shortcodes — bracketed text like [vc_row] — that only render correctly while WPBakery itself is active and processing them. Deactivate WPBakery, switch to a different builder, or change themes without converting that content first, and visitors see the raw shortcode text sitting on the page instead of the layout it was meant to produce.
Before you buy, check the raw content
Read-only. Open the affected page and switch to the Text or Code view in the editor, rather than the visual view, to see the raw content underneath.
If you see bracketed text like [vc_row] or [vc_column] sitting in the content, that confirms this is exactly a raw, unprocessed shortcode issue rather than a different kind of display bug.
Checking a couple of other pages the same way, not just the one you noticed, gives us a sense of how widespread this is before we start, which affects how the cleanup is scoped. Older pages tend to carry more of this than recently-created ones, so checking your oldest content first is usually a reasonable place to start looking before assuming the whole site necessarily needs exactly the same amount of the same treatment.
WPBakery legacy shortcode cleanup
Pages are showing raw shortcode text like [vc_row] instead of the layout they should. We convert the content properly so it renders without WPBakery active.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Bracketed shortcode text visibly showing on the page instead of rendering | This fix covers it |
| WPBakery still active but a specific element displaying wrong | A different WPBakery-specific display fix |
| Migrating fully to the block editor, not just cleaning up leftover shortcodes | WPBakery to block editor migration |
| The page looks broken but shows no visible shortcode text | A different display-fault diagnosis |
| General theme or builder residue after a switch, no visible shortcodes | Old page builder residue removal |
What you are seeing
- Bracketed text like [vc_row] or [vc_column] appearing directly on the page
- The problem appearing right after deactivating WPBakery or switching page builders
- Some pages affected while others display correctly, depending on which builder created them
- Content that looked fine while WPBakery was active, now showing raw code
- The issue affecting older pages specifically, built before a more recent switch to another tool
Common causes
- WPBakery deactivated without first converting its shortcode content to another format
- A theme switch removing WPBakery’s own shortcode-processing integration
- Content copied or imported between sites without its builder dependency coming along
- A plugin conflict preventing WPBakery from processing shortcodes even while still active
- Cached page output serving a version saved before shortcodes were properly processed
What we do
- Identify every page still carrying unprocessed WPBakery shortcodes
- Determine whether WPBakery needs reactivating temporarily or the content should convert directly
- Convert shortcode-based content into standard blocks or clean HTML, preserving the original layout
- Verify each converted page visually matches the original, working version
- Remove leftover shortcode artefacts that don’t convert cleanly, replacing them appropriately
- Confirm no page on the site still shows raw shortcode text after the cleanup
What is included
- Shortcode content converted to a format that renders without WPBakery active
- Visual verification that converted pages match the original layout
- A full sitewide check for any remaining unconverted shortcodes
- The pre-cleanup backup, kept for 30 days
Not included
- Redesigning pages beyond preserving their existing layout
- Migrating fully to a specific new builder as an ongoing setup
- Fixing content that was already broken before the shortcode issue appeared
- Recreating WPBakery-specific features that have no equivalent elsewhere
Questions about this fix
Do I need WPBakery reactivated for you to do this?
Sometimes temporarily, since converting content accurately is easier with the tool that understands its own shortcodes still active — we reactivate only as long as needed and confirm with you first.
Will the converted pages look exactly the same?
That's the goal, verified visually against the original rather than assumed — where an exact match isn't achievable with a different builder, we tell you what changed and why.
Can this happen again if I switch builders in the future?
Any switch away from a shortcode-based builder carries this risk if content isn't converted first — we can advise on doing it safely if you're planning a change.
Why did this only show up on some pages and not others?
Pages built entirely with the newer builder or standard blocks were never dependent on WPBakery's shortcodes, so only pages actually built with WPBakery show the problem.
Is this the same as migrating my whole site to the block editor?
No — this specifically fixes pages showing broken shortcode text. A full migration to the block editor as an ongoing standard is a separate, larger piece of work.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.