What We Check Before Publishing GEO Content to a Client's CMS

Writing the content is half the work. Getting it into a client's CMS correctly, with the right fields, the right metadata, and the right approval, is where small errors creep in. A page that was perfect in the editor goes live with a missing author, a broken table, or a title in the wrong field.

We use a pre-publish checklist for every piece. It is dull and it works.

Where we publish from

Promptwatch publishes to WordPress through an official plugin, to Webflow including localized collections, and to Framer. It uses AI field mapping to match content to the CMS fields. WordPress publishing is available to every organization, and the other connections are set up per client.

We treat publishing as a convenience for the last step. It does not replace review.

Before anything is connected

Confirm ownership and permissions. Who owns the CMS account? Who approves publishing? We get written permission for what we may push and where.

Choose draft or live. Our default is to push drafts for the client to review, not to go live. Hands-off publishing is possible in some workflows, and the Content Agent, available on Business and Enterprise, can plan, write, and publish on a schedule with either a review inbox or a hands-off mode with a quality check. We lean on the review inbox. Agency plans do not include the Content Agent.

Map fields once. Title, slug, body, summary, author, category, images, and metadata. We check the mapping on a test item before sending real content.

The content check

Before pushing, a human reads the piece with these questions.

1. Is every factual claim sourced or from the client? Statistics, prices, quotes, and customer names are the usual trouble. Anything we cannot verify comes out.
2. Does the first paragraph answer the question? Pages that start with a long preamble tend to waste their best chance.
3. Are headings in sentence case and meaningful? They serve readers and extraction alike.
4. Is the tone the client's? We check against their style notes.
5. Is there a named author and a date that reflects reality?
6. Are links correct? Internal links point to live pages, external links to sources that say what we claim.
7. Do images have alt text and the right licence?

The technical check

Slug and URL. Short, descriptive, and consistent with the site's structure. We avoid changing the slug of an existing page.

Title and meta description. Written for people, with the main topic early.

Canonical and indexing. No stray noindex, and the canonical points at the page itself. Templates copied from staging are a classic source of trouble.

Structured data. If the site uses schema, the new page carries the right type and valid properties.

Rendering. We view the page's raw HTML and confirm the content is in it and not loaded later by script.

Internal links to and from the page. A new page nobody links to is hard for bots to find. We add links from related pages.

Sitemap. Check that the page appears.

Redirects. If we replaced an old page, the redirect is in place and not a chain.

Platform-specific notes

WordPress. Check that the plugin maps categories and author profiles, and that the theme does not strip headings or tables.

Webflow. Check the collection fields, and for localized collections, confirm each locale has the right translation and slug.

Framer. There is no per-item publish. Going live redeploys the whole Framer site. This means any unfinished change elsewhere on the site goes live with ours. We coordinate with whoever else is editing, and avoid publishing at a moment when something half-done sits in the project. We also tell clients about this up front, because it surprises people.

After publishing

We open the live page and check it again, because live output sometimes differs from preview. Then:

• Request a fetch or let sitemaps do their work.
• Check Agent Analytics for a successful crawl by the relevant bots. Crawler logs need Professional or higher, or an agency plan.
• Add the page to the Page Tracker and the target prompts to the panel.
• Note the date, so we can compare periods later.

A rollback plan

For each client we know how to unpublish or revert. If a page goes live with a problem, we want to fix it in minutes, not hours. We keep a note of who has the access.

What we do not publish

Content with unsourced claims. Content the client has not approved. Content we have not read in full. Content that exists only to fill a gap in a report. This restraint has saved us embarrassment more than once.

Documenting the workflow

We write down the steps, owners, and approvals in a short runbook per client. When someone is on holiday, the process does not depend on memory.

Our recommendation

Push drafts, review them as a human, run the technical check, and verify crawling after going live. We use Promptwatch's publishing connections and Agent Analytics for the last steps, since the same project holds the content, the target prompts, and the crawler evidence. See promptwatch.com.