Publishing to a client's CMS

The article is approved, someone clicks publish, the tool reports success, and two weeks later the client asks why their blog hasn't changed. The post exists in the CMS. The page it was supposed to create never went live. Publishing to a client's site is three separate problems, access, the write itself, and proof the page is reachable, and most agencies solve the first two and skip the third.

Get access you can revoke

Never publish with the client's own login. A shared login can't be revoked without locking the client out of their site, it ends up in a password document, and it makes every action look like the client did it. Every major platform offers a scoped credential instead, and each one behaves differently:

1. WordPress issues application passwords. Created under the user's profile in WordPress admin, named for your agency, and revocable on their own without touching the account's real password. Publishing runs over the WordPress REST API, so a security plugin that blocks the API blocks publishing too, which is worth testing on day one rather than deadline day.
2. Shopify uses a custom app. Created under the store's settings with write access to blog content, which then issues an Admin API access token. Uninstalling the app kills the credential, and changing its permissions means reinstalling, which rotates the token, so record where each token came from. The API talks to the store's myshopify.com address even when visitors use the custom domain.
3. Webflow uses a site API token plus a collection ID. The token is scoped to one site, and the articles land as items in the CMS collection you point at, so the blog collection has to exist before anything can be published into it.

Name every credential after your agency, keep a per-client record of what was created where, and offboarding becomes a ten-minute revocation instead of an awkward conversation about changing passwords. Test each connection when you set it up, while the client's developer is still paying attention.

Publish as drafts until the chain is proven

The first article through a new connection tests everything at once: the credential, the formatting, the images, the categories or collection fields, and the theme that renders it all. So land the first articles as drafts, open them in the platform's admin, and look at how they actually render before setting anything live.

Each platform has one habit worth knowing in advance. On WordPress, uploading images needs the same credential to have upload permission, and categories are matched by name and created if missing, so a typo in a category name quietly creates a new one. On Shopify, the theme decides how the post looks, so headings and images can arrive correctly and still render in whatever style the theme imposes. On Webflow, CMS items appear on the live site only after the site itself is published, so a post can sit correct and invisible until someone clicks publish in Webflow.

Watch the first few articles on any new connection all the way to the live page. After that, trust the process and check by exception.

A successful write is not a live page

Here is the mechanism that catches agencies out: the API call and the public page are different systems. The CMS can accept the post, and report success honestly, while the URL a reader would visit returns a 404, because the post is still a draft, the blog template is unpublished, the permalink isn't what you assumed, or the site needs its own publish step. The write succeeded. The publish didn't.

So verification is its own stage: fetch the public URL and look at what comes back. A publish record worth trusting says published only after the page was fetched and found, and shows a still-checking state as distinct from live. Two judgement calls make that record honest, and they're worth copying even if you verify by hand. A fresh 404 isn't yet a failure, because hosts deploy asynchronously and a page can honestly take minutes to appear, so allow a grace window before concluding it's missing. And a server error proves nothing about the page, because a 5xx means the host had a bad moment, so check again rather than record a false failure.

One boundary to keep in mind: reachable means the URL returns the page, and says nothing about how the theme renders it. Layout is what your drafts-first check covered by eye.

Report URLs, not writes

What reaches the client is the live URL, verified. A monthly report listing published articles that 404 is the fastest way to lose an account, because the client will click, and the one broken link will outweigh the ten good ones. When a post shows as not live, the fix is on the platform side, set the post live, publish the Webflow site, correct the permalink, and then check the URL again. The report waits for the page, never the other way round.

What to take away

• Publish with a scoped, revocable credential named for your agency, never the client's own login, and record what was created where.
• The first articles through any new connection go out as drafts, because the first publish tests the credential, the formatting and the theme at once.
• A successful CMS write is not a live page, so verify by fetching the public URL, allow a grace window for a fresh 404, and never treat a server error as proof the page is gone.
• Clients get verified URLs, not publish confirmations.

Next

A verified URL is the first honest line of the monthly report. Reports clients actually read covers the rest of the page.