If you have ever loaded a WordPress page and found a wall of text beginning `[vc_row content_width="grid"`, you have met this problem. It is one of the most common ways a working website quietly stops working, and it is almost always discovered by a customer rather than by the owner.
Here is what is actually happening, and what can be saved.
Page builders do not store pages, they store instructions
When you build a page with a shortcode-based builder, WordPress does not save the layout. It saves a set of instructions that the builder translates into a layout every time someone loads the page.
The instructions look like this, and they are what is really sitting in your database:
[vc_row content_width="grid"][vc_column width="1/2"][vc_column_text]Your actual sentence lives in here[/vc_column_text][/vc_column][/vc_row]
As long as the builder plugin is active, WordPress hands those instructions to it and gets HTML back. The moment the plugin is deactivated, expired, renamed or lost in a migration, nothing is there to translate them. WordPress does what it does with any text it does not recognise: it prints it.
Why it usually happens
In our experience it is one of four things, and rarely a dramatic one:
- The builder's licence lapsed and the plugin stopped updating, then broke on a PHP upgrade.
- The site was migrated and the premium plugin, which is not in the WordPress plugin directory, did not come with it.
- A theme was changed, and the builder was bundled with the old theme rather than installed separately.
- Someone deactivated plugins while debugging something unrelated and did not reactivate all of them.
The second failure, which is worse
There is a subtler version of this that cannot be fixed by reinstalling the plugin.
WordPress runs a filter called `wptexturize` over post content. Among other things, it converts straight quotes into typographic curly quotes, because that is what looks right in prose. It is supposed to leave shortcodes alone.
When that protection fails — through a plugin conflict, a bad migration, or content that was pasted back in through the wrong editor — the quotes inside the shortcode attributes get converted too. What was `content_width="grid"` becomes `content_width=”grid”`.
Shortcodes with curly quotes cannot be parsed. Reinstalling the builder will not help, because the builder no longer recognises its own syntax. At this point the layout information is gone for good.
What you can recover
The good news, and it is genuinely good news: **your words are still there.** They sit between the shortcodes, intact. Headings, paragraphs, list items, image references — all recoverable.
What is not recoverable, once the quotes are mangled, is the layout: which column something was in, what the spacing was, which background applied to which row. That has to be rebuilt.
In practice that is a smaller loss than it sounds. If you are already rebuilding, you were probably going to change the layout anyway.
How to check your own site in two minutes
- Open your homepage and press Ctrl+F (Cmd+F on a Mac). Search for `[vc_` — and also for `[et_pb`, `[fusion_`, `[elementor`. If any of them appear in the visible page, you have this problem.
- View the page source and search for `js_composer` or your builder's name. If its stylesheet is not loading, the plugin is not running.
- Check whether the quotes in any exposed shortcode are straight (`"`) or curly (`”`). Straight quotes mean reinstalling the plugin may fix it. Curly quotes mean it will not.
How to avoid it next time
The underlying issue is that your content is only readable by software you are renting. There are two reasonable ways out.
The first is to accept the dependency and manage it: keep the licence current, keep the plugin updated, and make sure it is included in every backup and migration.
The second, which we prefer for sites that need to last, is to keep content in the native WordPress block editor. Blocks store their output as ordinary HTML in the database, with a small comment marking each block. If every block plugin on your site vanished tomorrow, the page would still render — you would simply lose the ability to edit those blocks visually.
That is a meaningfully different failure mode. One degrades. The other publishes your source code to your customers.
If it has already happened
Do not panic, and do not start deleting pages.
- Take a full backup before touching anything, including the database.
- Try reactivating the builder first. If the quotes are still straight, this may restore everything.
- If that fails, export the text. The words can be pulled out of the shortcodes reliably, page by page.
- Rebuild the layouts in native blocks, so the next plugin change does not do this again.
It is a rebuild rather than a repair. But it is a rebuild you only have to do once.