How We Architect Search on Optimizely Commerce Builds: Graph, Coveo, and Knowing When You Need Both

Most CMS platforms ship with no search at all. You get a content management system, and then you're on your own figuring out how visitors are going to find anything. Optimizely is an exception. Between Search & Navigation (Find, to those of us who've been around a while) and now Optimizely Graph, you've always had a real, integrated search capability out of the box. That matters more than it gets credit for.

But here's something we've learned building commerce sites at WOW over the past couple of years: there's a point where "out of the box" isn't enough. Not because Graph is bad, but because enterprise commerce search is a different animal entirely. And pretending one tool can cover both content discovery and complex product search is how you end up with an architecture that doesn't serve either use case well.

This post is about how we think about that boundary, and what our search architecture actually looks like when a client's needs cross it.

Full disclosure: WOW is both an Optimizely implementation partner and a Coveo partner. I'm going to be straightforward about where we use each and why, and you can weigh that accordingly.

Search Isn't One Problem

This is the thing that trips up most project scoping conversations. Someone says "we need search" and it goes on the backlog as a single line item. But on a commerce site, "search" is actually several distinct problems:

Content discovery is how visitors find pages, articles, resources, and support documentation. It's keyword-driven, it benefits from semantic understanding, and it mostly needs to be fast and relevant.

Product search is how shoppers find what they want to buy. It involves structured data (SKUs, prices, inventory, categories), faceted navigation, and results that need to be ranked by commercial intent, not just relevance.

Personalised search is product search that adapts to individual behaviour. Returning customers see different results than new visitors. Purchase history, browsing patterns, and segment membership all influence ranking.

Merchandising is the editorial layer on top of search. Marketing teams need to boost seasonal products, bury out-of-stock items, pin promotional results, and manage rules that change weekly or daily.

You can handle the first problem with Graph and handle it well. Once you're into the second, third, and fourth, you're in a different category of tooling.

Where Optimizely Graph Fits (And Why We Use It on Every Build)

We've been building all new Optimizely sites at WOW with Graph for over a year. On CMS-focused projects, it's the only search layer we need. For content-heavy sites, it does exactly what you want: fast, CDN-served, GraphQL-native, with semantic search that genuinely improves content discoverability.

Graph is also becoming the connective tissue for Optimizely's broader platform direction. Content Manager depends on it. External Content depends on it. RAG for Opal flows through it. If you're building on Optimizely in 2026, Graph isn't optional, it's foundational. We covered this in detail in our CMS 13 post, but the short version is: Graph is the backbone and we're fully committed to it in that role.

For simpler commerce implementations, Graph can handle product search too. If you have a manageable catalogue, straightforward faceting needs, and your search requirements are mostly "help people find the right product by keyword and category," Graph will get you there. The commerce integration package works, the faceting is functional, and the GraphQL query model is clean once you've learned it.

The question is what happens when a client's requirements go beyond that.

Where the Walls Are

I want to be careful here because this isn't a criticism of Graph. Most platforms don't offer anything close to what Graph provides, and the team at Optimizely is actively developing it. But when we've tried to run Graph as the sole search engine on commerce builds with more complex requirements, we've hit real limits.

Personalized search and behavioral ranking don't exist yet in Graph. For a B2B client where returning customers expect results tuned to their purchase history, or a B2C site where conversion depends on showing the right products to the right segments, this is a core requirement, not a nice-to-have. Graph treats every visitor the same.

Merchandising control is limited. Graph recently added pinned results (their version of Best Bets), which is a step forward. But commerce teams that are used to sophisticated merchandising rules, seasonal boosting, time-based promotions, and visual result management need more than what's currently available. We've had clients with marketing teams who manage hundreds of search rules across product categories. That workflow doesn't exist in Graph today.

The commerce search provider is still early. The IncludeInDefaultSearch attribute isn't supported yet, which means all string properties become searchable whether you want them to or not. On a product catalogue with rich metadata, that creates noise in results. The sync job approach (rather than real-time indexing) also introduces latency that matters for fast-moving inventory.

Multilingual product search has gaps. Semantic search is English-only. For clients selling across multiple markets with localized catalogues, that's a meaningful limitation.

None of these are architectural dead-ends. They're features in development on a product that's maturing. But when a client needs them today, you need a plan.

Enter Coveo: Enterprise Search for Enterprise Commerce Problems

When a client's search requirements cross the threshold I've described above, we bring in Coveo. Not as a replacement for Graph, but as a complement to it.

Coveo is an enterprise search and relevance platform. It handles the personalization, the merchandising, the behavioral ranking, and the multilingual product search that commerce sites with mature requirements need. It also brings machine learning models that improve relevance over time based on actual user behavior, which is something no amount of manual tuning can replicate.

What we've found is that the two tools actually coexist well when you architect for it deliberately.

The Architecture: How Graph and Coveo Work Together

On our commerce builds where both are in play, the separation is clean:

Graph handles content. CMS pages, articles, resources, documentation, and any content-driven search experience runs through Graph. It also serves its platform role for Content Manager, Opal, and the broader Optimizely ecosystem features that depend on it.

Coveo handles product search. Catalogue queries, faceted product navigation, search-as-you-type on the product side, personalized results, and merchandising all run through Coveo. The product data is indexed from the commerce catalogue (and often enriched from PIM sources), and Coveo's ML models handle relevance and personalization.

The frontend calls both through a unified API layer. This is the architectural piece that makes it work. Rather than having the frontend make direct calls to two different search services, we build API endpoints that abstract the search source. The frontend makes a search request, and the API layer routes it to the appropriate engine based on what's being searched. Content queries go to Graph. Product queries go to Coveo. The visitor never knows (or needs to know) that two engines are involved.

This also gives us a clean separation of concerns for the development team. The Graph integration follows Optimizely's standard patterns. The Coveo integration follows Coveo's SDK and API patterns. The API layer is where we manage the boundary, and it's where any shared logic (like unified search that spans both content and products) lives.

How We Decide What a Client Needs

Not every commerce client needs Coveo. That's important to say, because recommending enterprise tooling to a client who doesn't need it is bad consulting.

Here's roughly how we think about it:

Graph is sufficient when the product catalogue is moderate in size, search requirements are primarily keyword and category-based, the site is single-language or English-primary, the marketing team doesn't need active merchandising control over search results, and there's no requirement for personalized or behaviorally-ranked results.

Coveo enters the conversation when the client has a large or complex product catalogue, search is a meaningful part of the conversion funnel (not just a utility), the marketing team needs merchandising control that goes beyond pinned results, there's a multi-market or multilingual requirement, or the client expects search relevance to improve over time based on user behavior.

There's a middle ground too. Some clients start with Graph-only and graduate to Coveo as their requirements mature. We architect for that possibility from the start by keeping the API layer abstracted, so swapping the product search engine doesn't require a frontend rebuild.

What This Means for CMS 13 Planning

If you're planning a CMS 13 upgrade and the Graph migration is part of that conversation, it's worth thinking about this before you scope the search workstream.

For content search: migrate to Graph. It's where the platform is going, it's what CMS 13 features depend on, and it works well.

For product search: assess honestly. If your client's commerce search needs are straightforward, Graph will serve them. If they're complex, the Graph migration is still necessary for the platform benefits, but it might not be sufficient as your sole search engine. Plan accordingly.

The worst outcome is telling a client "Graph will replace Find for everything" and then discovering mid-project that their commerce search requirements need a different tool. That conversation is much easier to have during scoping than during UAT.

Wrapping Up

We're bullish on Graph. We use it on every build, we think it's central to Optimizely's platform future, and for content search it's genuinely excellent. The fact that Optimizely ships an integrated search capability at all puts them ahead of most CMS platforms.

But we've also learned, through real project experience, that enterprise commerce search is its own discipline with its own tooling requirements. Graph and Coveo aren't competitors in our architecture. They're complements, each doing what it does best.

If you're navigating this decision on your own commerce builds, happy to compare notes. It's a conversation worth having before the upgrade timeline starts compressing.