Building a custom Drupal search page with faceted navigation
When a Drupal site grows past a handful of content types and a few hundred nodes, the built-in search quickly stops being useful. Visitors looking for a specific product, a research paper, or a council submission want to narrow the results by category, location, date, or price without wading through a long, unfiltered list. Faceted navigation fills that gap, turning a flat search box into a guided drill-down experience that mirrors how people actually browse.
This guide walks through the practical steps for delivering a polished, custom search interface in Drupal, from picking a backend through to accessibility, performance, and Australian privacy obligations. The patterns described here apply to Drupal 10 and 11 sites, and most of them transfer cleanly to multilingual deployments run by teams in Sydney, Melbourne, or regional Queensland.
What faceted search actually changes for users
A faceted search interface exposes the indexed properties of content as clickable filters, usually arranged along the side of the results column. Clicking "Workshops" or "Brisbane" or "Under $50" trims the result set immediately, with the active facets shown as removable chips. The interaction is familiar to anyone who has shopped on a major Australian retailer, browsed a university research portal, or sorted through news articles on a publisher such as the ABC.
For content teams, the payoff is more than visual. Facets are generated automatically from the indexed fields, so a new content type or taxonomy term can appear as a filter without any new template work. Drupal's Search API module treats the index as the source of truth, and the Facets module reads that index to build the refinement widgets. The combination means editorial changes propagate to the search page on the next cron run, with no developer intervention.
Choosing a backend: database, Solr, or Elasticsearch
The first real decision is where the indexed data will live. Drupal ships with a database-backed search option, but the moment you want relevance scoring, typo tolerance, or fast partial matches, an external search server becomes attractive. The table below compares the three options most teams evaluate.
| Backend | Strengths | Weaknesses | Typical fit |
|---|---|---|---|
| Database (Search API DB) | No extra infrastructure, works on shared hosting, easy local setup | Slower on large corpora, limited full-text features, no faceting on text fields without special tricks | Small brochure sites, prototypes, internal knowledge bases |
| Apache Solr | Mature ecosystem, strong faceting, spellcheck, language analysers | Operational overhead, JVM tuning, version compatibility with Search API Solr | News archives, university repositories, large e-commerce catalogues |
| Elasticsearch | Fast aggregations, good for analytics-style facets | License changes affect some use cases, requires Kibana for serious ops | High-traffic platforms, log search, complex multi-field refinement |
For most Australian mid-size sites, Solr remains the comfortable default because the Search API Solr module is well-maintained and Australian hosts such as Pantheon, Acquia partners, and local providers in Brisbane and Perth offer managed Solr instances.
Setting up Search API and the index
Once a backend is chosen, the build is largely the same. Install Search API, the relevant backend sub-module (db, solr, or elasticsearch), and Facets. If multilingual support is required, add Search API Multilingual Facets as well, and enable the language-aware processors on the index.
A sensible index for a content-heavy site bundles the fields visitors will actually filter on:
- Title, body summary, and a concatenated text field for relevance
- Taxonomy reference fields, with a separate indexed term name for sorting
- Date fields, stored as ISO 8601 strings for range facets
- Integer and decimal fields for price, duration, or stock counts
After the field setup, attach the index to a server, run a few items through the queue, and confirm the indexed view in the dashboard. Pay attention to the "Processors" tab at this stage; the HTML filter, tokenisation, and stop-word processors have a large effect on result quality for English-language content written by an Australian editorial team.
Building the search view and exposing filters
The search results page is a Drupal View that displays indexed items, with the index itself acting as the data source. Most teams expose filters directly from the View UI by clicking "Expose this filter" on the relevant Fulltext or Term reference fields. For Solr backends, switching the filter type to "Search API Fulltext" unlocks relevance scoring, phrase matching, and the operator options that real visitors expect.
Small touches that make the search feel faster:
- Use AJAX on the View so facets update the result list without a full page reload
- Set the result count above the facets so users always know how many items match
- Make the active-facet chips removable with a single click
- Keep the URL query string canonical so filtered results can be shared and indexed by search engines
For visitors on flaky regional networks, a non-AJAX fallback that still preserves facet state in the URL is worth configuring as a progressive enhancement rather than a hidden feature.
Wiring up the facet blocks
Facets are configured separately from the View, through the Facets module. Each facet points at a field on the search index, picks a widget (links, dropdowns, checkboxes, ranges), and chooses a hard or soft limit for the number of values shown. Soft limits work well for taxonomy facets such as topic or location, where the first ten values usually cover the long tail, and visitors can click "Show more" for the remainder.
A practical layout for a retail-style search might place taxonomy and price facets in the left sidebar, date and location facets in a collapsible drawer on mobile, and the active-facet summary at the top of the results. Block visibility rules can hide facets that have only one value, which removes clutter on small result sets. For news and publication sites, hierarchical facets on a parent term such as "Sport" → "AFL" → "Adelaide Crows" help readers drill into specific coverage without ever leaving the page.
Performance, caching, and Australian hosting realities
Search pages are a notorious source of cache fragmentation because every combination of facets produces a unique URL. Drupal's render cache and the Search API cache plugin can absorb most of that load, but the configuration matters. Set a long max-age for the facet blocks themselves, because they usually only change when the index updates, and a shorter max-age for the results list so newly published content appears promptly.
Australian audiences have a few expectations worth planning around. Browsing spikes during AEST business hours, with secondary surges in the evening in Adelaide and around Friday arvo, so a CDN with points of presence in Sydney and Melbourne is more useful than a single overseas edge. Hosts that keep data onshore simplify compliance with the Privacy Act 1988, and they reduce the latency that visitors in Hobart or Darwin otherwise see. Caching the search index file itself on the application servers, rather than refetching it on every request, can shave several hundred milliseconds off each search.
Accessibility, localisation, and Australian privacy
A faceted search page is a complex widget, and accessibility needs deliberate work. The facet checkboxes and links should sit inside landmark regions with descriptive headings, the active chips need aria-labels that read "Remove filter: Workshops", and the live result region should announce its update count to screen readers. WCAG 2.2 conformance is the baseline expected by most Australian government and university clients, and the practical impact is that every facet widget must be operable by keyboard alone.
Localisation affects more than translation. Datetimes on the search page should display in the site's configured timezone, and any currency facets need to match the formatting Australian shoppers expect, including the dollar sign and the comma as a thousands separator. Multilingual sites should configure separate indexes per language so a French term does not pollute the English results.
Privacy compliance is the other half that often gets deferred. Search queries are personal data when they can be tied back to an individual, so logging them indefinitely can conflict with the Australian Privacy Principles under the Privacy Act 1988. The Office of the Australian Information Commissioner has been clear about the Notifiable Data Breaches scheme covering such logs, and many Drupal teams now anonymise query strings in their analytics after a short retention window. The same discipline applies to the cookies set by the search page for filter state; if they are strictly functional, the consent banner can be configured to treat them as essential, but the legal review should still happen.
For teams that want a more opinionated walkthrough of how these pieces fit together in a real Australian deployment, the about page on this site has a short note on consulting work and content archives. Putting faceted search in place is rarely a one-day task, but the combination of Search API, Facets, and a well-tuned View gives Drupal a foundation that scales comfortably from a small business catalogue to a national research portal.