Drupal
Drupal Search API on production catalogues in 2026
Drupal Search API is the search framework I put on Drupal catalogues when core Search cannot do facets, multilingual indexes, or a dedicated Solr backend. I am Alan Vo, a Gold Coast web developer with 18 years on Drupal, Magento, Shopify, and WooCommerce catalogues. In 2026 this is still the production path for museum, regulator, and property listings that have to filter like a store.
Core Search is fine for a brochure site with a keyword box. It is not fine when editors need type, topic, location, language, and status filters on thousands of nodes, or when merchandisers expect the same facet behaviour I ship on Magento faceted navigation. The Search API getting started guide is the platform spec. This note is how I run it on live catalogues, not a Database Search Defaults demo.
Why Drupal Search API matters on catalogues in 2026
Drupal Search API matters on catalogues in 2026 because it splits "what Drupal knows about an entity" from "which engine stores and queries it". You pick a server backend, you pick datasources and fields, you attach Views and Facets. Core Search does not give you that swap. Adobe Live Search and Shopify predictive search do a similar job on those platforms. On Drupal, Search API is the layer.
I still see teams enable core Search, then fight it when a client asks for a filter rail. You cannot bolt Facets onto core Search in a way I will sign off on a government or museum site. The server backends page, updated in July 2026, lists Database, Solr, Elasticsearch, OpenSearch, and which optional features each one implements.
The 2026 ticket-changer is Solr versioning. Search API Solr 4.4.0 shipped 28 July 2026 for Drupal 11.3 and later. The 4.3 line still covers Drupal 10.6 and earlier 11.x. If the lockfile is 11.2, do not require 4.4 and hope.
I treat Drupal Search API as catalogue infrastructure the same way I treat a Shopify collection index or a Magento search cluster. It is a server, a schema, an access model, and a cron budget, not a module you flick on in week two.
How Drupal Search API actually works
Drupal Search API actually works as a search server, one or more indexes, processors, and a Views display that queries the index instead of the node table. After you Composer-require drupal/search_api (and a backend module if you are not using the included Database search), you create those objects at /admin/config/search/search-api. The README also offers Database Search Defaults for a quick node search. I never leave that as the production catalogue. It is a starter view, not an IA.
A server is the connection. Database search ships in the Search API project and is the right first backend on a small or medium catalogue. The official FAQ still says start there, then move to Solr or Elasticsearch when search load becomes a database problem. I move to Solr when listings are large, when I need multilingual analysis Solr already does, or when I need features the database backend does not implement (grouping, more-like-this, spellcheck, location). I do not add a second cluster because it is fashionable.
An index is the catalogue contract. On the add index form you choose datasources, bundles, and languages, then attach a server. Fields are explicit: title, body, bundle, status, language, and every taxonomy or entity-reference that will become a facet, each with a type. Fulltext fields get a boost. If a facet is missing later, the field was never indexed.
Index options I actually set: Index items immediately on any catalogue that can unpublish or change access (the common pitfalls page is blunt about leaks until cron runs); cron batch size timed to the official 5 to 10 seconds of work; Read only only when the index points at an engine I do not write.
Processors run in three phases: change items as they index, change the query, then change the results. On a Database server I enable content access, entity status, HTML filter, and highlight, and keep the recommended order. On Solr I turn analysis processors off. The processors guide says Solr already tokenises and cases better than Search API. If you started on Database then moved the same index to Solr, those processors stay enabled. Turn them off after the move.
Views is the public search. Create the view on the index, not on Content. The keyword filter must be Search: Fulltext search. Mark it required, or set the exposed form to Input required, so an empty box does not dump the whole catalogue. Facets attach to that Search API display. AND narrows. OR (search_api_facets_operator_or) widens. Both Database and Solr support those two features.
Solr needs extra homework. Add the server, pick a connector, then deploy the module-generated config.zip from the server page or drush solr-gsc before you expect a green status. Language or field-type changes mean a new zip. The add a Solr server howto is the host checklist. Solr 10 support still reads as experimental. I stay on a supported 7.x to 9.x line unless the host has a written reason.
Drupal Search API production checklist
A Drupal Search API production checklist starts with the backend choice, then datasources, fields, access, and a cron batch you have timed on a copy of production content.
- Decide Database versus Solr (or the host's Elasticsearch/OpenSearch) in writing. Database first unless you already know you need Solr features or volume.
- Composer-require Search API and the backend. Lock versions. On Drupal 11.3+ I will take Search API Solr 4.4.x. On 11.2 I stay on 4.3.x.
- Create the server in config, not only in the UI. Export
search_api.server.*andsearch_api.index.*so git is the source of truth. - Limit datasources to the bundles that belong on the public catalogue. Do not index every content type "in case".
- Set languages on the index to match the site. A bilingual ROM-style build needs both languages in the datasource, then hreflang on the result pages.
- Add only the fields you will search, sort, or facet. Rendered HTML is a last resort, not the first fulltext field.
- Enable Content access and Entity status (or equivalent Views filters) and test as anonymous, as an editor, and as a role that should not see drafts.
- Turn on Index items immediately if unpublish or access can change between cron runs.
- Time the cron batch on a database copy. Aim for the official 5 to 10 second window. Watch memory, not only item count.
- Build the Views page on the index. Use Search: Fulltext search. Mark keywords required if an empty landing page must not list everything.
- Add Facets only for indexed fields. Check AND versus OR with a merchandiser, not only with a developer.
- If the backend is Solr, deploy
config.zip, confirm the server is reachable, then index. Enable Retrieve result data from Solr only after you understand the Views field rules that go with it. - Disable leftover Search API analysis processors after a Database-to-Solr move.
- Disable core Search (or at least its block and default search page) so you do not run two result pages.
- Write who may clear the index in production. Clearing and re-indexing a large catalogue is an incident, not a tidy-up.
I refuse Search API recipes that import a Solr server pointing at localhost and a view named solr_search_content on a site that already has listings. Drupal CMS recipes are useful for Metatag. They are a poor way to surprise a search cluster.
What breaks in Drupal Search API on a live catalogue
Drupal Search API breaks on a live catalogue when the index lags access changes, when referenced entities never re-index, and when Solr still runs Database-era processors.
The official pitfalls I hit on real sites:
- Unpublished or private nodes in results. Search API does not restrict access by default. Views can hide a row after the query and still leave facet counts lying. Fix the index with Content access and Entity status. Only enable Skip item access checks if the query cannot return a restricted item. The processors guide calls that a security risk.
- Index items immediately left off. A regulator unpublishes a page. Cron is twenty minutes away. The node is still in Solr.
- Related entities that do not re-index. Change a taxonomy label or a referenced venue and the listing keeps the old string until you mark parents dirty. Catalogues with entity references fail here first.
- The wrong Views filter, or an empty keyword box that lists every node. Use Search: Fulltext search, and make it required.
- Partial word search on the Database backend. The FAQ documents it on the server edit form. It is off by default because it is slow. Do not enable it to avoid Solr.
delete_on_failleft at TRUE on a flaky database. The README warns a failed entity load removes the item from the index. I set that option to FALSE on unreliable replicas.- Solr config never redeployed after a language or field-type change, or Retrieve result data from Solr combined with entity-rendered Views fields. Follow the Solr howto if you want a fields-only view: indexed fields, no entity rendering, and a written access story.
I also see two search UIs: core Search at /search and the Search API view at /catalogue. Pick one public URL. Redirect the other.
How I measure Drupal Search API
I measure Drupal Search API by index completeness, lag, query time, zero-result rate, and access failures, not by a vanity "search is on" checkbox.
On the index View tab the indexed count should match the published bundles I chose. A permanent gap is a tracker or cron problem. Lag is save-to-visible time: the request if you index immediately, otherwise cron interval plus batch. I time both on staging with production-sized content.
Query time belongs in the host APM, plus Solr's log if we have one. I care about p95 on the catalogue URL, not a Views preview. Database backend plus partial-word search plus five facets is how you flatten MySQL. That is the official signal to change backends.
Zero-result rate in logs tells me whether synonyms or stemming are wrong. I do not invent conversion lifts from turning search on. Access I test as anonymous, as an editor, and as a role that should see nothing. If facet counts differ from the list, fix the index. For Solr I also watch collection status after every config zip and every language add.
Related work on this site
Large Drupal catalogues are why I care about Search API more than a core Search block. The NDIS Commission site is Drupal for quality and safety information that participants and providers have to find by topic. The Royal Ontario Museum rebuild is bilingual Drupal for exhibitions, membership, and visits, so the index has to respect language the same way hreflang does. Immobel is a property catalogue: location, type, and status filters, which is the same problem as a store PLP even though the items are developments rather than SKUs. All three were contract work on an agency team. None of them can use Database Search Defaults and call it a catalogue.
FAQ
Is Drupal Search API a replacement for core Search?
Drupal Search API is a replacement for core Search on any site that needs a chosen backend, field-level indexes, or Facets. Core Search can stay disabled. You still need a backend (Database, Solr, or another listed engine) and a Views page. Search API is the framework, not the engine.
Can I run Drupal Search API on the database, or do I need Solr?
You can run Drupal Search API on the included Database backend, and the official FAQ still recommends starting there. Move to Solr (or Elasticsearch/OpenSearch) when search load, multilingual analysis, or missing features force it. Search API Solr 4.4.0 is the July 2026 line for Drupal 11.3 and later.
How do I keep Drupal Search API from showing unpublished catalogue items?
You keep Drupal Search API from showing unpublished items by indexing status and access (Entity status and Content access processors), turning on Index items immediately, and testing Views as anonymous. Do not rely on Views post-filters alone. Facet counts will still advertise the hidden node.
Does Drupal Search API work for a store-style facet rail?
Drupal Search API works for a store-style facet rail when you index the facet fields, attach the Facets module to the Search API Views display, and pick AND or OR the way a merchandiser thinks. That is the same job as Magento layered navigation or a Shopify collection filter, on a Drupal content model instead of SKUs.
Keep reading
Contact if you want this kind of work on a live store.