Riseo published to WordPress and nothing else. This website does not run WordPress, which left us with an awkward choice and a better answer than the one we started with.
Key takeaways
- Publishing to a website turned out not to require pushing content into it at all.
- Riseo already holds every post and its state, so a site can read from Riseo rather than Riseo writing into the site.
- The same interface that publishes this blog is what will support websites that do not run WordPress.
A product that publishes to your website should probably publish to its own. Ours could not, for a slightly embarrassing reason: Riseo publishes to WordPress, and riseo.ai does not run WordPress.
The options were not appealing. Stand up a WordPress instance purely to feed our own blog, which is a second system to secure and maintain for no reason a customer benefits from. Or copy and paste posts by hand, which would make the claim on this page a lie.
The realisation
The WordPress integration works by pushing: Riseo authenticates against a site and writes a post into it. That is necessary for WordPress, because WordPress owns the content once it is there.
But Riseo already holds every post. The draft, the compliance result, the edit history, the approval, the publication state — all of it lives in Riseo, and the copy in WordPress is a downstream duplicate.
Which means a website that can fetch does not need to be pushed to. It can read from Riseo directly. Publishing stops being a transfer and becomes a state change: a post is approved, its state flips to published, and any site reading from Riseo sees it on the next request.
Publishing stopped being a transfer and became a state change. That is the whole idea.
What actually happens when a post goes live here
- Riseo drafts the post overnight from tracked search data and the services on this site.
- The compliance engine checks it and rewrites what it flags.
- It appears for approval. Someone reads it and edits what needs editing.
- On approval, the post's state changes and a cache invalidation fires.
- This site requests the current list of published posts and renders them.
Elapsed time between someone clicking approve and a post being readable here: usually under ten seconds. No editor, no plugin, no file uploaded anywhere, no credentials handed to a third-party system.
Why this matters beyond our own blog
The reason Riseo supported WordPress first is that WordPress is roughly two in five websites, and for a small team that is where you start.
But a great many clinics are not on it. They are on Webflow, or Squarespace, or Wix, or something a local developer built. Under the push model, each of those is a separate integration with separate authentication and separate failure modes, built one at a time.
Under the read model, they are all the same problem. Any site that can make a request can display its posts, and the work moves from us building an integration per platform to a small amount of work once per site.
What we are honest about
This is newer than the WordPress path and it has had far less production use — this blog is the first thing running on it. WordPress remains the supported, documented route for customers today, and the read interface is rolling out with sites we work through directly.
Which is the other reason our own blog runs on it. If it breaks, it breaks for us first, in public, on a page where every post carries a record of exactly how it got here.