Search is not a built-in CMS feature
Key takeaway
Many CMS vendors treat search as an afterthought. Don’t copy that.
Weigh it as critically as a new website build.
Have a strategy before go-live. Included is a pitch, not a plan.
The replatform pack was already printed. CMS in green. A column called dependencies in amber. Search was in there, next to forms.
I asked why search was a dependency of a CMS move. The person with the pen didn’t blink. Because that’s where it lives. Same login. Same contract. It came with the old platform, so it would come with the new one.
They weren’t trying to replace search. They were trying to leave a CMS. The box had to be packed because it had never been allowed to stand on its own.
That is what happens when you treat search as a built-in feature.
Included is not a strategy
I’ve sat through the pitch, on old suites and on newer cloud CMS platforms. Search as a line under the CMS, marked included. One login. One contract. Nobody has to explain a second product to procurement.
On paper the cheap part is real. Then you go live, and someone wants to boost a campaign term, hide a dead product, add a synonym for the word people actually type. There is no screen for that. Or there is, and it looks like 2014. So it becomes a ticket. Feature gaps. A roadmap that belongs to the CMS, not the box. Support is polite. Nothing moves. That is what an afterthought looks like. Many CMS vendors see search that way. The CMS is the product. Search is what they ship so the suite looks finished.
Visitors don’t see the contract. They type the word from the email. Nothing useful comes back. A week later it’s a support call.
I really do think selling search inside a CMS is a gimmick. A line on the slide so the suite looks complete. That is my opinion.
What I will not do is treat that opinion as your architecture. A gimmick in the pitch is not a reason to rip the box out on Monday. Look at the site you actually run. Budget, skills, how much the box matters. If search isn’t the job, included might be enough. If it is the job, included is the wrong kind of cheap. “It came in the contract” is not a decision.
Pending the next release
With single vendor technology platforms, organizations run the risk of locking themselves into a set of limited capabilities that are pending upgrades in a next release.
— MACH Alliance, MACH Manifesto
You wait for their roadmap. Their roadmap is the CMS.
One customer I worked with replatformed from a legacy CMS to a SaaS one. That was supposed to be the hard part. The hard part was everything bolted to the old platform. Forms. Search. Same programme, twice. They weren’t choosing a new search because they wanted one. The old one could not leave without the CMS.
Weigh it like the website
Here is the thing I want people to think about.
It is wrong to think of search as a built-in feature. A lot of CMS vendors do. Search is an afterthought in their roadmap, their admin, their support queue. If you copy that, you will feel it after launch.
If you are building a new site or leaving an old one, search deserves the same weight as the website itself. Templates get a plan. Content gets a plan. Search gets a tick. Then launch day, and nobody owns the zeros, the synonyms, or what happens when you move CMS again.
If you don’t want those problems after launch, you need a strategy before you go live. Who runs the box. What you do when a campaign term doesn’t match. Whether a merchandiser can change a result without a ticket. Whether this CMS can leave without taking search with it.
A composable DXP is supposed to make that choice possible. Pick what’s best for the job, against the budget and the skills you have. Pay for what you need. You can still switch the built-in index on. You just shouldn’t have to rebuild search because you rebuilt the site.
If you would not buy that search as a product on its own, don’t inherit it because it lives inside the CMS. And don’t skip the strategy because the slide said included.
The search you inherited isn’t free. It just invoiced later.
