Nutzerprofile / Nutzerverzeichnis in robots.txt / x-robots-tag Header

Fehler
1

EDIT: Dies stellt sich als ein Fehler heraus, siehe Beitrag #3

Wenn „Benutzerprofile vor der Öffentlichkeit verbergen“ aktiviert ist, sollte /u dann nicht in der robots.txt verboten werden?
Andernfalls erhalten Suchmaschinen eine 403-Antwort, was sich auf das Ranking und die Sichtbarkeit auswirken könnte.

Dies wurde angeblich 2014 implementiert: Excluding user profiles in robots.txt (or allow edit of file) - #2 by neil Disallow /users/ in robots.txt · discourse/discourse@8267a45 · GitHub

Das einzige Discourse-Forum, das ich finden konnte, das Disallow: /u hat, ist Meta :thinking:

2

[quote=“RGJ, post:1, topic:395780”]Das einzige Discourse-Forum, das ich finden konnte, das Disallow: /u hat, ist Meta :thinking:
[/quote]
Vielleicht wurde Meta angepasst, sodass die Migration in FIX: Remove /u/ from robots by nattsw · Pull Request #30782 · discourse/discourse · GitHub übersprungen wurde

3

Guter Fund @Moin

Derzeit fügen wir bereits noindex zu /u-Routen hinzu. Da dies jedoch durch robots.txt blockiert wird, können Suchmaschinen den Header nicht sehen.

Dann wird auf eine frühere Änderung verwiesen: FIX: Always noindex /u routes by nattsw · Pull Request #27712 · discourse/discourse · GitHub

welche besagt:

Zweitens löst SiteSetting.hide_user_profiles_from_public ein Forbidden aus, was verhindert, dass unser after_action: add no index header ausgelöst wird.

Dieser PR stellt sicher, dass der no index Header stattdessen über before_action hinzugefügt wird. Wir sollten in Betracht ziehen, /u von

discourse/app/controllers/robots_txt_controller.rb

Zeile 24 in 2900cbe

DISALLOWED_WITH_HEADER_PATHS = %w[/badges /u/ /my /search /tag//l /g /t//.rss /c/.rss]

Leider funktioniert das nicht immer. Während /u/rgj einen x-robots-tag: noindex Header hat, hat /u/rgj/summary keinen, sodass es scheint, als hätte die jüngste Änderung einige unerwünschte Nebenwirkungen.

(Verschoben nach Bug)

1 „Gefällt mir“