Customers Cannot Find an Old Model: How Catalog Search Should Handle Aliases and Separators

If a website has internal search but a customer’s old model number returns no results, first check whether the product is still publicly sold and whether the old name genuinely corresponds to a current model. Then define search rules. Case, spaces, and hyphens can be handled under confirmed model-number rules; model aliases need business documentation; fuzzy search must avoid presenting technically different products as directly interchangeable.

Resolve this with real input samples. Collect spellings from sales emails, old catalogs, or confirmed product records and specify what each should find. A casual “try searching” without expected answers makes correctness difficult to assess.

1. Define Which Products and Fields Can Be Searched

List search coverage: product titles, official models, confirmed aliases, categories, summaries, and whether it includes text in published attachments. A downloadable specification sheet does not automatically mean its body text is searchable. The developer or system owner must confirm the actual indexing method.

Define handling rules for drafts, withdrawn products, and restricted resources. An old model no longer sold but retaining maintenance resources differs from one no longer public at all. The former may provide historical product information or confirmed clues to a later model. The latter must not continue showing invalid entry points because its search index is outdated.

Also identify what a model number belongs to. The same letters may represent a series abbreviation, complete-machine model, or accessory number. If an old number should find a particular product, the material owner must confirm the relationship and its applicable period. The website team must not create mappings simply because names look similar.

The completion criterion is that each test input identifies the public object it should match and objects it must not show. To determine whether search is needed and its main purpose, start with assessing when corporate website search is appropriate.

2. Separate Four Rules to Avoid Incorrect Matches

The first rule is exact matching of a complete model number. Entering the official model should make the corresponding product easy to find, without first paging through articles whose titles happen to contain the same letters. Result titles should show the model and product identity so customers can verify their selection.

The second rule is confirmed alias mapping. Historical product names, common sales abbreviations, and official names can be linked using documentation. If an old model points to a new one, explain whether this is a rename, a version upgrade, or a case requiring new selection. Search results alone must not imply complete interchangeability.

The third rule normalizes writing forms, such as ignoring case or treating particular spaces or hyphens as equivalent. Base rules on actual product naming. Suffixes, hyphen positions, or number differences may distinguish configurations; removing them all could merge different products. Search systems also handle separators differently. Check the selected system’s configuration instead of merely changing text in the front-end input.

The fourth rule is typo tolerance or fuzzy matching. It can help customers discover possible candidates, but a candidate is not necessarily the same product. If model numbers differ by one character, prompt users to check specifications instead of directly redirecting and hiding the original input. Be especially careful when suffixes distinguish voltage, interfaces, or materials.

Record the rules separately so a later search can be explained as an official-model, alias, or typo-tolerant match. Incorrect matches can then be addressed by adjusting the relevant rule without disabling every convenience.

3. Keep the Original Question on No-Results Pages and Offer a Usable Next Step

When nothing is found, retain the customer’s input and state clearly that no corresponding public product was found. Suggest checking the model, removing unnecessary spaces, or returning to a relevant category. Do not label something “possibly related” as “the product you need.”

If users can contact sales, explain that they may submit the original model number, usage context, or materials they have. If the original search is automatically carried into the inquiry, verify that it is actually saved and delivered. Without that feature, explicitly ask customers to enter it in the requirements description. Do not promise automatic transfer.

For many results, show model numbers, key distinguishing information, and conditions for further filtering. Whether filters are needed depends on actual product quantity and procurement tasks; not every specification needs to become a filter. Verify summary sources too, so an accurate model number is not paired with another configuration’s introduction.

For no-results guidance and recovery entry points, see designing website search no-results pages. Completion means customers can understand the result, retain their input, and continue verification even without finding the model, rather than only guessing a new search term.

4. Build Passing and Failing Cases From Actual Products

Select products that remain public and spellings from real historical materials, and prepare the following tests:

• Official model number: find the correct product and check ranking and the destination link.
• Confirmed old name: show the confirmed object, with explanations of upgrade or replacement limits where applicable.
• Case, space, and hyphen variations: match according to prior agreement while retaining differences that change configuration meaning.
• Similar but different models: do not force them into the same product.
• Nonexistent model: show a clear no-results state with usable inquiry and category entry points.
• Draft or withdrawn model: follow publication rules without crossing permission boundaries.

Enter the inputs on computers and actual phones, checking keyboard entry, copying and pasting, and the search button. Records should retain original input, expected objects, actual results, and page version. A screenshot showing the search box alone does not establish that rules work.

If search covers English and Chinese, also confirm whether aliases are set separately by language and whether language switching keeps the correct object. State whether searching across languages for another language’s model is included. One accidental match does not establish sitewide support.

5. Check Index Synchronization After Product Updates

Identify who maintains models and aliases and who sends public content into the index. For publication, renaming, withdrawal, or attachment replacement, record update triggers and acceptable waiting times. These times depend on the current system’s actual mechanism; do not casually write a guarantee into requirements.

After content owners update pages, retest with the same samples. In particular, check whether old results still lead to invalid pages and whether new models are findable. Successful saving in the CMS and an updated search index are two separate checkpoints.

A maintainable delivery includes search scope, alias evidence, normalization rules, expected results, and owners. Later “customers cannot find it” reports can then be investigated from actual input instead of repeatedly asking customers to change keywords.

Frequently Asked Questions

Would removing hyphens from every model make searching easier?Equivalence rules are appropriate only when hyphens are confirmed not to distinguish model meanings. Test incorrect-match risks using actual products first.

Can an old model automatically redirect to a new one?The business must confirm their relationship. If configurations or applicability differ, show explanations and a verification entry point so search rules do not make the selection decision for customers.