Common problems and patterns iWeb sees.
How this system fits next to commerce, PIM and ERP.
Questions we get asked.
What does ecommerce search and filtering cover?
On-site search, autocomplete, faceted filtering, category listings and merchandising. For trade and technical catalogues this also includes part numbers, fitment, technical attributes and account-specific catalogues.
Why does on-site search drift in trade and technical catalogues?
Catalogues grow faster than the attribute model. New product lines are added with inconsistent attributes, synonyms and units, and search relevance quietly degrades. The fix is upstream in the product data, not only in the search engine.
Can search be tuned for trade SKUs and part numbers?
Yes. Exact and partial part-number matching, fitment lookups, supplier codes and account-specific SKUs are all in scope. Tuning is informed by query logs, not assumptions.
Does search work for B2B and account-specific catalogues?
Yes. Account customers can be shown a catalogue scoped to what they are entitled to buy, with their own pricing and SKUs, and search restricted accordingly.
How do you measure whether search is working?
Zero-results rate, click position on top queries, conversion on search-driven sessions and exit rate from search pages. These are tracked over time, not measured once at launch.
When is dedicated search worth the integration?
When the catalogue is large or technical, the query log shows real demand the native engine cannot serve, or B2B account-specific catalogues need their own relevance. Smaller estates often run well on the native platform search.
When is on-platform search enough?
Small SKU bases with simple browsing, where the catalogue model is consistent and the query log does not show real friction. iWeb will say so rather than add a search engine the team has to support.
Which search providers does iWeb work with?
The decision is client-led. iWeb works with Algolia, Constructor and native commerce search, among others. The pattern is the same: attributes from PIM, pricing and stock from ERP, relevance tuned from query logs.
How does search connect to PIM and ERP?
PIM provides the attributes, media and channel rules that drive relevance. ERP provides pricing and stock for filtering and ranking signals. The search index reads from both rather than holding its own copies.
Can iWeb take over an existing search implementation?
Yes. The first step is reading the index, the relevance configuration and the query logs, then writing down what to tune, stabilise or replace. The first month is deliberately conservative on change.
How is search relevance kept honest after launch?
As a continuous activity, not a launch milestone. Zero-result and low-CTR queries are reviewed regularly and rules updated under change control with merchandising in the loop.
Where does the search index read from?
From PIM where one exists, not from the storefront. Catalogue truth stays in PIM; search reads it, with re-indexing tied to PIM publish events and stock changes.