Auf einen Blick
ProjektProduktentwicklung, Fragon StudiosBrancheKI / WordPress-ÖkosystemTechnologienPHP 8, WordPress, MySQL, OpenAI-kompatible APIs, Vanilla JSErgebnisKI-Chatbot mit Vector Search in MySQL, läuft auf jedem Shared Hosting
Die Ausgangssituation
WordPress-Seitenbetreiber wollen ihren Besuchern schnelle Antworten bieten, ohne ein Support-Team zu beschäftigen. Die vorhandenen Chatbot-Plugins sind entweder regelbasiert (statische Frage-Antwort-Paare, die manuell gepflegt werden müssen) oder an spezifische SaaS-Dienste gebunden (Daten verlassen den Server, monatliche Kosten, Vendor Lock-in).
Unser Ziel: Ein Plugin, das die Inhalte der Website automatisch indexiert und daraus KI-gestützte Antworten generiert. Mit jedem OpenAI-kompatiblen Modell, vollständig auf dem Server des Kunden.
Die zentrale Designentscheidung: Vector Search in MySQL
Die gängige Architektur für RAG-Systeme (Retrieval-Augmented Generation) setzt auf spezialisierte Vector-Datenbanken wie Pinecone, Weaviate oder Qdrant. Für ein WordPress-Plugin ist das unpraktisch, weil es eine zusätzliche Infrastrukturkomponente erfordern würde, die die meisten WordPress-Hoster nicht anbieten.
Unsere Lösung: Embeddings direkt in MySQL speichern und Cosine Similarity in PHP berechnen.
Embeddings werden als Binary Blob gespeichert (pack('f*', ...$vector) als LONGBLOB) und bei Abfragen entpackt. Die Ähnlichkeitssuche berechnet das Dot Product über alle gespeicherten Vektoren.
Das klingt nach einem Performance-Problem, ist aber in der Praxis überraschend schnell: Bei 1.000 bis 5.000 Content-Chunks (was für 95% aller WordPress-Seiten reicht) liegt die Suchzeit unter 500ms. Keine externe Datenbank, kein zusätzlicher Service, alles bleibt auf dem Server des Kunden.
Was Sie daraus mitnehmen können: Vector Search braucht keine Vector Database. Für Anwendungen mit wenigen tausend Dokumenten reicht eine relationale Datenbank mit binärer Vektorspeicherung völlig aus. Die Komplexität einer dedizierten Vector DB lohnt sich erst ab sechsstelligen Dokumentenzahlen.
Architektur
Das Plugin besteht aus vier Kernmodulen:
Indexer Service. Crawlt WordPress-Inhalte (Posts, Pages, Custom Post Types), teilt sie in Chunks und generiert Embeddings über die konfigurierte API. Der Indexer wird automatisch bei Änderungen ausgelöst. Wenn ein Post gespeichert oder gelöscht wird, aktualisiert sich der Index über WordPress-Hooks (save_post, delete_post).
Chat Engine. Empfängt Nutzerfragen über eine REST API, findet relevante Chunks via Vector Search, baut einen Kontext zusammen und generiert Antworten mit dem konfigurierten LLM. Der System-Prompt ist im Admin konfigurierbar, sodass der Seitenbetreiber Ton, Sprache und Verhalten des Bots anpassen kann.
Cache Manager. Speichert häufige Fragen und deren Antworten auf zwei Ebenen: Exact Cache für identische Fragen und Semantic Cache für ähnliche Fragen (über Cosine Similarity der Frage-Embeddings). In der Praxis werden nach einer Einlaufphase 60 bis 80% aller Anfragen aus dem Cache beantwortet.
Admin Dashboard. Konfiguration der API-Credentials (Endpoint-URL, API-Key, Modellname für Chat und Embeddings), System-Prompt-Editor, Feature Flags zum Ein- und Ausschalten einzelner Features, Index-Status mit Übersicht über indexierte Inhalte und Re-Index-Button.
Kostenkontrolle durch Semantic Caching
LLM-API-Calls kosten Geld. Ein viel besuchter WordPress-Shop mit Chatbot kann schnell hohe API-Kosten verursachen, besonders wenn viele Besucher Variationen derselben Fragen stellen ("Wie sind die Öffnungszeiten?", "Wann habt ihr offen?", "Bis wann ist geöffnet?").
Der Semantic Cache erkennt, dass diese Fragen inhaltlich identisch sind, und liefert die gecachte Antwort, solange die Cosine Similarity über einem konfigurierbaren Schwellenwert liegt. Kombiniert mit dem Exact Cache reduziert das die API-Calls um den Faktor 3 bis 5.
Was Sie daraus mitnehmen können: Semantic Caching ist der größte Hebel für API-Kosten bei KI-Anwendungen. Die meisten Nutzer stellen Variationen derselben Fragen. Ein Cache, der nicht nur exakte Treffer, sondern auch semantisch ähnliche Fragen erkennt, spart mehr als jede andere Optimierung.
Feature Flags statt Feature-Bloat
Kunden haben unterschiedliche Bedürfnisse. Ein kleiner Blog braucht kein Rate Limiting, ein hochfrequentierter Shop schon. Ein technisch versierter Betreiber will Semantic Caching konfigurieren, ein anderer will einfach nur einen "funktioniert"-Schalter.
Statt separate Plugin-Versionen (Light, Pro, Enterprise) zu pflegen, nutzt WP FAQ Bot Feature Flags: Jedes Feature kann einzeln aktiviert oder deaktiviert werden. Das ergibt ein einziges Plugin, das sich an verschiedene Anforderungen anpasst, ohne die Codebasis zu fragmentieren.
Was Sie daraus mitnehmen können: Feature Flags in einem kommerziellen Plugin sind kein Over-Engineering. Sie ermöglichen es, ein einzelnes Produkt mit unterschiedlichen Preistiers zu verkaufen, ohne separate Versionen maintainen zu müssen.
OpenAI-kompatibel statt OpenAI-abhängig
Das Plugin ist bewusst nicht an einen bestimmten KI-Anbieter gebunden. Jeder Dienst, der die OpenAI-API-Spezifikation implementiert, funktioniert. Dazu gehören Anthropic Claude, Google Gemini, lokale Modelle via Ollama oder selbst gehostete Instanzen.
Der Kunde konfiguriert im Admin drei Werte: API-Endpoint-URL, API-Key und Modellname. Das war's. Wer ein lokales Modell über Ollama betreibt, trägt http://localhost:11434/v1 als Endpoint ein und hat einen komplett lokalen KI-Chatbot. Kein einziger API-Call verlässt den Server.
Was Sie daraus mitnehmen können: OpenAI-Kompatibilität öffnet den Markt. Indem das Plugin nicht an einen Anbieter gebunden ist, bleibt der Kunde flexibel und DSGVO-konform. Und das Plugin funktioniert auch dann noch, wenn ein Anbieter seine Preise verdreifacht.
Technische Constraints: WordPress-native
Ein WordPress-Plugin muss auf Shared Hosting laufen. Das bedeutet: Kein Composer, kein Node.js, keine Python-Runtime, keine Docker-Container. Alles muss in PHP funktionieren und die WordPress-Datenbank nutzen.
Das klingt nach einer Einschränkung, erzwingt aber gutes Design. Alle Dependencies sind inline, die Datenbankstruktur nutzt WordPress Custom Tables, die REST API nutzt die WordPress REST API-Infrastruktur, und das Frontend-Widget ist reines Vanilla JS ohne Framework-Abhängigkeiten.
Das Ergebnis: Installation via "Plugin hochladen", Aktivieren, API-Key eingeben, fertig. Kein Server-Setup, kein CLI, kein SSH-Zugriff nötig.
Ergebnisse
MetrikWertUnterstützte Content-Chunks1.000 bis 5.000Similarity-Suche< 500msWidget-Ladezeit< 100msErste Chat-Antwort< 2 Sekunden (inkl. API-Call)Gecachte Antwort< 100msIndexierung (100 Posts)< 60 SekundenExterne AbhängigkeitenKeine (außer LLM API)Hosting-AnforderungStandard WordPress Shared Hosting
Takeaways für Ihre Projekte
Vector Search braucht keine Vector Database. Für Anwendungen mit wenigen tausend Dokumenten reicht MySQL mit binärer Vektorspeicherung. Die Grenze liegt erfahrungsgemäß bei ca. 10.000 Chunks, darüber hinaus lohnt sich eine dedizierte Lösung.
Semantic Caching ist der größte Kostenhebel. Vor der Optimierung von Prompt-Länge oder Modellwahl: Caching einbauen. Die meisten Nutzer stellen Variationen derselben Fragen, und ein semantischer Cache fängt das zuverlässig ab.
DSGVO-Compliance ist ein Feature, kein Hindernis. Kunden in der EU achten zunehmend darauf, wo ihre Daten verarbeitet werden. Ein Plugin, das komplett auf dem eigenen Server läuft und optional lokale Modelle unterstützt, ist kein Nachteil, sondern ein Alleinstellungsmerkmal.
WordPress-Plugins können mehr als die meisten denken. RAG-Architektur, Vector Search, Semantic Caching, alles implementierbar in PHP auf Standard-Hosting. Die Plattform-Constraints erzwingen effizienten Code statt aufgeblähter Architekturen.
WP FAQ Bot wird von Fragon Studios entwickelt. Als Engineering Lab verbinden wir KI-Integration mit WordPress-Expertise.