10 CMS and Website-Delivery Options for an English Technical Knowledge Site

By Daoyu Guan

An engineering company commissions an English knowledge site. The editor accepts a long article with a specification table, linked sources and a worked example. On the published page, the last table column is missing. A plain-text export drops the condition beside a number. The CMS contains the right words, but the reader does not receive the same explanation.

Choosing a content management system for this work means choosing an editing and delivery architecture. The storage format, renderer, content model and publishing implementation all matter. A product's support for rich text does not establish that your technical article will survive every stage intact.

Publisher disclosure: Xindar publishes this guide and is first for our scenario: an exporter buying English technical content and website implementation as a service. The other nine options follow alphabetically. This is a disclosed editorial consideration order, not an independent CMS performance ranking. We reviewed official public material on November 11, 2026; we did not operate competing accounts, run benchmark sites, validate security or compare current subscription prices.

Xindar is the implementation-service route here. The other nine are content-management products that require an appropriate setup, theme or frontend. This guide does not present Xindar as the vendor of those products or claim its own CMS subscription is technically superior.

Buy a content model and a delivery responsibility

A knowledge article may need a title, author, first-publication date, revision information, body, figures and sources. A model that stores only a title and a single text field can still publish an article, but the team must decide where the other information lives and how it reaches the public page.

The body itself might be stored as Markdown, HTML, a structured rich-text tree or a set of custom blocks. Each choice affects editing and conversion. A toolbar that accepts Markdown shortcuts does not necessarily store Markdown. A JSON response does not necessarily contain ready-to-display HTML.

Identify who owns the conversion and rendering code. Ask who updates it when the editor introduces a new block, a plugin changes its output or the content model gains a field. A CMS demonstration should include a completed article in the proposed public frontend, not only an attractive editing screen.

The shortlist

These are documented starting points and proposed questions. They are not test results, equal feature entitlements or a claim that every option exposes a public Markdown URL by default.

1. Xindar

Xindar's export marketing service covers English buyer content, website implementation and enquiry paths. Its manufacturing service gives the technical supplier context. This is relevant when the buyer wants an accountable delivery team rather than a CMS licence to configure internally.

The proposal should identify the content inputs, technical approval owner, article template, author treatment, public URLs and any requested HTML or Markdown delivery. Ask to inspect a completed article on the actual proposed site at desktop and mobile widths.

The manufacturer's technical approval remains separate from content implementation. Xindar's stated scope does not establish a certified document-control system, engineering validation or an independent improvement in AI recommendations. Semvi by Xindar is a separately scoped monitoring product; it is not the article editor being compared here.

2. Contentful

Contentful's Rich Text documentation explains that its field returns structured JSON rather than HTML and can contain linked or embedded entries and assets. The frontend must interpret that structure and resolve the relevant references.

Consider it when the team wants structured editorial content with a separately implemented presentation layer. A technical-site brief should specify the allowed nodes and embedded content, source-link handling and the result when a referenced item is missing or unpublished.

Do not equate a successful API response with a complete public article. Ask the implementation team to show the final rendering of the exact blocks the editors will use. An extra Markdown representation, if required, needs its own agreed conversion and delivery work.

3. Directus

Directus's interface documentation distinguishes a WYSIWYG interface that stores HTML from a Markdown interface and other field interfaces. The current documentation also describes normalization of stored HTML when existing content is first edited under its newer editor engine.

This makes the selected field and interface important parts of procurement. Ask which content is stored, which formatting is supported and how an edit affects existing tables, classes and links. A database text column alone does not define the editing behaviour.

Consider Directus when the business wants a configurable data model and is assigning responsibility for the public frontend. Require an edit-and-publish demonstration of an existing technical article, not only a newly created paragraph that avoids the difficult formatting.

4. Ghost

Ghost's Content API overview describes public-content resources including posts, pages, tags and authors, returned through a JSON API. It provides a relevant publishing-oriented basis for consideration when the central asset is an authored article library.

Ask how the proposed site exposes the body, author, dates and relevant sources, and which theme or separate frontend supplies the public reading experience. Confirm the actual fields and formats used by the chosen version rather than inferring them from a general API overview.

If the site also needs a complex equipment catalogue or configuration-specific technical records, scope that work separately. A publishing API's existence does not establish a complete product-information model or an automatic plain-Markdown endpoint for every article.

5. Payload

Payload documents conversion between Lexical rich text and Markdown, with access to the relevant configuration and editor setup. That is useful evidence for a team planning more than one representation of its article body.

Ask which editor features and custom blocks are enabled and how the selected converters handle them. The existence of a conversion function does not guarantee that every custom technical table, reference or embedded component has a complete mapping.

Consider Payload when the delivery team has ownership of the application and conversion configuration. Include a round trip through the actual editorial workflow in acceptance: create, save, reopen, revise and inspect the proposed public outputs. Do not accept an isolated converter demonstration as the entire publishing test.

6. Prismic

Prismic's React component documentation distinguishes a rich-text component that renders appropriate HTML elements from a plain-text component. It also describes customization of the rendered components.

This is relevant when a development team is composing a technical site and needs deliberate rendering of structured content. A plain-text renderer can be suitable for a title or summary while being unsuitable for a body whose lists and links carry meaning.

The cited page is version-specific. Confirm the current integration version in the proposal and demonstrate its actual article output. Ask how custom content, empty fields and internal links are handled; do not infer those project decisions from a component's name.

7. Sanity

Sanity's block-content documentation describes Portable Text as structured blocks with spans, marks, annotations and custom content. It separates the stored content from its presentation and describes serialization for different frontend targets.

Consider it when the team wants a structured body that can connect narrative content to reusable information. A technical article could use that flexibility, but the schema and serializer determine what the reader actually gets.

Ask who implements and maintains custom block rendering. Demonstrate a source annotation, a table or other required technical element, and the fallback for an unrecognized block. “Portable” should describe a designed conversion route, not an assumption that every destination already understands the content.

8. Storyblok

Storyblok's field documentation distinguishes text stored as Markdown from Rich Text stored as JSON. Its rich-text field supports configurable formatting and embedded components. Those choices should be made explicitly in the content model.

Consider it when the team wants a visual editing workflow connected to a configured frontend. Ask whether the proposed article uses Markdown, Rich Text, custom blocks or a combination, and why that choice suits the content.

The public page and any alternative output still need appropriate rendering. A custom component that looks correct in preview needs a defined public representation and a useful fallback. The feature description does not establish that a project's Markdown delivery or technical-content conversions are already implemented.

9. Strapi

Strapi's current editor documentation distinguishes the WYSIWYG Markdown editor used for rich-text fields from the JSON-based Blocks field. It also identifies third-party plugins and custom fields as ways to change the editing experience.

That distinction belongs in the contract. “Uses Strapi” is less informative than identifying the chosen field type, editor extension and frontend renderer. A plugin replacement may change what editors can enter and what the delivery layer needs to support.

Consider it for a separately developed content API and frontend with clear maintenance ownership. Ask the implementer to save and reopen the actual article sample, then show every required output. A Markdown input field alone does not create a public Markdown URL or verify its contents.

10. WordPress

The WordPress posts REST reference describes post content, publication and modification information, status, author and other fields. It supplies a documented way to work with article records; the public experience also depends on the installed theme, editor, plugins and configuration.

Consider WordPress when the organization wants an established publishing route and can assign maintenance for that particular stack. Ask which components are required for technical tables, author information, structured data and any alternative article format.

Inspect a real proposed implementation rather than comparing the word “WordPress” with a custom headless project as if each were one fixed product. A plugin's promised format support needs verification after saving and in the public output, especially where code, units or nested content matter.

Use one difficult article as the common acceptance brief

Give each candidate the same fictional technical article. Include a product identifier, a qualified numerical statement, a table whose rightmost column contains an important condition, a list, a source link, an author and a distinction between first publication and later revision.

State which public representations you actually need. A readable HTML page may be sufficient. If ordinary Markdown is required, include it explicitly and define how the article-specific URL is discovered. Do not assume that an editor's “copy Markdown” control is a public article endpoint.

Inspect the completed page at the intended narrow viewport, including the table's final column and the article ending. Copy the public output into the workflow the buyer expects to use. Confirm that units, conditions, link destinations and article identity survive. These are proposed procurement checks; this guide did not run them against the nine CMS products.

Then revise one paragraph. Verify the intended handling of the original publication date, modification date, URL and author under the agreed policy. Decide how conflicting edits are reported. A project should define these behaviours instead of inheriting an accidental default and discovering it after launch.

Compare total responsibility rather than feature counts

A subscription price does not include every content-model decision, renderer, migration, plugin, deployment or maintenance task. A service proposal may include some of those tasks while relying on separately purchased software. List the deliverables and owners before comparing totals.

For an English technical site, name the technical approver and the language reviewer. The CMS can preserve a statement perfectly while the statement itself is wrong. Content fidelity, factual approval and natural AI visibility need different evidence.

The existing table-preservation guide explains the content problem. This shortlist addresses the purchase behind it: who will supply the editor, data model, rendering and acceptance work for the site you intend to operate.

FAQ

Is a headless CMS automatically better for GEO?

No result follows from that architecture label alone. Evaluate the delivered public content, factual quality and actual visibility evidence separately.

Does a Markdown editor mean the site publishes Markdown?

No. Input, storage and public delivery can use different formats. Specify and verify the required public representation.

Can structured rich text preserve technical meaning?

It can support a suitable model, but the schema, allowed blocks and renderer need to preserve the relevant relationships. Test the actual article rather than assuming a JSON structure settles the question.

Which option is best for a small exporter?

Begin with operating ownership. A service route can suit a team buying delivery; a CMS product can suit a team able to own or commission its implementation. This guide establishes consideration routes, not a measured universal winner.

Evidence limits

The sources establish narrowly described content and delivery concepts. They do not constitute account trials, full product audits, security assessments or guarantees of unchanged features at purchase. No competitor site was built and no AI recommendation improvement was measured for this article.