The standard way to build search in Drupal. Search API is a framework that connects your content to a database or Solr backend. Free, well-maintained, and worth the setup time.
This trips up people expecting a plug-and-search module. Search API does not search anything on its own. It is the layer between your Drupal content and whatever actually does the searching, whether that is your database or a Solr server. You define an index, pick which fields go in it, choose a backend, and build the results with Views. That indirection is the point: you can start on the database and move to Solr later without rebuilding your search from scratch.
Most sites start on the database backend, and plenty never need more. If you have a few thousand nodes and you are searching titles and body text, the database backend indexes it fine and there is nothing extra to host. We reach for Solr when the content gets large, into the tens of thousands of items, when you need real relevance ranking, typo tolerance, or fast faceted filtering across many fields, or when search speed on the database has started to drag. Solr is a separate service to run, so we do not add it unless the site earns it. When search is what is slowing a page down, that is a job for our Drupal performance work.
Search API on its own gives you indexing and basic results. The pieces most projects add: Facets, for the checkbox filters on the side of a search or catalog page; Search API Autocomplete, for the type-ahead suggestions in the search box; and Search API Solr when you move off the database. All free, all maintained by the same community around the core module.
The indexing model has a learning curve. Fields have to be added to the index explicitly, processors for things like tokenizing, stemming, or stripping HTML run in an order that matters, and after config changes you often have to clear and reindex before results look right. It is powerful once it is set up, but the first build is not a five-minute job.
Start on the database backend, move to Solr or another engine later without rebuilding your search.
Search results are built as a View, so you shape them with the same tools you use everywhere else in Drupal.
Tokenizing, stemming, HTML filtering, and highlighting run as configurable processors on the index.
Companion modules add sidebar filters and type-ahead suggestions on top of any index.
We use this in real client projects — here's what we've learned.
Search API is the right way to do search in Drupal, but budget for setup time and start on the database backend. For a few thousand nodes the database is usually enough and needs nothing extra to host. Move to Solr when you actually need relevance ranking, typo tolerance, or fast facets at scale, not before. Add Facets and Autocomplete as the project needs them.
It is a framework for building search. Search API does not do the searching itself; it connects your Drupal content to a backend that does, either your database or a Solr server, and lets you build the results with Views. It is a free contributed module for Drupal 9, 10, and 11.
No. Search API works over your database out of the box, and for a few thousand nodes that is usually enough. You add Solr when you need relevance ranking, typo tolerance, or fast faceted search across a large catalog.
Core search is a fixed block that searches nodes. Search API lets you choose what gets indexed, how it is processed, which backend runs it, and how results look, plus facets and autocomplete. It is more work to set up and far more flexible.
With the Facets module, which is built to sit on top of a Search API index. Once your index and search View exist, Facets adds the sidebar checkbox filters for things like content type, tags, or date.
Yes. Search API and its main companions, Facets, Autocomplete, and Search API Solr, are free contributed modules. If you run Solr, the cost is hosting and maintaining that service, not the modules.
We can install, configure, or customize it for you.
Don't want to install yourself? Our developer connects via FTP, installs, configures, tests with a real transaction. Usually takes one business day.
