ke_search Premium für TYPO3

Enterprise-Suche ohne Solr-Server ist mit ke_search Premium in TYPO3 möglich

Die interne Suche einer Website ist das Feature, das am meisten genutzt und am wenigsten gepflegt wird. Besucher erwarten Autocomplete, Tippfehler-Toleranz und die Fähigkeit, nicht nur Seiten, sondern auch PDFs und Office-Dokumente zu durchsuchen. ke_search Premium liefert genau das für TYPO3, ohne dass ein externer Solr- oder Elasticsearch-Server betrieben werden muss. Alle Daten liegen in der TYPO3-Datenbank, der Index wird über den Scheduler aktualisiert, und die Administration bleibt im TYPO3-Backend.

Für mittelgroße Websites mit 500 bis 5.000 Seiten und einer Handvoll Datei-Downloads ist ke_search Premium die wirtschaftlichste Suchlösung im TYPO3-Ökosystem. Erst ab 10.000+ indexierten Dokumenten oder bei Sub-Sekunden-Anforderungen an die Antwortzeit wird Solr zur besseren Wahl.

Typische Einsatzszenarien reichen von Unternehmenswebsites bis zu Wissensportalen

Das Standardszenario ist die Unternehmenswebsite mit Produktkatalog, Magazin, FAQ und Download-Bereich. Besucher suchen nach Produktnamen, Fachbegriffen oder Dokumenten und erwarten Ergebnisse aus allen Bereichen in einer einzigen Trefferliste. ke_search indexiert Seiteninhalte, News-Artikel, Downloads (PDF, DOCX, XLSX) und Custom-Records wie Produkte oder Mitarbeiterprofile. Die Autocomplete-Funktion der Premium-Version zeigt bereits beim Tippen Vorschläge an und reduziert die Suchabbruchrate um geschätzte 15 bis 25%.

Zweites Szenario: Wissensportale und Dokumentensammlungen. Hochschulen, Verbände und öffentliche Einrichtungen stellen oft hunderte PDFs zum Download bereit: Forschungsberichte, Satzungen, Formulare, Protokolle. Ohne Datei-Indexierung durchsucht die TYPO3-Suche nur die Seitentexte, nicht den Inhalt der PDFs. ke_search extrahiert schon in der kostenlosen Version den Text aus PDF, DOCX und weiteren Formaten und macht ihn durchsuchbar.

Drittes Szenario: Custom Indexer für Drittsysteme. Unternehmen mit einem PIM, einem DAM oder einem externen Produktkatalog können über die Custom-Indexer-API beliebige Datenquellen in den Suchindex einbinden. Ein Indexer-Job holt Daten per API, transformiert sie in ke_search-Records und speichert sie im Index. Das ist besonders relevant für E-Commerce-Szenarien, in denen Produktdaten nicht in TYPO3 liegen.

Technische Architektur nutzt die TYPO3-Datenbank als Suchindex

ke_search speichert den Index in einer dedizierten Tabelle (tx_kesearch_index) in der TYPO3-Datenbank. Jeder Index-Eintrag enthält Titel, Inhalt, Tags, Typ und Sortierungsinformationen. Die Indexierung läuft über Scheduler-Tasks, die in konfigurierbaren Intervallen (typisch: nächtlich) den Content neu indexieren. Datei-Indexierung und eigene Indexer bringt schon die kostenlose Version mit; die Premium-Version ergänzt unter anderem Autocomplete, Synonyme, „Meinten Sie?“ und Custom Ranking.

Die Datei-Indexierung nutzt pdftotext und pdfinfo für PDFs sowie catdoc, catppt und xls2csv für ältere Office-Formate; DOCX, PPTX und XLSX liest ke_search ohne Zusatzwerkzeug. Diese Tools müssen auf dem Server installiert sein, was auf Shared-Hosting-Umgebungen ein Problem sein kann. Auf dedizierten Servern und in Docker-Containern ist die Installation trivial.

Die Suchanfrage im Frontend nutzt die Volltextsuche von MySQL bzw. MariaDB (MATCH … AGAINST) auf einem FULLTEXT-Index, den ke_search in der Tabelle tx_kesearch_index selbst anlegt. Einen zusätzlichen Index auf den relevanten Spalten müssen Sie dafür nicht einrichten.

Autocomplete wird über einen AJAX-Endpoint realisiert und schlägt Suchbegriffe vor, die andere Besucher schon verwendet haben und die dabei Treffer lieferten. Die Ergebnisse werden als JSON geliefert und im Frontend per JavaScript als Dropdown angezeigt. Die Konfiguration erlaubt, die Mindest-Zeichenanzahl (empfohlen: 3) und die maximale Anzahl der Vorschläge (empfohlen: 8) einzustellen.

Häufige Probleme betreffen Indexierungszeit, fehlende pdftotext-Installation und Relevanz-Sortierung

Problem eins: Lange Indexierungszeiten bei großen Datenmengen. Eine Website mit 3.000 Seiten und 500 PDFs kann 30 bis 60 Minuten für eine vollständige Neuindexierung benötigen. Die Lösung: Inkrementelle Indexierung aktivieren, die nur geänderte Inhalte neu indexiert. Das kann ke_search seit Version 3.8 schon in der kostenlosen Version, eingerichtet über den Scheduler.

Problem zwei: Fehlende pdftotext-Installation. Ohne das Werkzeug landen PDFs nicht im Index, und ke_search vermerkt das nur im Log. Redakteure laden PDFs hoch, die nie im Suchindex landen. Die Lösung: Nach der Installation einen Test-Indexierungslauf starten und prüfen, ob PDF-Inhalte im Index erscheinen. Ein einfacher CLI-Befehl prüft die Verfügbarkeit: which pdftotext.

Problem drei: Relevanz-Sortierung. Die Standard-Sortierung basiert auf einem einfachen Scoring-Algorithmus, der Treffer in Titeln höher gewichtet als Treffer im Body. Für komplexe Anforderungen (Boosting nach Aktualität, nach Seitentyp oder nach Custom-Feldern) reicht das nicht: Eigene Gewichtungen bietet die Premium-Version mit Custom Ranking und Boost Keywords, das Titelgewicht der Basisversion stellen Sie in der Extension-Konfiguration ein.

Die aktuellen Versionen unterstützen TYPO3 v13 und v14, für v12 gibt es die 6er-Reihe

ke_search wird von einem dedizierten Entwicklerteam gepflegt und ist bei jedem TYPO3-LTS-Release zeitnah kompatibel. Die aktuellen Versionen 7.x von ke_search und ke_search Premium unterstützen TYPO3 v13 und v14, für TYPO3 v12 gibt es die Versionen 6.x. Beim Upgrade von älteren TYPO3-Versionen betreffen Breaking Changes vor allem die TypoScript-Konfiguration der Indexer und die Scheduler-Task-Registrierung. Der Suchindex selbst muss nach einem Upgrade komplett neu aufgebaut werden, was je nach Datenmenge eine Stunde oder mehr dauern kann.

Gosign setzt ke_search Premium in TYPO3-Projekten ein, die eine interne Suche brauchen, aber den Betrieb eines Solr-Servers nicht rechtfertigen. Für die meisten mittelgroßen Websites mit unter 5.000 indexierten Dokumenten ist ke_search Premium die wirtschaftlich sinnvollste Lösung. Erst wenn Anforderungen wie Fuzzy-Matching oder Sub-Sekunden-Antwortzeiten bei großen Datenmengen dazukommen, empfehlen wir den Umstieg auf Apache Solr mit der TYPO3-Solr-Extension.