JTL-Shop SEO: Suchmaschinenoptimierung und KI-Lesbarkeit

Ein JTL-Shop wird nicht gefunden, weil im Backend irgendwo „SEO“ angehakt ist. Er wird gefunden, wenn Google die richtigen Seiten crawlt, der Title zum Suchbegriff passt und die Seite schnell genug ist, dass der Besucher bleibt. Dazu kommt inzwischen eine zweite Lesart: KI-Assistenten übernehmen Preis, Verfügbarkeit und Sortiment nur, wenn das im Quelltext steht, nicht nur hübsch im Template.

Dieser Leitfaden ist die Reihenfolge, in der wir einen Shop durchgehen. Technik zuerst, dann messen, dann Texte. Die Plugins am Ende nehmen einzelne Stellen ab. Den Rank aufbauen sie nicht von allein.

Erst aufräumen, dann Texte schreiben

Produktbeschreibungen für das ganze Sortiment zu schreiben, bevor Filter-URLs den Index füllen, ist verschenkte Arbeit. Google verteilt die Aufmerksamkeit eines Shops auf alles, was indexiert ist. Je mehr irrelevante Adressen dazwischenliegen, desto weniger bleibt für die Artikel, die verkaufen sollen.

URLs, Canonical und was in den Index darf

Sprechende URLs

Suchmaschinenfreundliche URLs (mod_rewrite) gehören an. Bindestriche, keine Unterstriche. Die Struktur bleibt flach: Startseite, Kategorie, Artikel reichen in den meisten Shops. Vier Ebenen sind die Obergrenze, nicht das Ziel.

Den SEO-Pfad von Artikel und Kategorie pflegst du in der JTL-Wawi. Besondere Seiten, Hersteller und eigene Inhaltsseiten legst du im Shop-Backend unter den SEO-Einstellungen fest. Der Menüpunkt heißt je nach Shop-Version etwas anders. Such nach „SEO“.

Canonical-Tags

JTL setzt Canonical-Tags im Normalfall von allein. Prüfen musst du sie, sobald Varianten, dieselbe Ware in zwei Kategorien oder Parameter-URLs dazukommen.

Kindartikel verweisen in der Regel per Canonical auf den Vaterartikel. Ausnahme: Die Variante hat ein eigenes Suchvolumen, etwa eine Farbe oder Ausführung, nach der Leute gezielt suchen. Dann verdient sie eine eigene Seite mit eigenem Text. Eine reine technische Variante zeigt auf den Vater. Sonst konkurrieren fünf URLs um dasselbe Keyword.

Index steuern

Systemseiten haben im Index nichts verloren: Bestellvorgang, interne Suche, Warenkorb, Kundenkonto. Dasselbe gilt für Sortierungen und für Filterkombinationen, nach denen niemand sucht.

Als grober Abgleich, keine Vorgabe von Google: Stell in der Search Console die Zahl der indexierten URLs neben die Artikelzahl. Kommen auf einen Artikel ungefähr zwanzig indexierte Adressen, ist fast immer die Filtersteuerung das Loch.

Die erste Seite einer Kategorie soll ranken. Folgeseiten der Blätterfunktion führen zu weiteren Artikeln, sie sollen dasselbe Keyword nicht noch einmal beanspruchen.

Sitemap, Ladezeit, eine H1

XML-Sitemap

In die Sitemap gehören die Seiten, die du bewerben willst. Keine Filter, keine Seiten mit noindex, keine Kindartikel, deren Canonical woandershin zeigt. Der Abgleich mit der Wawi hält die Datei aktuell, wenn Artikel rein- oder rausgehen. In der robots.txt steht die Adresse der Sitemap, sonst findet Google sie nur, wenn du sie in der Search Console einreichst.

Ladezeit

JTL-Shops hängen an der Datenbank. Time to First Byte und Largest Contentful Paint leiden zuerst am Server: SSD, eine aktuelle PHP-Version, die Cache-Schichten des Shops, bei viel Traffic Redis. Bilder komprimierst du, bevor du ein CDN davorstellst. Ein langsamer Artikel verliert den Besucher, der schon da war. Wenn das Hosting der Engpass ist, liegt der Hebel bei Hosting und Cache, nicht bei einem weiteren Textabsatz.

Überschriften

Jede Seite hat genau eine H1. Auf dem Artikel ist das der Artikelname, auf der Kategorie der Kategoriename, und darin steckt der Suchbegriff. H2 bis H4 gliedern den Text darunter. Zwei H1 auf einer Seite kommen fast immer aus dem Template, nicht aus der Wawi. Ein Crawler wie Screaming Frog zeigt das in einem Durchlauf.

Messen, bevor du umschreibst

Die Google Search Console gehört an den Shop, bevor du die ersten zehn Texte anfasst. Dort siehst du, welche URLs im Index liegen, wo das Crawling scheitert und wie die Core Web Vitals aussehen. Exportier die indexierten URLs, crawl den Shop und leg drei Listen nebeneinander: intern verlinkt, indexierbar, in der Sitemap. Was in keiner der drei steht, rankt nicht. Was in allen dreien steht und trotzdem keine Klicks bringt, ist ein Title- oder Textproblem.

Dazu brauchst du Zahlen aus dem Shop: welche Landingpage Bestellungen bringt und welche nur Aufrufe. Tracking-Codes, die von Hand im Template stehen, laufen oft auch ohne Einwilligung und sind nach dem nächsten Template-Update weg. Der Smart Analyser meldet Matomo, GA4 und den Tag Manager am Consent Manager des Shops an. Die Skripte laden erst nach Zustimmung, die Einstellung liegt im Backend. Matomo kann auf dem eigenen Server laufen, die Besucherdaten bleiben dann bei dir. Ist GA4 schon im Tag-Manager-Container eingerichtet, bleibt das GA4-Feld leer, sonst zählst du doppelt.

Wenn du den Shop einmal gegen diese Liste halten willst, schreib uns. Wir schauen Index, Texte und Technik an. Ein Ranking versprechen wir nicht.

Titel, Texte, Kategorien

Title und Description

Jede indexierbare Seite bekommt einen eigenen Title und eine eigene Meta-Description. Als Arbeitslänge reichen um die 60 Zeichen für den Title und um die 155 für die Description. Google kürzt nach der Breite, nicht nach einem festen Zähler. Das Suchwort steht vorn, der Shopname hinten. Die Description nennt einen Grund zum Klicken.

In der JTL-Wawi pflegst du das pro Sprache am Artikel und an der Kategorie. Den Title leer zu lassen und zu hoffen, dass der Shop aus dem Artikelnamen etwas Brauchbares baut, funktioniert bei austauschbaren Namen schlecht.

Produkttexte

Fang bei den Artikeln an, die Umsatz oder Suchanfragen haben. Die ersten 50 bis 100. Herstellertexte kopierst du nicht. Die stehen auf zwanzig anderen Shops, und Google hat keinen Grund, deinen zu bevorzugen.

Ein brauchbarer Text sagt, was das Teil ist, für wen es gedacht ist und worin es sich unterscheidet. Das Hauptkeyword am Anfang, danach die Formulierungen, mit denen Leute tatsächlich suchen. 250 bis 500 Wörter sind eine Orientierung für erklärungsbedürftige Artikel, keine Pflicht für einen Dübel. Am Ende steht der nächste Schritt: Variante wählen, in den Warenkorb, nachfragen.

Kategorien

Der Kategoriename ist der Suchbegriff, nicht die interne Warengruppenlogik der Wawi. „Schrauben“ kann ranken, „HW-042 Befestigung“ eher nicht. Der Kategorietext ist einmalig, sagt, was in der Kategorie liegt, und verlinkt verwandte Kategorien. Eine Kategorie ohne Text ist eine Liste. Die kann ranken. Gegen Shops mit einem klaren Text tut sie das seltener.

Bilder mit eigenem Dateinamen

In der Bildersuche zählt der Dateiname mit. IMG_0042.jpg sagt nichts. In der Wawi gibt es pro Artikel genau ein Feld für den Bildnamen. Jedes weitere Bild hängt der Shop daraus mit ~2, ~3 an. Für die Suche ist das verschenkt.

Jedes Bild bekommt einen sprechenden Namen und ein Alt-Attribut, das das Bild beschreibt. Wichtige Bilder liegen oben auf der Artikelseite, komprimiert vor dem Upload. Eigene Fotos schlagen das Herstellerpaket, das jeder Händler im Sortiment hat. Auch hier gilt: erst die Artikel, die verkaufen, nicht alle 8.000 auf einmal.

Das Plugin für SEO-Dateinamen gibt jedem Artikelbild einen eigenen Namen, auch dem zweiten und dritten. Die Originaldatei bleibt liegen, der Name übersteht den Wawi-Abgleich. Ausgespielt wird er auf der Artikelseite, in Listen, bei og:image und in der Bilder-Sitemap. Wer die Namen in der Wawi pflegt, hinterlegt sie als Funktionsattribute ab bildname_2. Die Alt-Texte img_alt_1, img_alt_2 bleiben in der Wawi, das Plugin zeigt sie nur an.

Verlinkung und Filterseiten

Von Seiten, die schon Besucher bringen, verlinkst du auf die Seiten, die ranken sollen. Verwandte Kategorien untereinander, Zubehör zum Hauptartikel, ein Ratgeber zum Sortiment. Ein Link aus dem Footer auf alles ist keine Strategie. Ein Link aus einem starken Kategorietext auf den Artikel, den du nach vorn bringen willst, schon.

Bei Filtern entscheidest du pro Merkmalwert. Hat „für Außenbereich“ oder eine bestimmte Farbe echtes Suchvolumen, bekommt der Wert eine eigene Seite: eigener Text, eigene interne Links, indexierbar. Hat er keins, bleibt die Kombination draußen, per noindex. So schiebt nicht jede Kreuzung aus Farbe, Größe und Marke eine eigene URL in den Index.

Was Google und KI aus dem Shop lesen

Strukturierte Daten sind JSON-LD im Seitenquelltext: Produkt, Preis, Verfügbarkeit, Bewertungen, Breadcrumb. Google kann daraus Rich Results bauen. Ein Assistent entnimmt einer Seite ebenfalls nur das, was ausgezeichnet ist. Ein Preis, der im Template ein hübsches Div ist und im Quelltext nichts weiter, fehlt beiden.

Das Structured-Data-Plugin schreibt diese Auszeichnung aus den Shop-Stammdaten, ohne dass du das Template anfasst. Produkt und Angebot, GTIN nur wenn die Prüfziffer stimmt, Versand und Widerruf, Bewertungen, Breadcrumb aus dem echten Kategoriepfad, Unternehmensdaten, die Shopsuche, die Artikelliste in der Reihenfolge der Seite. Dazu eine llms.txt im Shop-Wurzelverzeichnis für Assistenten und ein Produktfeed unter /export/ai_products.json. Erzeugen und Überschreiben der Textdateien sind ab Werk aus. Du schaltest sie ein, wenn der Inhalt stimmt.

Eine zweite Aufgabe ist die Bedienung. Das Web-MCP-Plugin meldet dem Browser des Besuchers Werkzeuge: Katalog durchsuchen, Produktdaten lesen, Varianten auflösen, Warenkorb ansehen. Bestellt und bezahlt wird nichts, die Kasse bleibt beim Menschen. Warenkorb ändern und Bestellungen zeigen sind ab Werk aus.

Die Auszeichnung beschreibt die Seite für Crawler. Die Schnittstelle lässt einen Assistenten im Shop nachschlagen, was die Seite zeigt. Beides ersetzt keinen eigenen Text.

Wenn der Kunde den Artikel schon kennt

Zwischen „den brauche ich wieder“ und der Bestellung liegen sonst mehrere Klicks. Ein Direktkauf-Link legt den Artikel über die Artikelnummer aus der Wawi in den Warenkorb: Newsletter, QR-Code am Regal, Support-Mail, Partnerseite. Dieselbe Adresse kannst du im Google-Shopping-Feed als Ziel eintragen. Der Klick kommt dann mit gefülltem Warenkorb an.

Die Artikelseite bleibt die Seite, die du für die Suche optimierst. Preis und Verfügbarkeit dort, auch in den strukturierten Daten, müssen zum Feed passen. Der Link verkürzt den Weg. Title, Text und Bild ersetzt er nicht.

In dieser Reihenfolge

1. Technik: URLs, Canonicals, Index, Sitemap, Ladezeit, eine H1.
2. Messen: Search Console verbinden, die drei Listen vergleichen, Tracking an die Einwilligung binden.
3. Inhalte: Title, Description, die wichtigsten Produkttexte, Kategorietexte, Bildnamen und Alt-Texte.
4. Danach: interne Links, Filterstrategie, strukturierte Daten, und erst dann die Stellen, an denen ein Plugin die Pflege abnimmt.

Diese Plugins nehmen einen Teil der Liste ab

Der Leitfaden steht auch ohne sie. An fünf Stellen spart ein Plugin die Handarbeit im Template. Mit den folgenden Plugins setzt du vieles davon um, auch als Bundle erhältlich. Einzelartikel und Bundle liegen in der Kategorie JTL im Onlineshop.

• Smart Analyser für Matomo, GA4 und den Tag Manager, erst nach Einwilligung.
• Structured Data für JSON-LD, llms.txt und den KI-Produktfeed.
• Web MCP, damit ein Assistent Katalog und Produktdaten abfragen kann. Die Kasse bleibt beim Menschen.
• SEO-Dateinamen für Artikelbilder, jedes Bild einzeln, auch nach dem Wawi-Abgleich.
• Direktkauf-Link für Newsletter, QR-Code und als Zieladresse im Shopping-Feed.

Einen Überblick über die Plugin-Entwicklung gibt es auf JTL-Shop Plugins. Shops betreuen wir unter Onlineshops. Für eine Durchsicht deines Shops reicht eine Nachricht über die Kontaktseite.

Häufige Fragen

Reicht ein SEO-Plugin?

Nein. Ein Plugin kann Canonicals, Sitemap-Pflege oder Metadaten nicht ersetzen, und es schreibt auch keine Produkttexte. Es nimmt die Stellen ab, die im Template nach dem nächsten Update kaputtgehen: Einwilligung beim Tracking, strukturierte Daten, Bildnamen, die Assistenten-Schnittstelle, den Direktlink.

Sollen Varianten eine eigene URL haben?

Nur wenn nach der Variante selbst gesucht wird. Sonst Canonical auf den Vaterartikel, und die Kindartikel raus aus der Sitemap.

Brauche ich Schema und eine KI-Schnittstelle?

Schema, damit Google und Assistenten Preis und Verfügbarkeit aus der Seite lesen. Die Schnittstelle, damit ein Assistent im Shop nachschlagen kann, statt den Seitentext zu raten. Wer nur gefunden werden will, fängt bei Text, Index und Schema an.

crispy web ist kein offizieller JTL-Partner. Wir entwickeln und betreuen JTL-Shops und eigene Plugins aus Projekterfahrung. Stand: 29. September 2026. Keine Rankingversprechen.

Dieser Beitrag wurde mit KI-Unterstützung erstellt.