ke_search Premium for TYPO3

ke_search Premium brings enterprise search to TYPO3 without a Solr server

A website’s internal search is the feature that gets used the most and maintained the least. Visitors expect autocomplete, typo tolerance and the ability to search not just pages but PDFs and Office documents as well. ke_search Premium delivers exactly that for TYPO3, without an external Solr or Elasticsearch server to operate. All data lives in the TYPO3 database, the index is updated via the scheduler, and administration stays in the TYPO3 backend.

For mid-sized websites with 500 to 5,000 pages and a handful of file downloads, ke_search Premium is the most cost-effective search solution in the TYPO3 ecosystem. Solr only becomes the better choice beyond 10,000+ indexed documents or when sub-second response times are a hard requirement.

Typical use cases range from corporate websites to knowledge portals

The standard scenario is a corporate website with a product catalog, magazine, FAQ and download area. Visitors search for product names, technical terms or documents and expect results from every section in a single hit list. ke_search indexes page content, news articles, downloads (PDF, DOCX, XLSX) and custom records such as products or staff profiles. The premium version’s autocomplete shows suggestions while the visitor is still typing and reduces the search abandonment rate by an estimated 15 to 25%.

The second scenario is knowledge portals and document collections. Universities, associations and public bodies often offer hundreds of PDFs for download: research reports, bylaws, forms, meeting minutes. Without file indexing, the TYPO3 search only covers page text, not the content of those PDFs. Even the free version of ke_search extracts the text from PDF, DOCX and other formats and makes it searchable.

The third scenario is custom indexers for third-party systems. Companies with a PIM, a DAM or an external product catalog can pull any data source into the search index through the custom indexer API. An indexer job fetches the data via API, transforms it into ke_search records and stores them in the index. This is particularly relevant for e-commerce, where product data often does not live in TYPO3 at all.

The technical architecture uses the TYPO3 database as the search index

ke_search stores its index in a dedicated table (tx_kesearch_index) in the TYPO3 database. Each index entry contains title, content, tags, type and sorting information. Indexing runs through scheduler tasks that re-index the content at configurable intervals, typically every night. File indexing and custom indexers already come with the free version; the premium version adds autocomplete, synonyms, did-you-mean suggestions and custom ranking, among other things.

File indexing relies on pdftotext and pdfinfo for PDFs and on catdoc, catppt and xls2csv for older Office formats; ke_search reads DOCX, PPTX and XLSX without any extra tool. These tools have to be installed on the server, which can be a problem in shared hosting environments. On dedicated servers and in Docker containers, installing them is trivial.

In the frontend, queries use the MySQL or MariaDB full-text search (MATCH … AGAINST) on a FULLTEXT index that ke_search creates in the tx_kesearch_index table itself. You do not need to add an index on the relevant columns yourself.

Autocomplete is implemented through an AJAX endpoint and suggests search terms that other visitors have already used and that returned results. The results come back as JSON and are displayed as a dropdown in the frontend via JavaScript. The configuration lets you set the minimum number of characters (recommended: 3) and the maximum number of suggestions (recommended: 8).

Common problems involve indexing time, missing pdftotext installations and relevance ranking

Problem one: long indexing times for large data volumes. A website with 3,000 pages and 500 PDFs can take 30 to 60 minutes for a full re-index. The fix: enable incremental indexing, which only re-indexes content that has changed. ke_search has offered this in the free version since 3.8, configured via the scheduler.

Problem two: a missing pdftotext installation. Without it, PDFs never reach the index, and ke_search only notes this in the log. Editors upload PDFs that never make it into the search index. The fix: after installation, start a test indexing run and check whether PDF content shows up in the index. A simple CLI command confirms availability: which pdftotext.

Problem three: relevance ranking. The default sorting is based on a simple scoring algorithm that weights hits in titles higher than hits in the body text. For more demanding requirements, such as boosting by recency, by page type or by custom fields, that is not enough: the premium version offers custom ranking and boost keywords, while the title weight of the basic version is set in the extension configuration.

Current versions support TYPO3 v13 and v14, the 6.x series covers v12

ke_search is maintained by a dedicated development team and becomes compatible with every TYPO3 LTS release shortly after it ships. The current 7.x versions of ke_search and ke_search Premium support TYPO3 v13 and v14; for TYPO3 v12 there is the 6.x series. When upgrading from older TYPO3 versions, breaking changes mainly affect the TypoScript configuration of the indexers and the registration of scheduler tasks. The search index itself has to be rebuilt from scratch after an upgrade, which can take an hour or more depending on the data volume.

Gosign uses ke_search Premium in TYPO3 projects that need an internal search but cannot justify running a Solr server. For most mid-sized websites with fewer than 5,000 indexed documents, ke_search Premium is the most economical solution. Only when requirements such as fuzzy matching or sub-second response times on large data volumes come into play do we recommend moving to Apache Solr with the TYPO3 Solr extension.