What happens to your pages when you switch the page builder off
Deactivate a shortcode builder and visitors see the shortcodes. Deactivate ours on WordPress and the page is blank, because the layout is JSON in post meta and the post body is empty. Here is where each kind of builder keeps your layout, and the twenty-minute test that tells you before you commit.
There is a well-known way to find out how much a page builder owns your website. You deactivate it and look at the page.
With some builders you get a screen of shortcodes where your content used to be, visible to anyone who happens to load that URL. With others you get most of your text back. With ours, on WordPress, you get a blank page. I will come back to that, because a comparison that flatters the person writing it is not a comparison.
The question is not the plugin, it is where the layout lives
Every visual builder has to store your layout somewhere, and there are only a few somewheres. Which one it picked decides exactly what happens the day the builder is not running.
Shortcode builders keep the layout inside the post itself, as instructions only that plugin can read. While it runs, those instructions become a page. While it does not, they are just text — and they are text your visitors can see, which is why this is the failure mode people post screenshots of.
Block-based builders are gentler. A block is an HTML comment wrapped around real markup, so the markup underneath survives on its own. You lose the layout and keep the words. That is a genuinely better position to be in.
DragGo's WordPress plugin stores the document as JSON in post meta and leaves the post body empty. The page is assembled when the page is requested. Switch the plugin off and there is nothing in the post to fall back to, so the page renders blank.
Blank is tidier than gibberish. It is not better. Either way the page is gone until the tool comes back, and I would rather say that here than have you find it out on a staging site.
Hosted builders are a different shape of the same question. There is no plugin to deactivate, because the site is not yours to switch off; it stops when the subscription does. Wix is explicit that the site has to run on their servers, and that is architecture rather than policy.
So what actually fixes it
Only one thing: the builder has to be able to hand you the finished markup, and you have to have read what that markup is missing.
That second half is where most of the disappointment lives. Several builders do export, and the export is real, and it is also partial — the CMS, the forms, the search and the shop are usually services rather than files, so they do not come in the zip. An export you have not opened is a promise, not a plan. Which builders export what, and what each one leaves out, is its own article.
What I can say about our side without overstating it: a published DragGo site is class-based HTML and CSS with no JavaScript by default — script ships only when a page actually uses something that needs it. What the server sends is the markup, not a runtime that assembles the markup in the browser. That is a real difference from a hosted builder and it is a smaller claim than a download button, so I am making the smaller claim.
The twenty-minute test
You do not have to take anyone's word for any of this, including mine. The test is cheap and it is the same test for every builder.
- Clone the site to staging. Never run this on the live one.
- Deactivate the builder — do not delete it. Deactivating is the whole test, and it is reversible in one click.
- Open three real pages: the home page, your longest page, and one with a form on it.
- Read them as a visitor would. Gibberish, blank, or readable text. Write down which, because in six months you will not remember.
- Then ask for the export and open it. Not whether one exists — what is missing from it.
Run that before the site is built and the answer is information. Run it after and the answer is a problem.
Class-based HTML, and no JavaScript by default. What gets served is the markup itself. Script ships only when a page actually uses one. Browse the Market.
What this is not an argument for
It is not an argument against page builders. The alternative for most people is not hand-written HTML, it is no website, and a site that exists and is a bit locked in beats a site that never got built.
It is not an argument that lock-in is always wrong either. A runtime buys you things — animation and interaction that are genuinely hard without one — and some projects should pay that price knowingly.
What it is an argument against is finding out by accident. The cost of asking the question is twenty minutes on a staging copy. The cost of not asking it is a rebuild, usually at the worst possible moment, usually for someone who is already annoyed.
The useful thing to take from this
When you are choosing a builder, the feature list is the easy part to compare and the least useful. Ask instead: where does this thing keep my layout, and what do I have if it stops running? Every builder has an answer. Some of the answers are fine. The only bad situation is not knowing which one you bought.