ImkerPur verkauft Honig und Bienenprodukte über einen JTL-Shop 5 auf Strato-Shared-Hosting. Gesucht war Sichtbarkeit für Produktgruppen, die im Shop selbst nur als Artikelliste existierten — ohne ein Plugin zu installieren und ohne das Update-Risiko des Shops zu erhöhen.
Shop · Unterordner · Schema Der Shop lief. Produkte, Preise, Bestellprozess — alles vorhanden. Was fehlte, waren Seiten, die die Fragen vor dem Kauf beantworten: Was ist roher Honig überhaupt? Warum kristallisiert er schneller? Dürfen Kinder ihn essen? Diese Fragen wurden nachweislich gestellt — sie stehen in der Google Search Console des Shops. Beantwortet wurden sie dort nirgends.
Die naheliegende Lösung — ein SEO-Plugin im Shop — schied bewusst aus. Sie hätte in Templates und Datenbank eingegriffen und bei jedem JTL-Update erneut zur Diskussion gestanden. Stattdessen entstand ein zweites, unabhängiges System neben dem Shop, unter derselben Domain.
Jede Seite entsteht aus einer JSON-Datei — eine neue Landingpage ist eine neue Datei, kein neuer Code. Bewertungen und Preise sind die echten Werte aus dem Shop, keine Platzhalter.
Die Bewertungen stammen aus dem ImkerPur-Shop und werden im AggregateRating-Schema unverändert übernommen. Sie sind Kundenbewertungen des Shops — kein Ergebnis dieses Projekts.
Architektur, strukturierte Daten, KI-Lesbarkeit und rechtliche Leitplanken — maßgeschneidert für schnelles Hosting und 0-Plugin-Betrieb.
Astro erzeugt reines HTML. Der Build landet per SFTP unter /jtlshop/lp/ und ist damit unter imkerpur.de/lp/ erreichbar. Keine Datei des Shops wird verändert, keine Datenbank berührt, kein Plugin installiert.
Eine llms.txt beschreibt Shop und Seiten für LLM-Crawler. Zusätzlich beginnt jede Seite nach dem Hero mit einem Direkt-Antwort-Block: eine präzise, ohne Kontext verständliche Antwort auf die Kernfrage der Seite. Genau dieses Format übernehmen KI-Suchen bevorzugt, weil es sich ohne Umformulierung zitieren lässt.
Die 27 FAQ-Einträge über alle fünf Seiten sind aus den Suchanfragen der Google Search Console des Shops abgeleitet — aus dem, was Menschen tatsächlich eingegeben haben. Sie sind nicht geraten und nicht von Wettbewerbern abgeschrieben.
Push auf main → GitHub Actions baut → lftp lädt per SFTP hoch. Bewusst ohne Lösch-Flag: der Workflow kann im Zielordner hinzufügen und aktualisieren, aber nichts beim Shop entfernen.
Organization Product FAQPage Die Preisspanne im AggregateOffer wird zur Build-Zeit aus den tatsächlich hinterlegten Produktpreisen berechnet — sie kann dadurch nicht von den angezeigten Preisen abweichen.
Der Kunde wünschte die Button-Optik des Shops — Orange mit weißer Schrift. Das Marken-Orange #EF8D06 trägt weiße Schrift aber nicht AA-konform. Statt den Wunsch abzulehnen oder die Regel zu ignorieren, wurde ein eigener, vertiefter Button-Ton eingeführt:
#B55E08 #3A2508 #9E5700 #FFD733 Die Werte stehen als Kommentar direkt neben den Farbvariablen im Code — nachvollziehbar für jeden, der das Projekt später übernimmt.
Über eine Redaktionsmaske bearbeitet der Inhaber die Inhalte selbst. Die Maske zeigt sprechende deutsche Feldnamen statt JSON — „Überschrift (H1)", „Vorteils-Karten", „Häufige Fragen". Technische Felder wie Shop-Links und Bilddateien sind mit einem Zahnrad-Symbol als „nicht ändern" markiert; das Anlegen und Löschen von Seiten ist gesperrt.
Wichtig für die Praxis: Der Login läuft über eine E-Mail-Einladung. Der Inhaber braucht kein GitHub-Konto und muss nichts über das darunterliegende Repository wissen — eine Hürde, an der Self-Service-Übergaben sonst regelmäßig scheitern. Der Zugang ist auf dieses eine Projekt beschränkt und jederzeit entziehbar, es entstehen keine laufenden Kosten, und nach dem Speichern ist die Änderung rund zwei Minuten später live.
Bewusst nicht freigegeben wurden Bilder und Bewertungen. Bewertungen müssen mit den echten Shop-Ratings übereinstimmen, sonst wird das Schema falsch — dieses Risiko gehört nicht in eine Redaktionsmaske. Jede Änderung ist versioniert und rücknehmbar.
Die Redaktionsmaske löst nur das Bedienproblem, nicht das Formulierungsproblem. Deshalb kam ein Custom GPT dazu, in dem die Grenzen des Lebensmittelrechts als feste Regeln hinterlegt sind: Health-Claims-Verordnung (EG) 1924/2006, § 11 LMIV und § 5 UWG — konkret ausformuliert als Liste unzulässiger Formulierungen wie „stärkt das Immunsystem" oder „entzündungshemmend". Ebenso festgeschrieben: keine erfundenen Zahlen, Zertifikate oder Auszeichnungen.
Entscheidend ist das Verhalten im Konfliktfall. Ein unzulässiger Wunsch wird nicht still abgelehnt und nicht umgesetzt, sondern kurz erklärt — und sofort durch eine zulässige, werblich trotzdem starke Alternative ersetzt. Aus „Schreib, dass der Honig das Immunsystem stärkt" wird der Hinweis auf das rechtliche Problem plus der Vorschlag: „Roh, ungefiltert und nicht über 40 °C erhitzt — so bleibt der volle Charakter erhalten."
Der interessante Teil eines Projekts steht selten im Angebot. Diese fünf Punkte haben den Ablauf tatsächlich beeinflusst:
Der Strato-Zugang landet auf „/", ausgeliefert wird aber aus „/jtlshop/". Ein Upload nach „/lp/" wäre unsichtbar geblieben. Das Deploy-Ziel ist deshalb „/jtlshop/lp/" — ermittelt vor dem ersten Upload, nicht nach dem ersten Fehlschlag.
Die .htaccess des JTL-Shops wurde vor dem ersten Upload gelesen: Der Rewrite greift nur bei nicht existierenden Dateien. Da unter /lp/ echte HTML-Dateien liegen, bleibt der Ordner unberührt — geprüft statt gehofft.
Die verbreitete FTP-Deploy-Action war unbrauchbar, weil der Strato-Host nur SFTP auf Port 22 anbietet. Der Workflow nutzt deshalb lftp — dieselbe Methode, die vorher manuell verifiziert wurde.
Der Upload läuft bewusst ohne Lösch-Flag. Der Workflow kann dadurch Dateien im Zielordner hinzufügen und aktualisieren, aber nichts im Shop entfernen — auch nicht bei einem fehlerhaften Build.
Bevor die robots.txt des Shops um die Sitemap ergänzt wurde, ist das Original versioniert abgelegt worden. Rückweg vorhanden, bevor der Hinweg gegangen wird.
Echte Messergebnisse aus Google PageSpeed Insights — sauber getrennt zwischen Labor- und Felddaten.
PageSpeed Insights, Modus Mobil, für eine ausgelieferte Landingpage unter imkerpur.de/lp/, gemessen im Juli 2026. Mobil ist der strengere der beiden Messmodi. Die 100 bei Barrierefreiheit ist das Ergebnis der oben beschriebenen Kontrast-Nachrechnung — sie kam nicht von selbst.
Die Google-Search-Console meldet für imkerpur.de „Core Web Vitals: Failed". Dieser Wert stammt aus CrUX-Felddaten der gesamten Domain über 28 Tage und wird vom JTL-Shop dominiert (TTFB rund 2,8 Sekunden). Er beschreibt nicht die statischen Landingpages, deren Laborwerte oben stehen.
Wir könnten hier bequem nur die vier Hundertwerte zeigen. Wir zeigen beides, weil die Unterscheidung zwischen Labor- und Felddaten für die Bewertung entscheidend ist — und weil ein Kunde, der später selbst in die Search Console schaut, sonst zu Recht irritiert wäre. Ein perfekter Laborwert bedeutet nicht, dass die Domain insgesamt schnell ist; er bedeutet, dass der ausgelieferte Teil es ist.
Es stehen auf dieser Seite keine Angaben zu Traffic-Zuwachs, Ranking-Verbesserungen, Conversion-Rate oder Umsatz. Der Grund ist schlicht: Diese Werte wurden nicht erhoben, und die Seiten sind zum Zeitpunkt dieser Case Study wenige Wochen alt — für belastbare SEO-Aussagen ein zu kurzer Zeitraum. Sobald verwertbare Daten vorliegen und der Kunde ihrer Veröffentlichung zustimmt, wird diese Case Study ergänzt. Erfundene Zahlen wären einfacher und wären wertlos.
Das Vorgehen ist nicht an Honig gebunden und nicht an JTL. Gebraucht werden eine eigene Domain, ein Webspace-Zugang und Produktgruppen, zu denen Menschen Fragen stellen.
Pragma-Code Support (AI) • Online