JTL-Shop SEO: Was das System kann und wo du nachhelfen musst

JTL-Shop ist speziell im deutschsprachigen Mittelstand eines der am häufigsten eingesetzten Shop-Systeme, meist gekoppelt an JTL-Wawi als Warenwirtschaft im Hintergrund. Genau diese Kopplung erzeugt eine SEO-Logik, die sich von reinen SaaS-Shopsystemen unterscheidet: Ein großer Teil der SEO-relevanten Felder – Meta-Titel, Kurzbeschreibung, Attribute – wird nicht im Shop selbst gepflegt, sondern in der Wawi, und dann synchronisiert. Wer nur im Shop-Backend schraubt und die Wawi-Seite ignoriert, wundert sich früher oder später, warum eine sorgfältig formulierte Meta-Beschreibung beim nächsten Abgleich plötzlich wieder verschwunden ist.

Dieser Beitrag konzentriert sich auf die Punkte, die bei JTL-Shop anders laufen als bei den meisten anderen Systemen: die SEO-Pfad-Einstellungen und ihre Fallstricke, die beiden größten Duplicate-Content-Quellen durch Varianten und Filter, den Datenfluss aus der Wawi in die Meta-Angaben – und die Frage, welche Art von Plugin du überhaupt brauchst, bevor du eines installierst.

URL-Pfade in JTL-Shop: wo du wirklich Kontrolle hast

Jede Kategorie, jeder Artikel, jeder Hersteller und jedes Merkmal hat in JTL-Shop einen eigenen Reiter „SEO“ mit einem Feld für den URL-Pfad – unabhängig von der internen, numerischen Artikel- oder Kategorie-ID. Lässt du das Feld leer, erzeugt der Shop den Pfad automatisch aus dem Namen: Umlaute werden transliteriert, Sonderzeichen entfernt. Das funktioniert im Alltag meist zuverlässig, führt aber bei Produktnamen aus der Wawi, die Größen- oder Farbangaben enthalten, schnell zu langen, wenig sprechenden Pfaden.

Wichtiger als die Automatik ist die globale Einstellung, ob der Kategoriepfad im Artikel-Link enthalten sein soll oder nicht. Diese Entscheidung solltest du früh treffen, denn sie bestimmt die URL-Struktur für den gesamten Katalog – ein nachträglicher Wechsel bedeutet bei einem synchronisierten Wawi-Katalog mit mehreren Tausend Artikeln praktisch immer eine großflächige Weiterleitungsaktion, nicht ein einzelnes Setting, das sich mal eben umschalten lässt.

Ein Sonderfall sind Hersteller- und Merkmal-Seiten, die JTL-Shop ebenfalls automatisch aus den Wawi-Stammdaten erzeugt. Sie tauchen im SEO-Alltag seltener auf als Kategorie- und Artikelseiten, sind aber oft die Seiten mit der dünnsten eigenen Textbasis – ein Hersteller-Filterergebnis ohne eigene Einleitung ist im Kern nur eine Kategorieliste mit einem anderen Titel. Willst du für einzelne, verkaufsstarke Hersteller eine eigene Landingpage, lohnt es sich, dort händisch einen kurzen Einleitungstext zu ergänzen, statt die automatisch erzeugte Seite unverändert zu lassen.

Für die interne Verlinkung nutzt JTL-Shop standardmäßig den Kategoriebaum als Breadcrumb auf Artikel- und Kategorieseiten, inklusive der zugehörigen strukturierten Daten. Das funktioniert zuverlässig, solange die Kategoriestruktur selbst sauber ist – verschachtelst du Artikel jedoch in mehreren Kategorien gleichzeitig, zeigt die Breadcrumb je nach Aufrufkontext einen anderen Pfad, und die interne Verlinkung verteilt sich über mehrere Wege zur gleichen Seite, statt sich auf einen klaren Pfad zu konzentrieren.

• Ändere einen bestehenden URL-Pfad nicht einfach so – er wird nicht automatisch weitergeleitet.
• Trage die alte auf die neue Adresse manuell unter Administration > SEO > Weiterleitungen ein, sonst entsteht ein 404 und die bisherigen Signale der Seite gehen verloren.
• Prüfe bei Sammelimporten aus der Wawi, ob transliterierte Umlaute (ü zu ue) im gesamten Katalog konsistent gehandhabt werden – Brüche entstehen oft erst nach einem Wawi-Update oder einem Vorlagenwechsel.

Varianten und Filter: die zwei größten Duplicate-Content-Quellen

JTL-Shop unterscheidet zwischen Vaterartikeln und Kindartikeln für Varianten wie Farbe oder Größe. Wie diese Struktur nach außen dargestellt wird, ist eine Konfigurationsentscheidung mit direkter SEO-Wirkung: Entweder bekommt jeder Kindartikel eine eigene, eigenständig crawlbare Seite, oder alle Varianten werden über ein Auswahlfeld auf der Seite des Vaterartikels zusammengeführt. Die zweite Variante ist für die meisten Kataloge die bessere Wahl, weil sie verhindert, dass fünf fast identische Produktseiten – ein Modell in fünf Farben – um dieselbe Suchanfrage konkurrieren und sich dabei gegenseitig die Relevanz-Signale wegnehmen.

Existieren in deinem Shop historisch bereits Kindartikel als eigene Seiten und haben einzelne davon Backlinks oder eigenen organischen Traffic, ist ein pauschales Zusammenlegen keine gute Idee. Prüfe zuerst in der Search Console, welche der Varianten-URLs tatsächlich rankt, und entscheide dann von Fall zu Fall, ob eine 301-Weiterleitung auf den Vaterartikel oder ein Canonical-Tag auf die Vaterartikel-Seite der richtige Weg ist. Ein Canonical ist die vorsichtigere Option, wenn die Kindartikel-Seite trotzdem separat aufrufbar bleiben soll, etwa weil Kunden einen bestimmten Farb-Link bereits geteilt haben.

Die zweite Quelle ist die Filternavigation über Merkmale, Preis und Hersteller. Je nachdem, wie das Template die Filterung technisch umsetzt, erzeugt jede Kombination von Filtern eine eigene, potenziell crawlbare URL – und die Zahl möglicher Kombinationen wächst mit jedem zusätzlichen Merkmal multiplikativ. Ohne bewusste Steuerung crawlen Suchmaschinen dann viele Kombinationen, die inhaltlich nichts anderes zeigen als eine leicht gefilterte Version derselben Kategorieliste, und verbrauchen dabei Crawling-Kapazität, die besser in echte Produkt- und Kategorieseiten fließen würde.

• Lege eine Regel fest: Filterkombinationen sind standardmäßig noindex,follow oder über ein robots.txt-Muster gesperrt.
• Definiere gezielt Ausnahmen für einzelne, werthaltige Kombinationen, die du bewusst als eigene Landingpage ranken lassen willst, zum Beispiel eine Marke innerhalb einer Kategorie.
• Der Live-Filter (per AJAX, ohne URL-Änderung) ist für alle Kombinationen sinnvoll, die du bewusst nicht indexieren willst – das ist keine Notlösung, sondern die gewünschte Abkürzung um das Problem herum.

Der Datenfluss aus JTL-Wawi: wer die Meta-Angaben wirklich besitzt

Meta-Titel, Meta-Beschreibung, Kurz- und Langbeschreibung sowie die Attribute eines Artikels werden in JTL-Wawi angelegt und über die Synchronisation an den Shop übergeben. In den meisten Installationen ist die Wawi die führende Quelle für diese Felder – wer eine Meta-Beschreibung direkt im Shop-Backend überarbeitet, riskiert also, dass genau diese Änderung beim nächsten Abgleich wieder mit dem alten Wawi-Stand überschrieben wird, ohne dass irgendetwas im Shop selbst darauf hinweist.

Die praktische Konsequenz: Lege für jedes SEO-relevante Feld einmal fest, wo es tatsächlich gepflegt wird, und halte dich – und dein Team – daran. Produktname und technische Attribute gehören meist in die Wawi, weil sie Stammdaten sind. Bei der Meta-Beschreibung ist das weniger eindeutig; manche Teams pflegen sie bewusst nur im Shop, weil dort die Vorschau des Suchergebnisses direkt sichtbar ist. Entscheidend ist nicht, welche Variante du wählst, sondern dass die Entscheidung dokumentiert ist – besonders wenn eine Agentur oder ein Kollege ebenfalls Wawi-Zugriff hat und ahnungslos die andere Seite bearbeitet.

Ein zweites, sehr konkretes Problem: Die Eingabefelder in der Wawi erzwingen keine Zeichenbegrenzung. Bei Sammelimporten aus Lieferanten-Feeds landet häufig der komplette Hersteller-Fließtext unverändert im Meta-Beschreibungsfeld – deutlich länger als die praktisch sichtbaren rund 155 Zeichen im Suchergebnis, was zu einer von Google gekürzten, oft mitten im Satz abgeschnittenen Vorschau führt.

Damit eng verwandt ist ein Problem, das an der eigenen Sorgfalt vorbeigeht: Nutzen mehrere JTL-Shop-Betreiber dieselben Lieferanten-Feeds und übernehmen die mitgelieferten Herstellertexte unverändert aus der Wawi in den Shop, entsteht Text, der auf vielen unabhängigen Shops nahezu identisch ist. Das lässt sich nicht durch bessere SEO-Einstellungen im Shop selbst lösen, sondern nur durch eine eigene Überarbeitung der übernommenen Beschreibungstexte, zumindest für die Artikel, die tatsächlich Umsatz bringen sollen. Das alte Meta-Keywords-Feld in der Wawi kannst du dabei ignorieren; es wird von keiner relevanten Suchmaschine mehr ausgewertet, und die Zeit, es zu pflegen, ist an anderer Stelle besser investiert.

Bilder und Alt-Texte: ein oft übersehener Teil der Wawi-Synchronisation

Produktbilder werden in JTL-Wawi hochgeladen und über die Synchronisation an den Shop übergeben – inklusive Dateiname und, falls gepflegt, Alt-Text. In der Praxis kommen viele Bilder direkt aus Lieferanten- oder Herstellerportalen mit generischen Dateinamen wie img_2481.jpg oder produktbild_01.jpg, die unverändert in den Shop übernommen werden. Ein Dateiname ohne Bezug zum Produkt und ein leeres Alt-Attribut sind für die Bildersuche eine verschenkte Chance, auch wenn sie für das Produkt selbst keine harte SEO-Bremse sind.

Der pragmatische Ansatz ist nicht, jedes einzelne Bild händisch umzubenennen, sondern eine Regel für neue Artikel festzulegen: Haupt- und Variantenbilder bekommen beim Import einen sprechenden Dateinamen und ein kurzes, konkretes Alt-Attribut, das die Wawi mitsynchronisiert. Für den Bestand an bereits importierten Artikeln lohnt sich eine Priorisierung nach Umsatz oder Traffic, statt den gesamten Katalog auf einmal zu überarbeiten – der Aufwand steigt linear mit der Artikelzahl, der Nutzen aber nicht.

• Prüfe stichprobenhaft, ob Alt-Texte tatsächlich synchronisiert werden oder ob dein Template ein leeres Attribut ausgibt, selbst wenn in der Wawi ein Text hinterlegt ist.
• Bei Variantenbildern (Farbe, Ansicht) sollte der Alt-Text die jeweilige Variante benennen, nicht bei jedem Bild denselben Produktnamen wiederholen.

Cache, Sitemap und ausgelaufene Artikel: wann eine Änderung wirklich sichtbar wird

JTL-Shop kompiliert Smarty-Templates und hält je nach Konfiguration zusätzlich einen Objekt-Cache für Kategorie- und Artikeldaten vor. Nach einem größeren Wawi-Abgleich oder einer Anpassung der SEO-Einstellungen kann es deshalb passieren, dass eine Änderung im Backend zwar gespeichert ist, im Frontend aber noch nicht sichtbar wird. Wer in diesem Moment prüft, ob die Änderung „funktioniert hat“, bekommt ein falsches Ergebnis – nicht weil die Einstellung falsch ist, sondern weil der Cache noch die alte Version ausliefert. Bei größeren SEO-Umstellungen lohnt es sich, den relevanten Cache gezielt zu leeren, statt zu warten und zu hoffen.

Die integrierte XML-Sitemap wird automatisch unter einem festen Pfad erzeugt und lässt sich direkt in der Google Search Console einreichen. Nach größeren Strukturänderungen – etwa einer Umstellung der URL-Pfade oder einer Bereinigung der Kategorien – solltest du die Sitemap erneut prüfen, damit sie tatsächlich die aktuelle Struktur widerspiegelt und nicht noch alte Pfade enthält, die längst durch neue ersetzt wurden.

Ausgelaufene und ausverkaufte Artikel sind in einem Wawi-gesteuerten Katalog ein Dauerthema, weil Artikel dort regelmäßig regulär aus dem Sortiment fallen. JTL unterscheidet zwischen vorübergehend nicht lieferbaren Artikeln und Artikeln, die komplett aus der Wawi entfernt wurden (EOL). Für Letztere solltest du dir bewusst eine Regel überlegen, statt es dem Zufall zu überlassen: eine harte 404- oder 410-Antwort, eine Weiterleitung auf die passende Kategorie, oder eine bewusst gestaltete Alternativseite mit Empfehlungen. Was du vermeiden willst, ist der Zustand, in dem Hunderte tote Artikel-URLs mit einer generischen „Nicht mehr verfügbar“-Meldung weiter im Index stehen, ohne für Nutzer oder Crawler einen sinnvollen nächsten Schritt anzubieten.

• Nutze den Menüpunkt zum Leeren des Caches im Backend gezielt nach SEO-relevanten Änderungen, statt auf den nächsten automatischen Ablauf zu warten.
• Unterscheide zwischen Template-Cache und Objekt-Cache, wenn eine Änderung nach dem Leeren eines der beiden immer noch nicht sichtbar ist – oft muss der jeweils andere ebenfalls geleert werden.

Plugins: welche Kategorie du tatsächlich brauchst

Bevor du im JTL-Extension-Store nach einem SEO-Plugin suchst, lohnt sich die Frage, welche Kategorie von Problem du eigentlich lösen willst – die meisten Anfragen fallen in eine von vier Gruppen. Erstens: strukturierte Daten. Viele aktuelle Templates liefern bereits vollständiges Product- und Offer-Schema mit; ob das bei deinem Template und deiner Version tatsächlich der Fall ist, prüfst du am schnellsten mit Googles Rich-Results-Test an einer echten Produktseite, bevor du ein zusätzliches Plugin installierst, das im schlimmsten Fall ein zweites, konkurrierendes JSON-LD-Objekt auf derselben Seite erzeugt.

Zweitens: Weiterleitungs-Management über die einfache Eins-zu-eins-Verwaltung hinaus, etwa für Bulk-Umzüge ganzer Kategoriebäume. Drittens: hreflang-Automatisierung, die vor allem dann relevant wird, wenn du mit mehreren Mandanten arbeitest. Viertens: erweiterte Sitemap-Generierung für Kataloge, die über die praktischen Grenzen des mitgelieferten Generators hinauswachsen.

• Prüfe vor der Installation das Datum der letzten Aktualisierung und die angegebene Kompatibilität mit deiner JTL-Shop-Version.
• Teste jedes Plugin, das in Routing oder Template-Rendering eingreift, zuerst auf einer Staging-Instanz – genau diese Plugins können bestehende URL-Pfade oder Canonical-Einstellungen unbeabsichtigt überschreiben.
• Installiere kein zweites Plugin für eine Funktion, die dein aktives Template bereits abdeckt, nur weil eine Anleitung im Internet es empfiehlt.

Mehrsprachigkeit und mehrere Mandanten

Innerhalb eines einzelnen JTL-Shops mit mehreren aktivierten Sprachen erzeugt das System die hreflang-Auszeichnung automatisch, sobald jede Sprache tatsächlich eigenständig übersetzten Text enthält – nicht nur eine umgeschaltete Sprachflagge über unverändertem deutschen Text. Anders sieht es bei mehreren getrennten Mandanten aus, wie sie in vielen JTL-Wawi-Konfigurationen für unterschiedliche Länder oder Preismodelle genutzt werden: Jeder Mandant läuft als eigenständige Shop-Installation mit eigener Domain, und diese Installationen wissen im Kern nichts voneinander. Eine hreflang-Verknüpfung zwischen ihnen entsteht nicht automatisch, sondern muss manuell oder über ein zusätzliches Plugin ergänzt werden.

Auch innerhalb einer einzelnen Installation wirkt sich die Sprachkonfiguration auf die URL-Struktur aus: JTL-Shop kann Sprachen über ein Pfadsegment, eine Subdomain oder getrennte Domains abbilden, je nachdem, wie das Setup aufgesetzt wurde. Diese Entscheidung solltest du wie die Kategoriepfad-Frage früh und endgültig treffen, denn ein späterer Wechsel des Sprach-Schemas verändert die URLs sämtlicher übersetzten Seiten gleichzeitig – mit entsprechend großem Weiterleitungsaufwand.

Ein verwandtes Problem entsteht, wenn dieselben Wawi-Artikeldaten nahezu unverändert in zwei Mandanten landen, etwa auf einer .de- und einer .at-Domain mit fast identischen Texten. Auch wenn es sich technisch um dasselbe Produkt handelt, konkurrieren zwei Domains dann um dieselbe Suchanfrage mit fast identischem Inhalt. Eine korrekte hreflang-Verknüpfung entschärft dieses Problem für Suchmaschinen, die den richtigen Markt zuordnen sollen, ersetzt aber nicht die Prüfung, ob die Inhalte pro Markt tatsächlich eigenständig genug sind.