Magento robots.txt: Crawl-Steuerung korrekt konfigurieren

Die robots.txt ist in Magento 2 die erste Steuerungsebene für Googlebot – sie entscheidet, welche Bereiche überhaupt gecrawlt werden dürfen, bevor irgendein Meta-Tag greift. Alle technischen SEO-Hebel in Magento im Zusammenhang: Magento SEO.

User-agent: *
Disallow: /checkout/
Disallow: /customer/
Disallow: /*?
Sitemap: https://ihr-shop.de/sitemap.xml
# pro Store View eigene Regeln möglich

Magento generiert die robots.txt aus der Backend-Konfiguration – Regeln lassen sich je Store View pflegen.

Kostenlos · ohne Anmeldung · Ergebnis sofort

Wo Magento die robots.txt ablegt – und wie sie generiert wird

Magento 2 generiert die robots.txt dynamisch über den Bereich Stores → Konfiguration → Allgemein → Design → Suchmaschinen-Robots. Das bedeutet: Die Datei liegt nicht als statische Textdatei im Webroot, sondern wird aus den Backend-Einstellungen gerendert. Wer die robots.txt direkt per FTP editiert, überschreibt damit nicht die Backend-Konfiguration – beim nächsten Cache-Flush oder Deployment wird die Datei aus dem Backend neu generiert und die manuellen Änderungen gehen verloren.

Der „robots.txt Custom instructions"-Block im Backend erlaubt, zusätzliche Disallow-Direktiven einzutragen. Standard ist dort ein vorkonfigurierter Block mit typischen Magento-Pfaden – aber dieser Block ist kein verlässlicher Default, er variiert je nach Magento-Version und muss nach Upgrades überprüft werden.

Welche Pfade in Magento standardmäßig gesperrt sein sollten

Einige Pfade gehören in jeder Magento-Installation per Disallow gesperrt, weil sie kein Ranking-Signal tragen, aber Crawl-Budget verbrauchen:

• /admin/ und /adminhtml/ – Backend-Zugänge dürfen nie gecrawlt werden; in der Praxis heißt das Admin-Pfad nach individueller Konfiguration prüfen und explizit sperren
• /checkout/ – Warenkorbseiten, Checkout-Schritte und Bestellbestätigungen sind dynamisch und sitzungsabhängig
• /customer/account/ – Account-Seiten hinter Login-Wall; Magento setzt diese zwar teilweise per robots-Meta-Direktive, aber eine robots.txt-Sperre als zweite Ebene ist sinnvoll
• /catalogsearch/result/ – Suchergebnisseiten variieren je nach Eingabe und sollten nie gecrawlt oder indexiert sein; ob hier zusätzlich noindex gesetzt werden soll, erklärt Magento Noindex.
• /catalog/product_compare/ und /wishlist/ – nutzerspezifische Funktionsseiten ohne Suchrelevanz

Was diese Pfade gemeinsam haben: Sie produzieren keinen Inhalt, den Google sinnvoll bewerten könnte, belasten aber das Crawl-Budget bei jedem Googlebot-Besuch.

robots.txt vs. noindex: Nicht dasselbe Signal

Ein häufiger Denkfehler: robots.txt-Sperre und noindex-Tag werden als gleichwertige Alternativen behandelt. Sie sind es nicht – eine per robots.txt geblockte URL wird nicht gecrawlt, weshalb ein noindex-Tag dort nie ausgelesen wird. Welche URL wann noindex erhält und wie das in Magento konfiguriert wird, erklärt Magento Noindex.

Eine per Disallow gesperrte Seite kann trotzdem indexiert bleiben – zum Entfernen braucht es noindex.

Sitemap-Direktive: Referenz gehört in die robots.txt

Magento trägt die Sitemap-URL nicht automatisch in die robots.txt ein – die Sitemap-Direktive muss manuell im Custom-Instructions-Feld ergänzt werden. Bei Multistore-Setups sollte jede Store-View-Sitemap referenziert sein. Wie die Sitemap-Konfiguration insgesamt funktioniert, erklärt Magento Sitemap.

robots.txt im Multistore: Store-View-spezifische Regeln

In Magento-Multistores mit mehreren Store Views unter Subpfaden (z. B. /de/, /fr/) gilt die globale robots.txt für alle Views. Das erzeugt ein Problem: Ein Store View, der noch nicht live ist oder per noindex temporär aus dem Index ausgeschlossen wurde, kann trotzdem gecrawlt werden, weil die robots.txt keine pfadbezogene Ausnahme kennt. Hier empfiehlt sich ein explizites Disallow auf den Subpfad des noch nicht fertigen Store Views. Nach Go-Live wird der Eintrag entfernt – nicht vergessen, das ist ein wiederkehrender Fehler nach Launches.

Die robots.txt-Konfiguration prüfe ich als Teil jeder Magento-SEO-Analyse: welche Pfade geblockt sind, ob die Sitemap-Referenz fehlt und ob nach Upgrades automatisch generierte Fehlkonfigurationen entstanden sind – direkt im Backend, ohne Standardchecklisten.

Kostenlos · ohne Anmeldung · Ergebnis sofort