WordPress, Wix, Jimdo, Shopify: Vergleich der KI-Crawler-Einrichtung 2026

Wer heute eine Website für WordPress, Wix, Jimdo oder Shopify plant, trifft eine Entscheidung, die weit über Design und Preis hinausgeht: Sie bestimmt, wie leicht sich GPTBot, ClaudeBot oder der Google-Extended-Crawler später steuern lassen. Dieser Vergleich zeigt pro System, was technisch möglich ist, und liefert eine klare Empfehlung je nach Ausgangslage.

Warum die robots.txt-Steuerung je nach System so unterschiedlich ausfällt

Alle vier Systeme erzeugen eine robots.txt-Datei – aber mit völlig unterschiedlichem Grad an Eingriffsmöglichkeit. Das ist kein Nebenschauplatz: Über diese Datei signalisieren Betreiber, ob Crawler wie ClaudeBot ihre Inhalte für Trainingsdaten nutzen dürfen oder ob Agenten wie Claude-User live auf Seiteninhalte zugreifen können, wenn Nutzer Claude direkt befragen. Anthropic beschreibt diese beiden Bot-Typen ausdrücklich getrennt und unterstützt zusätzlich die nicht-standardisierte Crawl-delay-Erweiterung, mit der sich die Zugriffsfrequenz drosseln lässt. Wer nicht weiß, welche Bots überhaupt vorbeischauen, sollte zunächst die Übersicht Welche KI-Bots Ihre Website besuchen – und warum die meisten die falschen sperren lesen, bevor er an Regeln für ein CMS feilt.

Die vier Systeme im Detail: Was technisch möglich ist

WordPress: volle Kontrolle über den robots_txt-Hook

WordPress bietet die größte Tiefe. Über den Filter-Hook robots_txt, aufgerufen per apply_filters( 'robots_txt', $output, $public ), lässt sich die komplette Ausgabe der robots.txt programmatisch verändern. Dieser Hook wird laut WordPress Developer Resources von der internen Funktion do_robots() genutzt, die die Standardversion der Datei ausliefert, und berücksichtigt zusätzlich den Parameter $public, der angibt, ob eine Seite überhaupt als öffentlich sichtbar gilt. In der Praxis heißt das: Jeder, der ein eigenes Plugin schreiben oder eine Code-Snippet-Lösung einsetzen kann, steuert pro User-Agent exakt, was GPTBot, ClaudeBot oder PerplexityBot sehen dürfen – ganz ohne Rücksprache mit einem Hosting-Support.

Shopify: robots.txt.liquid zwischen Flexibilität und Risiko

Shopify generiert standardmäßig eine robots.txt, die laut Shopify.dev für die meisten Shops funktioniert. Wer eigene Regeln braucht, legt eine Datei namens robots.txt.liquid im Templates-Ordner des Themes an – diese ersetzt dann die automatisch generierte Ausgabe vollständig. Zulässig sind laut Dokumentation drei Eingriffsarten: eine Regel zu einer bestehenden Gruppe hinzufügen, eine Regel entfernen oder komplett eigene Regeln ergänzen. Das klingt komfortabel, hat aber einen Haken: Der Shopify Help Center stellt klar, dass der reguläre Support bei Änderungen an dieser Datei nicht helfen kann – dafür muss ein Shopify Partner beauftragt werden. Eine fehlerhafte Anpassung kann laut Anbieter zum vollständigen Verlust des organischen Traffics führen, weil versehentlich ganze Bereiche oder sogar die komplette Domain für Crawler gesperrt werden.

Wix: geschützte Funktion mit Warnhinweis

Wix stuft die Bearbeitung der robots.txt-Datei selbst als „erweiterte Funktion" ein. Wix Support schreibt ausdrücklich, dass Änderungen zu Problemen mit der Website in den Suchergebnissen führen können und dass das Support-Team nicht bei allen Anpassungen helfen kann, die Nutzer selbst vornehmen. Technisch ist die Datei einsehbar, indem man „/robots.txt" an die Root-Domain anhängt – die Bearbeitungsoberfläche existiert also, richtet sich aber an Nutzer, die wissen, was eine Crawl-Direktive bewirkt. Wichtig: Suchmaschinen prüfen die Datei zwar beim Crawlen, eine Garantie, dass eine Seite dadurch tatsächlich gecrawlt oder ausgeschlossen wird, gibt es laut Wix nicht – ungenaue Indexierungsversuche lassen sich damit lediglich verhindern, nicht vollständig steuern.

Jimdo: automatisiert, aber ohne Stellschrauben

Jimdo geht den entgegengesetzten Weg. Laut Jimdo Help Center übernimmt die Plattform automatisch die Erstellung von Sitemap und robots.txt – Nutzer müssen sich darum nicht selbst kümmern. Das reduziert die Einstiegshürde für Einsteiger erheblich, bedeutet im Umkehrschluss aber: Es gibt keine dokumentierte Möglichkeit, einzelne KI-Crawler wie GPTBot oder ClaudeBot gezielt zu blockieren oder freizugeben. Wer auf Jimdo setzt, akzeptiert die Standardkonfiguration des Anbieters.

Vergleichstabelle: KI-Crawler-Tauglichkeit auf einen Blick

Klare Empfehlung je nach Ausgangslage

Die Wahl hängt weniger vom Preis als von der gewünschten Kontrolle ab. Folgende Entscheidungsregeln lassen sich aus den Herstellerangaben ableiten:

• Bereits auf WordPress: Bleiben Sie, nutzen Sie den robots_txt-Hook gezielt für einzelne User-Agents und kombinieren Sie das mit einer Prüfung über ChatGPT-SEO: Bots und Suchindex.
• Shopify-Shop mit Agentur im Hintergrund: Lassen Sie die robots.txt.liquid nur von jemandem anfassen, der vorher eine Kopie der aktuellen Ausgabe sichert und testweise vergleicht – genau das empfiehlt Shopify.dev ausdrücklich vor jeder Veröffentlichung.
• Wix ohne Entwicklerressourcen: Fassen Sie die robots.txt nur an, wenn Sie den Effekt einer Regel verstehen; andernfalls bleiben Sie bei den Standardeinstellungen und konzentrieren sich auf Inhalte, Struktur und Antworten, die über Sichtbarkeit in ChatGPT messbar werden.
• Jimdo als reiner Einstieg: Akzeptieren Sie die Automatik, prüfen Sie stattdessen regelmäßig mit Perplexity als Diagnosewerkzeug, ob Inhalte überhaupt zitiert werden – und planen Sie einen Wechsel, sobald KI-Sichtbarkeit zum strategischen Thema wird.
• Neustart ohne Altlasten: Wer heute komplett neu beginnt und KI-Sichtbarkeit priorisiert, sollte direkt zu einem System mit voller robots.txt-Kontrolle greifen und die technische Basis von Anfang an sauber aufsetzen, statt später nachzurüsten.

Praxisbeispiel: Vom Baukasten zum angepassten System

Beispiel: Ein Handwerksbetrieb betreibt seit Jahren eine Jimdo-Seite mit Leistungsübersicht und Kontaktformular. Die automatisch erzeugte robots.txt lässt alle Standard-Crawler zu, es gibt aber keine Möglichkeit, etwa einen aggressiven Trainings-Crawler gezielt zu drosseln oder einen Live-Agenten wie Claude-User bevorzugt zuzulassen. Der Betrieb entscheidet sich für einen Umzug auf WordPress, weil dort über den robots_txt-Hook einzelne Regeln ergänzt werden können – etwa ein Crawl-delay für ClaudeBot, wie ihn Anthropic als nicht-standardisierte Erweiterung unterstützt. Zur Einordnung: Ein Crawl-delay von 1 Sekunde begrenzt die maximale Zugriffsfrequenz rechnerisch auf höchstens 60 Zugriffe pro Minute – unabhängig davon, wie häufig der jeweilige Crawler ohne diese Vorgabe zugreifen würde. Ob und in welchem Umfang sich dadurch im Einzelfall tatsächlich Serverlast abfedern lässt, ist durch keine der hier herangezogenen Quellen belegt und hängt von der tatsächlichen Zugriffshäufigkeit des jeweiligen Bots sowie der Leistungsfähigkeit des Hostings ab. Dieser Schritt ersetzt keine inhaltliche Optimierung, schafft aber die technische Voraussetzung dafür, dass Crawler die Seite überhaupt zuverlässig erreichen.

Einschätzung: Wo die Baukästen an ihre Grenzen stoßen

Einschätzung: Die Diskussion um robots.txt-Feinsteuerung wird in der Praxis oft überschätzt, weil sie nur die halbe Wahrheit abbildet. Wichtiger als die perfekte Crawler-Regel ist meist, ob Inhalte überhaupt in einer Form vorliegen, die ein Sprachmodell zitierfähig findet – strukturierte Antworten, klare Fakten, nachvollziehbare Quellen. Gleichzeitig zeigt die Recherche, dass Google selbst inzwischen Entwarnung bei einer vermeintlichen Pflichtdatei gibt: Laut Search Engine Journal bezeichnete John Mueller eine spezielle llms.txt-Datei als „rein spekulativ" und verwies stattdessen auf den von Google unterstützten Ansatz WebMCP; Google Search Central stellt zudem klar, dass Publisher keine solchen Spezialdateien benötigen, um in generativen KI-Sucherlebnissen aufzutauchen. Wer also Budget in eine komplizierte CMS-Migration allein wegen robots.txt-Feinheiten steckt, sollte zuerst die inhaltliche Seite prüfen – notfalls im Rahmen eines kostenlosen Erstgesprächs.

Häufige Fragen