When Typo Tolerance Makes Search Worse

Typo tolerance is intended to rescue shoppers who search for “sneekers” instead of “sneakers” or “iphnoe” instead of “iPhone.” In a WooCommerce catalog, however, the same behavior can make search less useful when every character matters. Product codes, model numbers, sizes, measurements, and brand names often contain short tokens where a one-character edit changes the intended product completely.

Why more matches can mean worse search

Algolia can find records that differ from the query by one or more character edits. This is valuable for natural-language product searches, but it can reduce precision for structured catalog terms.

• SKU searches: A query such as ABC-123 may match ABC-128 after typo tolerance is applied.
• Model numbers: X100 and X110 may represent different generations or accessories.
• Sizes: A search for 32 should not casually expand to unrelated numeric tokens.
• Short brand names: A single edit in a short token can produce many plausible but incorrect alternatives.
• Technical attributes: Terms such as 802.11ac, H7, or 10mm are not ordinary misspelled words.

The problem is not that typo tolerance is inaccurate in general. The problem is applying the same tolerance policy to every attribute and every query type.

Separate discovery searches from exact-intent searches

WooCommerce stores usually have at least two search behaviors:

1. Discovery search: The shopper searches for descriptive terms such as “waterproof hiking jacket.” Typo tolerance can improve recall here.
2. Exact-intent search: The shopper enters a SKU, part number, model, barcode, or highly specific identifier. Precision is more important than recall.

Use different Algolia request settings or indices for these cases rather than weakening typo tolerance across the entire catalog. A practical implementation can classify the query before sending the request. Signals include a high proportion of digits, hyphens, slashes, long alphanumeric tokens, or an exact match in a dedicated identifier field.

const looksLikeIdentifier = query => /^(?=.*[A-Za-z0-9])[A-Za-z0-9./_-]{4,}$/.test(query) && (/[0-9]/.test(query) || /[-_/]/.test(query)); const searchParams = looksLikeIdentifier(query) ? { query, typoTolerance: false } : { query, typoTolerance: true, minWordSizefor1Typo: 5, minWordSizefor2Typos: 9 };

The classifier should be tuned against the store’s actual catalog. A fashion store with numeric sizes needs different rules from an electronics store whose catalog is dominated by model numbers.

Use attribute-level restrictions

When typo tolerance is useful in product titles but harmful in identifiers, keep those fields separate in the index. Typical fields include name, brand, sku, mpn, gtin, and normalized attribute values.

Configure identifier attributes so they are available for exact matching without making them broad typo-tolerant text fields. Algolia’s disableTypoToleranceOnAttributes setting can be used for attributes where edits should not be accepted. For example:

{ "typoTolerance": true, "disableTypoToleranceOnAttributes": ["sku", "mpn", "gtin"] }

Exact identifier matching should still be supported deliberately. Add those attributes to the searchable attributes configuration in an appropriate order, and consider a dedicated exact-match path that looks up the identifier directly before running a broader full-text search.

Raise the minimum word sizes carefully

Algolia exposes minWordSizefor1Typo and minWordSizefor2Typos to prevent typo expansion on very short words. Raising these values is often safer than disabling typo tolerance globally.

{ "typoTolerance": true, "minWordSizefor1Typo": 5, "minWordSizefor2Typos": 9 }

These settings affect the whole query, so validate them with real search logs. A higher threshold may protect short product codes while also failing to recover common misspellings in short brand names. Do not assume that the default values are appropriate for every WooCommerce catalog.

Protect domain-specific vocabulary

Some terms are valid catalog vocabulary even though they resemble misspellings. Product names, brands, chemical terms, compatibility codes, and regional spellings should be represented in the index as intentional values.

Use a controlled synonym strategy for genuine equivalents, such as “tv” and “television,” rather than relying on typo tolerance to connect them. Add known alternate spellings to a synonym set or a normalized field, and use typo-tolerance exceptions for terms that must not be altered. Keep the exception list managed as catalog data; it should be reviewed whenever brands, suppliers, or product lines change.

Index normalized identifiers

WooCommerce data often stores identifiers with inconsistent punctuation or casing. A shopper may enter AB-123, while the product feed contains AB123. Solve that mismatch during indexing instead of asking typo tolerance to bridge it.

function normalizeIdentifier(value) { return String(value || '').toUpperCase().replace(/[^A-Z0-9]/g, ''); } const record = { objectID: product.id, name: product.name, sku: product.sku, sku_normalized: normalizeIdentifier(product.sku), mpn: product.mpn, mpn_normalized: normalizeIdentifier(product.mpn) };

Use the normalized value for exact lookup and retain the original value for display. This approach treats punctuation differences as a known normalization rule rather than as spelling errors.

Measure precision, not only search volume

A typo-tolerant configuration can increase the number of searches that return results while reducing the number of useful results. Review search analytics and WooCommerce conversion data together.

• Track zero-result searches before and after changing typo settings.
• Compare click-through rate for exact identifier queries.
• Measure add-to-cart and purchase rates for searches containing digits or hyphens.
• Inspect searches where the first result was not clicked.
• Review false-positive matches such as one SKU being replaced by a nearby model.

Build a test set from production queries. Include correct spellings, common misspellings, SKU prefixes, complete SKUs, model numbers, short brand names, sizes, and queries with punctuation removed. For each query, define acceptable results before changing Algolia settings.

A practical WooCommerce rollout

1. Export several weeks of search queries and label them as descriptive, branded, or identifier-focused.
2. Normalize SKU, MPN, and GTIN values during the WooCommerce-to-Algolia indexing process.
3. Disable typo tolerance on identifier attributes or route identifier-looking queries to an exact-search path.
4. Raise the minimum typo word sizes only after testing the impact on ordinary product searches.
5. Add synonyms and controlled exceptions for known vocabulary instead of using broader typo tolerance.
6. Deploy the change behind an experiment and compare conversion, not just result counts.

For most agencies, the strongest design is hybrid: forgiving search for natural-language discovery, strict matching for identifiers, and explicit normalization for formatting differences. Typo tolerance should recover likely spelling mistakes, not reinterpret data that was designed to be exact.