How Website Builders Work Under the Hood

How website builders work is the part of this subject that almost every guide waves at and moves past — a sentence about drag-and-drop, and on to the templates. That is a shame: the machinery is not complicated, and once you see it, three baffling things make sense: why the editor feels instant, why HTTPS arrives without you asking, and why nobody will give you your site as a folder.

What you'll have at the end of this lesson: a working mental model of what a builder stores, what it renders, and what actually happens when you press publish.

You do not need to write code to follow this.

The four machines behind the editor

Lesson 01 defined a builder as four things sold as one: an editor, a data model, a renderer and a serving layer. This lesson opens each one. If you have not read what a website builder is, start there.

Two ways an editor lets you drag

Every visual editor must answer one question: when you drop something, what decides where it goes? There are two answers, and the choice shapes your next six months more than any feature does.

Absolute positioning. Every element carries explicit coordinates. You can put anything anywhere, down to the pixel. This feels like power, and on a fixed-size canvas it is.

The cost is structural rather than cosmetic. If elements have coordinates but no relationships, the layout has no rules to reflow by when the screen narrows. So editors built this way give you a second, separately maintained mobile layout — and every change you make afterwards is a change you make twice. The classic Wix editor works this way.

Section and grid systems. The page is a stack of sections, and elements snap into a grid inside each one. You lose pixel freedom. You gain layouts that reflow on their own, because the elements are described by their relationships instead of their coordinates. Squarespace's Fluid Engine uses a snap-to-grid model, and Wix Studio, launched at the end of 2023, moved to a fluid grid for the same reason.

Beginners nearly always read absolute positioning as the more capable option, then meet the maintenance tax weeks later, when the phone version has to be rebuilt by hand. If you are choosing today, that is the most useful sentence on this page.

Your page is JSON, not HTML

Here is the part that surprises people. When you save a page in a builder, no HTML file is written anywhere. Your page is stored as structured data — a tree of typed component nodes, each with a name and a bag of options.

Builder.io publishes its document shape openly, which makes it an unusually good primary source for a pattern the whole category shares. A page is a data object holding a blocks array, and each block names a component and its options:

{ "data": { "blocks": [ { "component": { "name": "Text", "options": { "text": "Hello world!" } } } ] } }

Then, at render time, the renderer walks that blocks array and creates one component instance per node. The docs describe the mechanism plainly: Builder "keeps a map of component names to references, and messages the web app what components exist and what inputs they take", as set out in Builder.io's technical documentation.

Read that twice; it is the whole lesson in one sentence. The word "Text" in your saved page is not text — it is a key into a registry that only that vendor's renderer holds. Without the registry, the key means nothing.

How the editor stays in sync

Live editing in a builder is typically an iframe with messages passing between the editor shell and the page inside it. The application sends the document down, and then, in Builder's own description, "sends patches when edits are made to what to render differently. The SDK renders the updates accordingly."

That is why builder editors feel instant: nothing is rebuilt or re-uploaded, only patched in place. It is also why preview and published page can differ slightly — two runs of the same tree in two different environments.

What a template actually is

Not a file. A template is a pre-populated tree plus a set of style tokens — colours, type scales, spacing — applied over it.

This explains a constant frustration. "Changing template" is not swapping a file underneath your content; it is re-mapping content from one tree into a differently shaped one, and where the shapes do not correspond something is dropped or guessed. That is why template changes are rarely lossless, and why the safest time to change one is before you have written anything.

Where the HTML comes from

Someone requests your page; something must produce HTML. Large builders do this on the server, at genuinely impressive scale.

Wix runs a dedicated Node.js server-side rendering platform executing React on the server, reported by its own engineering team at roughly one million requests per minute, alongside published work on multi-threading Node.js to cut the number of rendering pods and what they cost to run.

Two consequences. First, it is why builder sites are indexable and quick to first paint: real HTML arrives in the response, not an empty shell waiting for scripts. Second, it is why no vendor can hand you a folder of files. The HTML did not exist until somebody asked for it.

How your domain, CDN and certificate appear on their own

You point a domain at a builder and, minutes later, it works, on HTTPS, with a valid certificate you never requested. This looks like magic and is entirely mechanical.

The flow is standardised: you point a CNAME at the vendor or hand over your nameservers, the vendor registers your hostname through its edge provider's API, and a certificate is issued and renewed automatically for as long as you stay.

Cloudflare documents this pattern precisely in its custom hostnames documentation for platforms: the platform registers customer domains via REST API, certificates are issued through Let's Encrypt or DigiCert, domain control validation can be done over HTTP, TXT or email, and Cloudflare manages the entire certificate lifecycle including issuance and automated renewal.

So when someone asks why HTTPS became free and automatic, the honest answer is that it is an API call and an automated protocol, not a favour. Any vendor could do it. Most now do.

Why exporting a builder site does not give you your site

This is where all of the above lands.

Squarespace's own support documentation is refreshingly specific about what an export contains. It produces an XML file designed for WordPress import — and it explicitly does not export album, cover, index, info, calendar, portfolio or store pages; content in page-specific headers, footers and sidebars; more than one blog page; dropdowns, audio blocks, product blocks or video blocks; drafts; style settings; or custom CSS. One blog page comes across, with up to 1,000 comments per post. You can read the list yourself in Squarespace's export article.

Wix, for its part, documents no code export at all.

The structural reason is exactly what we built up to. Your page lives as vendor-specific JSON, interpreted by a vendor-specific renderer. Export the JSON without the renderer and you have data with no design. Export the rendered HTML and you have a frozen snapshot with no editability. Neither of those is your website.

One fairness note, because this is not a complaint about visual editing. Builder.io's documentation positions the opposite model outright: "You control your site, code, and hosting—Builder only passes content within your own setup." Same underlying architecture, opposite arrangement. Lock-in is a product decision, not a property of JSON.

What to do with this

Nothing dramatic. Three things, though, are worth acting on.

Read the export page of any platform before you build on it, not after. It takes four minutes and it is the most honest document a vendor publishes.

Keep your originals — text, photographs, logos — somewhere that is not the platform. If the design cannot travel, let the content walk out on its own legs.

And size your caution to the site: five pages you could rebuild in a day is a small risk, two hundred posts and a portfolio structure is a large one. That judgement, plus the routes in the complete guide to making a website, is enough to choose well.

Before you move on

• I can explain that a builder stores pages as structured data, not as HTML files.
• I know what a component registry is and why the renderer needs one.
• I can tell an absolute-positioning editor from a section or grid editor, and name the cost of each.
• I know that a template is a pre-populated tree plus style tokens, which is why swapping one loses things.
• I can explain in one sentence why automatic HTTPS is not a favour.
• I have read the export documentation for any platform I am seriously considering.