Publishing and attestation: your CMS publishes, VarynForge records

VarynForge ships no publish connectors, on purpose. Your agent almost certainly drives one already: WordPress, Webflow, Wix, Sanity, Ghost and Contentful all ship an MCP server. Connect it in your host and your agent publishes through it directly. VarynForge does the research, the brief and the verification gate. Placing the piece is your agent's job, or yours. Recording where it landed comes back here.

The flow, for every channel#

1. Publish. Your agent publishes through the CMS or platform MCP it already drives, or you place the piece yourself. Each channel's writer prompt ends with plain publishing guidance for that channel.
2. Verify it is live. Your agent opens the URL and checks the piece is there. An article is never reported as published before this step.
3. Record the live URL. The tool depends on the destination. list_destinations reports it on each destination as publishVia.

Recording an article#

mark_article_published takes the suggestion and its live URL. In one transaction it moves the suggestion to published, writes a row in the distribution ledger and stamps the published event on the article's timeline in the app. The URL is what Search Console outcome tracking keys off, which is why a status flip alone is not enough: update_article_status set to published records no URL, and the article stays invisible to the clicks and impressions the app reports later.

{
  "id": "<suggestion id>",
  "publishedUrl": "https://example.com/blog/the-piece",
  "publishedAt": "2026-10-20T09:00:00Z"
}

publishedAt is optional. Pass it when the article went live before the call, for a backfill or to match the CMS publish date, so the record carries the real go-live moment. It must not be in the future; the call rejects a future date. You can call the tool again on a published suggestion to attach a missing or corrected URL. The ledger keeps every row as history, and the suggestion keeps the latest URL.

IndexNow, and why the order matters#

IndexNow tells Bing, Yandex, Naver, Seznam and Yep that a URL exists. Google does not take part. mark_article_published sends one IndexNow ping when two things hold:

• The project's IndexNow key is verified. You set it up once under the project's indexing settings in the app; VarynForge checks that the key file resolves on your host and holds the key.
• The published URL is on that same verified host.

Otherwise no ping goes out. A project whose platform already submits to IndexNow on its own is marked that way, and VarynForge sends nothing, so URLs are never submitted twice.

The ping fires as soon as the call lands, and nothing re-pings later. A ping for a URL that is not live yet is wasted: the engine crawls, finds nothing, and drops it. That is the reason for step 2. The app shows the last ping only when IndexNow acknowledged it.

Scheduled articles#

When the CMS will publish later, your agent does not call mark_article_published. It sets scheduledFor with update_article_status and leaves the suggestion at ready_to_publish. Publish detect then checks the project's sitemap every hour and matches staged titles against the URLs it finds. On a clean match it attests the article itself, IndexNow ping included. A staged article with no match after 3 days is flagged on the Desk; a scheduled one is exempt until 3 days after its scheduled date.

Recording posts and videos#

register_derived_asset adds a row to the same ledger for anything made from the suggestion: kind is one of carousel_pdf, social_post, video, image or other, and channel is one of reels, youtube, x or linkedin. This is also where a video's URL lands once it is live, since the script gate never sees the video. A repeat post on the same channel registers again with its new URL, and every registration is kept. scheduledFor records a date from an external scheduler, for display only. These rows never change the suggestion's status or its Search Console attribution.

Where to go next#

Drafting and verification covers the gate that comes before this. The five channels explains what each destination expects.