JTL robots.txt: Konfiguration und häufige Fehlerquellen

Die robots.txt ist eine der wenigen Dateien im JTL-Shop, bei der ein einzelner Fehler den gesamten organischen Traffic zerstören kann. Gleichzeitig wird sie in der täglichen Shop-Arbeit kaum angefasst – was dazu führt, dass Standardkonfigurationen jahrelang unverändert laufen, ohne dass jemand prüft, ob sie noch zur aktuellen Shop-Struktur passen. Den strategischen Rahmen für technische SEO im JTL-Ökosystem erkläre ich auf der JTL SEO-Seite.

User-agent: *
Disallow: /Warenkorb
Disallow: /Bestellablauf
Disallow: /navi.php
Sitemap: https://ihr-shop.de/sitemap.xml
# CSS/JS niemals sperren!

JTL-Shop 5 erzeugt die robots.txt im Root – Funktionspfade sperren, aber niemals CSS/JS oder rankfähige Bereiche.

Kostenlos · ohne Anmeldung · Ergebnis sofort

Wo die robots.txt in JTL-Shop 5 liegt und wie sie erzeugt wird

JTL-Shop 5 erzeugt die robots.txt nicht als statische Datei, sondern liefert sie dynamisch über eine Route aus. Das bedeutet: Es gibt keine robots.txt im Webserver-Root, die man per FTP bearbeiten könnte. Die Steuerung erfolgt ausschließlich im Shop-Backend unter Einstellungen → SEO. Wer diese Logik nicht kennt, sucht die Datei an der falschen Stelle und landet bei direkten Serverkonfigurationen, die das dynamische Ergebnis überschreiben – ein klassischer Konfigurationsfehler bei Shopwechseln oder Servermigrationen.

Was JTL standardmäßig blockiert – und was problematisch ist

Die JTL-Standardkonfiguration sperrt eine Reihe von Pfaden per Disallow: Warenkorb, Checkout, Wunschliste, Kontobereich. Das ist korrekt. Problematisch wird es bei Pfaden, die je nach Shop-Konfiguration auch indexierbare Inhalte enthalten können:

Funktionspfade dürfen raus – kritisch wird es, wenn versehentlich CSS/JS oder ranking-relevante Bereiche blockiert werden.

• /?kf=: Merkmalfilter-URLs werden in vielen Standardkonfigurationen pauschal geblockt. Ob das sinnvoll ist, hängt davon, welche Filterkombinationen eigenes Suchvolumen haben. Eine pauschale Blockierung hier verschenkt Long-Tail-Potenzial.
• /?s=: Suchergebnis-URLs gehören geblockt – sie erzeugen Duplicate Content ohne inhärenten Ranking-Wert.
• Hersteller- und Tag-Seiten: je nach Sortiment können diese Seiten echtes Suchvolumen haben. Wer sie pauschal sperrt, verliert indexierbares Potenzial ohne Gegenwert.

Für Filterseiten gilt: Die robots.txt ist das falsche Steuerungsinstrument, wenn es um differenzierte Indexierungsentscheidungen geht. Ob eine Filterkombination crawlbar sein soll, regelt man besser über noindex-Tags auf Seitenebene als über pauschale robots.txt-Disallows. Die zugehörige Strategie ist Teil des JTL SEO-Merkmalfilter-Clusters.

Sitemap-Verweis in der robots.txt

Die robots.txt sollte einen Sitemap-Verweis enthalten – das ist kein Pflichtfeld, aber eine etablierte Praxis, die Googlebot die Sitemap-URL direkt mitteilt. JTL fügt diesen Verweis in der Standardkonfiguration ein, sofern die Sitemap aktiviert ist. Kritischer Punkt: Wenn die Sitemap-URL später geändert wird, bleibt der Verweis in der robots.txt oft veraltet – unnötige Verwirrung für den Crawler. Wie die Sitemap im JTL-Shop korrekt konfiguriert wird, ist Teil der JTL SEO-Dokumentation.

robots.txt und Crawl-Budget: wann es wirklich relevant wird

Bei kleinen Sortimenten unter ein paar hundert Seiten ist die robots.txt selten ein Crawl-Budget-Problem. Relevant wird sie einem gewissen Skalenniveau: Shops mit mehreren tausend Produkten, tiefen Kategoriestrukturen und aktiven Filterseiten erzeugen schnell fünfstellige URL-Räume. Wenn der Googlebot dabei regelmäßig in Warenkorb-Pfade, Session-URLs oder interne Suchergebnisse läuft, verbraucht er Crawl-Kapazität ohne Indexierungsgewinn. Die robots.txt ist hier das erste Mittel – aber sie wirkt nur, wenn die zu blockierenden URL-Muster sauber definiert sind. Ein Wildcard-Disallow auf /? blockiert im Zweifel auch parametrisierte URLs, die indexierbar sein sollten.

Kostenlos · ohne Anmeldung · Ergebnis sofort