JTL-Shop-Template anpassen: NOVA-Child statt Core-Änderung

Anpassungen am JTL-Shop-Template gehören in ein Child-Template mit NOVA als Parent, niemals in die ausgelieferten Dateien. JTL stellt dafür die Vorlage NOVAChild bereit. Die häufigste Fehlerquelle ist die Namenskonvention: Ordnername, Name in der template.xml und Namespace in der Bootstrap.php müssen identisch sein. Und: NOVA liefert strukturierte Daten nur als Microdata aus.

Stand dieses Beitrags: 7. September 2026. Alle Messwerte stammen aus dem offiziellen Komplettpaket JTL-Shop 5.8.0, das wir an diesem Tag vom JTL-Build-Server geladen und entpackt haben. Die Versionskonstante im Paket lautet 5.8.0; höhere Builds wie 5.8.1 oder 5.9.0 beantwortete der Build-Server am selben Tag mit einem Serverfehler, existierten also nicht. Wenn Sie diesen Beitrag später lesen, prüfen Sie zuerst diesen Absatz — die Version ist die einzige Angabe, an der alle Zahlen hängen.

1. Template, Theme, Child: drei Begriffe sauber trennen

Die meisten Missverständnisse beim Thema Shop-Design entstehen an der Sprache, nicht an der Technik. Die JTL-Entwicklerdokumentation stellt das gleich zu Beginn klar: Das Template ist nicht mit dem Theme zu verwechseln — das Theme ist ein Teil des Templates. Wer beide Begriffe vermischt, sucht Farbeinstellungen in Dateien und Strukturänderungen im Backend.

Praktisch heißt das: Für Farben, Schriften und das Logo brauchen Sie kein Child-Template. Das erledigen die Template-Einstellungen im Backend und das Plugin JTL Theme-Editor, mit dem sich die mitgelieferten Themes anpassen lassen. Erst wenn Sie an der Struktur etwas ändern wollen — eine Zeile in der Kopfleiste, ein zusätzlicher Block auf der Artikelseite, ein eigenes Skript — beginnt die Arbeit am Template. Genau dort setzt dieser Beitrag an. Welche Erweiterungen Ihnen die Arbeit ganz abnehmen können, haben wir in der Übersicht zu den JTL-Shop-Plugins zusammengestellt; hier geht es um den Weg über eigenen Code.

2. Das Child-Template aufsetzen

Ein Child-Template ist ein eigener Ordner unter templates/, der NOVA als Elterntemplate benennt. Der Shop lädt dann alle Dateien von NOVA — außer denen, die Sie in Ihrem Ordner an derselben Stelle hinterlegt haben. Diese eine Regel trägt das gesamte Konzept: In Ihrem Child liegen nur die Dateien, die Sie tatsächlich geändert haben. Eine vollständige Kopie von NOVA ist ausdrücklich nicht erforderlich und wäre der sicherste Weg, sich das nächste Update zu verbauen.

Sie müssen dafür nicht bei null anfangen. JTL stellt auf seinem Build-Server eine Vorlage namens NOVAChild bereit. Wir haben sie am 7. September 2026 geladen und entpackt: Das Archiv ist rund 320 Kilobyte groß und enthält genau die Dateien, die ein Child-Template mindestens braucht.

1. template.xml — die Kennkarte des Templates. Hier stehen Name, Version, die Mindest-Shopversion und vor allem der Parent-Eintrag, der NOVA als Elterntemplate bestimmt.
2. Bootstrap.php — die PHP-Klasse des Templates. Sie erweitert die Bootstrap-Klasse von NOVA und ruft in beiden Methoden die Elternversion mit auf. Ihre Namespace-Zeile ist die Stelle, an der die meisten Umbenennungen scheitern.
3. themes/my-nova/ — der eigene Theme-Ordner mit den kompilierten CSS-Dateien und den SASS-Quellen. Die Variablen-Datei importiert die Variablen des gewählten NOVA-Themes und lässt sich darüber gezielt überschreiben.
4. themes/my-nova/custom.css — die Datei für schnelles eigenes CSS. Sie wird als letzte geladen und überschreibt deshalb andere Regeln.
5. js/custom.js — eine leere Datei für eigenes JavaScript, die Sie über die Minify-Definition in der template.xml einbinden.
6. preview.png und favicon/ — Vorschaubild für die Template-Übersicht im Backend sowie ein Standard-Favicon.

Der entscheidende Eintrag steckt in der template.xml. Dort steht <Parent>NOVA</Parent> — und dieser Wert ist kein freier Text, sondern der Ordnername des Elterntemplates. Die mitgelieferte Vorlage weist sich als Version 5.8.0 aus und verlangt mindestens Shop 5.5.0. Aktiviert wird sie wie jedes Template im Backend unter Darstellung, Einstellungen, Templates. Danach lohnt ein Blick in den Cache: Nach einem Template- oder Themewechsel empfiehlt die Dokumentation ausdrücklich, den Template-Zwischenspeicher zu leeren.

Ein Detail, das beim Lesen der Vorlage auffällt und Sie nicht irritieren sollte: Die beiliegende README trägt noch die Überschrift „NOVA-Child-Vorlage für Shop 5.0", während die template.xml daneben Version 5.8.0 ausweist. Sie verweist außerdem auf eine SASS-Datei namens nova-child.scss, die es im Paket nicht gibt — dort heißt die Datei my-nova.scss. Die Vorlage funktioniert; nur ihre Begleittexte sind mitgealtert.

3. Die Namenskonvention: drei Stellen, ein Name

Hier scheitern die meisten ersten Versuche, und zwar reproduzierbar. Die Vorlage heißt NOVAChild — und viele benennen sie sofort in etwas Eigenes um. Das ist erlaubt, aber es sind drei Stellen, nicht eine. Die Entwicklerdokumentation formuliert die Regel klar. Seit JTL-Shop 5.0.0 gilt für alle Templates: Der in der template.xml definierte Name muss dem Ordnernamen entsprechen. Zusätzlich lädt ein Autoloader alle PHP-Dateien im Hauptverzeichnis. Deren Namespace muss deshalb immer dem Schema Template\<template-name> folgen.

Die README der offiziellen Vorlage sagt dasselbe noch deutlicher: Eine Änderung des Verzeichnisnamens sei nur möglich, wenn dazu auch die Namespace-Zeile in der Bootstrap.php angepasst werde — und sie nennt sogar die Zeilennummer. Wer den Ordner umbenennt und die anderen beiden Stellen vergisst, bekommt keinen sprechenden Fehler, sondern einen Autoloader, der eine Klasse nicht findet. Dazu kommt eine zweite Regel, die gern übersehen wird: Der Name darf keine Sonderzeichen enthalten, weil alle Klassennamen seit Shop 5 der PSR-4-Spezifikation folgen müssen. Umlaute, Leerzeichen und Bindestriche im Templatenamen sind also keine Geschmacksfrage.

Unser praktischer Rat aus Projekten: Behalten Sie den Namen NOVAChild, wenn Sie nur ein Child-Template betreiben. Der Aufwand des Umbenennens hat keinen technischen Gegenwert, und die Fehlerquelle verschwindet ersatzlos. Erst wenn Sie mehrere Shops mit unterschiedlichen Kindern derselben Installation fahren, brauchen Sie sprechende Namen — und dann ändern Sie eben alle drei Stellen in einem Zug.

4. Smarty-Blöcke: ersetzen, anhängen, voranstellen

Template-Dateien mit der Endung .tpl sollten Sie laut Dokumentation nicht direkt ändern, weil der Shop sonst seine Updatefähigkeit verliert. Der vorgesehene Weg sind Smarty-Blöcke: benannte Stellen im Template-Code, die ein Child-Template überschreiben oder ergänzen darf. Wie viele davon zur Verfügung stehen, haben wir ausgezählt — die Zahl ist der eigentliche Grund, warum der Weg über das Child-Template praktikabel ist: NOVA 1.8.0 definiert 2.212 Blockanfänge mit 2.177 verschiedenen Namen, verteilt auf 227 der 229 Template-Dateien.

Um einen Block zu ändern, legen Sie die betreffende Datei in Ihrem Child-Template an derselben relativen Position an. Die Ordnerstruktur des Childs muss der des Parents entsprechen: Aus templates/NOVA/layout/header.tpl wird also templates/NOVAChild/layout/header.tpl. In diese Datei schreiben Sie ausschließlich den Block, den Sie anfassen wollen — nicht den restlichen Inhalt der Originaldatei. Dafür kennt Smarty drei Modi.

Für eigenes JavaScript gilt eine eigene Regel. Die Dokumentation verlangt, zusätzliche Skripte im Block layout-footer-js der footer.tpl zu laden und dabei das Attribut async zu setzen, damit der Seitenaufbau nicht ausgebremst wird. Wollen Sie eine Skriptdatei des Elterntemplates komplett ersetzen, tragen Sie in der template.xml am Datei-Eintrag override="true" ein — ohne dieses Attribut wird Ihre Datei zusätzlich eingebunden, nicht anstelle der Originaldatei. Der Name des gebündelten Skripts selbst ist übrigens eine feste Konstante und darf nicht geändert werden.

Eine ganze .tpl-Datei zu ersetzen ist möglich, aber die Dokumentation warnt davor: Nach jedem Shop-Update müssen Sie dann sicherstellen, dass die modifizierte Datei noch korrekt funktioniert. Warum das mehr als eine Floskel ist, zeigt Abschnitt 6.

5. Die Smarty-Falle in Shop 5.8

Jetzt der Punkt, den keiner der Ratgeber auf der ersten Suchergebnisseite erwähnt — und der darüber entscheidet, gegen welche Engine Sie eigentlich testen. JTL-Shop 5.8.0 liefert Smarty 5 aus und arbeitet trotzdem im Smarty-4-Modus.

Beides lässt sich im Paket nachlesen. Die composer.json fordert smarty/smarty in der Version 5.7, die composer.lock weist die installierte Version 5.7.0 aus. Zwei Zeilen weiter in includes/defines.php steht aber der Standardwert: SMARTY_LEGACY_MODE ist auf true gesetzt. In der Klasse, die Smarty im Shop hochfährt, wird diese Konstante 33-mal ausgewertet.

Die Entwicklerdokumentation erklärt den Hintergrund: Mit Shop 5.6.0 wurde die Template-Engine auf Smarty 5.4 aktualisiert, was umfangreiche Umbauten am Shop-Kern nach sich zog. Damit der Umstieg gefahrlos bleibt, führte JTL die Konstante ein — mit dem Standardwert true, der dafür sorgt, dass intern weiterhin Smarty 4 genutzt wird. Umschalten können Sie mit const SMARTY_LEGACY_MODE = false; in der Konfigurationsdatei des Shops.

Was das für Ihr Child-Template bedeutet: Solange die Konstante auf true steht, läuft Ihr Template gegen Smarty 4. Ein Test mit false auf einem Testsystem zeigt Ihnen früh, was später bricht. JTL nennt dafür zwei häufige Anpassungen. Erstens sind in PHP definierte Funktionen in Templates nur noch nach Registrierung nutzbar; welche nativen Funktionen der Shop-Kern bereits registriert, legt eine eigene Konstante fest. Zweitens gilt der Modifikator implode als veraltet und soll durch join ersetzt werden. Für Plugins gibt die Dokumentation Entwarnung: Sie sollten weiterhin wie bisher funktionieren, mit demselben Vorbehalt.

Der praktische Rat: Suchen Sie in Ihren Child-Dateien einmal nach implode und nach Aufrufen von PHP-Funktionen direkt im Template. Das sind zwei Suchvorgänge, und sie ersparen Ihnen später eine Fehlersuche unter Zeitdruck.

6. Was ein Shop-Update mit Ihrem Template macht

Die beruhigende Hälfte der Antwort steht in der Dokumentation: Bei einem Update werden die Dateien Ihres Child-Templates nicht überschrieben, Sie müssen Ihre Änderungen also nicht erneut vornehmen. Die unbequeme Hälfte steht direkt daneben — Sie sollten nach einem Update trotzdem prüfen, ob Ihre Änderungen noch korrekt funktionieren.

Diese zweite Hälfte lässt sich messen statt beschwören, denn JTL veröffentlicht zu jedem Release einen Template-Diff: eine Datei, die alle Unterschiede des NOVA-Templates zur Vorgängerversion enthält. Der Link steht im Releasepost, gleich unter dem Download des Komplettpakets. Wir haben den Diff für den Sprung von 5.7.3 auf 5.8.0 geladen — knapp drei Megabyte — und ausgezählt: 70 Pfade wurden geändert, davon 32 Template-Dateien. Darunter sind die Artikeldetailseite, die Preisdarstellung, die Artikelkachel der Listen, das Mega-Menü — und die Kopfzeilen-Datei layout/header.tpl.

Genau daran hängt die praktische Konsequenz. Wenn Sie einzelne Blöcke überschrieben haben, überstehen die meisten Änderungen ein Update unbemerkt, weil der Blockname stabil bleibt und JTL innerhalb des Blocks arbeitet. Wenn Sie dagegen eine ganze Datei kopiert haben — und header.tpl ist die mit Abstand beliebteste Kandidatin dafür —, dann friert Ihre Kopie den Stand von 5.7.3 ein. Sicherheitsrelevante Korrekturen, neue Meta-Angaben und geänderte Auszeichnungen kommen bei Ihnen nicht an, ohne dass irgendetwas kaputtgeht. Das ist der unangenehmste Fehlermodus überhaupt: einer, der nicht auffällt.

Ein Blick auf das Release 5.8.0 macht das konkret. Der Post vom 26. August 2026 weist es ausdrücklich als Update mit einem kritischen Sicherheitsfix aus — einer Cross-Site-Scripting-Lücke in zwei Funktionen des Admin-Backends, gemeldet von einem externen Sicherheitsforscher. Dazu kamen ein EU-Gewährleistungs- und Garantie-Label im Shop, eine verbesserte Sortierung nach Bruttopreis, ein Admin-Werkzeug zum Löschen historischer Daten und eine schnellere Besucherstatistik. Wer sein Template pflegt, arbeitet den Diff nach jedem Update einmal durch. Wer es nicht tut, merkt es erst, wenn ein Kunde eine Darstellung meldet, die es seit zwei Versionen nicht mehr gibt.

7. Der Befund: Microdata statt JSON-LD

Damit zum zweiten Thema dieses Beitrags — und es gehört hierher, weil es nur im Template lösbar ist. Wir haben alle Template-Dateien von NOVA 5.8.0 nach strukturierten Daten durchsucht. Das Ergebnis in einem Satz: In allen 229 Dateien mit der Endung .tpl steht kein einziger Block mit application/ld+json.

Damit dieser Negativbefund belastbar ist, haben wir den Suchvorgang an einem Positivfall geprüft. Nach dem Microdata-Attribut itemprop finden sich Treffer in 25 Dateien. Die Auszeichnung nach schema.org kommt in 19 verschiedenen Typen vor: Product, Offer, UnitPriceSpecification, AggregateRating, Review, Rating, Brand, BreadcrumbList, ListItem, Organization, ItemList, ItemPage, CollectionPage, WebPage, Blog, BlogPosting, Comment, Person und QuantitativeValue. Die Suche funktioniert also; die Null ist echt. Zur Gegenprobe lief dieselbe Suche über das gesamte Paket, PHP-Kern eingeschlossen. Die einzigen Treffer liegen in zwei Bibliotheks-Tabellen für Dateitypen und haben mit der Ausgabe des Shops nichts zu tun.

Die Auszeichnung beginnt dabei ganz oben. NOVA setzt das itemtype-Attribut bereits auf das html-Element und wechselt es je nach Seitentyp zwischen ItemPage für Artikelseiten, CollectionPage für Kategorien und WebPage für alles Übrige. Der Rest verteilt sich über die Artikeldetailseite, die Listen, die Breadcrumb und den Blog.

Und jetzt die wichtige Einordnung, damit daraus kein falscher Alarm wird. Microdata ist gültiges Markup. Google nennt in seinen Richtlinien für strukturierte Daten ausdrücklich drei unterstützte Formate: JSON-LD, das als empfohlenes gekennzeichnet ist, sowie Microdata und RDFa. NOVA macht also nichts falsch. Der Punkt ist ein anderer: Google empfiehlt JSON-LD, weil es sich am leichtesten umsetzen und im großen Maßstab pflegen lässt — und weil es unabhängig vom sichtbaren Markup steht. Wer Auszeichnungen über den mitgelieferten Umfang hinaus braucht, etwa eine FAQ-Auszeichnung auf einer Kategorieseite oder ein Organisationsprofil mit Verweisen auf die eigenen Profile, muss ohnehin ergänzen. Und für diese Ergänzung ist JSON-LD der einfachere Weg, weil Sie es an einer Stelle einhängen, statt es durch das gesamte Markup zu fädeln. Wie das auf einer Plattform aussieht, die JSON-LD im Standard mitliefert, zeigt der Vergleich mit Shopify SEO.

8. Was Rich Results sind — und was sie nicht sind

An dieser Stelle wird in Agenturangeboten regelmäßig zu viel versprochen, deshalb der nüchterne Teil. Strukturierte Daten sind kein Rankingfaktor. Das ist keine Meinung, sondern von Google dokumentiert. In den Richtlinien zu strukturierten Daten steht zur manuellen Maßnahme gegen fehlerhaftes Markup wörtlich: Eine Seite verliere dadurch die Eignung für die Darstellung als Rich Result. Auf die Position in der Websuche wirke sich das nicht aus.

Dieselbe Dokumentation dämpft auch die zweite verbreitete Erwartung. Strukturierte Daten ermöglichen eine Darstellungsform, sie garantieren sie nicht; und Google sichert ausdrücklich nicht zu, dass Ihr Markup in den Suchergebnissen erscheint, selbst wenn die Seite korrekt ausgezeichnet ist.

Was bleibt, ist trotzdem viel — nur eben etwas anderes, als der Verkaufsprospekt suggeriert. Korrekte Auszeichnung macht Ihre Seite für erweiterte Darstellungen überhaupt erst infrage kommen: Sterne, Preise, Verfügbarkeit, Breadcrumb-Pfade. Und sie liefert Sprachmodellen und Antwortmaschinen eine maschinenlesbare Fassung dessen, was auf der Seite steht — der Grund, warum wir strukturierte Daten in unserer SEO-Systematik als Grundlagenarbeit führen und nicht als Wachstumshebel. Eine Regel gilt dabei unbedingt: Markup bildet ab, was sichtbar auf der Seite steht. Eine ausgezeichnete Bewertung ohne sichtbare Bewertung ist kein Optimierungstrick, sondern ein Verstoß gegen die Richtlinien — und der kostet die Eignung wieder.

9. Wo JSON-LD im Child-Template hingehört

Wenn Sie ergänzen wollen, brauchen Sie eine Stelle im Kopfbereich, die ein Update übersteht. NOVA hat sie — und sie ist bemerkenswert leicht zu übersehen. Im Kopfbereich der header.tpl steht ein Block namens layout-header-head-base, der vollständig leer ist. In ganz NOVA gibt es nur zwei solcher leeren Blockdefinitionen; diese hier liegt genau dort, wo strukturierte Daten hingehören. Für ein Child-Template ist das der natürliche Einhängepunkt: Sie legen die Datei an derselben Stelle an, überschreiben ausschließlich diesen Block und geben darin Ihr Skript aus. Der Rest des Kopfbereichs bleibt in JTLs Hand und wird mit jedem Update mitgepflegt.

Zwei Dinge sollten Sie dabei wissen. Erstens ist der Canonical-Link in NOVA nicht in einen eigenen Block gefasst — er steht als bedingte Ausgabe zwischen zwei Blöcken. Wer die Canonical-Logik ändern will, kommt deshalb um das Überschreiben des großen Kopfbereich-Blocks nicht herum, mit allen Folgen aus Abschnitt 6. Prüfen Sie vorher gründlich, ob Sie das wirklich brauchen. Zweitens zeichnen Sie mit einem eigenen JSON-LD-Block dieselben Inhalte ein zweites Mal aus, die NOVA bereits als Microdata ausgibt. Zwei widersprüchliche Angaben zum selben Produkt sind schlechter als eine unvollständige. Halten Sie sich deshalb an eine einfache Aufteilung: Was NOVA bereits liefert, lassen Sie in Ruhe; ergänzen Sie nur, was fehlt.

Denselben Weg gehen Sie übrigens für zwei weitere Kopfbereich-Themen. Das og:type-Attribut steht in NOVA fest auf website — an beiden Fundstellen im Template, auch auf Artikelseiten. Und die Meta-Angaben für Artikel, Kategorien und Hersteller kommen nicht aus dem Shop, sondern aus JTL-Wawi. Welche Stammdatenfelder dort welche Shop-Seite steuern, hat der Beitrag zu Attributen, Merkmalen und Eigenen Feldern in JTL-Wawi im Detail auseinandergenommen — dort liegt für die Datenpflege der größere Hebel als im Template.

10. Der SEO-Standard von JTL-Shop

Damit die Verhältnisse stimmen: Der JTL-Shop bringt technisch mehr mit, als sein Ruf vermuten lässt. Die folgende Aufstellung stammt aus dem Guide und aus dem Template selbst, jeweils am 7. September 2026 geprüft.

Was eingebaut ist:

• Canonical, hreflang und Robots-Meta stecken fest im Kopfbereich des NOVA-Templates. Der Canonical wird nur ausgegeben, wenn eine Adresse gesetzt ist und die Seite nicht auf noindex steht; hreflang erscheint je aktivierter Sprache samt x-default für die Standardsprache.
• SEO-URLs werden automatisch erzeugt und auf Eindeutigkeit geprüft. Existieren eine gleich benannte Kategorie und ein gleich benannter Hersteller, zählt der Shop die Adresse laut Guide hoch, statt zwei Seiten auf dieselbe Adresse zu legen.
• Manuelle Weiterleitungen sind Standard und liegen unter Administration, SEO, Weiterleitungen. Die Quelladresse tragen Sie relativ ein, dazu wählen Sie eine von drei Parameterbehandlungen: exakter Treffer, GET-Parameter verwerfen oder GET-Parameter mitnehmen.
• Der Sitemap-Export ist im Detail konfigurierbar: eigene Seiten, Kategorien, Hersteller, Blog und Blogkategorien lassen sich einzeln zuschalten, ebenso Bilder und Kindartikel von Variationskombinationen. Auf Wunsch erzeugt der Shop die Sitemap bei jedem Abgleich mit JTL-Wawi neu.

Was fehlt oder in die Irre führt:

• Kein JSON-LD. Die strukturierten Daten kommen ausschließlich als Microdata; wer Product-, Review- oder FAQ-Auszeichnungen über den mitgelieferten Umfang hinaus braucht, ergänzt sie selbst.
• Das og:type-Attribut steht in NOVA fest auf website — auch auf Artikelseiten. Wer Produkte oder Beiträge für soziale Netzwerke sauber typisieren will, muss den Kopfbereich anfassen.
• Die Meta-Angaben für Artikel, Kategorien und Hersteller pflegen Sie nicht im Shop, sondern in JTL-Wawi. Im Shop-Backend lassen sich nur die Seiten bearbeiten, die ihre Angaben nicht aus der Warenwirtschaft beziehen.
• Der Guide schreibt zur Sitemap, Suchmaschinen entschieden anhand der Priority, wie dringend Inhalte eingelesen werden. Googles Dokumentation sagt das Gegenteil: Priority und Changefreq werden ignoriert, ausgewertet wird nur ein glaubwürdiges Lastmod.
• Der Guide nennt für Weiterleitungen keinen HTTP-Statuscode. Ob eine eingerichtete Weiterleitung als dauerhaft oder als vorübergehend ausgeliefert wird, steht in der Dokumentation schlicht nicht — prüfen Sie es an Ihrer Installation nach.

Der vierte Punkt in der zweiten Liste verdient eine kurze Erläuterung, weil er eine echte Fehlentscheidung auslösen kann. Der JTL-Guide beschreibt die Sitemap-Option „Priority" mit dem Satz, Suchmaschinen entschieden anhand dieses Werts, wie dringend neue Inhalte eingelesen werden müssten. Googles eigene Dokumentation zum Erstellen einer Sitemap sagt das Gegenteil: Priority und Changefreq werden ignoriert; ausgewertet wird allein das Lastmod-Datum, und auch das nur, wenn es nachweislich stimmt. Wer also Stunden in die Feinjustierung von Prioritätswerten steckt, optimiert an einer Stellschraube, die auf der anderen Seite nicht angeschlossen ist. Setzen Sie stattdessen sicher, dass Ihr Lastmod die tatsächliche letzte inhaltliche Änderung abbildet.

Für Varianten mit Kindartikeln bringt JTL-Shop einen eigenen Schalter mit: Unter Darstellung, Standardansichten, Artikeldetailseite legt die Option „Canonical-URLs bei Kindartikeln“ fest, ob Kindartikel per Canonical auf ihren Vaterartikel zeigen. Im Sitemap-Export lässt sich getrennt davon einstellen, ob Kindartikel in die Datei kommen. Beide Einstellungen gehören zusammen, denn Google rät von widersprüchlichen Angaben in Sitemap und Canonical ab. Wann welche Kombination passt, steht im Beitrag zum Canonical-Tag für Varianten und Filter.

Für die Entscheidung, ob dieser Standard für Ihr Vorhaben reicht, ist ohnehin die Systemfrage die erste — den direkten Gegenüber haben wir im Vergleich zwischen JTL-Shop und Shopify aufgeschlüsselt. Wenn die Entscheidung für JTL steht, ist die Reihenfolge klar: erst Datenpflege in der Warenwirtschaft, dann Template, dann Ergänzungen.

11. Fazit: eine Regel, drei Namen, ein Messwert

Die technische Antwort auf die Frage, wie man ein JTL-Shop-Template anpasst, ist erfreulich kurz: Child-Template anlegen, NOVA als Parent eintragen, nur die geänderten Dateien hineinlegen, dort nur die benötigten Smarty-Blöcke überschreiben. Wer diese vier Schritte einhält, verliert bei keinem Update etwas. Die Fehlerquelle liegt fast nie in der Technik, sondern in der Namenskonvention — drei Stellen, ein Name, keine Sonderzeichen.

Zwei Dinge kommen hinzu, die in keinem der Ratgeber auf der ersten Suchergebnisseite stehen. Der Shop liefert Smarty 5 aus und läuft im Smarty-4-Modus; ein Testlauf mit umgeschalteter Konstante kostet eine Stunde und nimmt Ihnen später eine unangenehme Überraschung. Und NOVA zeichnet strukturierte Daten ausschließlich als Microdata aus. Das ist gültig und von Google unterstützt — aber wer über den mitgelieferten Umfang hinauswill, ergänzt am besten JSON-LD im leeren Kopfbereich-Block des Child-Templates. Mit realistischer Erwartung: Das macht Ihre Seiten für erweiterte Darstellungen infrage kommend, nicht für bessere Positionen.

Alle Zahlen dieses Beitrags stammen aus eigenen Messungen am offiziellen Komplettpaket JTL-Shop 5.8.0 und an der NOVAChild-Vorlage, beide am 7. September 2026 vom JTL-Build-Server geladen und entpackt. Die zitierten Regeln stammen aus der JTL-Entwicklerdokumentation und dem JTL-Guide, die Aussagen zu strukturierten Daten und Sitemaps aus der Dokumentation von Google Search Central. Die vollständige Quellenliste steht am Ende des Beitrags.

12. Häufige Fragen zum JTL-Shop-Template

Wie passe ich das NOVA-Template im JTL-Shop an?

Farben und Logo ändern Sie über die Template-Einstellungen und das Plugin JTL Theme-Editor. Alles darüber hinaus gehört in ein Child-Template: ein eigener Ordner unter templates mit einer template.xml, die NOVA als Parent nennt. Dort überschreiben Sie einzelne Smarty-Blöcke, statt Dateien des Standard-Templates zu ändern.

Was ist der Unterschied zwischen Template und Theme?

Das Template gibt die Struktur vor: welche Bausteine auf einer Seite liegen und in welcher Reihenfolge. Das Theme ist laut Entwicklerdokumentation ein Teil des Templates und regelt die feinere Gestaltung. NOVA bringt drei Themes mit: clear als Standard, dazu midnight und blackline. Ein Child-Template kann eigene Themes ergänzen.

Gehen meine Anpassungen bei einem Shop-Update verloren?

Dateien in Ihrem Child-Template werden bei einem Update nicht überschrieben. JTL rät trotzdem ausdrücklich, nach jedem Update zu prüfen, ob die Anpassungen noch funktionieren. Der Grund ist messbar: Von NOVA 5.7.3 auf 5.8.0 hat JTL 32 der 229 Template-Dateien geändert, die Kopfzeilen-Datei eingeschlossen.

Wie darf mein Child-Template heißen?

Der Ordnername, der Name-Eintrag in der template.xml und der Namespace in der Bootstrap.php müssen identisch sein. Sonderzeichen sind verboten, weil alle Klassennamen seit JTL-Shop 5 der PSR-4-Spezifikation folgen müssen. Wer nur den Ordner umbenennt und die anderen beiden Stellen vergisst, bekommt einen Autoloader-Fehler.

Liefert der JTL-Shop strukturierte Daten als JSON-LD aus?

Nein. Wir haben alle 229 Template-Dateien von NOVA im Paket 5.8.0 durchsucht: kein einziger JSON-LD-Block. Die Auszeichnung erfolgt vollständig als Microdata, verteilt über 19 schema.org-Typen von Product bis BreadcrumbList. Microdata ist ein von Google unterstütztes Format, aber nicht dessen empfohlenes.

Verbessern strukturierte Daten mein Ranking?

Nein. Google schreibt zu manuellen Maßnahmen gegen fehlerhaftes Markup ausdrücklich, dass eine Seite dadurch die Eignung für Rich Results verliert, es aber nicht beeinflusst, wie sie in der Websuche rankt. Strukturierte Daten ermöglichen eine Darstellung, sie garantieren sie nicht und sie heben keine Position an.

Was ist SMARTY_LEGACY_MODE und muss ich reagieren?

JTL-Shop 5.8.0 liefert Smarty 5.7.0 aus, arbeitet aber im Auslieferungszustand weiter im Smarty-4-Modus. Die Konstante kam mit Shop 5.6.0 und steht standardmäßig auf true. Sofort reagieren müssen Sie nicht. Sinnvoll ist ein Testlauf mit false auf einem Testsystem, damit die Umstellung später keine Überraschung wird.

Welche SEO-Funktionen bringt JTL-Shop im Standard mit?

NOVA setzt Canonical, hreflang mit x-default und ein Robots-Meta fest im Kopfbereich. Dazu kommen SEO-URLs, manuelle Weiterleitungen mit drei Varianten der Parameterbehandlung und ein konfigurierbarer Sitemap-Export. Die Meta-Angaben für Artikel, Kategorien und Hersteller stammen dabei nicht aus dem Shop, sondern aus JTL-Wawi.

Brauche ich für ein Child-Template ein gekauftes Template?

Nein. JTL stellt auf seinem Build-Server eine offizielle Vorlage namens NOVAChild bereit. Das Archiv ist rund 320 Kilobyte groß und enthält genau die Dateien, die ein Child-Template mindestens braucht: template.xml, Bootstrap.php, ein Vorschaubild, einen eigenen Theme-Ordner mit SASS-Quellen und eine leere Datei für eigenes JavaScript.

13. Quellen & offizielle Informationen

Alle Angaben in diesem Beitrag stützen sich auf die folgenden Quellen. Alle wurden am 7. September 2026 abgerufen und im Text gegengelesen. Externe Quellen öffnen in einem neuen Tab.

• JTL-Build-Server — Komplettpaket JTL-Shop 5.8.0 — Grundlage aller eigenen Messungen: Versionskonstanten, PHP-Anforderung, Aufbau des NOVA-Templates, die Konstante für den Smarty-Modus, die Zahl der Template-Dateien und Smarty-Blöcke sowie die vollständige Suche nach JSON-LD.
• JTL-Build-Server — offizielle NOVAChild-Vorlage — Dateibestand eines minimalen Child-Templates, der Parent-Eintrag in der template.xml, die Bootstrap-Klasse mit ihrem Namespace und der Hinweis in der README, dass ein Umbenennen des Ordners den Namespace mitziehen muss.
• JTL-Entwicklerdokumentation — Eigenes Template — Die Namenskonvention seit JTL-Shop 5.0.0, die PSR-4-Anforderung an den Namen, die drei Blockmodi, die Spiegelung der Ordnerstruktur, das Verhalten bei Updates und die Regel, dass ein Child nur die geänderten Dateien enthält.
• JTL-Entwicklerdokumentation — Migration von Smarty 4 auf 5 — Einführung der Konstante in Shop 5.6.0 mit Standardwert true, die Umschaltung in der Konfigurationsdatei sowie die beiden häufigsten Anpassungen: Registrierung von PHP-Funktionen und der Ersatz des veralteten implode-Modifikators.
• JTL-Guide — Templates anpassen — Aktivierung eines Templates im Backend, die Rolle des Theme-Editor-Plugins für Farbanpassungen und die Aussage, dass ein eigenes Template über ein Child-Template entsteht.
• JTL-Releaseforum — JTL-Shop 5.8, aktuell 5.8.0 — Veröffentlichungsdatum 26. August 2026, der kritische Sicherheitsfix, die vier wichtigsten Änderungen gegenüber 5.7.3 und die Links auf den Template-Diff sowie den Diff der E-Mail-Vorlagen.
• JTL-Build-Server — Template-Diff NOVA 5.7.3 auf 5.8.0 — Der vollständige Unterschied zwischen beiden NOVA-Ständen. Eigene Auszählung: 70 geänderte Pfade, davon 32 Template-Dateien, darunter die Kopfzeilen-Datei layout/header.tpl.
• JTL-Guide — Seitentitel und Meta-Angaben pflegen — Herkunft der Meta-Angaben aus JTL-Wawi, der eingeschränkte Zuständigkeitsbereich des Shop-Backends, der Vorrang individuell gepflegter Angaben und die Regel zur Eindeutigkeit von SEO-Adressen.
• JTL-Guide — Manuelle Weiterleitungen einrichten — Der Weg im Backend, die relative Quelladresse, die drei Varianten der Parameterbehandlung und der Rat, für gelöschte Inhalte bewusst keine Weiterleitung einzurichten. Ein HTTP-Statuscode wird auf der Seite nicht genannt.
• JTL-Guide — Detailbeschreibung Sitemap-Aufbau — Die vollständige Optionsliste des Sitemap-Exports samt Changefreq, Priority und Lastmod — und die Aussage, Suchmaschinen entschieden anhand der Priority über die Dringlichkeit.
• Google Search Central — Structured data general guidelines — Die drei unterstützten Formate mit JSON-LD als empfohlenem, die fehlende Garantie auf eine Rich-Result-Darstellung und die ausdrückliche Aussage, dass der Verlust der Rich-Result-Eignung die Position in der Websuche nicht beeinflusst.
• Google Search Central — Intro to structured data markup — Die Empfehlung, strukturierte Daten als JSON-LD auszuzeichnen, sofern die Umgebung der Website das zulässt, weil dieses Format am leichtesten zu pflegen ist.
• Google Search Central — Build and submit a sitemap — Dass Google die Angaben zu Priority und Changefreq ignoriert und nur ein nachvollziehbar korrektes Lastmod auswertet.