Manchmal zeigen sich neue Probleme, bei denen man auch nach jahrelanger Erfahrung mit CMS-Konfigurationen wie ein Ochse vor dem Berg steht. Bei mir war das kürzlich der Fall, als ich in WP 5.2.3. eine neue Seite, in der ich mit dem Elementor diverse Layouts ausprobiert hatte, auf ihre Responsivität testen wollte. Da kam die Fehlermeldung, dass kein Botzugriff möglich sei. Dieselbe Fehlermeldung zeigt sich in der Search Console. Die Begründung: Sperrung durch die Robots.txt-Datei.
Hä, kann doch gar nicht sein. Gleich die Robots.txt aufgerufen – dort war alles ok, nur die Admin-Bereiche waren gesperrt. Es handelte sich noch die virtuelle Robots, die vom System in /wp-includes/functions.php eigens erstellt wird und bei einer falschen Einstellung im Backend problematisch wird. Problematisch vor allem deshalb, weil sie im Rootverzeichenis gar nicht auftaucht. Die Datei überschrieb ich erfolgreich mit einer Robots.txt ganz ohne Disallows, in der nur die erste Zeile für den “User-agent: *” stand. Dumm war nur, dass die Sperre blieb – sowohl bei Google als auch anderen online Testtools. Browser-Cache geleert, Cache in wordpress geleert – nichts half.
Der Support meines Hosters (allinkl.com) war diesmal ebenso ratlos. Also installierte ich testweise ein blankes neues WP mit den wichtigsten Voreinstellungen auf dem Server und in WP. Dazu gehörte neben der passenden PHP-Version auch SSL, damit die Webseite im Browser nur noch über HTTPS aufgerufen würde. X-mal durchgegangen diese Routinen. Nur: Wieder kein Bot-Zugriff wegen Robots.txt-Einstellungen. Der Support checkte nochmals alle Verzeichnisse – ergebnislos, keine Fehler bei der Installation etc. Testweise stellte er aber dann die SSL-Einstellungen zurück. Mit dem Resultat: Ab dem Moment war die Zugriff wieder erlaubt.
Der Support empfahl mir das Plugin “Better Search Replace” zu und dann den Einstellungen für WordPress auf der Website des Providers zu folgen. Die Hilfe findest du hier: