In the vendor demo, the CMS drafts a page, shows each visitor a different version of it and records authorship on a blockchain, all in twenty minutes. The marketing lead for a hospital chain with sites in six cities watches it while choosing the platform her team will live with for the next five years. Each of the three ideas has a practical core, and each comes with work that the demo skips. Before signing, she needs to know which of that work her team can actually take on.
What AI inside the CMS actually does
The common features are drafting copy, headlines and meta tags, auto-tagging with related-content suggestions, translation into other languages, and flagging compliance risks before publishing.
They carry very different risk. Auto-tagging and related links are low risk, because a wrong tag is visible and takes a second to fix. Drafting is useful as a starting point, but the text can be confidently wrong, and it will read like every other hospital's site until an editor reshapes it. Translation needs a fluent reviewer per language. A Hindi draft from a model still needs someone who knows how patients in Lucknow actually phrase a question. Compliance flags can miss things, so they work as a second check and never as the only one.
In every case, the feature only helps if the workflow has an approval step. A draft that publishes itself is a liability, and on a hospital site a legal one. If you want the longer version of this argument, our post on AI content automation in an API-first CMS goes through what works and what is still hard.
Personalization needs consent and content
Personalized pages rest on three things. You need to recognise the visitor, you need a consent record for the data you use, and you need different content ready to show them.
Teams underestimate that third part every time. Each variant is a page someone has to write and keep current. If the cardiology page has one version for first-time visitors, one for returning patients and one for referring doctors, that is three pages to update whenever a consultant joins or leaves. The editing team is still the same two people.
- 01Signalcookie, referrer, city
- 02Consent checkmay we use it?
- 03Rulepicks a variant
- 04Variant servedwritten and approved
- 05Measureddid it help?
If any step is missing, the visitor should get the default page.
Start with explicit rules. A returning visitor sees a different call to action from a first-time one. A visitor who came from the Pune city page sees Pune appointment slots. Rules are easy to explain to the marketing head and easy to debug when the wrong version appears. A predictive model is worth adding only once you have enough variants and enough traffic to show it beats the rules, and most sites never get there.
Where the variant gets picked matters
Vendors rarely mention this part, and it shows up in your Core Web Vitals.
If personalization runs in the browser, the page loads the default version, a script asks a service which variant to show, and the content swaps after it has painted. The visitor sees the page jump. Open the network tab and you will see the personalization script near the top of the waterfall, delaying everything behind it. On a mid-range Android phone the swap is easy to notice, and it pushes up Cumulative Layout Shift.
Picking the variant on the server, or at the edge before the HTML is sent, avoids the swap. In Next.js that is a few lines of middleware:
// middleware.js
import { NextResponse } from 'next/server';
export function middleware(req) {
const consented = req.cookies.get('consent')?.value === 'personalise';
const returning = req.cookies.get('visited')?.value === '1';
if (consented && returning) {
return NextResponse.rewrite(new URL('/cardiology/returning', req.url));
}
}
export const config = { matcher: ['/cardiology'] };
The consent check sits in the code path, so a visitor who has not agreed always gets the default page. Each variant is still a pre-built page you can cache.
When a lighter Web3 solves something
Early Web3 projects bolted a blockchain onto products that did not need one, which is why most businesses sensibly stayed away. The lighter version applies a few of the ideas in narrow places. Users can hold their own verifiable credentials and present them to different apps. Authorship and rights can be traced without anyone needing a crypto wallet. Shared automation can run on a record that several parties rely on.
The test is whether a normal login and a database would do the job. A single company running its own site does not need a shared ledger. It starts to make sense when several organisations must verify the same fact without trusting one operator, such as a group of colleges checking a certificate without phoning the issuing university each time. If you cannot name the second organisation, you do not have that case.
Where CMS upgrades go wrong
The feature gets bought before the editorial process is defined, so AI drafts start arriving and nobody owns reviewing them.
Personalization gets treated as a switch, when consent, variants and measurement are three separate pieces of work with three separate owners. Behavioural data gets collected first and the decision about how to use it comes later, which ends in a pile of data that cannot lawfully or sensibly be used.
A CMS gets chosen that cannot expose content over an API, and a year later the personalization layer or the AI service has nowhere to plug in. Our comparison of headless and traditional CMS platforms is a good place to check that before you sign. And decentralised features get adopted because they are fashionable, after which someone maintains wallet and key recovery flows that no patient asked for.
Adopt, wait or skip
| Idea | Adopt when | Hold off when |
|---|---|---|
| AI in the CMS | An editor reviews every output before publishing | The goal is to remove the editor |
| Personalization | You have consent, variants and a way to measure | You have one version of each page and little traffic |
| Web3-lite | Several organisations must verify the same record | A normal login and database would work |
Before you evaluate any of the three, write down the workflow you want. Who creates content, who approves it, who sees which version, and where the data lives. Take that one page to every vendor demo and ask them to show your workflow, not theirs. Drop any feature that does not fit it, however good it looked on screen. If you are rebuilding the platform anyway, that written workflow is also the first thing our CMS development team asks to see.
