Choose a CMS by testing how your team creates, reviews and publishes content. WordPress suits many publishing workflows, a headless CMS separates editing from presentation, and MDX suits content maintained through a developer workflow. The best fit is the system the responsible people can operate safely, including previews, corrections and recovery.
Start with a page that changes often and a person who will actually edit it. A feature list cannot tell you whether that person can update opening hours without breaking a layout.
Establish who publishes and how
Write down the content lifecycle. A service page might move from a subject expert to a copy editor, then a legal reviewer and finally a publisher. A developer blog may need a pull request reviewed by an engineer. Those are different workflows even if both produce web pages.
Ask who can create, approve, publish and unpublish. Include contractors, translation partners and people who leave the company. Decide whether changes need a history, a scheduled release or an approval trail. Then test those requirements in the specific product and plan under consideration.
Separate a marketing site's content from application records. Customer permissions, orders and medical notes need application controls. They should not become editable CMS entries simply because the CMS has an admin screen.
Compare the three approaches
| Approach | Where content lives | Who can work comfortably | Responsibility you retain |
|---|---|---|---|
| WordPress | WordPress database and media library | Editors familiar with its publishing interface | Hosting choices, updates, plugin governance and backups |
| Headless CMS | A content service or separately hosted CMS | Editors using structured forms and configured previews | Frontend implementation, API integration and publishing behaviour |
| MDX | Text files, commonly in a Git repository | Writers comfortable with Markdown and code review, or supported by an editor tool | Validation, preview builds, deployment and trusted-content controls |
These are operating patterns. An individual headless CMS may be hosted or self-hosted. MDX can have a graphical editor layered on top, and WordPress can act as a headless CMS through its REST API.
If you are still choosing the whole website platform, begin with Webflow vs WordPress vs custom code.
Model content before designing editing screens
Avoid storing every page as one large rich-text field. A service page might need a title, introduction, list of deliverables, related work and enquiry link. A case study needs a client-approved description, scope, genuine assets and evidence for any results.
Structured fields let you validate requirements and reuse content. They also impose a maintenance cost: changing a field can require a schema migration and frontend changes. Model repeated business concepts, and leave appropriate room for prose.
Consider a location entry with a name, address, opening hours and contact method. If the same address appears in the footer, contact page and structured data, one maintained record avoids conflicting versions. That does not require exposing arbitrary page layout controls to every editor.
Make preview part of the acceptance criteria
The editor should see the unpublished page in its real layout, including links, images and mobile behaviour. An API response full of content fields is not a useful preview for a marketing lead.
For a headless system, test draft access, authenticated previews and cache invalidation. Publish a correction and check when the public page changes. Unpublish the entry and verify what the old URL returns. Draft content must not leak through a public API, preview URL, sitemap or cached response.
For MDX, a preview deployment can let a reviewer inspect a pull request before it reaches production. Agree who checks broken links, frontmatter, tables and code examples. A pipeline should reject invalid content with an error the author can understand.
Understand MDX's trust boundary
MDX can combine Markdown and JavaScript or components. That power makes the source more sensitive than a plain text field. Next.js explicitly warns that processing untrusted remote MDX can lead to remote code execution in its MDX guide.
For a developer-maintained marketing site, a narrower content contract can be sensible: Markdown, tables and code fences, with no imports or arbitrary components in articles. Code review and compilation remain part of publication. If you need submissions from untrusted authors, use an appropriately constrained content format and review pipeline instead of treating MDX as harmless text.
Test portability before signing
Export a representative entry with images, references and a redirect. Check whether it includes stable identifiers, alt text, publication dates, slugs and relationships. An export containing only rendered HTML may be awkward to edit in the next system.
Ask how you would replace each dependency:
- The content store and asset hosting.
- The editor interface and approval workflow.
- Preview authentication and publishing webhooks.
- Search, redirects and image transformations.
WordPress's export tool produces a content export; it is not a complete restore of the installation. A headless vendor's export format needs similar scrutiny. Git gives MDX files a portable text history, but custom component syntax can still tie the content to your renderer.
Calculate the maintenance burden
Include editorial seats, environments, API usage, media bandwidth and support in a hosted CMS estimate. For self-hosting, include patching, monitoring, storage, backups and recovery practice. For MDX, include developer review and publishing time rather than assigning that work a cost of zero.
Do not buy a complex workflow for an organisation that publishes once a month through one developer. Equally, do not require a busy non-technical content team to learn Git merely to avoid a subscription.
Run a short selection trial
Use one existing article, one service page and one page with a relationship to another entry. Have the actual editor create a draft, obtain approval, preview it, publish, correct a mistake and export it. Record where they needed help and which tasks required engineering.
Choose the system that handles those tasks within your staffing and budget constraints. Document the accepted limitations, such as fixed page layouts or developer-reviewed publication, so the next team understands the choice.
For a Next.js implementation, Apex's web team can scope the content model and editor workflow alongside the site rather than treating the CMS as an afterthought.