How This Site Is Built Without Touching a CMS

A walkthrough of the static pipeline behind this site: how content becomes HTML, why the response headers matter more than the design, and which checks run before anything is published.

Content is plain text, the build is the compiler

The writing on this site lives in Markdown files. Each file has a short block of metadata at the top — a title, a description, and a type — and everything after it is ordinary prose. There is no database, no admin panel, and no editor to log into. Adding a page means adding one file.

A build step then turns those files into HTML. This is worth stating plainly because it is the single most consequential design decision on the site. When a generator produces HTML ahead of time, the finished text is present in the response the moment it leaves the server. A crawler does not have to execute JavaScript, wait for an API call to resolve, or hope that a client-side router renders the right branch. Those approaches can work, but each one introduces a failure mode in which the page looks fine in a browser and is empty to everything else.

That failure mode is not hypothetical. A site can serve a few thousand URLs, all of which return a 200 status and a correctly sized HTML document, while every one of them contains nothing but an empty container element and a script tag. Browser-based tools report the page as working. Only when you strip the tags and count the words does the problem appear.

The boring checks that decide whether a page is viable

Three mechanical properties do more to determine whether a content site succeeds than any amount of visual design.

The text must be in the server response. Not fetched afterwards. If the word count of the raw HTML, with tags removed, is under a few hundred words on a page that is supposed to be an article, something is wrong with the pipeline rather than with the writing.

A missing URL must return 404. A site that answers every imaginable address with the same generic page is telling search engines that every address is valid. Those pages get crawled, indexed, and counted. The fix is trivial — ship a proper error page and return the correct status with it — but it has to be deliberate.

The security policy must permit the third-party scripts the business depends on. This is the quiet one. A restrictive script-src directive that omits the advertising and analytics hosts produces no error message in the page, no console warning for the visitor, and no visual defect. It produces a site that earns nothing while appearing finished.

What gets verified before publishing

Every build runs a fixed list of checks, and a hard failure stops the release rather than producing a warning nobody reads. The list covers whether each generated page contains readable text, whether the error page exists and behaves correctly, whether the four pages that advertising networks require are present, whether the content policy allows the advertising domains, whether the sitemap covers the pages that exist, and whether any internal link points at a page that was never generated.

The checks run against the build output first, and then again against the live site after deployment. Running them twice is not redundancy for its own sake. The build output proves the generator did the right thing; the live check proves that nothing between the generator and the visitor — caching, a redirect rule, a host configuration — changed the answer.

Why the maintenance rules are strict

Once several sites share a common template, the temptation is to let each one drift. A fix applied to one site looks harmless, and it usually is, right up until the same defect has to be fixed in twenty places and the twenty copies have diverged just enough that a patch no longer applies cleanly.

The rule that prevents this is simple: a site owns its content and its branding, and the shared machinery belongs to the pipeline. Edits to the shared part go through the pipeline and are then distributed to every site by a single command, which also verifies that no site has quietly forked. Nothing here is clever. It is just the difference between a collection of sites and a collection of one-off projects that happen to resemble each other.