Publish & Measure — the loop that compounds
Plain-English briefing on getting content live on any platform, the internal-linking flywheel, and the re-measurement that proves the whole thing is working. Written 24 July 2026. Last verified: 3 September 2026 (Agent 11 — Wix walkthrough step split, and the new Co-Kinetic Sites automatic behaviours, folded in).
Publishing — any platform, without losing the invisible layer
Most of the value in a generated article is in two layers: the visible words, and the invisible structured data (schema) that AI engines parse directly. Naive copy-paste publishing keeps the first and silently loses the second. The platform's publishing routes are built to deliver both, on whatever the clinic runs:
WordPress — genuinely one click. For clinics on WordPress, publishing is a single click. The Co-Kinetic plugin pushes everything directly: content, schema, correct site section, clean URLs (with automatic redirects if section structure changes), and the clinic's live review rating rendered into both the page schema and a visible badge — server-side, always fresh, never fabricated. Updates work the same way — refresh an article on the platform and push again. The platform gets the live URL back automatically, so the linking flywheel (below) runs entirely hands-off. (Plugin 1.13.1, released 21 Aug 2026: the author panel now populates the documented author fields — credentials no longer show the photo URL on themes following the guide example. There is no auto-update: customers must re-download and reinstall the plugin to pick it up.)
Wix, Squarespace, and everything else — guided copy-paste. The "Put it on your website" flow asks which platform the clinic uses and shows the one recommended route for it, with platform-specific honesty. The standout example: on Wix, pasting a full web page traps it in a container AI can't read — so the Wix route explicitly guides adding the words as native text and the schema through Wix's own SEO settings, in a short tick-off checklist. Formats the platform can't make AI-visible are labelled as such rather than quietly offered. Every route includes copyable schema, sized for platform limits. (Since 31 Aug 2026 the Wix walkthrough's step 1 "Add the words" is guaranteed words-only; the schema code appears ONLY in step 2, at Wix: SEO & GEO → SEO Settings → Advanced SEO → Structured Data Markup. Previously an article could carry its schema block at the bottom of the step 1 text, so a customer asking "why is there code with my article?" was seeing that old behaviour. In the same fix: a reviewer chosen at article creation now carries through to the ready screen with no second prompt, and the "Reviewed by" section renders on newly approved articles.)
A developer, if preferred. A shareable developer hand-off link carries everything a web developer needs.
And coming: our own web builder. We're building a Co-Kinetic web builder that integrates directly with the content system — the clinic's site and its content engine as one connected platform. That takes hands-off to its logical conclusion: content flowing straight from plan to published page with nothing to copy, paste or configure, on a site built for AI visibility from the ground up. Watch this space.
Co-Kinetic Sites — what happens automatically (live from late Aug 2026). For clinics on a Co-Kinetic Sites website, three things that other platforms need steps for are simply automatic:
- Structured data (schema) is emitted on every page type — clinic, condition, article, and clinician profile with credentials. Sites customers never paste schema anywhere; the "put it on your website" schema step does not apply to them. Support note: self-rating star schema is deliberately NOT emitted, because Google disallows it (deployed 27–30 Aug 2026).
- "Reviewed by [clinician]" appears automatically on every condition, treatment, service and blog page once the article's peer review is approved in CCS. If a page shows no reviewer line, the review isn't approved yet — there is nothing to configure (#2813/#2826, deployed 28–30 Aug 2026).
- Pages link themselves — each page carries automatic "related" links to the practice's other CCS pages (conditions ↔ treatments ↔ services ↔ articles), derived from stored relationships and shared topics. No customer action; a page with nothing related simply shows no related rail (#2755/#2775/#2779, deployed 27 Aug 2026).
Closing the loop on the live URL. The platform needs to know where a piece went live (see why below). WordPress publishes report it automatically. For copy-paste routes: the moment a customer copies an article, a card asks "where did it go live?"; a straggler nudge follows later if unanswered; and — most elegantly — the periodic re-measure auto-detects newly published pieces by matching the site's new pages against the clinic's written pieces, so even a customer who never tells us anything gets credited automatically.
The internal-linking flywheel
Every new article links to relevant other pages — drawn from two pools:
- Pool A: the clinic's existing site pages, known from the assessment crawl. Works from day one.
- Pool B: pieces the platform generated, once live. Each published piece becomes a linking target for every future piece.
This is why the live URL matters: each publication makes every subsequent article better-connected. Over months, the clinic's topic clusters become densely interlinked — the exact structural signal AI engines read as topical authority. The tenth article is worth more than the first, because it lands in a richer web. This compounding is the structural argument for the subscription: the platform's value per article increases with tenure.
Re-measurement — proving it's working
The Re-measure is a lighter, periodic re-run of the assessment: it reuses the stored site discovery, re-crawls the pages (catching new and changed content), refreshes all the score-driving inputs — page scores, AI-visibility probing against the fixed benchmark query set, reviews, search positioning — and writes a new dated snapshot alongside the old ones, never replacing them.
The preserved snapshot history is the customer's evidence trail: score at signup, score each measure since, and the specific inputs that moved. Because the AI-probe queries are held fixed as a benchmark, a citation-rate improvement is a genuine like-for-like gain, not an artefact of changed questions.
Re-measurement also drives the plan's honesty. Material movement — beyond deliberately noise-robust thresholds — arms the customer's Regenerate Plan button with a plain-language explanation of what changed. Completing enough plan actions, or a topic cluster crossing a health band, does the same. The plan reacts to reality, not to page loads.
What the customer experiences, end to end
Publish a piece (one click or guided paste) → the piece flips to Published and joins the linking pool → the next generated article links back to it → the cluster's health ticks up → the next re-measure registers the new pages, re-scores, re-probes AI → the score history gains a new data point → if enough moved, the plan offers to refresh with reasons. Repeat. The customer's dashboard tells the story in their own numbers: you published X, your score went from Y to Z, AI now cites you for these queries.
Common questions this briefing answers
- "I'm not on WordPress — do I get a worse experience?" Different, not worse: guided platform-specific routes preserve the full value (including the schema layer), with honest labelling where a platform imposes real limits.
- "Why do you keep asking where I published?" Because each live URL makes every future article better-connected — and if you forget, the next re-measure finds it automatically.
- "How do I know it's working?" Your own preserved score history, on fixed benchmarks, with the inputs itemised. Not our claims — your instruments.
- "What happens to my score history if things are re-measured with a newer algorithm?" History is additive and dated; nothing is overwritten. The platform's cardinal rule is that your benchmark trail is never destroyed.