Make Price low to high mean what the shopper thinks it means

Write the sorting promise in customer terms

Algolia’s sorting support article, checked 7 November 2026, describes exhaustive sorting in a standard replica as primarily ordered by the selected attribute, with relevance breaking equal-value ties. It distinguishes that approach from relevance-preserving sorting. Confirm the actual implementation rather than inferring the mode from a dropdown label.

Choose one control and write what a reasonable shopper would expect it to do. Does Price low to high mean all eligible matches arranged by price, or the most relevant subset with price influencing order? Those are different contracts. Keep result eligibility, the sorting attribute and the displayed price basis explicit so a disagreement can be diagnosed rather than dismissed as subjective relevance.

Build a result set that exposes the tradeoff

Create a synthetic query with several plausible matches: a strong textual match at a higher price, a weaker match at a lower price and two matches with the same price. Keep the products genuinely within the declared query scope; unrelated bargain items do not help test a useful sorting promise. Record the expected order under each candidate contract before examining the actual result.

Check which numeric value is being compared. A family’s minimum price, the selected variant’s price and a unit price answer different questions. Use the same declared basis in the fixture and the result card. If the business cannot identify the intended comparison value, stop before changing the search mode. An ascending sort can be technically correct while comparing a value the shopper never sees.

Trace mode, membership and order separately

Record the actual index or replica route selected by the control, the query and filters, the returned membership and the final display order. Distinguish a missing item from an item placed later. A relevance-constrained mode may choose a different set, whereas another mode may order the same set differently; the acceptance record must show which occurred.

Include switching back to the default mode and retaining an existing filter. The control should not quietly change eligibility or discard the shopper’s constraint while announcing only a sort change. Use observed behavior from the supported implementation rather than assuming every search engine or replica uses the same mechanism. Do not change production ranking settings during the diagnostic exercise.

Approve the label and implementation together

Choose the contract the business can support and make the interface describe it honestly. If relevance remains part of selection, avoid an unqualified claim that the first result is the lowest-priced qualifying item in the entire catalog. If exhaustive price order is intended, test the counterexample set and equal-value cases against that requirement.

Save the fixture with its declared price basis, query scope and mode. Rerun it when record granularity, price fields or search routing changes. Keep business judgments about preferred products separate from the numeric ordering promise. The deliverable is an explainable sort contract and observed result sequence, not a claim that one mode universally improves conversion or customer satisfaction.

Make the reasoning concrete.

A fictional equipment store labels a relevance-preserving result mode Cheapest first. Its test query returns a more relevant but higher-priced item before a cheaper eligible alternative, and staff initially treat the mismatch as a pricing error.

The store resolves the label-versus-mode disagreement using the synthetic counterexamples. It does not alter product prices to make the list resemble the promised order.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Promise

   What ordering would the shopper reasonably expect?

2. Basis

   Which exact price or numeric attribute is compared?

3. Fixture

   Which relevant low-price and equal-price cases expose the rule?

4. Mode

   What route, membership and order does the control actually produce?

5. Acceptance

   Does the label honestly describe the supported result contract?

Watch for the wrong conclusion.

• Calling a relevance-constrained subset the cheapest complete assortment.
• Comparing a hidden minimum price while displaying another price.
• Treating missing membership and wrong order as the same defect.

Sources & scope

Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked. Synthetic acceptance only; no external changes, messages, index operations or permissions are performed.

• Why do my search results look less relevant after adding sorting? →Primary platform documentation · Supports: Supports the documented distinction between exhaustive sorting and relevance-preserving behavior. The sort-contract matrix and price-basis review are original.