robots.txt richtig konfigurieren: Crawling steuern ohne Rankingverlust

1. Was ist robots.txt und wie funktioniert das Robots Exclusion Protocol

robots.txt ist eine reine Textdatei im Root einer Domain, die dem Robots Exclusion Protocol folgt und beschreibt, welche Bereiche einer Website von Crawlern besucht werden dürfen. Sie liegt zwingend unter https://mironsoft.de/robots.txt, root-relativ und ohne Unterordner. Jede standardkonforme Suchmaschine ruft diese Datei vor dem eigentlichen Crawlen ab und respektiert die dort definierten Regeln, bevor eine einzelne URL überhaupt angefragt wird.

Wichtig zu verstehen: robots.txt ist eine Kann-Vorschrift, keine Sicherheitsmaßnahme. Seriöse Crawler wie Googlebot oder Bingbot halten sich daran, die Datei verhindert aber nicht den Zugriff durch böswillige Bots oder Nutzer, die eine URL direkt kennen. Sensible Bereiche wie das Admin-Backend gehören daher zusätzlich hinter Authentifizierung und IP-Beschränkung, nicht nur hinter ein Disallow.

Für Magento-Shops mit tausenden Kategorie- und Filterkombinationen ist robots.txt vor allem ein Werkzeug zur Steuerung des Crawl-Budgets. Google investiert pro Domain nur eine begrenzte Anzahl an Crawl-Anfragen pro Tag, und jede unnötig gecrawlte Parameter-URL verringert die Wahrscheinlichkeit, dass wichtige neue Produktseiten zeitnah entdeckt werden.

2. Syntax im Detail: User-agent, Disallow, Allow, Sitemap und Wildcards

Das Robots Exclusion Protocol kennt wenige, aber präzise Direktiven. User-agent legt fest, für welchen Crawler die folgenden Regeln gelten, ein Sternchen steht für alle Crawler. Disallow sperrt einen Pfad, Allow erlaubt eine Ausnahme innerhalb eines gesperrten Pfads, und Sitemap verweist auf die XML-Sitemap, unabhängig vom User-agent-Block. Jede Regel bezieht sich auf den Pfad ab der Domain, nicht auf die vollständige URL.

Zwei Wildcards machen die Syntax mächtig: Der Stern (*) steht für eine beliebige Zeichenfolge innerhalb eines Pfads, das Dollarzeichen ($) markiert das Ende einer URL. Disallow: /*.pdf$ sperrt beispielsweise alle PDF-Dateien, aber keine URLs, die zufällig ".pdf" enthalten, gefolgt von weiteren Zeichen. Ohne das Dollarzeichen würde die Regel auch Pfade wie /produkt.pdf-uebersicht/ blockieren, was in der Praxis selten gewollt ist.

Spezifischere Regeln gewinnen gegenüber allgemeineren, unabhängig von der Reihenfolge in der Datei. Google wählt bei widersprüchlichen Treffern die Regel mit dem längsten übereinstimmenden Pfad. Das erlaubt gezielte Ausnahmen: Ein globales Disallow: /media/ lässt sich durch ein spezifischeres Allow: /media/wysiwyg/ gezielt wieder öffnen.

# Basic robots.txt syntax with wildcards
User-agent: *
Disallow: /checkout/
Disallow: /customer/account/
Allow: /media/wysiwyg/

# Block all PDF files, but not URLs merely containing ".pdf"
Disallow: /*.pdf$

# Sitemap directive works independently of User-agent blocks
Sitemap: https://mironsoft.de/sitemap.xml

3. Häufige Fehler: gesperrte CSS/JS, Disallow: / und falsche Parameter-Regeln

Der teuerste Fehler: Disallow: /*.js$ oder Disallow: /*.css$ sperrt versehentlich alle JavaScript- und CSS-Dateien. Da Google Seiten seit Jahren rendert statt nur den HTML-Quelltext zu lesen, kann Googlebot ohne diese Ressourcen das tatsächliche Layout nicht mehr korrekt darstellen und stuft Seiten im schlimmsten Fall als defekt oder als "Mobile nicht nutzbar" ein. Das betrifft in Magento besonders generische Regeln wie Disallow: /static/, die ungewollt auch pub/static/frontend/*/*/de_DE/*.css treffen.

Ebenso riskant: Ein Disallow: / im Root-Block bleibt nach einem Relaunch oder Staging-zu-Live-Wechsel versehentlich stehen und sperrt die komplette Domain für alle Crawler. Google entfernt betroffene Seiten dann nicht sofort, aber neue Inhalte werden nicht mehr entdeckt, und bestehende Rankings verfallen innerhalb weniger Wochen, weil keine aktuellen Signale mehr erfasst werden.

Ein dritter häufiger Fehler betrifft Parameter-URLs: Statt gezielt Disallow: /*?p=* oder Disallow: /catalogsearch/result/*?* zu setzen, sperren viele Shops versehentlich auch Pfade wie /*?* pauschal und blockieren damit legitime, kanonisierte Landingpages mit Tracking-Parametern.

# BAD: blocks rendering-critical assets and every parameterized URL
User-agent: *
Disallow: /static/
Disallow: /*.js$
Disallow: /*.css$
Disallow: /*?*

# BAD: leftover from staging, blocks the entire site
Disallow: /

4. robots.txt testen: URL-Inspection-Tool und curl

Der klassische robots.txt-Tester in der alten Google Search Console ist offiziell abgeschaltet, seine Funktion lebt aber im URL-Inspection-Tool weiter: Für jede geprüfte URL zeigt Google an, ob sie durch robots.txt blockiert wird und welche konkrete Regel dafür verantwortlich ist. Das ist der zuverlässigste Weg, eine Blockade zu verifizieren, weil das Tool exakt die robots.txt-Version nutzt, die Google zuletzt gecrawlt hat.

Für einen schnellen manuellen Check genügt curl: curl -s https://mironsoft.de/robots.txt ruft die Datei direkt ab und zeigt, was live ausgeliefert wird, unabhängig von Caching-Schichten im Browser. Wichtig ist, denselben Check auch mit dem User-Agent-Header von Googlebot durchzuführen, falls ein CDN oder Varnish unterschiedliche Antworten je nach User-Agent ausliefert, was bei Cloaking-Verdacht sofort auffallen würde.

Third-Party-Crawler wie Screaming Frog respektieren robots.txt standardmäßig ebenfalls und markieren blockierte URLs im Crawl-Report separat. Das eignet sich gut, um vor einem Deployment die komplette robots.txt-Wirkung auf alle URLs im Sitemap-Index zu simulieren, bevor Änderungen live gehen.

# Fetch the live robots.txt directly, bypassing browser caches
curl -s https://mironsoft.de/robots.txt

# Fetch it while impersonating Googlebot's user agent
curl -s -A "Googlebot/2.1 (+http://www.google.com/bot.html)" \
  https://mironsoft.de/robots.txt

# Check response headers for caching behavior and status code
curl -sI https://mironsoft.de/robots.txt

5. robots.txt vs. noindex: Crawling- und Indexierungssteuerung im Vergleich

robots.txt und der noindex-Meta-Tag lösen unterschiedliche Probleme und dürfen nicht verwechselt werden. robots.txt steuert das Crawling, also ob Google eine URL überhaupt abruft. Der noindex-Tag im HTML-Head steuert die Indexierung, also ob eine bereits abgerufene Seite im Suchindex landet. Beide gemeinsam auf derselben URL zu verwenden, führt zu einem der häufigsten technischen SEO-Fehler überhaupt.

Wird eine URL per Disallow gesperrt, kann Googlebot die Seite nicht mehr abrufen und sieht damit auch den noindex-Tag im Quelltext nie. Das Ergebnis: Die URL kann trotzdem im Index verbleiben, wenn genügend externe Links auf sie zeigen, allerdings nur als "URL ohne Beschreibung verfügbar", ein Karteileichen-Eintrag ohne Snippet, Title oder Meta-Description, der Nutzer verwirrt und die Klickrate der gesamten Domain drückt.

Die korrekte Reihenfolge zum sicheren Entfernen einer Seite aus dem Index: Zuerst den noindex-Tag setzen und crawlen lassen, warten bis Google die Seite als deindexiert bestätigt, und erst danach optional ein Disallow ergänzen, falls die Seite auch aus Crawl-Budget-Gründen nicht mehr besucht werden soll.

<!-- This tag only works if robots.txt does NOT disallow the page -->
<meta name="robots" content="noindex, follow">

<!-- WRONG: robots.txt blocks the page, so Googlebot never sees the tag above -->
<!-- User-agent: *
Disallow: /alte-kategorie/ -->

6. Magento-spezifische robots.txt: Admin, Suche, Parameter und Sitemap

Magento liefert unter Stores > Configuration > General > Design > Search Engine Robots einen eingebauten robots.txt-Editor, inklusive vordefinierter Presets für "Default Rules" und "Restrictive". Diese Oberfläche speichert die Regeln direkt in der Datenbank statt in einer physischen Datei im Webroot, was bei Multi-Store-Setups mit unterschiedlichen robots.txt-Inhalten pro Store-View praktisch ist, aber im Deployment-Workflow beachtet werden muss.

Typische Magento-spezifische Sperren betreffen /catalogsearch/result/ mit Parametern, da interne Suchergebnisseiten selten eigenständigen Suchwert bieten und massenhaft Near-Duplicate-Content erzeugen. Ebenso empfehlenswert: Disallow: /*?___store=* gegen Store-Switcher-Parameter und Disallow: /*SID=* gegen Session-IDs in URLs, die sonst für jeden Bot-Besuch neue, technisch identische URL-Varianten erzeugen und das Crawl-Budget unnötig aufblähen.

Der Sitemap-Pfad gehört zwingend in die robots.txt, unabhängig vom Store-View: Sitemap: https://mironsoft.de/sitemap.xml. Magento generiert die XML-Sitemap über bin/magento sitemap:generate oder den Cron-Job in Stores > Configuration > Catalog > XML Sitemap. Die Angabe in robots.txt beschleunigt die Entdeckung neuer URLs zusätzlich zur manuellen Einreichung in der Search Console.

# Magento-specific robots.txt: admin, search, parameters, sitemap
User-agent: *
Disallow: /admin/
Disallow: /catalogsearch/result/
Disallow: /*?___store=*
Disallow: /*?p=*
Disallow: /*SID=*
Disallow: /downloadable/
Allow: /media/catalog/
Allow: /static/version*/frontend/

Sitemap: https://mironsoft.de/sitemap.xml

7. Admin-Pfad und statische Assets richtig behandeln

Der Admin-Pfad gehört grundsätzlich per Disallow gesperrt, allerdings mit Einschränkung: Wer den Standardpfad /admin/ in der env.php auf einen individuellen, schwer erratbaren Pfad umbenannt hat, sollte diesen individuellen Pfad NICHT in robots.txt eintragen. Eine öffentlich einsehbare robots.txt mit Disallow: /mein-geheimer-admin-pfad/ verrät genau den Pfad, den Security-by-Obscurity eigentlich verstecken sollte, an jeden, der die Datei aufruft.

Für statische Assets gilt die differenzierte Regel aus Abschnitt 3: pub/static/ und pub/media/ dürfen nicht pauschal gesperrt werden, weil Google CSS und Bilder zum Rendern braucht. Sinnvoll ist dagegen, echte Nicht-Rendering-Ressourcen wie /pub/media/downloadable/ oder /pub/media/customer/ gezielt zu sperren, sofern dort keine indexierungswürdigen Inhalte liegen, sowie generierte Cache-Verzeichnisse wie /var/ und /generated/, die ohnehin nie öffentlich erreichbar sein sollten.

Für Multi-Store- oder Multi-Language-Setups mit separaten Subdomains oder Verzeichnissen braucht jede Domain-Variante eine eigene robots.txt mit eigenen Sitemap-Verweisen, da Google die Datei strikt pro Host und Protokoll auswertet. Eine robots.txt unter https://mironsoft.de/ hat keinerlei Wirkung auf https://www.mironsoft.de/ oder eine separate Länder-Subdomain.

8. Best Practices für eine robuste robots.txt-Strategie

Eine robuste robots.txt-Strategie beginnt mit dem Prinzip so wenig Sperren wie möglich, so viele wie nötig. Jede zusätzliche Disallow-Regel ist ein potenzielles Risiko für versehentliche Kollateralschäden, besonders bei generischen Wildcard-Mustern. Änderungen an der robots.txt sollten daher wie Code-Änderungen behandelt werden: mit Versionierung, Review vor dem Deployment und einem Test im URL-Inspection-Tool, bevor die neue Version live geht.

Vor jedem Relaunch oder Domain-Umzug gehört die robots.txt auf eine feste Checkliste: Steht noch ein Disallow: / aus der Staging-Umgebung drin? Ist der Sitemap-Pfad korrekt und erreichbar? Werden CSS- und JS-Verzeichnisse tatsächlich nicht blockiert? Ein einzelner vergessener Root-Disallow nach dem Go-Live kann wochenlange Rankingverluste verursachen, die sich erst mit Verzögerung in der Search Console zeigen.

Änderungen an der robots.txt sollten grundsätzlich nicht isoliert betrachtet werden, sondern immer zusammen mit der XML-Sitemap, den kanonischen Tags und der internen Verlinkung, da alle vier Mechanismen gemeinsam steuern, welche Version einer URL Google letztlich indexiert und im Ranking bevorzugt.

9. Häufige Fehler im direkten Vergleich

Die folgende Übersicht fasst die häufigsten robots.txt-Fehler in Magento-Shops der korrekten Direktive gegenüber und zeigt die jeweilige SEO-Auswirkung.

Die meisten dieser Fehler entstehen nicht durch Unwissen über die Syntax, sondern durch zu breite Wildcard-Muster, die mehr Pfade treffen als beabsichtigt. Wer jede Disallow-Regel gegen eine reale Beispiel-URL testet, bevor sie live geht, vermeidet die teuersten Kollateralschäden zuverlässig.

10. Zusammenfassung

Eine korrekt konfigurierte robots.txt löst ein einfaches, aber teures Problem: Sie steuert, welche Bereiche eines Magento-Shops Google überhaupt zu Gesicht bekommt, ohne versehentlich rendering-kritische Ressourcen oder ganze Seitenbereiche zu sperren. Die Syntax aus User-agent, Disallow, Allow, Sitemap und den Wildcards * und $ wirkt einfach, verzeiht aber keine unpräzisen Muster. Ein einziges vergessenes Disallow: / nach einem Relaunch kann wochenlange Rankingverluste verursachen.

Der entscheidende konzeptionelle Punkt ist die klare Trennung zwischen robots.txt und dem noindex-Tag: robots.txt steuert das Crawling, noindex steuert die Indexierung, und beide gemeinsam auf derselben URL führen zu Karteileichen-Einträgen ohne Snippet. Mit regelmäßigen Tests über das URL-Inspection-Tool und curl, einer sauberen Trennung von Crawling- und Indexierungssteuerung sowie einer festen Relaunch-Checkliste bleibt robots.txt ein präzises Werkzeug statt eines Rankingrisikos.

11. FAQ: robots.txt für Magento-Shops