Website content silos the build enforces.
The folder is the URL, and an unregistered folder fails the build. Information architecture stops being a diagram somebody drew once and becomes a rule.
The diagram was right. The site drifted anyway.
Every site starts with a structure. Someone draws it: the sections, what goes where, which page answers which question. It is usually correct on the day it is drawn.
Then the site is edited by people who never saw the diagram. A page is added where it was convenient. A section is renamed in the menu but not in the address. Two years on, the structure exists in three places — the diagram, the navigation and the URLs — and no two of them agree. Search engines read the third one. So does the client, when they type an address from an old proposal and land on a page that moved.
Nobody decided this. It happened because the structure was a document, and a document cannot refuse a page.
A diagram describes. A rule refuses.
Three rules, one registry.
The folder is the URL
A page’s address is its position on disk and nothing else. A file in the codes folder is served under the codes path. There is no routing table to fall out of step with the files, because the files are the routing table.
Every folder is registered
The site keeps a short list of the folders allowed to exist: its silos. Each is a subject the site has decided to own, and each page inside it answers one question within that subject.
An unregistered folder fails the build
Add a folder the list does not name, and the build stops with the folder’s name and the list it is not on. The page cannot be deployed until somebody decides, in writing, that the subject belongs on the site.
The registry is deliberately small. Adding a silo is a one-line change, which is the right amount of friction: enough to force the decision, not enough to prevent it. Removing one is the same line deleted, and the build then refuses every page that lived there until each is moved or retired, which is what closing a section should mean.
This site has four silos. The build knows their names.
ownthecode.dev registers four folders: the CODES test, the escape pages, the playbook and the free chapter. This page lives in the third, and its address says so. The second holds one page per platform — leaving Wix, leaving Squarespace, leaving Webflow — and the address of each says which. Every page under each folder links back to the argument it belongs to, and all but the thank-you page end on the same form.
Try to add a blog. The build fails, because there is no blog silo, and the failure is the point: a blog is a place to put pages that have no subject, and this site does not have one. If a subject earns a silo, it gets registered and a page can be written. Until then, the structure the reader sees is the structure the build enforces, and the two cannot drift apart.
Silos give the gate something to check and the query rule something to organise. They are also what Extensibility looks like done honestly: adding a subject is allowed, and it is a decision rather than an accident.
Structure as a rule. Not as a memory.
Every silo holds pages. Every page holds one query.
The release gate checks the silo list on each build. The next system, one query per page, decides what each page inside a silo is for, and the playbook takes the two together.
Read the sharpest chapter first. It costs an email.
We’ll send the build-gate chapter in full: the checks, the code, and the reasoning. Read it. If it doesn’t change how you think about shipping client sites, you’ve lost ten minutes and kept a working release gate.
That did not send. Check the address and try again.