Authoring in YAML, serving from Wix: a headless pipeline that survives contact with reality

Most content setups force a bad choice. Either the client gets a friendly editor and the developer inherits a pile of unstructured, untyped mush — or the structure is airtight and the client cannot change a comma without a deploy. I wanted both: clean, typed, version-controlled content and a non-technical owner who can update their own site whenever they like.

The shape that gets me there is a headless one. The content management lives in Wix; the site is a separate, custom front end that reads from it. Here is how the pipeline actually fits together.

One section, authored as YAML

Each section of a page starts life as a small YAML file in the repo, keyed by what kind of section it is. YAML because it is human-readable, diffs cleanly in version control, and is pleasant to write — copy lives next to a comment explaining the section's job, not buried in a database row.

That file is the authoring source. It is also the seed: a script reads the YAML and pushes each section into a Wix collection as a structured record. So the same words I write in the repo become the words the client sees in their CMS, ready to edit.

Validate at the door, every time

The thing that keeps this from rotting is a validation layer between the content and the page. Every section's data is checked against a schema before it is allowed to render. A field that is missing, mistyped, or malformed does not crash the page and it does not render broken — it is caught and skipped, and in development it tells me exactly which file and which field to fix.

This is the part people skip and regret. The CMS is editable by humans, and humans paste odd things. The schema is the seatbelt: the client can edit freely because the structure cannot be broken by a bad entry, only ignored.

Wix wins at request time, YAML is the safety net

At request time the page asks two questions: is there a Wix record for this section, and is it valid? If yes, Wix wins — the client's live edits are what ship. If Wix is unreachable or unconfigured, the page falls back to the YAML in the repo, so it still renders something correct rather than a blank.

That fallback is not just belt-and-braces. It means the site builds and runs in development and in CI with no live CMS connection at all — the repo carries a complete, valid copy of the content. Nobody is blocked waiting on a credential.

Why a client should care about any of this

The headline for an owner is simple: you can change your own content, and you cannot break your own site. Update copy, swap a section's text, fix a typo at midnight — it goes live without a developer in the loop, and the structure holds because it was designed to.

That is the difference between renting a site you have to phone someone to touch, and owning one you can actually run.

Building that kind of editable, durable backend is one of the things I do under application development — content systems that are friendly at the front and disciplined underneath. If you are tired of raising a ticket every time you want to change a sentence, book a free intro call and I will show you what self-serve, without the fragility, looks like.