WordPress robots.txt richtig einrichten: Diese Ordner nie sperren

Kurze Antwort
Wie sollte die WordPress robots.txt richtig aussehen?
Die WordPress robots.txt sollte kurz bleiben: Sie sperrt für alle Bots das Dashboard unter wp-admin, erlaubt die Datei admin-ajax.php und nennt die Adresse Ihrer Sitemap. Zudem darf sie wp-content und wp-includes nicht blockieren, denn Google braucht die dort gespeicherten CSS und JavaScript Dateien, um Ihre Seiten korrekt darzustellen.
Die WordPress robots.txt ist eine kleine Textdatei, die kaum ein Seitenbetreiber jemals öffnet. Allerdings kann eine einzige falsche Zeile verhindern, dass Google die Stylesheets Ihres Themes lädt. Dann bewertet Google eine kaputte Version Ihrer Seiten. In diesem Leitfaden erklären wir, Talha Aslan und Team, wie WordPress diese Datei erzeugt, welche Ordner Sie nie sperren sollten und wie eine sichere Grundkonfiguration aussieht. Wenn Sie die Regeln nicht von Hand schreiben möchten, erstellt unser kostenloser robots.txt Generator in wenigen Klicks einen sauberen Entwurf.
Anders gesagt: Eine gute Datei misst sich nicht daran, wie viel sie sperrt. Sie misst sich daran, wie wenige Fehler sie enthält. In unserer Praxis ist das häufigste Problem keine fehlende Regel. Stattdessen ist es eine überflüssige Regel. Lange Listen aus alten Anleitungen sperren oft Ressourcen, die Google heute zum Rendern braucht. Deshalb erklären wir im Folgenden, warum jede Zeile dort steht. Falls Ihnen die Grundlagen neu sind, lesen Sie zunächst unseren Beitrag was robots.txt ist und wie Sie sie erstellen. Hier konzentrieren wir uns nur auf WordPress.
Warum finden Sie die WordPress robots.txt nicht auf dem Server?
Viele Betreiber tippen /robots.txt hinter ihre Domain und sehen einen Inhalt. Danach öffnen sie den Dateimanager und finden nichts. Der Grund ist einfach. Wenn im Hauptverzeichnis keine physische robots.txt liegt, beantwortet WordPress die Anfrage selbst und erzeugt den Inhalt dynamisch. Die WordPress Entwicklerreferenz zeigt, dass eine Funktion namens do_robots diese Aufgabe übernimmt (offizielle WordPress Referenz).
Es gibt also zwei Fälle. Erstens die virtuelle Datei, deren Inhalt WordPress und Plugins im Code festlegen. Zweitens die physische Datei. Sobald Sie eine robots.txt auf den Server laden, liefert der Webserver diese direkt aus, und WordPress greift nicht mehr ein. Zum Beispiel: Wenn eine Änderung in einem Plugin live nicht erscheint, liegt vermutlich eine alte physische Datei im Hauptverzeichnis. Außerdem passiert das häufig nach Umzügen und Themewechseln.
- Die Adresse funktioniert, aber es gibt keine Datei: Sie nutzen die virtuelle Datei.
- Eine Datei existiert und Plugineinstellungen greifen nicht: Die physische Datei hat Vorrang.
- Beides fehlt und die Adresse liefert 404: Prüfen Sie Permalinks oder Umleitungsregeln des Servers.
Welche Zeilen enthält die virtuelle WordPress robots.txt standardmäßig?
Die Standardausgabe von WordPress ist sehr schlank. Die erste Zeile lautet User-agent: * und richtet sich an alle Bots. Danach folgt eine Disallow Zeile für den Pfad des Dashboards und eine Allow Zeile, die admin-ajax.php freigibt. WordPress berechnet diese Pfade aus Ihrer Adminadresse. Folglich enthält der Pfad auch den Unterordner, falls WordPress in einem Unterordner läuft.
Zudem kann der Core eine Sitemap Zeile ergänzen, wenn die eingebaute WordPress Sitemap aktiv ist. Nutzt ein SEO Plugin seine eigene Sitemap, verwaltet meist das Plugin diese Zeile. Kurz gesagt: Die Standardausgabe ist bereits ein sinnvoller Anfang. In den meisten Fällen behalten wir diesen Kern der WordPress robots.txt und ergänzen nur die wenigen Zeilen, die eine Website wirklich braucht.
Ein kleines, aber wichtiges Detail: Regeln in der robots.txt unterscheiden Groß und Kleinschreibung. Ein Pfad mit großen Buchstaben gilt also als anderer Pfad. Deshalb sollten Sie Pfade exakt so übernehmen, wie WordPress sie verwendet.
Warum gibt es die Ausnahme für admin-ajax.php?
Das Dashboard bietet Bots keinen nützlichen Inhalt, daher ist es sinnvoll, wp-admin zu sperren. Allerdings liegt admin-ajax.php in diesem Ordner und dient nicht nur Administratoren. Viele Themes und Plugins nutzen die Datei auf öffentlichen Seiten. Formulare, Filter, Warenkorbelemente und Schaltflächen zum Nachladen laufen oft darüber.
Zum Beispiel füllt sich eine Produktliste manchmal erst, nachdem die Seite diese Datei aufgerufen hat. Sperren Sie den ganzen Ordner ohne Ausnahme, kann Google diesen Aufruf beim Rendern nicht ausführen. Dann übersieht Google womöglich einen Teil Ihres Inhalts. Genau deshalb setzt WordPress die Zeile Allow: /wp-admin/admin-ajax.php selbst in die Standardausgabe. Schreiben Sie Ihre eigene Datei, behalten Sie diese Ausnahme bei.
Wie löst Google also zwei widersprüchliche Regeln auf? Die Details folgen weiter unten. Kurz geantwortet: Die längere und damit spezifischere Regel gewinnt. Die Allow Zeile beschreibt einen längeren Pfad und hebt daher die Disallow Zeile für genau diese Datei auf.
Warum sollten Sie wp-content und wp-includes nie sperren?
Ältere WordPress Anleitungen empfahlen oft, wp-content und wp-includes komplett zu sperren. Heute ist dieser Rat ein ernster Fehler. Stylesheets, Schriften, Bilder und das JavaScript für interaktive Elemente liegen in diesen Ordnern. Google bewertet Seiten dagegen, indem es sie ähnlich wie ein Browser rendert.
Die offizielle robots.txt Dokumentation von Google sagt klar, dass Sie keine Ressourcen sperren sollten, die das Verständnis einer Seite erschweren (Google Search Central). Sind diese Ressourcen blockiert, sieht Google Ihre Seite womöglich ohne Styles, mit zerschossenem Layout oder mit fehlendem Inhalt. Somit können Mobilfreundlichkeit und Inhaltsverständnis leiden.
- Der Ordner themes unter
wp-content: Hier liegen Styles und Skripte des Themes. - Im Ordner uploads liegen Ihre Bilder; gesperrt verschwinden sie auch aus der Bildersuche.Der Ordner plugins: Hier liegen die Frontenddateien Ihrer Plugins.
wp-includes: Hier liegen gemeinsame JavaScript Bibliotheken von WordPress.
Kurz gesagt: Schreiben Sie für diese Ordner keine Disallow Zeile. Selbst wenn ein Pluginordner scheinbar unnötige Anfragen erzeugt, prüfen Sie zuerst die Ursache. Eine pauschale Sperre schadet fast immer mehr, als sie nützt.
Wie liest Google die Regeln der WordPress robots.txt?
Die robots.txt Spezifikation von Google beruht auf wenigen Grundregeln (Google robots.txt Spezifikation). Zunächst wählt Google die User-agent Gruppe, die am besten passt, und befolgt nur diese. Gibt es zum Beispiel eine Gruppe User-agent: * und eine Gruppe User-agent: Googlebot, folgt Googlebot nur der Gruppe mit seinem Namen.
Danach gilt: Widersprechen sich Allow und Disallow für dieselbe Adresse, gewinnt die Regel mit dem längsten Pfad. Sind beide Pfade gleich lang, wählt Google die weniger restriktive Regel, also Allow. Zudem setzt Google eine Größengrenze für die Datei und speichert sie eine Zeit lang zwischen. Prüfen Sie die aktuelle Grenze und Cachedauer in der Dokumentation von Google.
- Die spezifischste Gruppe gewinnt: Eine eigene Googlebot Gruppe bedeutet, dass die allgemeinen Regeln für ihn nicht mehr gelten.
- Der längste Pfad gewinnt: Deshalb funktioniert die Ausnahme für
admin-ajax.php. - Google unterstützt keine noindex oder Crawl-delay Zeilen in der robots.txt.
- Pfade unterscheiden Groß und Kleinschreibung.
Diese Regeln sind vor allem dann wichtig, wenn Sie eigene Botgruppen anlegen. Der häufigste Fehler, den wir sehen: eine eigene Googlebot Gruppe, in der die Regel für das Dashboard fehlt.
Welche Zeilen der WordPress robots.txt sind sicher?
Die folgende Tabelle fasst zusammen, welche Zeilen Sie auf einer typischen WordPress Website sicher nutzen können und welche Sie meiden sollten. Verstehen Sie sie als Checkliste, denn jede Website hat eigene Anforderungen.
| Zeile | Wirkung | Unsere Empfehlung |
|---|---|---|
User-agent: * | Gilt für alle Bots. | Verwenden |
Disallow: /wp-admin/ | Hält Crawler aus dem Dashboard fern. | Verwenden |
Allow: /wp-admin/admin-ajax.php | Gibt die AJAX Datei für das Frontend frei. | Immer verwenden |
Sitemap: https://example.com/sitemap.xml | Nennt den Ort der Sitemap. | Verwenden, mit voller Adresse |
Disallow: /wp-content/ | Sperrt Themes, Plugins und Bilder. | Nie verwenden |
Disallow: /wp-includes/ | Sperrt gemeinsame JavaScript Dateien. | Nie verwenden |
Disallow: /tag/ | Stoppt das Crawling der Schlagwortarchive. | Besser noindex nutzen |
Disallow: / | Sperrt die gesamte Website. | Nur auf Testumgebungen |
Die Domain in der Tabelle ist nur ein Beispiel. Setzen Sie Ihre eigene Domain und die echte Adresse Ihrer Sitemap ein. In der Sitemap Zeile gehört immer eine vollständige Adresse mit Protokoll, kein relativer Pfad.
Sollten Sie Suchergebnisse und Schlagwortseiten per robots.txt sperren?
Interne Suchergebnisse, Schlagwortarchive und dünne Datumsarchive möchten Sie vielleicht nicht im Index sehen. Allerdings bringt eine Sperre per robots.txt nicht das erwartete Ergebnis. Die robots.txt stoppt das Crawling, nicht die Indexierung. Google kann eine gesperrte Adresse trotzdem indexieren, wenn andere Websites darauf verlinken.
Außerdem verbirgt eine gesperrte Seite ihr noindex Tag vor Google. Der richtige Weg ist daher: Seite crawlbar lassen und noindex setzen. Den Unterschied erklären wir ausführlich in unserem Vergleich von noindex, nofollow und robots.txt.
- Interne Suchergebnisse: Setzen Sie noindex über Ihr SEO Plugin.
- Schlagwortarchive: Setzen Sie noindex, wenn sie keinen Mehrwert bieten, oder vereinfachen Sie Ihre Schlagwörter.
- Anhangseiten: Leiten Sie sie auf die eigentliche Datei weiter.
Zu Anhangseiten finden Sie mehr in unserem Beitrag über WordPress Anhangseiten und SEO. Nutzen Sie die robots.txt dagegen für ihre eigentliche Aufgabe, nämlich die Steuerung des Crawlings.
Was bewirkt die Einstellung "Suchmaschinen davon abhalten, diese Website zu indexieren"?
Dieses Kästchen in den Leseeinstellungen von WordPress verwechseln viele mit der robots.txt. Laut WordPress Referenz fügten ältere Versionen bei aktivem Kästchen eine Zeile in die virtuelle robots.txt ein, die die ganze Website sperrte. Neuere Versionen haben dieses Verhalten entfernt. Stattdessen setzt WordPress nun über das Robots Meta Tag den Wert noindex.
Ist das Kästchen aktiv, wirkt Ihre robots.txt also harmlos, während Ihre gesamte Website noindex trägt. Das passiert oft, wenn eine Testumgebung live geht und niemand das Kästchen deaktiviert. Falls Ihnen das bekannt vorkommt, folgen Sie den Schritten in unserem Beitrag wenn das Abhalten von Suchmaschinen aktiviert blieb.
Prüfen Sie daher bei einem Audit der WordPress robots.txt nicht nur die Datei. Sehen Sie sich auch die Leseeinstellungen und das Robots Meta Tag im Quelltext an. Ist die Datei sauber und das Kästchen aktiv, liegt das Problem nicht in der Datei.
Wie nutzen Sie den robots.txt Editor Ihres SEO Plugins?
Viele verbreitete SEO Plugins erlauben es, die robots.txt im Dashboard zu bearbeiten. Diese Editoren arbeiten meist auf eine von zwei Arten. Manche ändern die virtuelle Ausgabe. Andere schreiben eine physische Datei ins Hauptverzeichnis. Welche Variante gilt, erfahren Sie in der Dokumentation Ihres Plugins.
In der Praxis ist ein Punkt entscheidend: Nutzen Sie immer nur eine Methode. Liegt zum Beispiel eine alte physische Datei im Hauptverzeichnis, während Sie im Plugin bearbeiten, gehen Ihre Änderungen nie live. Zudem können zwei Plugins, die derselben Ausgabe Zeilen hinzufügen, verwirrende Ergebnisse erzeugen, etwa doppelte Sitemap Zeilen.
- Sichern Sie vor jeder Änderung eine Kopie der aktuellen Ausgabe.
- Schreiben Sie im Editor nur die Zeilen, die Sie wirklich brauchen.
- Öffnen Sie nach dem Speichern die Liveadresse und prüfen Sie das Ergebnis.
Physische oder virtuelle Datei: Was ist besser?
Beide Varianten haben ihren Platz. Die virtuelle Datei ist pflegeleicht, weil WordPress die Pfade berechnet und Plugins die Sitemap Zeile verwalten. Eine physische Datei gibt Ihnen volle Kontrolle. Allerdings müssen Sie sie nach einem Umzug oder einem geänderten Unterordner von Hand anpassen.
| Kriterium | Virtuelle Datei | Physische Datei |
|---|---|---|
| Wer verwaltet sie? | WordPress und Plugins | Sie selbst, per Dateimanager oder FTP |
| Sitemap Zeile | Oft automatisch | Von Hand ergänzen |
| Risiko nach Umzug | Gering | Alte Pfade bleiben eventuell stehen |
| Vorrang | Inaktiv, wenn eine physische Datei existiert | Wird immer zuerst ausgeliefert |
Für die meisten kleinen und mittleren Websites empfehlen wir die virtuelle Datei. Eine physische Datei lohnt sich eher bei mehrsprachigen Strukturen, komplexen Filtern oder eigenen Botregeln. So oder so: Behalten Sie eine einzige verlässliche Quelle.
Wie richten Sie die WordPress robots.txt Schritt für Schritt ein?
Wenn Sie dieser Reihenfolge folgen, erhalten Sie eine Datei, die sicher und leicht zu pflegen ist. Wir haben die Schritte so angelegt, dass Ihre Website dabei nicht beschädigt wird.
- Hängen Sie /robots.txt an Ihre Domain, öffnen Sie die aktuelle Ausgabe und sichern Sie eine Kopie.
- Prüfen Sie im Dateimanager, ob im Hauptverzeichnis eine physische robots.txt liegt.
- Stellen Sie sicher, dass das Kästchen zum Abhalten von Suchmaschinen in den Leseeinstellungen deaktiviert ist.
- Erstellen Sie den neuen Inhalt mit unserem robots.txt Generator, inklusive Dashboardregel, Ausnahme für
admin-ajax.phpund Sitemap Adresse. - Setzen Sie den Inhalt nur an einer Stelle um: im Editor Ihres SEO Plugins oder in der physischen Datei.
- Öffnen Sie die Liveadresse erneut und prüfen Sie, ob die neuen Zeilen erscheinen.
- Prüfen Sie mit dem robots.txt Bericht in der Search Console, wie Google die Datei liest.
Für den letzten Schritt hilft Ihnen unser Beitrag den robots.txt Bericht der Search Console lesen. Somit sehen Sie, dass auch Google die Änderung korrekt erkennt.
Wie fügen Sie die Sitemap Zeile in die WordPress robots.txt ein?
Die Sitemap Zeile zeigt Google, wo Ihre Sitemap liegt. Sie gehört zu keiner User-agent Gruppe und darf daher überall in der Datei stehen. Der Lesbarkeit halber setzen wir sie dennoch meist ans Ende. Die Adresse muss vollständig sein, also Protokoll und Domain enthalten.
Laufen die eingebaute WordPress Sitemap und die Sitemap Ihres SEO Plugins gleichzeitig, entscheiden Sie sich für eine. Nennen Sie dann nur diese in der robots.txt. Haben Sie mehrere Sitemaps, dürfen Sie mehrere Sitemap Zeilen schreiben. Fehlt Ihnen eine Sitemap, hilft unser XML Sitemap Generator.
Allerdings garantiert eine Sitemap Zeile allein keine Indexierung. Sie hilft Google nur beim Entdecken Ihrer Adressen. Deshalb lohnt es sich, die Sitemap zusätzlich in der Search Console einzureichen.
Welche WordPress Adressen gehören nie in die robots.txt?
Manche Zeilen wirken auf den ersten Blick wie Sicherheitsmaßnahmen, schaden aber. Tragen Sie etwa Ihre Loginseite oder eine versteckte Adminadresse in die robots.txt ein, verraten Sie diese Adresse allen. Die robots.txt ist öffentlich, und bösartige Bots halten sich ohnehin nicht an ihre Regeln.
- Login oder Adminadressen, die geheim bleiben sollen.
- Die Ordner
wp-content,wp-includesund uploads. - Seiten, die Sie aus dem Index entfernen möchten und die bereits noindex tragen.
- Doppelte Adressen, die Sie schon per Canonical Tag steuern.
Setzen Sie für die Sicherheit daher auf starke Passwörter, Zweifaktorauthentifizierung und aktuelle Plugins, nicht auf die robots.txt. Bei doppeltem Inhalt und Parameteradressen ist das Canonical Tag oft das bessere Werkzeug. Für Sonderfälle wie Filterseiten lesen Sie unseren Beitrag über Facettennavigation und robots.txt.
Wann sollten Sie in WordPress Platzhalter verwenden?
Google unterstützt in robots.txt Regeln den Stern und das Dollarzeichen. Der Stern steht für eine beliebige Zeichenfolge, das Dollarzeichen für das Ende einer Adresse. In WordPress helfen diese Zeichen vor allem bei Adressen mit endlosen Parametern. Erzeugen etwa Sortier oder Filterparameter Tausende Adressen, möchten Sie das Crawling dort womöglich begrenzen.
Allerdings kann ein fehlerhafter Platzhalter einen viel größeren Bereich sperren als geplant. Testen Sie daher jede Platzhalterregel nach dem Schreiben mit einigen echten Adressen. Ausführliche Beispiele finden Sie in unserem Leitfaden zu robots.txt Platzhaltern.
Kurz gesagt: Eine typische Unternehmenswebsite mit WordPress braucht meist gar keinen Platzhalter. In Onlineshops und gefilterten Katalogen setzen Sie ihn also sorgfältig und sparsam ein.
Wie testen Sie die robots.txt nach einer Änderung?
Ohne Test bleibt ein kleiner Tippfehler oft wochenlang unbemerkt. Öffnen Sie zunächst die Liveadresse im Browser und prüfen Sie, ob die Datei als reiner Text mit den erwarteten Zeilen erscheint. Danach prüfen Sie im robots.txt Bericht der Search Console, welche Version Google zuletzt abgerufen hat und ob Fehler auftreten.
Anschließend testen Sie einige wichtige Seiten mit dem URL Prüftool. Kontrollieren Sie, ob die Stylesheets in der gerenderten Ansicht laden. So erkennen Sie sofort, ob Sie CSS oder JavaScript versehentlich gesperrt haben. Zudem eignet sich unser Beitrag über häufige robots.txt Fehler als Checkliste.
- Liefert die Liveadresse reinen Text?
- Ist
admin-ajax.phpfreigegeben? - Laden die Themedateien in der gerenderten Seite?
- Zeigt die Sitemap Zeile auf die richtige Adresse?
Brauchen KI Crawler eigene Regeln?
Manche Betreiber möchten nicht, dass ihre Inhalte zum Training von KI Modellen dienen. Mehrere dieser Crawler geben an, dass sie die robots.txt unter eigenen User-agent Namen beachten. Daher können Sie Ihrer WordPress robots.txt auf Wunsch eigene Gruppen für diese Bots hinzufügen.
Allerdings greift hier wieder die Regel von oben. Ein Bot mit eigener Gruppe befolgt die Regeln der allgemeinen Gruppe nicht. Wiederholen Sie also die nötigen Regeln in der neuen Gruppe. Welcher Bot was tut und wie Sie sie unterscheiden, erklären wir im Beitrag über KI Crawler und robots.txt. Achten Sie bei Ihrer Entscheidung darauf, keine Bots zu sperren, die Ihre Sichtbarkeit in der Suche beeinflussen.
Was ändert sich bei mehrsprachigen Websites und Unterordnern?
Die robots.txt gilt nur im Hauptverzeichnis eines Hosts. Auch wenn WordPress in einem Unterordner läuft, sucht Google die Datei also im Stammverzeichnis der Domain. Dann muss die Datei dort die richtigen WordPress Pfade enthalten.
Außerdem hat jede Subdomain ihre eigene robots.txt. Liegt etwa Ihr Blog auf einer Subdomain und Ihr Shop auf der Hauptdomain, verwalten Sie zwei getrennte Dateien. Bei mehrsprachigen Websites ist es fast nie richtig, Sprachordner zu sperren. Steuern Sie Sprachversionen stattdessen mit hreflang. Kurz gesagt: Prüfen Sie das Hauptverzeichnis jedes Hosts einzeln.
Auf Test und Stagingumgebungen ist es umgekehrt. Dort kann es sinnvoll sein, die ganze Website zu sperren. Denken Sie dann aber daran, diese Zeile beim Livegang zu entfernen. Dieser Fehler gehört zu den häufigsten Ursachen für Trafficverluste nach einem Umzug.
Braucht ein WooCommerce Shop eine andere WordPress robots.txt?
In einem WooCommerce Shop ändert sich die Grundkonfiguration nicht. Das Dashboard bleibt gesperrt, admin-ajax.php bleibt offen, und Themedateien bleiben erreichbar. Allerdings erzeugen Shops deutlich mehr dynamische Adressen. Warenkorb, Kasse und Kundenkonto sind für jeden Besucher persönlich und haben in den Suchergebnissen keinen Wert. Zudem erzeugen Links zum Hinzufügen in den Warenkorb Parameteradressen, die Crawling verschwenden können.
Deshalb kombinieren wir in Shops zwei Ansätze. Erstens setzen wir noindex auf persönliche Seiten wie Warenkorb und Kasse; viele SEO Plugins erledigen das bereits. Zweitens schreiben wir eine maßvolle Disallow Regel nur für Parameter, die endlose Adressen erzeugen. Konkret senkt eine Sperre für Adressen mit dem Warenkorbparameter unnötiges Crawling, ohne die Produktseiten zu berühren.
Andererseits sollten Sie Produktbilder und Kategorieseiten nie sperren. Diese Seiten tragen den Suchtraffic Ihres Shops. Zusammengefasst gilt auch hier: Lassen Sie alles offen, was Besuchern nützt, und begrenzen Sie nur Adressen, die endlose Kopien erzeugen.
Wie schadet ein robots.txt Fehler dem Traffic, und wie bemerken Sie ihn?
Das Tückische an robots.txt Fehlern: Für Besucher sieht die Website völlig normal aus. Seiten öffnen sich, Formulare funktionieren. Im Hintergrund kann Google die Seiten jedoch nicht sehen. Deshalb bemerken Sie die Anzeichen meist in den Daten der Search Console. Zum Beispiel sinken die Impressionen innerhalb weniger Tage deutlich, oder der Bericht zur Seitenindexierung zeigt mehr durch robots.txt blockierte Adressen.
Ein weiteres Anzeichen sind Suchergebnisse ohne Beschreibung. Behält Google eine Seite im Index, kann ihren Inhalt aber nicht sehen, erscheint statt eines Snippets womöglich ein ähnlicher Hinweis, dass keine Informationen verfügbar sind. Sehen Sie dieses Muster, prüfen Sie zuerst Ihre robots.txt und das Datum der letzten Änderung.
- Plötzlicher, unerklärlicher Rückgang der Impressionen.
- Mehr robots.txt Sperren im Indexierungsbericht.
- Eine Ansicht ohne Styles in der gerenderten Seite.
- Suchergebnisse ohne Beschreibung.
Nehmen Sie die robots.txt daher nach jedem größeren Theme, Plugin oder Serverwechsel in Ihre Checkliste auf. Diese einfache Gewohnheit hilft Ihnen, einen Sichtbarkeitsverlust früh zu erkennen, bevor er wochenlang anhält.
Können alte Zeilen in der robots.txt Probleme verursachen?
Auf WordPress Websites, die seit Jahren online sind, wächst die robots.txt oft Schicht um Schicht. Jedes neue Plugin, jeder Berater und jeder Forumstipp fügt eine Zeile hinzu, und niemand entfernt die alten. Schließlich sammeln sich Regeln für längst gelöschte Ordner, Tippfehler und Zeilen, die Google nicht unterstützt.
Zum Beispiel ignoriert Google die Zeile Crawl-delay und unterstützt auch keine noindex Zeile in der robots.txt. Solche Zeilen wirken harmlos, vermitteln aber ein falsches Gefühl von Kontrolle. Außerdem kann eine Regel für den Ordner eines entfernten Plugins eines Tages eine neue Struktur mit gleichem Namen sperren.
Gehen Sie die Datei deshalb mindestens einmal im Jahr Zeile für Zeile durch. Fragen Sie sich bei jeder Zeile: Welches Problem löst diese Regel heute? Können Sie das nicht beantworten, entfernen Sie die Zeile und beobachten Sie das Ergebnis in der Search Console. Zudem lohnt sich ein kurzes Änderungsprotokoll mit Datum, besonders wenn mehrere Personen an der Website arbeiten.
Kurze Checkliste: eine sichere Grundkonfiguration
Fassen wir den Leitfaden in einer Liste zusammen, ist die folgende Konfiguration für eine typische WordPress robots.txt auf den meisten Websites ein sicherer Anfang. Prüfen Sie dann jeden Punkt anhand der Anforderungen Ihrer eigenen Website.
- Legen Sie eine allgemeine Gruppe für alle Bots an.
- Sperren Sie das Dashboard und behalten Sie die Ausnahme für
admin-ajax.php. - Lassen Sie
wp-contentundwp-includesunangetastet. - Nennen Sie Ihre Sitemap mit vollständiger Adresse.
- Nutzen Sie noindex für Seiten, die aus dem Index sollen.
- Testen Sie nach jeder Änderung mit der Search Console.
Möchten Sie diesen und weitere Bereiche des technischen SEO gemeinsam angehen, prüft unsere SEO Beratung die Crawling und Indexierungsstruktur Ihrer Website von Anfang bis Ende. Für die meisten WordPress Websites reichen allerdings die obige Grundkonfiguration und eine regelmäßige Testgewohnheit aus.
Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.



