Skip to main content
Talk to an expert
Klevu logo

Klevu integration for ecommerce search and discovery

Searchable catalogue delivered without storefront code changes Klevu indexes your product data and handles search rankings, facets and zero-results recovery through a managed console. Merchandisers adjust rules and promotions live while your storefront consumes ranked results via API. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

Also searched as: search integration, merchandising connector, app, extension.

KlevuiWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Adobe Commerce · Magento Open Source · Shopify Plus · BigCommerce · Other storefronts
On this pageGet a brief reviewed
01 · What you get

What a Klevu integration gives you.

Searchable catalogue within hours

You publish a clean product feed to Klevu and see results indexed and searchable in your storefront within the refresh window. No code deployment, no catalogue freeze.

Facet and synonym governance at scale

Merchandisers own facet trees, synonyms and search rules through the Klevu console. Changes propagate to all storefronts and locales without waiting for IT.

Visibility into search behaviour

You capture every query, click and result impression in Klevu analytics. Trends, gaps and relevance drift become visible within days, informing content and merchandising priorities.

Zero-results recovery without code

Configure Klevu's built-in fallback rules to route empty-result searches to category pages, spelling suggestions or curated content. No storefront engineering required.

Ranking and promotion without redeployment

Adjust product promotions, keyword redirects and ranking boosts in the Klevu console. Live within minutes without storefront code changes or release cycles.

02 · When it's worth it

Where a Klevu integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Indexing product catalogue feeds and keeping the search index fresh as attributes and descriptions change
Building and maintaining facet trees, synonym dictionaries, and search-time rules without editing code
Routing zero-search-result queries to landing pages, category fallbacks, or spelling suggestions
Publishing merchandising rules that rerank or promote products for specific keywords without storefront deployment
Capturing and analysing search queries and click patterns to identify trends, gaps and relevance drift
Testing ranking changes, facet reconfigurations and campaign rules before live exposure
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

Feed format and attribute mapping

Klevu expects a structured XML or JSON feed with specific attribute semantics. If your commerce platform or PIM exports attributes with different names, types or hierarchies, mapping and transformation must happen before the feed reaches Klevu, adding an integration layer.

Real-time pricing and stock integration

Klevu indexes product data including base attributes and categories, but pricing and stock availability are typically owned by ERP or OMS systems. Integrating live pricing or stock into search results requires separate feeds or API calls that Klevu does not provide by default.

Facet cardinality and performance limits

Facets with very high cardinality (thousands of distinct values) or deeply nested hierarchies can degrade search performance or complicate the user interface. Klevu requires planning around facet depth and value counts.

Synonyms and localisation scope

Synonym rules and search-time text transformations are configured per language and market in the Klevu console. Managing synonyms across many locales, products or categories can become labour-intensive without automation.

Zero-results fallback customisation

Klevu provides built-in zero-results handling such as category suggestions or spelling correction, but complex fallback logic (e.g., rule-based routing to dynamic landing pages or inventory-aware substitutes) may require additional storefront code.

04 · The real work

The moment a feed fails to parse or a re-index stalls, you lose visibility into whether customers can still find products; silence does not equal success.

05 · Where it sits

Where this integration sits in your estate.

Klevu holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.

One integration architecture, any storefront. Klevu connects through the same governed layer whatever commerce core you run.

System of record
Source / owner
Klevu
Search index, facet configuration and merchandising rules engine
  • Catalogue indexing and freshness
  • Facet tree configuration and hierarchy
  • Synonym and redirect rules
  • Product ranking and promotional boosts
  • Zero-results handling and fallback routing
  • Search query and click event logging
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceShopify PlusBigCommerceOther storefronts
  • Search API endpoint integration
  • Search result page rendering
  • Fallback logic when Klevu is unavailable
  • Storefront caching of result sets
  • Mobile and desktop search UX
Connected neighbours
Integration layer
PIM / product data
Produces clean, validated catalogue feeds that Klevu indexes; Klevu does not modify product attributes.
Integration layer
ERP / pricing and inventory
Owns live pricing and stock; Klevu may include base pricing in search results but does not serve as inventory source of truth.
Integration layer
Data warehouse and BI
Consumes Klevu search events and click data for analytics, gap detection and merchandising insight.
Integration layer
Commerce storefront
Calls Klevu search API and renders results; implements fallback and caching for resilience.
Integration layer
Analytics and tracking
Captures user interactions with search results; feeds signals back to Klevu for relevance learning and A/B test measurement.
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.

Ecommerce platforms (examples)
  • Adobe Commerce
  • Magento Open Source
  • Shopify Plus
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • PIM / product data management
  • ERP / inventory and pricing
  • OMS / order and fulfilment
  • Data warehouse / BI platform
  • Commerce storefront or headless frontend
  • Analytics and event tracking
  • CDN and caching layer
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into KLEVU
↔OUT OF KLEVU & BOTH WAYS
Catalogue feed and attributes: Your commerce platform or PIM exports product names, descriptions, attributes, images and hierarchy to Klevu
Klevu indexes this data and makes it searchable within minutes to hours depending on feed size and refresh cadence.
Merchandising and ranking rule changes: Search governance owners configure synonyms, facet behaviour, redirect rules and product promotions in the Klevu console
Changes are applied to the index without waiting for storefront code deployment.
Search results and facets: Your storefront issues search queries to Klevu via API or integration module
Klevu returns ranked results, available facets, and spelling suggestions that your storefront renders into search result pages.
Query and click analytics: Klevu logs every search query, click, and result impression
These events flow back into your analytics platform or warehouse for trend analysis, gap detection, and relevance tuning.
Index rebuild and resync: When catalogue data changes significantly or index drift is detected, you trigger a full or incremental re-index from your feed
Klevu rebuilds the index and resumes serving results without downtime.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Feed design and transformation

    We map your product data (from PIM, ERP, or commerce) into Klevu's expected schema, handle attribute normalisation, hierarchy flattening, and image URL resolution. We validate the feed before submission and monitor parsing errors.

  2. 02
    Facet and attribute configuration

    We model facet trees, set cardinality limits, configure filtering behaviour and establish attribute-to-facet mappings. We document facet ownership so your team can adjust rules without re-indexing.

  3. 03
    Search API integration and fallback

    We integrate Klevu's search endpoint into your storefront or headless commerce layer. We implement fallback logic so that if Klevu is unreachable, your storefront falls back to database search or category browse.

  4. 04
    Merchandising rule governance

    We establish synonym dictionaries, redirect rules and merchandising campaigns. We create runbooks so your team can add synonyms, adjust promotions and manage zero-results routing without vendor support.

  5. 05
    Analytics and re-index automation

    We set up query and click event streaming into your BI platform or warehouse. We automate incremental and full re-index schedules, including pre-launch validation and rollback paths.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataCatalogue index source and attribute mapping
Source / ownerPIM or commerce platform
Maintained byProduct data team
NotesKlevu ingests this data; ownership of quality and timeliness stays with the source system.
DataIndexing pipeline and feed validation
Source / ownerKlevu
Maintained bySearch operations and iWeb
NotesKlevu owns the index structure and parsing; the feed publisher (PIM or commerce) owns feed quality and schedule.
DataFacet configuration and hierarchy
Source / ownerKlevu
Maintained byMerchandising and search teams
NotesFacets are configured in Klevu's console and applied at search time; no redeployment required.
DataSynonym dictionary and search-time rules
Source / ownerKlevu
Maintained bySearch merchandisers
NotesSynonyms and redirect rules are updated in the Klevu console and take effect within minutes.
DataMerchandising rules and product promotions
Source / ownerKlevu
Maintained byEcommerce and marketing teams
NotesPromotions, boosts and demotions are configured in Klevu without storefront code changes.
DataSearch query and click events
Source / ownerKlevu
Maintained byAnalytics and insights teams
NotesKlevu captures all search events; ownership of analysis and insight generation rests with downstream BI and merchandising.
DataZero-results fallback routing
Source / ownerKlevu
Maintained bySearch operations
NotesKlevu provides fallback rules; storefront may add custom logic for edge cases (e.g., inventory-aware substitutes).
10 · Experienced integrator

Built this before

iWeb has designed and deployed Klevu search estates for multi-brand retailers, fashion platforms and high-volume consumer sites. We understand how Klevu sits between PIM and storefront, and how to govern facets, synonyms and merchandising rules across teams without creating bottlenecks.

We design catalogue feeds from PIM, ERP or commerce platforms, including attribute mapping, hierarchy flattening and feed validation logic.
We configure facet trees, synonym dictionaries and zero-results routing in Klevu, then document ownership so merchandisers can maintain rules independently.
We integrate Klevu's search API into storefronts and implement fallback to database or cached search when Klevu is unavailable.
We set up query and click event streaming into data warehouses and BI platforms so teams can measure search performance and identify content gaps.
We establish re-index schedules, monitoring, alerting and rollback procedures so index corruption is caught and recovered within agreed SLAs.
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Validate that feed parsing succeeds and indexed product count matches source system count before go-live.
Confirm that facet hierarchy and cardinality match merchandising intent and do not degrade search page performance.
Test zero-results fallback routing for common typos and edge cases; verify fallback pages are current and inventory-aware.
Verify storefront fallback logic triggers gracefully if Klevu API is unavailable; confirm cached or database search results display without error.
Monitor re-index completion time and alert threshold; establish a runbook for handling failed re-indexes within one hour.
Perform a full re-index run and measure indexing time and result freshness to confirm feed schedule is realistic.
Capture query and click event payloads in staging and confirm all fields (query string, product ID, facet selections, timestamps) flow to your analytics platform.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Stale index after feed publishing delay

If your PIM or commerce platform publishes catalogue changes on an infrequent schedule (e.g., daily or weekly), Klevu will not see new products, attribute updates or delisted items until the next feed drop. Customers searching for newly added SKUs will not find them.

Index parsing errors blocking updates

If your feed contains malformed XML, invalid attribute values or encoding issues, Klevu may reject the entire batch or silently skip problematic records. The index remains unchanged and the failure may go unnoticed until customers report missing products.

Facet cardinality causing performance degradation

If a facet has thousands of distinct values (e.g., unconstrained colour or size variants), Klevu's facet aggregation and UI rendering can slow down. Search result page load times degrade, especially on mobile.

Merchandising rule drift and conflicts

If multiple teams adjust synonyms, redirects or product promotions without coordination, rules can conflict or create unexpected search behaviour. A promotion intended for one season persists after it ends.

Zero-results fallback mismatch with inventory

Klevu's zero-results handler might suggest a category or spelling correction, but if inventory or pricing has changed in your ERP since the last catalogue feed, the suggested products may be out of stock or mispriced.

Lost query and click events on integration failure

If the connection between Klevu and your analytics platform breaks, search queries and user clicks stop flowing into BI. You lose visibility into search trends, making relevance tuning decisions blind until monitoring surfaces the gap.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about Klevu integrations.

What data does Klevu index and how fresh does it need to be?

Klevu indexes product names, descriptions, attributes, categories, images and custom fields from your feed. Freshness depends on your feed schedule: you can re-index hourly, daily or on-demand. High-velocity businesses (fashion, perishables) often use daily re-index; stable catalogues may use weekly.

How do we maintain facet trees and prevent cardinality issues?

Facets are modelled in Klevu's console by mapping product attributes to facet names and setting value constraints. We recommend capping facets at 50-100 values per level and flattening deeply nested hierarchies. Quarterly reviews of facet performance and click distribution help identify bloated facets to split or archive.

Can Klevu integrate real-time pricing and stock data?

Klevu indexes base catalogue attributes but does not natively consume live pricing or stock feeds. Pricing and stock typically flow from your ERP or OMS. You can either include base pricing in the catalogue feed or call your pricing API at search-time via the storefront. Stock availability is best served by a separate OMS feed or lookup.

How do we handle zero-result searches without custom code?

Klevu provides built-in zero-results handling: spelling suggestions, phonetic matching, and category fallbacks. You configure these rules in the Klevu console. For complex logic (e.g., routing to a curated page or out-of-stock alternative), your storefront adds conditional rendering based on Klevu's zero-results flag.

Who owns synonym and redirect rules, and how do changes propagate?

Search merchandisers own synonyms and redirect rules in the Klevu console. Changes take effect within minutes at search-time without redeploying your storefront or waiting for a re-index. Document ownership per language and market so teams know who can adjust rules.

What happens to search results if Klevu becomes unavailable?

If Klevu is unreachable, your storefront search must fall back gracefully. Common strategies are database search, category navigation or cached results. We implement health checks and timeout logic so degradation is visible within seconds, and your team can switch fallback modes without customer-facing 500 errors.

How do we monitor search index health and catch stale data?

Monitor feed parsing errors, re-index completion times and result count changes. Klevu provides status dashboards; we also set alerts on missing products (comparing feed line count to indexed product count) and facet cardinality drift. Failed re-indexes should trigger escalation within the hour.

Can we A/B test ranking changes or merchandising rules?

Klevu supports rules with percentage-based audience splits. You can route a cohort of users to an alternate ranking or promotion set via Klevu's configuration. Tie test results to query and click event data to measure impact before full rollout.

How do we manage synonyms across multiple languages and locales?

Klevu allows synonym dictionaries per language. Build a centralised synonym register (e.g., in a spreadsheet or config file) and bulk-upload it to Klevu per language. Update schedules should align with content releases. Avoid manual per-language edits unless urgent.

What feed formats and attribute types does Klevu accept?

Klevu accepts XML and JSON feeds with attributes as strings, numbers, arrays and hierarchies. Ensure attribute names, types and cardinality match your Klevu schema. We validate feeds before submission and flag schema mismatches, missing required fields and encoding errors.

How do we ensure search results align with current inventory and pricing?

Include inventory status and base pricing in the catalogue feed to Klevu. Update the feed whenever inventory levels or pricing change significantly. For near-real-time accuracy, call your inventory or pricing API at search-time from the storefront to decorate Klevu results before display.

Who escalates and resolves search index corruption or rebuild failures?

Establish an on-call rotation for search operations. Failed re-indexes and parsing errors should be escalated within one hour. Have a rollback path (previous index backup) and manual re-trigger procedures. Document the decision tree: when to retry, when to roll back, when to request vendor support.

Next step

Have a Klevu integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →