The MDX content lifecycle

Content should have a lifecycle from creation through maintenance. Publishing a file is only the first step.

Create

A new document starts with a clear purpose, slug, title, description, category, and body. It should answer a distinct question or document a distinct system.

Review

Before merge, the page should be checked for duplicate intent, weak headings, broken links, unsupported claims, and formatting problems.

Build

The build process parses the frontmatter, generates the route, creates metadata, and includes the page in the sitemap when appropriate.

Publish

Deployment should make the new route available through the production domain without changing unrelated URLs.

Measure

For commercial and search-oriented content, we can watch impressions, clicks, engagement, and conversion paths. Documentation may also be judged by whether it reduces sales friction and answers technical questions before a call.

Maintain

A technical document can become wrong even when the URL still works. Framework changes, hosting changes, and internal standards should trigger updates to the relevant docs.

Retire carefully

If a document is no longer useful, it should be consolidated or redirected to the strongest replacement when possible. Deleting indexed content without a plan creates unnecessary dead ends.

The lifecycle is tied to Git, previews, and deployment

Because MDX content lives in the repository, editorial work can follow the same review path as application work. A new guide or article can be created on a branch, reviewed in source, rendered on a preview deployment, and merged when both the writing and the page are ready.

That is especially useful for content with technical dependencies. A new documentation page may require a new category, schema behavior, related links, or a route change. The content and the supporting code can ship together as one release instead of being coordinated across separate systems.

Validation happens before publication

Some of our repos inspect required frontmatter, duplicate slugs, date formats, image paths, metadata coverage, and SEO infrastructure during the build. The connectrader site also audits generated output after build. That means content quality has both an editorial review layer and a machine-checkable structural layer.

The machine cannot decide whether an article is worth reading. It can decide whether two articles claim the same slug. That division lets us spend human review on judgment instead of preventable formatting failures.

Modification history stays attached to the source

Several sites derive sitemap modification dates from Git history. The content file does not need a human to update a technical timestamp every time it changes. The release history already knows. Editorially meaningful dates can still live in frontmatter. Publication date and technical modification date answer different questions, so we keep them separate.

Maintenance includes consolidation

As a library grows, some pages become redundant or outdated. We do not want hundreds of documents merely because every historical idea deserves a permanent URL. When two guides converge on the same intent, consolidation can produce a stronger page and a clearer internal-link structure.

Retirement should preserve useful paths. If an indexed page has a clear replacement, a redirect is usually better than leaving a dead URL. Internal links should be updated to the surviving route so the redirect does not become permanent infrastructure.

The lifecycle is what makes a large library sustainable

Publishing is easy. Maintaining meaning across years is harder. A real content lifecycle gives the team a way to create, review, deploy, measure, revise, consolidate, and retire documents without turning the library into an archaeological site. That is the difference between "we have MDX files" and "we have a content system."