Building Fast, Filterable Search with Algolia: Lessons from a Directory Product

At Loot Discount I designed and integrated a directory and search page using Algolia, with custom indexes built for tailored list displays — one piece of a frontend that also leaned on FaunaDB APIs tuned to keep queries under 200ms. Algolia’s pitch is “fast search, easy to integrate,” and the integration part genuinely is easy — an SDK call and you have search. The part that took real design work was making the results actually relevant and the filtering actually fast for the specific ways people used the directory.

One index rarely fits every view

The first-pass mistake is building a single Algolia index and querying it differently for every view (search page, category browse, featured listings). This works until the different views need meaningfully different ranking — a text search should rank by relevance to the query, while a category browse page should rank by something like recency or popularity, with no text-relevance signal to rank by at all. Rather than fighting one index’s ranking configuration to serve every use case, I built separate indexes (or index replicas, Algolia’s mechanism for the same data with different ranking rules) per view, each tuned for what that specific view actually needed to optimize for. This cost more setup complexity upfront and paid for itself immediately in result quality — a listing page that “sort of” ranks correctly for every use case ranks correctly for none of them.

Faceted filtering needs to be designed around real usage, not every possible field

Algolia makes it easy to mark any field as a facet and let users filter on it — which makes it tempting to expose every filterable attribute as a facet “just in case.” In practice, a directory with fifteen available filters, most rarely used, is worse UX than one with the four or five filters people actually reach for, surfaced prominently, with the long tail available but not competing for attention. I looked at actual filter usage after launch and cut facets that weren’t earning their place in the UI — Algolia’s analytics made this straightforward to check, and the resulting simpler filter UI measurably improved how quickly people found what they were looking for.

Typo tolerance and relevance tuning are not “set and forget”

Algolia’s default typo tolerance and ranking are genuinely good starting points, but a directory with domain-specific terminology (business categories, location names, product-specific vocabulary) benefits from tuning searchable-attribute weighting so that, say, a match in the business name ranks above an incidental match somewhere in a long description field. The default “search across everything roughly equally” ranking is rarely what a specific product actually wants once you look closely at real query logs and see which results people actually clicked versus scrolled past.

index.setSettings({
  searchableAttributes: ["unordered(name)", "unordered(category)", "description"],
  customRanking: ["desc(popularity)", "desc(recency)"],
});

Index freshness matters more than search speed for a directory

Algolia’s raw query latency is fast enough that it’s rarely the bottleneck users notice. What they do notice is a listing that was just updated (or a new listing that was just created) not showing up in search yet, because the index update hadn’t propagated. For a directory where listings change moderately often, I set up indexing to happen synchronously as part of the write path for anything user-facing-critical (a new listing appearing), rather than relying purely on a batch reindex job — batch reindexing was fine for less time-sensitive attribute updates, but “I just created this and can’t find it” is a bad first impression worth engineering around specifically.

Custom indexes for tailored displays: the actual payoff

The “custom indexes for tailored list displays” part of this work meant building indexes whose shape — which fields were included, how they were structured — matched what a specific UI needed to render directly from the search response, rather than the UI doing a second round-trip to fetch full record details after getting search results back. For a fast-scrolling directory list, avoiding that second round-trip per result was a meaningful perceived-performance improvement, at the cost of some data duplication between indexes. That tradeoff — slightly more indexing complexity and storage, in exchange for the UI never waiting on a second fetch — was worth it for a product where scroll-and-browse was the primary interaction pattern.

What I’d tell someone starting an Algolia integration today

Don’t reach for one index serving every view — design indexes (or replicas) around what each view is actually optimizing for. Look at real facet usage before finalizing your filter UI, not just what’s technically filterable. And treat searchable-attribute weighting and custom ranking as an ongoing tuning exercise informed by real query and click data, not a one-time setup step you configure once and forget.