MDX vs a traditional CMS for marketing websites

MDX and a traditional content management system solve the same broad problem in very different ways.

Both can separate content from page layout.

The difference is where the content lives, how it is edited, how it is deployed, and what infrastructure the publishing workflow requires.

We use MDX heavily because it fits our operating model. It is not the right answer for every editorial team.

A traditional CMS is an application for editors

A database-backed CMS gives writers and editors a user interface.

They can sign in, create records, upload media, schedule content, manage authors, and often preview pages without touching source control.

That is extremely useful for organizations with internal publishing teams.

The CMS is not overhead if the editorial workflow genuinely needs the application.

MDX is a source format

MDX files live with the codebase.

They can contain frontmatter for structured fields and Markdown-style document content below it.

The repository provides version history. The build system turns the file into a page. The application controls layout, metadata, images, schema, and responsive behavior.

There is no separate publishing database to keep in sync.

Our MDX content standard describes the file conventions in detail.

Version control changes the editing model

In a CMS, the content history usually belongs to the CMS.

With MDX, the history is Git history.

A developer can see exactly what changed in the article, when it changed, and what code change shipped alongside it.

That is valuable when the same team manages development and content.

It is less convenient when twenty nontechnical editors need to publish independently every day.

MDX keeps layout out of the content

A general-purpose CMS often has to decide how much layout control editors receive.

Block editors and page builders can give authors substantial freedom, but that freedom can also create inconsistent spacing, duplicate patterns, and content records that contain presentation logic.

Our MDX standard takes the opposite approach.

The document describes the information. React and CSS describe how the information is presented.

That makes the content easier to move and the interface easier to keep consistent.

Build-time publishing has different tradeoffs

An MDX change normally ships through the same deployment process as a code change.

That means the content benefits from preview deployments, build validation, link checking, and reproducible releases.

It also means publishing may require a developer workflow or an editorial interface layered on top of the repository.

A CMS can publish without rebuilding the application, which is useful when immediate editorial independence matters.

Search infrastructure becomes easier to connect

Because the application reads the content directly, the same loader can provide data to several systems.

A single MDX record can feed:

• the page route
• static generation
• metadata
• article schema
• related-content logic
• category pages
• navigation
• sitemap entries
• modification-date systems

This reduces the number of separate places that have to be updated when a new page is added.

A CMS can still feed the same architecture

Using Next.js does not require using MDX.

A headless CMS can provide structured content to the same route and component system.

We would choose that architecture when the editorial team needs a strong authoring interface but we still want the rendering, performance, and deployment control of the application layer.

The important question is not "MDX or CMS" as an ideology.

It is where the source of truth should live.

Why MDX fits many of our clients

Most of our service-business clients are not running newsrooms.

They publish a manageable number of service updates, articles, case studies, location pages, and business changes. We are often the team making those updates.

Under that operating model, a separate CMS can become another system to secure, back up, train, and eventually migrate without solving a meaningful editorial problem.

MDX keeps the workflow close to the implementation.

When we would recommend a CMS

A traditional or headless CMS becomes attractive when the organization needs frequent independent publishing, multiple editorial roles, approval workflows, scheduled content, large media operations, or nontechnical staff who cannot reasonably use repository tooling.

That is a real requirement.

We would rather add the correct authoring system than force an internal team into a developer workflow that slows them down.

The reason we like MDX is not that databases are bad.

It is that simple content deserves a simple source of truth, and the application can stay sophisticated without making the document itself complicated.