When Drupal search with Search API and Solr is worth building
Build Search API with Solr when your site's search needs have outgrown what the database or core search can do well. Typical signals are large content volumes, faceted browsing across many fields, relevance tuning that editors and users both notice, and search results that must include content from several sites or sources. Search API is the indexing layer inside Drupal. It decides which entities and fields are indexed, how they are processed (tokenizing, stemming, rendering), and how queries are passed to a backend. Apache Solr is the external search engine that stores those indexes and answers queries. Search API can use the database backend for small sites, but a Solr backend moves the index, query load and relevance scoring out of the Drupal database and into a service you run separately.
The decision is less about Drupal's version and more about operations. Drupal 11 is the current major version and requires PHP 8.3 or later, so confirm that the Search API and Solr Search modules you plan to use support your target Drupal and PHP versions before you commit. Then compare your options honestly: the Facets module can work on either backend, but facet performance, autocomplete and the number of indexed fields behave differently at scale. Ask your team three questions: who will own a Solr server after launch, how quickly must new content appear in search, and what happens to search when the index is rebuilt. If the answers involve a team with no one to patch or monitor Solr, the database backend with tighter scope may be the lower-risk choice for now.
Before you scope a build, confirm the supported Solr release line with the module maintainers and your hosting team, since Solr upgrades are a recurring cost that does not go away after launch. Also confirm where Solr will run, which network path Drupal will use to reach it, and how index content is protected, because a search index can expose field data that the page itself hides from anonymous users. (Illustrative: a catalog with 40 facets and content from three regional sites usually needs a plan for index rebuilds and access control before it needs more hardware.)
What Search API and the Solr backend do in Drupal
Search API connects Drupal content to an external search engine through indexes, servers and processors. The cards below cover what gets indexed, how fields map to Solr, how text is prepared, how queries filter and facet, and how content changes reach the index. Each one needs a decision during planning.
Indexes over content entities
A Search API index is defined over one or more entity types, such as content nodes, taxonomy terms, users or media, and it decides which bundles are included. Each index holds the fields you choose to make searchable, filterable or sortable. Settle the index boundary before building search pages: one index per content type is simpler to reason about, while a combined index needs careful field naming so that a title on one bundle does not collide with a title on another. Confirm with editors which content must appear in results.
Fields sent to a Solr server
A Search API server connection points the index at a Solr core or collection. Field mapping then decides how each Drupal field is stored in Solr, including its type, whether it is full-text searched and whether it is stored for display. A field indexed as text supports relevance ranking and phrase matching, while a string field supports exact facet values. Ask your team to confirm the Solr schema for each index before go-live, because changing a field type later usually requires a full reindex.
Processing content before indexing
Processors transform field values before they reach Solr. Examples include stripping HTML, tokenizing text, ignoring case and removing stopwords, and their order can be set per index. Processor choices change what users can find. Stripping markup from body fields keeps HTML out of results, and ignoring case keeps facet values consistent. Test representative queries after every processor change, because a stopword list that suits one language may hide meaningful terms in another.
Filtered queries and facets
Search API queries accept keywords, filters and sorts. The contributed Facets module builds filter links from indexed fields such as taxonomy terms or numeric ranges. Each facet depends on an indexed field of the right type, so a facet on a full-text field returns tokens rather than whole values. Decide which facets show by default, how many values appear and how empty facets behave. Check that facet widgets are fully keyboard operable before sign-off.
Tracking changes and reindexing
Search API tracks entity changes and queues them for indexing, so content saved in Drupal reaches Solr on a later indexing run. Index batches are triggered through cron or Drush commands, and a full reindex rebuilds the index from the database. A change to field mapping or processors can mark content for reindexing, so plan the duration of a full reindex during deployment. Ask your team to time a full reindex on a copy of production before choosing a release window.
Multi-index search
Search API lets one site hold several indexes, for example one for articles and one for products, each with its own fields, processors and server. A search page can query one index or a defined set, but results from different indexes carry different fields, so the page needs a common display field set. Decide early whether users need one combined results list or separate tabs, because that choice drives field naming and how relevance is compared across indexes.
Which index, Solr and hosting choices to make before the build
This table compares the main configuration decisions for Search API with Solr: index structure, field processing, facet sources, Solr layout and hosting. Read each row as a decision point, and confirm supported Solr versions on the Search API Solr project page before you commit.
| Decision | Options | When it fits |
|---|---|---|
| Index structure | One index for all content types, or one index per content type or audience | One index suits a single site search across mixed content. Separate indexes fit catalogs, staff directories or content with different filters and access rules. |
| Multi-index search | Search API multi-index queries across several indexes, or a single combined index | Multi-index search fits a site-wide search page over distinct content types. A combined index is simpler to tune but needs shared field names. |
| Field types and processors | Text fields with tokenizers, stemming and stopwords, or string and numeric fields for exact filtering | Use text fields for free-text relevance and string or numeric fields for facets and sorting. Mixing them up is a common cause of poor results. |
| Facet data sources | Indexed fields, entity reference labels, or computed fields | Index the label and the ID separately when editors rename terms. Computed fields add indexing cost, so keep them to the values users actually filter by. |
| Solr core or collection layout | One core per index, or a shared core with filters on an index identifier | One core per index is easier to reason about and reindex. A shared core reduces the number of cores to administer but makes schema changes affect every index. |
| Hosted or self-managed Solr | Managed Solr service from a provider, or Solr you run on servers or Kubernetes in your infrastructure | Managed hosting fits teams without search operations skills. Self-managed Solr fits data residency needs or existing clusters, and requires planned backups, upgrades and monitoring. |
| Solr version | The Solr release your hosting uses, checked against the Search API Solr project page | Confirm the supported Solr versions for the module release you plan to install. Upgrading Solr and the module together should be tested in a staging environment. |
| Database backend | Search API database backend with the core or contributed search database support | The database backend can be enough for small catalogs with few facets and light traffic. Expect slower facet counts and weaker relevance as content and filters grow. |
How a Solr-backed search build runs, step by step
The sequence below moves a Drupal search project from a written inventory of what people need to find, through a provisioned Solr core and a tested index, to a relevance-tuned search page that replaces the old one without losing results.
Inventory search requirements and content sources
List every content type, taxonomy, media field and external source that search must cover, along with the queries users actually run today and the results they expect. Record which pages need facets, autocomplete, multilingual results or access-controlled content. DeployOpen and your editorial and product owners do this together, usually from current site analytics and the existing search logs. The step is done when you have a signed-off inventory that maps each source to an index and each user need to a feature, so later steps have a fixed target.
Provision the Solr server and Drupal connector
Choose the Solr version and topology in your infrastructure, install Solr, and configure a core or collection for the site. Confirm the Solr release is supported by the Search API Solr module version you plan to use, because support matrices change, and check the Drupal version against the module's compatibility notes before installation. Set up network access from the Drupal web tier, TLS, authentication and backups for the Solr data directory. The handover is a reachable Solr endpoint with a documented configset, credentials stored in your secrets tooling, and a successful test ping from a Drupal environment.
Design indexes, fields and field types
Define one or more Search API indexes, decide which entities and bundles each index holds, and map every field to a Solr field type with its tokenization, stemming, language and whether it is stored, indexed, faceted or sortable. Separate fields for display, filtering and relevance boosting rather than reusing one field for all three. Review the design with the editorial team using the query inventory from the first step. The output is an index specification document listing each index, field, Solr type and purpose, approved before any content is indexed.
Configure processors and data preparation
Set the Search API processors that shape indexed data: content access checks, HTML stripping, ignore-case and tokenization settings, entity rendering for the body and language handling. Add custom processors only where the built-in ones cannot express a rule, and write them as tested code. Decide what gets excluded, such as unpublished revisions or internal taxonomy terms. The handover is a configured processor chain with a sample indexed document per content type, which the team inspects to confirm that titles, summaries and access data look correct before a full run.
Build facets, query views and the results page
Add the facet sources, widget types, sort options and autocomplete configuration on top of the indexes, then wire them into a search view or custom route. Confirm facet counts match the filtered result set, and check that facet widgets meet your accessibility requirements, including keyboard operation and labeled controls. For multi-index search, define which indexes a query searches and how results from different content types are merged and labeled. The output is a working search page on a staging environment with the facet and query behavior documented against the inventory.
Tune relevance with a fixed test query set
Build a set of representative queries from the inventory, including misspellings, synonyms, product codes and long-tail phrases, and record the results each should return. Adjust field boosts, stemming, synonyms, stopwords and minimum-match behavior, then rerun the set after each change. Keep changes in configuration under version control so each tuning round is traceable. The handover is the approved query set with expected top results and a change log, which becomes the regression baseline for future Solr or module upgrades.
Reindex, verify and cut over
Run a full index build on staging with production-like content volume, check index counts against the source database, and time the run so you can plan the production window. Verify that access rules hide restricted content from anonymous and role-specific users. Then schedule the production build, switch the search page over, and keep the previous search route or index available until the first post-launch review. The step closes when reconciled counts match, the regression query set passes and the cutover is documented with a rollback path.
Hand over operations and monitoring
Transfer runbooks for cron-driven indexing, index rebuilds, Solr backups, restores and version upgrades, and set alerts for failed index runs, Solr node health and query latency. Agree who watches the Solr hosting, who approves Search API Solr module updates after Drupal security releases, and how tuning requests are handled. The output is a signed runbook, a monitoring dashboard or alert list, and a named owner for each recurring task, so search keeps working after the project team leaves.
How content reaches Solr and stays current
Search API tracks every entity it is configured to index. When a node, term, or user is saved, deleted, or changed through a referenced entity, the index is told that the item needs attention, and that item is placed on a queue rather than sent to Solr immediately. A separate step then takes items off the queue and sends them to the Solr server in batches. The indexing queue is the part to design first, because it decides how fresh search results are. Items wait in the queue until something processes them, and in most sites that something is cron, or a Drush command run on a schedule. Confirm with your team how the site runs cron today (web-triggered, system cron, or a dedicated worker), how often it runs, and whether a long-running cron job can block the next run. Those answers set the real delay between an editor pressing Save and a result appearing in search, so ask the implementation partner to document them as a measured expectation for your environment rather than a promise.
Updates and deletions follow the same path. A changed entity is re-sent to Solr using its document ID, and an unpublished or deleted entity is removed from the index when its queued item is processed. Relationships need attention here: if a product references a taxonomy term that is renamed, indexed fields that pull in that label only refresh when the referencing items are reprocessed, so the team should decide which related content triggers re-indexing. Keep queue workers and cron on the same reliable infrastructure as Drupal, and monitor the queue depth so a stalled worker is noticed before editors report stale results.
Schema changes require a reindex plan. Adding a field to the index or changing how a field is processed usually means existing items must be re-sent with the new data, and Search API marks the index as needing this work. Plan the reindex as a scheduled operation: decide whether search serves the old index during the rebuild, how long the rebuild takes at your content volume (measure this in a staging copy first), and who approves the switch. Test the reindex on a production-sized database copy and record the timing, because the first full run is the one most likely to surprise the team.
Hosting Solr alongside Drupal in each environment
On a single server, Drupal and Solr usually share one host or sit on two small virtual machines in the same network segment. This is the simplest model to build and the easiest to under-protect, because Solr's administrative interfaces are often left reachable on the same network as the web server. The Solr port should listen only on the loopback interface or a private address that Drupal can reach, never on a public interface. Index configuration (the Solr configset that Drupal's Search API Solr module pushes or expects) belongs in version control, so the server can be rebuilt without rediscovering field definitions.
- Network placement: bind Solr to localhost or a private interface and block its port at the host firewall.
- TLS: if Drupal and Solr talk across a host boundary, terminate TLS at Solr or a local proxy; on one host, document why plain HTTP is acceptable.
- Authentication: enable Solr's basic authentication and authorization for the Drupal connection user, with credentials stored outside the site configuration.
- Backups: back up the index directory and the configset from version control; a full reindex from Drupal is the recovery path for the index itself.
- Operations: on small estates the Drupal operations team usually runs Solr, so patching and restarts need a named owner.
Confirm with your Solr distribution's documentation which authentication plugins it supports and which Solr versions the Search API Solr module currently supports before choosing the version to install.
In containers or Kubernetes, Solr runs as its own workload, usually with persistent volumes for the index and a Service that Drupal pods reach by cluster DNS. The main decisions are whether Solr is exposed only inside the cluster, how the index volume survives rescheduling, and whether the Solr deployment is managed by an operator or by hand-written manifests. Network policies should allow traffic only from the Drupal namespace or pods, and the Solr admin interface should not be routed through the public ingress.
- Network placement: use a ClusterIP Service and a NetworkPolicy that admits only Drupal workloads.
- TLS: use cluster-internal TLS through a service mesh or certificates issued by your internal certificate authority, and rotate them through the normal process.
- Authentication: store the Solr credentials in a Kubernetes Secret or an external secrets manager, and mount them into Drupal and Solr pods rather than baking them into images.
- Backups: snapshot persistent volumes according to your storage class, and keep the configset in the Git repository that deploys Drupal.
- Operations: the platform team usually owns the cluster and the Solr workload, while the Drupal team owns the schema and index configuration, so write that split down.
Confirm with your platform team and the Solr image you choose whether the chosen operator and storage class meet your recovery targets, and check the Solr version against the module documentation before you build the image.
Some teams run Solr through a cloud provider's managed search offering or a hosted Solr service. The provider takes on much of the host patching and some availability work, but the Drupal team still decides the network path, the credentials and the index configuration. Confirm early whether the managed service exposes a standard Solr API that the Search API Solr module can use, because some managed products expose only their own search API or restrict the configset upload and schema operations that Drupal depends on.
- Network placement: prefer private endpoints or VPC peering so Solr is not reachable from the internet, and confirm the provider's network model for the Drupal hosting region.
- TLS: require encrypted connections to the endpoint and confirm which certificate authority the provider uses, so Drupal can verify it.
- Authentication: use the provider's identity controls where offered, or Solr credentials scoped to the Drupal connection, and rotate them through a secrets manager.
- Backups: read the provider's snapshot and restore documentation, note the retention period, and test a restore into a non-production index.
- Operations: the provider handles some infrastructure tasks, but Drupal index changes, reindexing and version upgrades still need a named owner on your side.
Ask the provider which Solr versions it runs, how it applies upgrades, and whether its configuration options cover the Solr features your Search API index design requires.
On-premises and air-gapped networks remove public package sources and external services, so every Solr package, container image, dependency and Drupal module update must come through an approved internal path. Network placement is usually governed by segmentation rules between the web tier, the data tier and any analytics networks. Solr often sits in the data tier, reachable only from Drupal application servers, and its administrative endpoints should be restricted to a named management network. Plan the offline update process at the start, because a security patch that cannot reach the Solr host quickly becomes a standing exception.
- Network placement: place Solr in the data zone, allow Drupal application servers on the Solr port only, and restrict the admin interface to management hosts.
- TLS: use certificates from your internal certificate authority and distribute the trust chain to both Drupal and Solr.
- Authentication: enforce Solr authentication and keep credentials in your approved vault, with separate accounts for indexing and administration.
- Backups: keep index snapshots and the configset in your internal backup system, with an offline copy of the configset that can rebuild the index without internet access.
- Operations: name the team that patches Solr and Java, and build an internal mirror of the packages you need so that updates do not depend on outside downloads.
Confirm with your security team which Solr and Java releases your accreditation process allows, and check the module's supported Solr versions before you mirror any packages.
What drives the cost and duration of a Solr search project
This table lists the main effort drivers in a Search API and Solr project and how each one changes the work. Read it before scoping, because the first release is easier to price and finish when you limit these drivers early. The main takeaway is that index count, access control and multilingual fields usually decide the size of the project more than the number of pages on the site.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of indexes and content types | Each index needs its own field mapping, datasource selection, processors and rebuild plan, and each content type adds fields to map. | Start with one index for core content. Add content types in later releases once the first index is stable. |
| Facet complexity | Each facet needs a Search API field, a widget, query type handling and tested behavior for multi-value and empty results. | Limit the first release to a few facets that users need most. Reuse one field definition across several facets where the data allows. |
| Multilingual fields | Translated entities, language-specific analyzers and per-language field copies multiply mapping and relevance tuning. | Confirm which languages must be searchable at launch. Index one language first if the others can follow. |
| Access control and entity permissions in results | Results must respect node access, so the Search API access check and Solr filter queries must agree with Drupal permissions, and this needs tests per role. | Define the roles that must see restricted content early. Keep access rules in one place and test them with a fixed set of accounts. |
| Relevance requirements | Boosting, synonyms, stemming and autocomplete need repeated tuning against real queries and a review loop with content owners. | Agree on a short list of test queries and expected top results before the build. Treat further tuning as a separate phase. |
| Data volume and rebuild time | Large content sets lengthen initial indexing and reindexing after mapping changes, and they affect Solr sizing and hosting. | Ask for the expected item count and update rate. Plan a staging index rebuild rather than reindexing production during working hours. |
| Integration with other systems | Pulling data from a CRM, product feed or external API into the index adds sources, sync rules and failure handling. | Index only Drupal content first. Add external sources as a separate work item with its own acceptance tests. |
| Solr version and hosting | The Solr version must be supported by the chosen Search API Solr connector, and self-hosted Solr adds provisioning, backups and monitoring work. | Confirm the Solr version and connector compatibility with the module documentation before the build. Ask who will operate the Solr servers after launch. |
How Solr search connects to the rest of the Drupal platform
A Solr index rarely stands alone. Facets, cron and queues, caching, hosting and external data feeds all touch the search build, and each one changes how indexes are designed, when content becomes searchable and who operates what. Plan these connections before the index schema is fixed.
Facets and faceted search
Facets are built on top of the Search API index, so every field a facet filters on must be indexed with the right type and tokenization in Solr. Changing a facet later often means reindexing the whole source. Decide the filter list early, then check how each facet widget behaves for keyboard and screen reader users and how facet counts change under the expected query load.
Multi-index search across sources
When one search page must cover articles, products and documents, teams choose between one shared index with a content type field or several indexes queried together. Each choice affects relevance scoring, facet consistency and the cost of reindexing one source. Confirm which sources must appear in the same results list and whether any source has different access rules.
Cron and queue processing
Search API tracks changed entities and sends updates to Solr in batches, usually during cron or through a processing queue. If cron runs rarely or fails silently, editors see stale results and the gap grows unnoticed. Define the run frequency, the batch size and an alert when the unindexed item count stops falling.
Hosting and caching layers
Search responses can be cached by Drupal, a reverse proxy or a CDN, and each layer has its own purge rules. Anonymous search pages may be cacheable, but personalized results or access-filtered queries usually are not. Map which layers sit in front of the search endpoint, decide how cache invalidation follows an index update, and confirm the Solr host is reachable only from the Drupal application network.
Product feeds and external indexes
Some search content comes from outside Drupal, such as a product feed from an ERP or a second search index used for legacy documents. Feed imports and external sources change how often content is current and which system owns the record. Agree the source of truth for each field, the import schedule and what happens to the Solr index when a feed sends malformed or partial records.
Questions teams ask before hiring help for Drupal Solr search
What drives the cost of a Drupal Solr search project?
The main cost drivers are the number of indexes, the number and type of facets, how much custom work the data needs before it is indexed, and how many environments must be set up. Ask for a quote that splits the work into index design, Drupal configuration, Solr hosting setup, testing and handover, and marks each item as one-time or recurring. Hosting Solr is usually a separate ongoing cost, paid either to your cloud or data center team or to a hosting provider you choose. Your own team pays for content owners' time during review, which is often overlooked in estimates.
How long does a Solr search implementation usually take?
Duration depends on how many content types and sources feed the index, how complex the facets are, and how quickly your team can answer design questions. Index design and search requirements usually take the longest, because they decide what the schema and facets must do. Ask the partner to tie the timeline to a written scope with named milestones, and ask which of your reviews and approvals sit on the critical path. No timeline should be accepted until those dependencies are listed.
What does our team need to provide before the work starts?
Plan to provide three things. First, content owners who can confirm which content types, fields and taxonomies belong in search and who signs off on relevance. Second, access to the Solr hosting environment, including network paths from Drupal, service accounts and a place to store configuration. Third, written search requirements, such as the sort orders, filters, synonyms, autocomplete behavior and the result pages editors and visitors expect. Missing any of these usually delays index design more than the build itself.
Can our in-house team build Drupal search with Solr without a partner?
Yes, if your team already has Drupal developers and someone who runs Solr. The work needs knowledge of Search API, the Solr connector module, Solr schema and configuration files, and performance testing against realistic content volumes. Teams without that combination often find the search index behaves differently in production than in development. Before deciding, compare your skills against the scope, check who will own the index after launch, and ask whether a partner would cover only the gaps, such as schema design or a load test.
How do Solr version upgrades affect the Drupal site?
A Solr upgrade can change the schema handling, configuration format or supported features, so the Drupal search module and the Solr configuration must be checked together before any change goes live. Confirm the Solr versions supported by your chosen Search API Solr module release on its Drupal.org project page, and test against a copy of production content. Plan for reindexing after a major change, and agree a rollback path. Drupal core upgrades can also affect the search module, so the two should be scheduled together.
How are security updates to Solr and the Drupal search modules handled?
Drupal core and contributed modules are patched through Drupal's security release process, which uses Wednesday release windows and published advisories with CVE identifiers. Solr has its own release and advisory channel, so your operations team must watch both. Ask the partner how they will track advisories for the Search API modules, test patches in a staging environment, and deploy them with your change process. Also confirm who holds the Solr hosting, patching and access responsibilities, since those sit outside Drupal.
Should we host Solr next to Drupal or in a separate environment?
Host Solr in the same network zone as Drupal only if your security policy allows it and the search service is restricted to Drupal's servers. Many teams run Solr on separate infrastructure so it can be sized, patched and backed up independently. Confirm the Solr hosting option against your data classification rules, backup requirements and capacity needs. Your cloud or data center team should own the hosting decision, and the partner should document the connection, credentials and failure behavior.
What should we ask for in a written quote for Solr search?
Ask for a fixed scope that lists each index, facet, data source and integration, with the deliverables for each. Require a clear split between one-time build work and recurring support, upgrades and hosting. Ask how testing, performance checks and content review are included, what your team must supply and by when, and how changes after sign-off are handled. Also ask which Drupal and Solr versions the quote assumes, so the price matches the platform you will run.
How DeployOpen scopes and delivers Drupal search work
Search work on Drupal goes wrong most often when the requirements stay vague until the build is half done. DeployOpen starts with a written scope that names the content types and fields to index, the search requirements (keyword matching, typo handling, facets, sorting, access rules for unpublished or restricted content), the number of Search API indexes, and the Solr server they will run on. Deliverables, acceptance checks and the timeline are agreed in writing before work begins, so the quote follows from that document rather than from an open-ended estimate. Ask for the scope to list each index, each processor and each facet, because those items drive most of the effort.
The build happens inside your own infrastructure, on the Solr servers, Drupal environments and cloud or data center accounts you control. Index design comes first: which entities go into which index, which fields are indexed as text, string or numeric types, how the content_access and language processors are set, and how the Solr configset is versioned alongside the site code. Facet configuration, autocomplete and the query tests follow. Before handover, confirm with your own team which Solr version your hosting plan supports, since the Search API Solr module documentation states the supported range and that range can change with new releases. Ask who owns the Solr configset in your repository and who approves changes to it.
Handover is part of the scope, not an add-on. Deliverables typically include the exported Search API configuration, the Solr configset, runbooks for reindexing and for restoring the Solr core from backup, and notes on what to monitor. Retainers are available if you want DeployOpen to handle Drupal and Solr updates, reindex after schema changes and review new module releases on a regular cycle. Whether you buy a retainer or run search in-house, agree in writing who patches Solr, who responds to a failed index run, and how much search-related change each quarter is included.
