openserp: selbst gehostete SERP-API mit sechs Suchmaschinen und Seiten-Extraktion

Kein Schlüssel, keine Rechnung, dafür eigener Betrieb

Das Projekt richtet sich an zwei Gruppen. Die eine sind Entwickler, die Suchtreffer als strukturierte Daten in eine Anwendung einspeisen wollen, etwa als Grounding-Quelle für ein Sprachmodell oder als Backend für Rank-Tracking im SEO. Die andere sind Nutzer, die Suchmaschinen abfragen möchten, die in kommerziellen SERP-APIs selten oder gar nicht vorkommen, im Repository genannt sind Yandex, Baidu und Ecosia. Der README formuliert den Kern so: no API keys, no per-search billing. Stattdessen läuft ein Dienst auf localhost, der die Abfrage selbst rendert und als JSON zurückgibt. Das verschiebt die Kosten von einer Rechnung pro Aufruf zu Infrastruktur, Wartung und der Frage, wie man nicht selbst blockiert wird. Wer beides nicht will, kann laut README auf eine gehostete Version mit derselben API ausweichen; die Lizenz des selbst gehosteten Codes ist MIT.

Ein Schema, sechs Engines, ein Zusammenführungsschritt

Die Architektur ist bewusst flach. Für jede der sechs Suchmaschinen existiert ein eigener Endpunkt, und alle liefern dasselbe JSON-Schema. Darüber liegt der Endpunkt /mega/search, der eine Anfrage auf mehrere Engines verteilt, die Antworten zusammenführt und Duplikate entfernt. Das Beispiel im README zeigt das Muster: /mega/search?engines=bing,google&text=golang+vs+rust&extract=1&mode=any. Der Parameter mode=any bedeutet, dass die erste Engine gewinnt, die überhaupt antwortet. Das ist schnell, aber es macht die Antwort nicht deterministisch: Im gezeigten Beispiel wurde nur bing zurückgegeben, google taucht lediglich unter engines_requested auf. Die Antwortstruktur trennt das sauber in engines_responded und engines_failed, dazu meta.took_ms und eine version. Im results-Array steht pro Treffer ein rank, eine id, engine, domain_info mit tld und sld sowie optional ein classification-Block mit content_type und source_hint. Unterhalb der Treffer liegt clusters, das dieselbe URL über mehrere Engines gruppiert und mit engines_count, best_rank und score bewertet. Genau dieser Cluster-Schritt ist der eigentliche Mehrwert gegenüber sechs einzelnen Abfragen, weil er Duplikate über Engine-Grenzen hinweg sichtbar macht statt sie zu verstecken.

extract=1: Treffer plus Markdown der Zielseite

Ein ungewöhnlicher Teil des Designs ist die Seiten-Extraktion. Mit extract=1 hängt openserp an jeden Treffer ein extracted-Objekt, das den Inhalt der Zielseite als Markdown enthält, mit eigenem title, format, fetched_at und einem mode_used. Im README-Beispiel steht dort mode_used: fast. Das ist praktisch, wenn ein Agent nicht nur Links, sondern lesbaren Text braucht: ein Aufruf statt Suche plus separatem Fetch plus eigener Konvertierung. Der Preis ist offensichtlich und wird vom Projekt nicht beschönigt. Jede Extraktion ist ein zusätzlicher Abruf fremder Seiten, was Laufzeit und Fehlerfläche erhöht. Das Feld fetched_at im Beispiel liegt eine Sekunde nach requested_at, was den zusätzlichen Netzwerkweg zeigt. Wer nur Rankings auswerten will, sollte extract=1 weglassen und die Antwort klein halten.

Installation: Docker, go install oder Build aus dem Quelltext

Drei Wege sind dokumentiert. Der kürzeste ist das vorgebaute Image: docker run --rm -p 127.0.0.1:7000:7000 karust/openserp:latest serve -a 0.0.0.0 -p 7000, alternativ docker compose up. Wer kein Docker will, installiert per go install github.com/karust/openserp@latest und ruft direkt die CLI auf, etwa openserp search duckduckgo "open source serp api" --format markdown. Aus dem Quelltext sind es git clone, go build -o openserp . und ./openserp serve. Der erste Testrequest ist ein curl gegen http://127.0.0.1:7000/mega/search mit engines, text, extract und mode als Query-Parameter. Auffällig ist die Bindung: Das Docker-Beispiel mappt explizit auf 127.0.0.1, der Server selbst lauscht aber auf 0.0.0.0. Wer das Image unverändert in ein Netz mit anderen Containern stellt, exponiert den Dienst, und openserp bringt keine Authentifizierung mit, weil sie für eine lokale Instanz nicht vorgesehen ist. Für den Zugriff aus Anwendungen gibt es offizielle Clients: @openserp/sdk für JavaScript und TypeScript, openserp auf PyPI für Python, @openserp/mcp als MCP-Server für Agenten und einen n8n-Community-Node. Laut README zeigen alle auf den selbst gehosteten Server über baseUrl oder auf die gehostete API über apiKey.

Wo das Modell an Grenzen stößt

Die größte Einschränkung steckt im Konzept selbst. openserp rendert Suchmaschinen mit einem Browser und liest die Ergebnisseite aus. Damit hängt die Zuverlässigkeit an der Struktur fremder HTML-Seiten, die sich jederzeit ändern kann, und an der Bereitschaft der Engines, die Anfragen zu beantworten. Das README nennt Proxies, Cache und einen resilient mode als Gegenmaßnahmen, was implizit zugibt, dass Blockierungen und Ausfälle zum Alltag gehören. Ein zweiter Punkt ist mode=any: Wenn Geschwindigkeit über Vollständigkeit gestellt wird, erhält man eine gültige Antwort von einer einzigen Engine und erfährt nur über engines_failed, dass der Rest nicht geantwortet hat. Für Rangvergleiche über Engines hinweg ist das die falsche Einstellung. Drittens ist openserp kein Archiv. Es gibt keinen Hinweis auf historische Rankings oder Speicherung über die Cache-Funktion hinaus, also eignet es sich nicht für Zeitreihenanalysen, ohne dass man selbst mitschreibt. Und schließlich: Wer Ergebnisse mit einer rechtlichen Garantie zur Weiterverwendung braucht, bekommt sie hier nicht. Das Projekt liefert die technische Möglichkeit, nicht die Erlaubnis.

Was ein kommerzieller SERP-Anbieter anders macht

Der naheliegende Vergleich ist ein bezahlter SERP-Dienst mit API-Schlüssel und Abrechnung pro Aufruf. Der Unterschied liegt nicht in der Antwortform, sondern im Betriebsmodell. Ein bezahlter Anbieter betreibt die Renderer, rotiert die IP-Adressen und trägt das Risiko, wenn eine Engine ihr Markup ändert. Bei openserp liegt genau dieses Risiko beim Betreiber, und der README adressiert es mit Proxy- und Cache-Optionen statt mit einer Garantie. Dafür gibt es zwei Dinge, die ein Abrechnungsmodell naturgemäß nicht bietet: volle Kontrolle über die Abfrage, inklusive der Möglichkeit, eigene Proxies zu setzen, und keine Obergrenze pro Suche. Ein zweiter Vergleichspunkt ist der MCP-Server. Wer Suchtreffer direkt einem Agenten geben will, kann statt openserp auch einen fertigen Such-Backend-Dienst einbinden. Der Unterschied ist, dass openserp die Suchschicht und die Extraktion in einem Dienst bündelt, während man sonst Suche und Seitenabruf getrennt verdrahtet. Das ist bequemer, koppelt aber beides an dieselbe Fehlerquelle.

Wartung, Releases und was die MIT-Lizenz bedeutet

Die Release-Historie ist dicht: v0.8.3 im Juni, v0.8.6 Ende Juni, v0.8.12 im Juli, jeweils im Abstand von Wochen. Das deutet auf aktive Pflege hin, ist aber auch ein Hinweis darauf, dass sich die API zwischen Versionen bewegen kann. Wer openserp einbettet, sollte die Version pinnen, statt latest zu ziehen. Die Kosten im Betrieb sind nicht die Installation, sondern der laufende Unterhalt: Proxy-Listen, Cache-Größe, Anpassungen, wenn eine Engine ihre Auszeichnung ändert. Die MIT-Lizenz erlaubt Weitergabe und kommerzielle Nutzung des Codes, verlangt aber die Beibehaltung des Lizenzhinweises. Sie deckt ausdrücklich nicht die Nutzungsbedingungen der abgefragten Suchmaschinen ab, und dazu gibt das Repository keine Aussage. Wer den Dienst öffentlich betreibt, sollte diesen Punkt vorher klären, nicht nachher.

Redaktionelles Fazit

Sinnvoll ist openserp für Teams, die Suchdaten in eigene Pipelines einspeisen wollen und den Betrieb eines Go-Dienstes samt Proxy- und Cache-Konfiguration selbst tragen können. Wer eine SLA, Support und keinerlei Infrastrukturverantwortung braucht, sollte auf die gehostete Variante oder einen kommerziellen Anbieter ausweichen. Vor dem Produktiveinsatz zu prüfen sind: ob die sechs dokumentierten Engine-Endpunkte gegen die eigenen Zielmärkte tatsächlich stabile Ergebnisse liefern, wie sich mode=any bei Teilausfällen verhält, und ob die MIT-Lizenz mit der geplanten Weitergabe des Dienstes zusammenpasst.

Offizielle Quellen

1. karust/openserp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases