How do I move an AI draft into a CMS without breaking its formatting?

Save the approved source, import it as a draft, and compare the converted content and its preview before publishing. Ghost's API documentation explicitly describes its HTML-to-Lexical conversion as lossy: the HTML it renders can differ from what you supplied.

The awkward failures can be easy to miss. In a small local test, a heading looked fine after conversion, but the link pointing to it stopped working. Here is how to find that kind of change without turning every import into a manual rewrite.

What should I save before importing the draft?

Keep an unchanged copy of the approved article, its images and the destinations its links should reach. That gives you something reliable to compare with the CMS draft after conversion.

For a Markdown source, save the actual file, including code indentation and relative links. For a document editor, retain the approved revision and the export you will import. A screenshot helps with appearance, but it cannot tell you whether copied code still contains the same characters.

Make a short list of the structures the article depends on. A nested step, a table header or a figure caption may carry part of the instruction. If the source itself needs a better structure, resolve that before the import; otherwise you will be trying to review editorial changes and conversion changes at once.

How does the CMS represent each part of the article?

Find out which parts become editable blocks and which are stored as embedded HTML. Two drafts can look similar while behaving differently when someone edits them later.

For this article, we ran a synthetic HTML sample through Ghost's official conversion and rendering libraries locally: kg-html-to-lexical 1.4.1 and kg-lexical-html-renderer 1.5.1. The sample included a nested list, a comparison table, indented code, a figure caption and a relative link.

All five survived the comparison. The table became an HTML card; the list, code and image used their corresponding content nodes. The source and runnable test show exactly what we compared. This tests those libraries with that input; your CMS editor and theme still need their own preview check.

That distinction matters during repair. Preserving a fragment as HTML may keep the markup you need, while changing how an editor can work on it.

How do I spot and repair a conversion loss?

Compare the source with the output, then change the smallest part responsible for the mismatch. Reconvert from the saved source so you can tell whether the repair worked.

Our source had a heading with id="conversion-checks" and a link to #conversion-checks. Conversion regenerated the heading's ID from its text: move-a-reviewed-draft-into-the-cms. The link kept its old destination. The words were still there; the destination was gone.

Ghost documents HTML-card markers for preserving supplied HTML. Wrapping just the heading kept its original ID in our rerun:

<!--kg-card-begin: html-->
<h2 id="conversion-checks">Move a reviewed draft into the CMS</h2>
<!--kg-card-end: html-->

The unchanged link then had a target again, and the other five checks still passed. You can inspect the original, converted and repaired samples.

Keeping the old ID is useful when existing links depend on it. If no link depends on that ID, updating the link to the new destination may be enough. Check that choice against the article's actual links before adding a preservation workaround.

What should I check beyond how the preview looks?

Use the content. Follow a nested procedure, read the table by its headers, copy the code and open the links. These checks reveal changes a visual skim can miss.

• Lists: confirm a substep still belongs to the step that controls it. A flattened list can change the order of work.
• Tables: check that each value has the right header and that the last column is reachable on a narrow screen.
• Code: copy it from the preview into a plain-text editor and compare the characters and indentation with the source. Run it only in an appropriate test environment.
• Figures: confirm the image loads and its caption and alternative text still describe the right thing.
• Links: check the resolved destination, including in-page anchors. A relative link such as ../publishing-checks/ depends on where the new article lives, even if conversion leaves its text untouched.

Inspect the draft at desktop and phone widths. Keep ordinary paragraphs within the page; give genuinely wide code or tables a usable scrolling area. A browser's developer tools can help distinguish a missing element from one hidden by styling.

When is the converted draft ready for publication?

When it preserves the approved meaning, the required structures work, and the preview has passed those checks in the destination's actual theme. Save the corrected CMS draft and compare it once more after saving.

Keep the approved source, the CMS draft identifier and a brief note of any deliberate conversion repairs together. The person publishing it should be able to tell which draft passed review and why its markup differs from the source.

If a necessary structure still fails, leave that draft unpublished and resolve the specific mismatch. Approval belongs to the version you checked.