Why our website content usually lives in the repository

A content management system is useful when the business has a real publishing workflow that needs one. It is not automatically an upgrade over files in a repository. For many of the sites we build, the content changes on a measured cadence. Service pages are reviewed deliberately. Location pages are written individually. Articles are edited before publication. Staff are not logging in every hour to move blocks around. In that environment, adding a CMS can create more infrastructure than value.

The question we start with

We do not ask, "Which CMS should this site use?" We ask, "Who changes the content, how often, and what has to happen when they do?" If the answer is that a developer or managed marketing team is already responsible for publishing, repository content has several advantages. The content sits beside the code that renders it. A content change gets a commit. The deployment tied to that commit can be previewed. If something goes wrong, the exact change can be found and reversed.

That is a much cleaner chain of custody than editing a live production database and hoping somebody remembers what the old copy said.

What this looks like in our repos

Across several unrelated builds, long-form content lives in MDX directories and is loaded with small server-side libraries. One site reads article files with gray-matter, normalizes their slugs, validates dates, and combines editorial dates with Git-derived modification dates. Another reads location files into a typed data model that includes the city name, page title, hero image, service descriptions, FAQs, and SEO fields.

The important part is not MDX itself. The important part is that content is treated as source. A new article is not an unexplained row in a database. It is a file that can be reviewed. A location page is not a pile of fields hidden behind an admin screen. It is a document with a known schema. The build knows where to find it, how to validate it, and which route it should create.

Version control is part of the editorial workflow

When content lives in Git, history comes for free. We can answer questions such as:

• What changed on this page before rankings moved?
• When did this service description get rewritten?
• Which image was replaced?
• Did the canonical logic change at the same time as the copy?
• Was this page published in the same release as a navigation change?

Those are technical questions, but they become marketing questions very quickly when a site is producing leads. A CMS can provide revisions too, but then the editorial history and application history live in separate systems. For a managed site, keeping them together is often more useful.

It removes an entire runtime dependency

A database-backed CMS introduces an application that must remain available for the site to retrieve content, unless the content is fully exported at build time. Repository content can be read during the build and turned into static pages. Once deployed, an article does not need a database query just to display a heading and six paragraphs.

That reduces failure points. There is no content API to rate limit, no CMS token to expire, no database connection pool to exhaust, and no separate content service to secure just so a service page can exist.

There is a tradeoff

Repository content is not right for every organization. If fifty nontechnical employees need independent publishing access, approvals, scheduled releases, localization workflows, or complex editorial roles, a real CMS may be the correct answer. We are not opposed to CMS platforms. We are opposed to adding one because websites are "supposed" to have one.

The difference matters because infrastructure should follow the operating model of the business.

Why this helps performance and search

Build-time content is easy to statically generate. The page can arrive as finished HTML with predictable metadata, internal links, and structured data. Search engines do not have to wait for a content API to respond in the browser. It also makes the sitemap easier to generate from the same source of truth. If a content file exists and passes the model, the route can exist. If it is removed or redirected, the application can reflect that deliberately.

Why this helps ownership

Repository content is portable. If a client takes the code somewhere else, the articles and page content leave with the code. There is no hidden export step and no proprietary database that only the original vendor understands. That fits our broader rule for managed websites: staying with us should be valuable because the work is good, not because the content is trapped.

For the kinds of business sites we build most often, source-controlled content gives us a smaller system, a better audit trail, and a clearer handoff. When a business actually needs the capabilities of a CMS, we can add one. Until then, we would rather not create infrastructure just to imitate a problem that does not exist.