JTL-Shop, weitergedacht.

Anlass-Kundinnen suchen mit Alltagssprache: „stäbe", „verschlüsse", „goldhochzeit oma", „30er". Die Cloud-Suche fand vieles davon nicht — weil Komposita, Synonyme und Anlass-Kontext fehlten. Statt eine weitere Cloud-Lizenz zu mieten, haben wir einen eigenen Such-Service auf dem Shop-Server aufgesetzt: ein BAAI/bge-m3-Embedding-Modell, das alle ~4.500 Produkte semantisch indexiert, kombiniert mit BM25 für exakte Treffer und einer kuratierten Synonym-Liste für die wichtigsten Sortiments-Begriffe.

Ein eigens entwickeltes JTL-Plugin klinkt sich in die Such-Hooks ein, schaltet die Standard-JTL-Cloud-Suche ab und ersetzt die Trefferreihenfolge — der Rest der Suchergebnisseite (Bilder, Preise, Filter, Add-to-Cart) bleibt natives JTL. Nightly-Cron indexiert neue Wawi-Artikel automatisch.

• FastAPI-Service mit bge-m3 (lokal, CPU-basiert, ~1024-dim Embeddings)
• Hybrid-Scoring: Semantik + BM25 + Synonym-Expansion + Name-Match-Bonus
• Kuratierte Synonyme für Komposita („stäbe" → „ballonstäbe")
• Eigenes JTL-Plugin mit gestaffelter Rollout-Logik (off · cookie · canary · all)
• Nightly Re-Index via systemd-Timer, ~30s Service-Restart, Wartungs-Page als Fallback
• JTL Cloud Search abgelöst — Lizenzkosten gespart

Die Standard-JTL-Cross-Sells zeigen, was die Wawi pflegt — und das ist bei einem Sortiment dieser Größe selten kuratiert. Wir haben sie durch eine eigene Bundle-Box ersetzt: drei bis vier komplementäre Artikel als Komplett-Set, sichtbar direkt unter „In den Warenkorb". Frontend in Smarty, Logik in einer eigenen Plugin-Struktur, Daten in eigenen Tabellen (nicht in JTL-Tabellen — das würde von jedem Wawi-Push überschrieben).

Phase 1 läuft live mit JTL-Cross-Sell-Daten als Quelle und ersetzt das optische und funktionale Original; Phase 2 stellt die Datenquelle um auf Co-Purchase-Mining aus der Bestellhistorie plus semantische Ähnlichkeit aus dem bestehenden Embedding-Index.

• Custom-Smarty-Template im Child-Theme des Shops
• 1-Klick-Add via AJAX gegen den JTL-Cart-Endpoint
• Eigene Plugin-Tabellen, Wawi-update-fest
• Markenfarben Grün/Gelb statt JTL-Default
• Geteiltes Anlass-Tagging mit Recommender + Magazin

Zeitdruck-Mechaniken sind in Deutschland heikel. Wir haben sie als eigenes Plugin gebaut: zweimal täglich öffnet sich ein 90-Minuten-Fenster zu algorithmisch festgelegten Zeiten, in dem der Warenkorb automatisch 15 % Direktrabatt erhält. Der Countdown im Mini-Cart zeigt den echten Endzeitpunkt — kein Dauer-Timer, kein falscher Dringlichkeits-Trick, sondern eine tatsächlich nur in dem Fenster gewährte Aktion. Sauber nach UWG, dokumentiert, ein/aus per Plugin-Setting.

• Eigens entwickeltes JTL-Plugin
• Algorithmisch festgelegte, nicht vorhersagbare Zeitfenster
• Konfigurierbar: Rabatt %, Fensterlänge, früheste Startzeiten
• Kein externer Dienst, kein zusätzlicher Tracking-Pixel
• Sofort-Notbremse über Plugin-Setting

Long-Form-Content treibt im Anlassgeschäft den Top-of-Funnel. Statt ein Drittsystem auf eine Subdomain zu hängen und SEO-Equity zu zerteilen, haben wir ein eigenständiges Magazin auf demselben Host gebaut: Astro mit MDX, Tailwind, View Transitions — gerendert zu statischem HTML, ausgeliefert via nginx vor dem JTL-PHP-Pfad. Header, Footer und Mini-Cart sind mit dem Shop synchronisiert, der Warenkorb-Cookie ist geteilt. Für die Leserin gibt es keinen Bruch zwischen Magazin und Shop.

Drei Embedding-Stufen erlauben, Produkte im Artikel zu zeigen ohne Marketing-Schräglage: ein Inline-Hover-Link, eine Produktkarte oder ein ganzes Set mit Bundle-Logik (gleiche Komponente wie auf der Produktseite). Beim Build entsteht ein Reverse-Index — auf der Produktseite kann eine „Aus dem Magazin"-Card auftauchen, sobald ein Artikel das Produkt verwendet.

• Astro + Tailwind + MDX, statisches Build, atomarer Deploy via Symlink-Swap
• nginx-Routing: /magazin → Astro-dist, alles andere → JTL-PHP
• Header/Footer-Sync mit dem Live-Shop, geteilter Cart-Cookie
• MDX-Komponenten <ProductLink>, <Product>, <Set> mit DB-Build-time-Query
• Reverse-Index Magazin ↔ Shop für „Aus dem Magazin"-Cards
• Pre-Commit-Link-Check gegen Produkt-DB

Ein Shop dieser Größe gehört nicht auf Shared Hosting. Die Last-Profile sind zu spitz (Anlasspeaks rund um Weihnachten, Silvester, Hochzeitssaison), die Datenbank zu schreibintensiv, und die KI-Komponenten brauchen Rechenzeit, die geteilte Server nicht garantieren. Luftballonwelt läuft deshalb auf einer eigenen Root-Maschine — sauber dimensioniert, sauber gepflegt, mit Backups vor jedem Plugin-Deploy.

Performance-seitig sitzen die wichtigen Stellschrauben übereinander: Redis als persistenter Cache-Backend für JTL (Objekt-Cache, Konfiguration, Smarty-Compile-Cache), OPcache für die PHP-Bytecode-Stufe, PHP-FPM für die Request-Verarbeitung, nginx mit HTTP/2 davor, MariaDB lokal über Unix-Socket (keine TCP-Roundtrips). Der Such-Service läuft auf derselben Maschine als systemd-Unit — eine Suchanfrage bleibt damit komplett auf der Box, ohne Cloud-Hop.

• Eigener Root-Server (kein Shared-, kein Managed-Hosting)
• Redis als zentraler Cache (Objekt-Cache, Sessions, Smarty-Compile)
• PHP-FPM + OPcache, getuned für JTL-Lastprofile
• MariaDB lokal über Unix-Socket — kein Netzwerk-Hop zur DB
• nginx mit HTTP/2 vor dem Shop und dem Magazin-Build
• KI-Such-Service intern (nur lokal erreichbar) — keine externe Cloud-API für jede Suche
• Full-Backups vor jedem Plugin-Deploy (DB + Files, integritätsgeprüft)
• Wartungs-Page als Fallback während Service-Restart (~30 s beim Re-Index)

SEO ist im Anlassgeschäft kein einmaliges Projekt, sondern eine Daueraufgabe — Kategorien, Anlässe, Saisonalitäten wechseln sich ab, Google ändert Bewertungsfaktoren, neue Konkurrenz taucht auf. Wir arbeiten deshalb nicht mit „SEO-Audit alle 12 Monate", sondern mit laufendem Monitoring und gezielten Eingriffen.

Inhaltlich greift das Magazin SEO-relevante Anlass-Themen tief auf (Hochzeit unter freiem Himmel, 30. Geburtstag, Babyparty, Helium-1×1) und brückenbaut zu konkreten Produkten im Shop — Long-Form als Eingang, Kategorie- und Produktseiten als Conversion-Ziel. Strukturierte Daten, saubere hreflang/Canonicals, dynamische Sitemaps und produktive Schema.org-Auszeichnungen ergänzen die rein redaktionelle Arbeit.

Technisch wird Sichtbarkeit kontinuierlich beobachtet: Core Web Vitals werden über echte User-Daten und Lighthouse-Läufe vor jedem größeren Release geprüft, die Suchkonsole liefert Impressions/Klicks/CTR/Position wöchentlich, die Server-Logs werden auf Bot-Crawl-Budget hin ausgewertet, und die hauseigene Hybrid-Suche wertet anonymisierte Such-Anfragen aggregiert aus — inklusive der „keine Treffer"-Fälle, die direkt ins Synonym-Backlog wandern.

• Anlass-Kategorien-Strategie, verzahnt mit dem Magazin-Stack
• Long-Form-Magazin-Artikel als Top-of-Funnel-Eingang
• Strukturierte Daten (Schema.org Product/Article), dynamische Sitemaps, Canonicals
• Core Web Vitals laufend gemessen (Field + Lighthouse vor Releases)
• Search-Console-Auswertung wöchentlich (Impressions, CTR, Top-Movers)
• Server-Log-Auswertung für Crawl-Budget & Bot-Verhalten
• Anonymisierte Auswertung von Such-Anfragen inkl. „Keine Treffer"-Cases → Synonym-Pflege
• Uptime- und HTTP-Status-Monitoring inkl. Alarmierung

Statt einen kompletten Relaunch zu fahren, arbeiten wir an einer priorisierten Liste konkreter Conversion-Hebel: eine Versandkosten-Schwelle als Progressbar auf PDP, Mini-Cart und Header (AOV-Hebel); ein Cart-Recovery-Mailflow, bewusst als DSGVO-saubere Eigenentwicklung statt Drittanbieter; ein Audit für Bilder-Karteileichen aus der Wawi-Migration; Trust-Elemente unter dem Buy-Button. Jeder Punkt ist für sich klein genug, um in Tagen lieferbar zu sein — und groß genug, um messbar zu wirken.

• Versand-Progressbar (datenbasierte Schwelle)
• Cart-Recovery-Mailflow, opt-in-basiert (Bestandskunden & Newsletter-Abonnenten), auf hauseigener Mail-Basis statt Drittanbieter
• Bilder-Karteileichen-Audit (FS↔DB-Diff)
• Trust-Elemente auf PDP nachschärfen (Cutoff-Counter, Bewertungen)
• Mengenrabatt-Staffeln sichtbar machen (Latex/Girlanden)