robots.txt in Shopware: was der Kern seit 6.7 selbst schreibt
Shopware 6.6 liefert keine robots.txt. Seit 6.7 erzeugt der Kern eine — mit Standardregeln, die etwa alle Adressen mit Parametern sperren. Was drinsteht, wo man es ändert und wann eine eigene Datei die Ausgabe überdeckt.
Lange war die Antwort auf „Welche robots.txt liefert Shopware?" einfach: keine. Mit Shopware 6.7 hat sich das geändert. Der Kern beantwortet die Adresse /robots.txt jetzt selbst — mit Regeln, die viele Shopbetreiber nie gesehen haben. Wir haben drei Versionen nebeneinander gelesen: 6.6.10.6, 6.7.2.2 und 6.7.10.1.
Shopware 6.6: keine Datei
In 6.6.10.6 gibt es weder eine Route für /robots.txt noch ein Template, noch liegt im Verzeichnis public eine Datei. Wer eine robots.txt braucht, legt sie selbst an — als Datei im Webroot oder über das Hosting. Fehlt sie, gibt es schlicht keine Regeln; Crawler dürfen dann alles abrufen.
Shopware 6.7: der Kern schreibt die Datei
Ab 6.7 gibt es eine eigene Route samt Template. Ab Werk ergibt sich daraus diese Ausgabe:
| Zeile | Herkunft |
|---|---|
User-agent: * | Template |
Allow: / | Template |
Disallow: /*? | Template — sperrt alle Adressen mit Parametern |
Allow: /*theme/ | Template — Theme-Dateien bleiben abrufbar |
Allow: /media/*?ts= | Template — Bilder mit Cache-Parameter bleiben abrufbar |
Disallow: /account/ · /checkout/ · /widgets/ | Voreinstellung aus einer Migration |
Allow: /widgets/cms/ · /widgets/menu/offcanvas | Voreinstellung aus einer Migration |
Sitemap: https://…/sitemap.xml | je Domain des Verkaufskanals |
Die Voreinstellungen stehen in der Systemkonfiguration (core.basicInformation.robotsRules) und lassen sich je Verkaufskanal in der Administration ändern. Die Zeilen aus dem Template stehen dort nicht — sie kommen immer mit. In 6.7.2.2 ließen sie sich nicht abschalten, in 6.7.10.1 gibt es dafür einen Schalter.
Was sich innerhalb von 6.7 geändert hat
Die erste Fassung in 6.7.2.2 nahm im Einstellungsfeld nur Allow- und Disallow-Zeilen an, die für die jeweilige Domain gelten. In 6.7.10.1 ist daraus mehr geworden:
- User-agent-Blöcke: Regeln für einzelne Crawler, etwa für einen KI-Crawler, lassen sich jetzt in der Administration eintragen. Sie gelten für alle Domains.
- Standardregeln abschalten: Ein eigener Schalter lässt die Zeilen aus dem Template weg — dann gilt nur, was man selbst einträgt.
- Prüfung der Eingabe: Beim Speichern zerlegt der Kern die Regeln und schreibt gefundene Probleme, etwa unbekannte Anweisungen, ins Shopware-Log.
Wer in 6.7.2.2 bestimmten Crawlern etwas erlauben oder verbieten wollte, kam um eine eigene Datei nicht herum. Welche KI-Crawler es gibt und welche man zulassen sollte, beschreibt Welche KI-Crawler Ihren Shop besuchen dürfen.
Eine alte Datei überdeckt alles
Die mitgelieferte .htaccess liefert eine vorhandene Datei aus, bevor Shopware überhaupt angefragt wird. Liegt also aus 6.6-Zeiten noch eine robots.txt im Verzeichnis public, sieht niemand die neue Ausgabe des Kerns — und Änderungen in der Administration wirken nicht. Bei nginx entscheidet die jeweilige Serverkonfiguration.
Dazu kommen Sperren, die gar nicht in der robots.txt stehen: An unserer eigenen Website hat eine Einstellung im Hosting-Panel einzelne Crawler abgewiesen, ohne dass die Datei davon wusste (beschrieben hier).
Staging und Testsysteme
Ist der Staging-Modus von Shopware aktiv, gibt der Kern statt aller Regeln nur Disallow: / aus. Das hält Crawler fern, entfernt aber nichts, was schon im Index steht. Dafür braucht es noindex — und Crawler müssen die Seiten abrufen dürfen, um es zu sehen.
Nach dem Update auf 6.7 einmal /robots.txt abrufen: Was dort steht, gilt — nicht das, was man in Erinnerung hat.
Wie die Sitemap entsteht, auf die die letzte Zeile verweist, steht in Die Sitemap in Shopware: was drinsteht und was fehlt. Das Zusammenspiel mit den übrigen SEO-Einstellungen von Shopware beschreibt unser Leitfaden Shopware-SEO.
Häufige Fragen
- Wo stellt man die robots.txt in Shopware 6.7 ein?
- In der Administration unter Einstellungen, Grundinformationen, im Bereich „Regeln für robots.txt“ — je Verkaufskanal. In 6.7.10.1 gibt es dort zusätzlich einen Schalter, der die Standardregeln abschaltet.
- Kann man KI-Crawler gezielt über die Administration sperren?
- In 6.7.10.1 ja: Die Regeln dürfen dort User-agent-Blöcke enthalten, die für alle Domains gelten. In 6.7.2.2 nahm das Feld nur Allow- und Disallow-Zeilen für die jeweilige Domain an; für einzelne Crawler brauchte es eine eigene Datei.
- Was passiert auf einem Testsystem?
- Ist der Staging-Modus aktiv, gibt der Kern statt der Regeln nur „Disallow: /“ aus. Das sperrt Crawler aus, entfernt aber bereits indexierte Seiten nicht — dafür braucht es noindex.
- Sperrt Disallow: /*? auch Filterseiten?
- Ja, jede Adresse mit Parameter. Das betrifft Filter, Sortierungen und Seitenzahlen. Eine gesperrte Seite kann trotzdem im Index stehen, wenn sie verlinkt ist; Google sieht dann nur ihren Inhalt nicht.
- Gilt das auch für nginx?
- Ob eine Datei in public Vorrang hat, entscheidet die Webserver-Konfiguration. Mit der mitgelieferten .htaccess für Apache ist das so; bei nginx hängt es von der jeweiligen Konfiguration ab.