Everything except the body is easy.

A title is a string. A date is a date. Tags are a list. Then there is the body, which is prose with structure inside it, and every CMS makes a different bet about how to store that.

As a blob of HTML. WordPress does this. The post_content column holds markup and the editor writes into it. It is honest about the medium and it is the fastest path to shipping. The problem is that you now have a database column containing arbitrary HTML written partly by a person and partly by whatever editor was installed that year. Changing how images are rendered means a find and replace across every row. Publishing the same content to an app means parsing HTML back into meaning, which is the reverse of the direction information flows naturally.

As markup. Markdown, usually. Smaller, readable, diffable, and it survives the CMS that wrote it, which is more than most storage formats manage. The limit shows up the first time someone wants a two column layout or an image gallery. Markdown has no syntax for that, so every system that stores Markdown grows an extension: shortcodes in WordPress, KirbyText tags, MDX, whatever the current fashion is. The extension is always the ugliest part of the system and always the part editors interact with most.

As structure. Store the body as an ordered list of typed blocks, each with its own fields. A paragraph is a block. An image gallery is a block with a list of images and a column count. This is what Sanity does with its portable text and what Ghost does with its cards, and it is where the industry has been drifting for a decade.

Structure is clearly right for anything that is not prose. A gallery as data can be rendered as a carousel on the site and as three separate images in a newsletter, and nothing has to parse HTML to work out what was meant.

It is less obviously right for the prose itself. A paragraph is a paragraph. Storing it as {"type":"paragraph","children":[{"text":"..."}]} is a lot of ceremony around a sentence, and it makes the content unreadable outside the system that wrote it. Open a Sanity export in a text editor and see how you feel about it.

There is an obvious compromise that nobody quite commits to: keep the prose as markup, because markup is good at prose, and use structure only for the things markup cannot say. The reason it is rare is that it needs both parsers and a rule for where the boundary sits, and it is easier to pick one and force everything through it.

The other thing that gets lost in this argument is that the editor and the storage are separate decisions. A block editor can write Markdown. A plain text field can hold JSON. People conflate them because most systems ship one editor bolted to one format, but the question of what an author sees and the question of what ends up on disk are not the same question, and answering them together is how you end up storing HTML because that is what the WYSIWYG produced.