TYPO3 Search: Apache Solr, Indexed Search, and Beyond

TYPO3 offers two sensible starting points for site search: the core Indexed Search extension for a contained, database-backed implementation, and Apache Solr for TYPO3 (EXT:solr) when faceting, scale, richer analysis, or operational separation justify another service. Choose from corpus and requirements, not from an assumption that every TYPO3 installation needs Solr.

Choose the backend from workload boundaries

Requirement	Indexed Search	EXT:solr
Small or moderate editorial site	Often the simpler first choice	Possible, with more operations
Facets and field-specific ranking	Limited	Designed for configurable indexed fields and facets
Separate search capacity	Shares TYPO3/database resources	Runs a separate Solr service
Operational burden	TYPO3 index tables and scheduler	TYPO3 extension, Solr cores, schema compatibility, backups, monitoring

Count pages, records, files, languages, permissions, update frequency, peak query rate, and required filters. Define an acceptable indexing delay and restoration time. A five-page brochure and a multilingual product catalogue should not inherit the same architecture.

Implement Indexed Search as a controlled baseline

TYPO3's Indexed Search documentation describes indexing for pages, records, and supported files, plus the frontend plugin and backend analysis. Confirm exactly what gets indexed: navigation, repeated footer content, draft or hidden pages, access-restricted content, and binary attachments can all distort relevance or expose text unexpectedly.

Configure the search page and templates in the site's maintained configuration rather than editing vendor files. Run a representative crawl or page-rendering path, inspect index statistics, and test updates, deletions, redirects, and permission changes. Schedule maintenance for stale rows and verify that a production cache does not prevent updated pages from reaching the index.

Adopt EXT:solr with version and schema discipline

The official EXT:solr documentation covers installation, index queues, frontend rendering, facets, suggestions, languages, and the Solr connection. Consult its version matrix before upgrading TYPO3, the extension, Java, or Solr. These components do not have independent compatibility.

Define indexed types and fields explicitly. Map titles, body text, identifiers, dates, categories, language, and access metadata; exclude layout chrome and unpublished content. Use separate cores or documented language fields according to the supported extension design. Treat synonyms, stop words, stemming, boosts, and fuzzy matching as relevance changes that require labelled queries and rollback. The Apache Solr Reference Guide provides the underlying operational and query behaviour.

Keep indexing, permissions, and publication in sync

Search results must follow TYPO3's visibility, workspace, language, start/end time, and frontend-user access rules. Test users with and without access and check titles, snippets, facets, suggestions, and cached responses—not merely the final page. When content is withdrawn, deletion from the index should be part of the publication workflow.

Make indexing idempotent and observable. Monitor queue age, failed items, last successful commit, document counts by site and language, query errors, and zero-result rate. A Solr process that answers health checks can still hold a stale or incomplete corpus. Document how to rebuild, how long it takes, and what visitors see during the rebuild.

Evaluate search with TYPO3-specific tasks

Build a judgement set from real page titles, product identifiers, abbreviations, German compounds, translated terms, common misspellings, and restricted documents. Measure exact lookup, first useful result, no-result rate, facet correctness, and indexing freshness. Test the frontend against keyboard and screen-reader interaction as well as empty, slow, and unavailable backends. The best backend is the least complex one that meets those measured tasks and can be operated through an upgrade.