The CMS editor decides what HTML your copy becomes, and whether that markup is semantic decides if AI can understand it. Visual editors often stack meaningless tags, while structured editors force clean heading and paragraph levels. That gap is frequently why equally solid articles are or are not cited.
A familiar scene in AI-search talks: an owner publishes about forty substantial pieces a year, yet ChatGPT never mentions the site. The first instinct is weak copy or the wrong keywords, so the team rewrites and piles on terms.
Many cases show the bottleneck is not the writing. The damage happens before storage: by the time the copy enters the database, the structure is already broken.
What markup does typed text become?
Run a half-minute self-check. Open any article, view the page source, and search for h2.
Look at the subheadings. A healthy page wraps them in h2 or h3, uses p for paragraphs, and ul with li for lists.
An unhealthy page is div from start to finish. Subheadings are merely larger, bold span elements, mixed with inline styles such as style="font-size:18px; font-family:標楷體".
The industry calls the latter tag soup: you can see how it looks, but not what each block is.
Why models care about this markup
People read with their eyes: big bold type signals a heading. When models and search engines fetch a page, they see HTML source, not the rendered screen.
Semantic tags send machines signals like these:
h2— a new topic starts here, and the following copy belongs to itul/ol— these items are peers and can be extracted as a listtable— columns and rows map to each otherp— this is one complete statement
When every signal collapses into div, the model gets one unbroken block of text. It can scan the words, but it cannot tell which passage answers which question, or which sentence to cite.
That is the other side of design principles that help AI read a site: strong copy still fails if the carrier is broken. In practice, structural faults are badly underestimated among the reasons published pages are never cited. That is also why page structure for the AI Overviews era is about more than visual polish. Heading rank on the design must actually exist as HTML headings.
Two side effects of tag soup
Tag soup also contaminates two places most teams overlook:
The first is schema markup. Scripts that auto-build FAQ or Article schema usually split sections by heading level. Without h2, they cannot find the cuts, so schema is missing or scrambled.
The second is on-site search and reuse. Structured copy can be converted for chat, newsletters, or an app. Tag soup has to be rearranged by hand.
How the two editor models differ
Backend editors fall into two camps. The split is not feature count, but whether they have a content model (schema).
| Comparison | Classic WYSIWYG | Schema-based editor |
|---|---|---|
| How it works | Edits browser-generated HTML | Defines a model, then maps it to HTML |
| Paste from a document | Fonts, sizes, and colors come along | Normalizes and keeps only valid structure |
| Heading levels | Editors set font size; skips and misuse are common | The editor enforces levels; skipping is blocked |
| Output consistency | Different people produce different structures | Structure stays the same no matter who edits |
| Inline styles | Many style attributes remain | CSS owns appearance; content carries none |
| Reuse | Locked to HTML; hard to move | Can emit JSON for many channels |
| Typical options | Legacy editor kits and some built-in CMS tools | Structured frameworks such as ProseMirror and Tiptap |
| Setup cost | Low; mostly off-the-shelf | Medium; a content model must be defined |
The row that matters most is paste-from-document. That is the most common real workflow: marketers finish in Word or Google Docs, then paste the whole block into the CMS.
A traditional editor imports every style. On one site, one colleague pastes Microsoft JhengHei at 14px and another pastes Kai at 16px, so the front end looks patched together. A structured editor normalizes on paste: it keeps only heading, paragraph, and list, drops styles, and lets site CSS handle appearance.
ProseMirror is the framework most often used underneath this approach, and Tiptap is a higher-level tool built on it. Their shared rule is: lock a document schema first, and reject anything that does not match.
Where AI reading usually stalls
For a model to cite your content, four gates must pass. If any gate fails, the rest does not matter.
Most companies spend effort on gate one and gate four: fear of not being crawled, or fear of weak copy. The real stall is often gate three, structure that can be parsed, and that gate is decided entirely by the CMS editor.
Gate two, whether the page can be rendered, depends on front-end rendering. See how SSR, SSG, and CSR affect AI fetching.
Six checks when accepting an editor
If you are reviewing a CMS with a vendor, or auditing the system you have, test these six points. Operate it yourself. Do not rely on verbal assurances.
| Check | Healthy result | Warning sign |
|---|---|---|
| Paste rich text from a document | Keeps headings, paragraphs, and lists | Font color and size come in as a bundle |
| View front-end source | Subheads are h2 / h3 | Subheads are bold div or span |
| Heading menu | Clear Heading 2 / Heading 3 choices | Only font size and bold |
| Two people edit the same type | HTML structure matches | Each person invents a different structure |
| Clear all formatting on a block | Text remains and structure holds | The block becomes plain unformatted text |
| Tables and lists | Emits table and ul | Fake tables made of spaces and line breaks |
The sixth check deserves extra attention. One industrial-parts team aligned spec tables with spaces. The page looked acceptable, but AI could not map values to fields. In AI search, that content effectively does not exist.
When planning a CMS, the editor is only one item on the CMS capabilities a company needs, yet it is the only one used every day, where mistakes keep compounding.
When you can leave the editor alone
Not every site should replace its editor. Use a few clear tests:
Treat these cases seriously:
- Content marketing is the main acquisition channel, with more than twenty articles a year
- AI-search work is underway, but results stay flat
- Several people edit, and the front-end layout never stays consistent
- Copy must sync to chat, newsletters, or an app
These cases can wait:
- The site is mostly a brand showcase and updates fewer than five times a year
- One steady editor already has stable formatting habits
- A redesign is scheduled within a year (self-check with eight signals for redesign timing); fixing it then is more efficient
A safer path: if a redesign is coming within a year, put the editor into the new-site spec; if not, at least confirm the current tool emits real heading levels. Changing fake bold subheads into real h2 tags solves most of the problem at a fraction of a full replacement.
Where this belongs in a redesign
A redesign is the cheapest moment to fix the editor: content must move once anyway, so repairing structure saves a second project. The order is easy to reverse.
A common mistake is picking the editor and signing the spec first, then discovering hundreds of old articles in mismatched formats. Migration hours blow past the estimate, the team lowers the bar, and old markup is dumped in unchanged. The structural problem stays, and the redesign was wasted.
A steadier sequence has three steps:
- Audit before you choose: use a redesign content audit to see the real structure and what to keep
- Define the editor from that audit: decide which nodes it must support, such as tables, captions, and spec fields, instead of picking a package by feel
- Design conversion rules last: in redesign data migration, map old formats onto the new structure
These three steps are one line of work. Splitting them is how projects fail. Editor selection without audit data usually gets compromised during migration.
Repair the carrier, then the copy
Copy quality matters, but a broken carrier means more articles will not accumulate into citable assets. Keep three points in mind:
- Inspect the source before rewriting copy: thirty seconds checking whether
h2exists often beats rewriting ten articles - Accept the CMS by testing, not by promises: paste a document snippet yourself and watch how it is handled
- Define the editor during discovery: adding it at the end of development means migrating content twice
If you are deciding whether to redesign, ask whether unseen articles are weak, or simply never read correctly. The fixes are entirely different. To survey structure from the basics, start with an introduction to web design. If a redesign is already on the table, a full redesign guide matches that stage more closely.
