Check the published article after the CMS handoff

Treat publication as a transformation

A draft can change when it moves through an editor, API, CMS, and page template. Headings may be altered, links rewritten, images omitted, or metadata replaced by defaults. A successful API response only confirms part of that journey. Plan a check of the actual public page or preview. Keep the approved revision available so the publisher can compare the intended article with the rendered result. This is especially important when automation sends the same content to several destinations that interpret formatting and fields differently.

Verify the reader-facing content first

Open the article at desktop and mobile widths. Check the headline, opening answer, heading hierarchy, lists, tables, and any worked example. Confirm that qualifications and hypothetical labels remain near the relevant claims. Inspect images for legibility and ensure captions or credits were not dropped. Follow the main internal and source links. A page that technically loads can still be unusable if a table overflows, a code sample loses line breaks, or a crucial warning is hidden by the template. Prioritize the parts that affect comprehension and action.

Check the publication signals

Confirm the intended URL, canonical, title, description, and publication state with the site owner's tooling. Google's title-link and canonical documentation are relevant references for these signals. Make sure a preview or staging hostname has not leaked into links or metadata. Verify that a scheduled article is not public early and that an approved public article is not accidentally left in draft. When a sitemap is generated automatically, check whether the intended canonical URL appears. These checks help align the content system with the actual page readers and crawlers encounter.

Hypothetical example: a successful job with a broken result

Imagine a publishing integration returns success after creating an article. The live check reveals that the CMS stripped a table and replaced the meta description with a site-wide default. The editor restores the table as supported markup and updates the description field. The team then adds those transformations to its integration test cases. The issue was not whether the request completed; it was whether the final page preserved the approved information. Recording that distinction prevents future reports from treating transport success as proof of editorial completion.

Keep rollback and ownership clear

Assign an owner for publication problems and define how to restore the previous version or return a page to draft when necessary. Save the external post identifier and final URL with the article record. Recheck the page after any repair rather than assuming the second publish worked. Track recurring failures by destination so the integration can be improved systematically. A short, consistent live-page check is usually more useful than a long checklist nobody completes. The final acceptance criterion is that the reader sees the approved article in the intended location and state.

• Compare the rendered article with the approved revision after every handoff.
• Verify the final URL, state, images, links, and essential metadata.
• Store the destination identifier and define who can reverse a faulty publication.