Frage URL Parameter per robot.txt ausschließen

[Fleming]

Moin Zusammen,

ich würde mal Meinungen zu folgender Problem-Lösung haben wollen:

Online-Shop generiert Millionen URLs durch Filter, da sich die Filter miteinander kombinieren lassen.

Beispiel:
domain.de/blau
domain.de/grün
domain.de/blau_grün
domain.de/grün_blau
etc. etc.

Diese wurden nun an einer Stelle maskiert mit PRG, sodass Crawler diese erstmal nicht sehen und diesen Folgen. Auf den Artikelseiten können die Filter einzeln weiter verfolgt werden, allerdings ohne die Möglichkeit, mehrere zu kombinieren.

Diese einzelnen Filter (domain.de/blau und domain.de/grün) würden wir als Landingpages benutzen wollen, sodass wir alle Filter-URLs als index follow gesetzt haben.

Da ich nicht 100%ig ausschließen kann, dass ein Crawler nicht doch noch Kombinations-Filter-URLs irgendwo findet, habe ich diese durch eindeutige Parameter gekennzeichnet und diese in der Robot.txt mit "Disallow /*Parameter" ausgesperrt. Im Grunde also nur als Backup.

Hat da jemand eine Einschätzung zu, ob das ein gangbarer Weg ist, um diese Kombinations-URLs vom Index fernzuhalten? Oder lieber komplett alle Filter-URLs auf noindex belassen?

Danke vorab

[arnego2]

Online-Shop generiert Millionen URLs durch Filter, da sich die Filter miteinander kombinieren lassen.

Ich würde das Shopystem wechseln, denn es scheint für euer Vorhaben ungeeignet zu sein.

[staticweb]

Das erste was du verstehen musst ist, dass Crawling und Indexierung 2 verschiedene Dinge sind. Wenn du das Crawling verbietest wird es keine Änderung im Bereich Indexierung geben und der Status bleibt erhalten.

[supervisior]

Ich würde das Shopystem wechseln, denn es scheint für euer Vorhaben ungeeignet zu sein.

Da gibts nix zu wechseln. Das gehört unweigerlich dazu und nennt sich Client Side Includes. Google fischt die URLs entweder aus forms raus oder eben (AJAX) Links. Tu' Dich mal updaten.

[Fleming]

Ich glaube da fehlte etwas Hintergrund: Der Shop ist noch nicht Live.

Es wird einen Relaunch geben, bei dem sich leider alle URLs ändern werden. Wir könnten alle Filter-URLs auf noindex setzen.

Das hat aber den Nachteil, dass es dennoch potentiell Millionen an URLs zu crawlen gäbe für den Bot.

Damit möglichst schnell die richtigen URLs im Index landen und das Crawling-Budget effizienz genutzt wird, werden diese Links maskiert. Um dann doch ein paar hundert gute neue Landingpages zu haben, wollen wir das noindex einfach rausnehmen und als Backup mit der Robot txt das Crawling der Kombinationen verhindern. So bleiben in der Theorie am Ende nur die einfachen Filter-URLs indexierbar und die Kombis sind nicht auffindbar, bzw. wenn doch dann mit Disallow gekennzeichnet.

[MSTnetsolutions]

Es ist immer so eine Sache mit dem steuern der Indexierung, da Google das selbst entscheidet. Auch eine Sperre in der robots.txt ist ja nicht in Stein gemeißelt, aber oft der beste Weg. Kannst Du vor die Filter nicht einen prefix setzen, sowas wie filter_...
Dann könntest du alle URLs mit dem prefix in der robots.txt ausschließen.
Die Filterseiten zusätzlich mit canonical und noindex versehen.
Nur so eine erste Idee.

Gruß
Michael

[staticweb]

> Es wird einen Relaunch geben, bei dem sich leider alle URLs ändern werden.

Ich hoffe ihr wisst was ihr da macht.

> Um dann doch ein paar hundert gute neue Landingpages zu haben, wollen wir das noindex einfach rausnehmen und als Backup mit der Robot txt das Crawling der Kombinationen verhindern.

Die Zeiten Google alles vorzuschreiben sind vorbei. Das kann funktionieren, allerdings sind Quereffekte nicht ausgeschlossen.

[supervisior]

@Fleming

Deine Idee die besagten URLs von der Indexierung auszuschließen, bzw. die robots.txt dafür zu nutzen, lässt sich so nicht machen, weil die robots.txt ein sehr stark beschränktes Limit hat über das Du weit hinausschiesst. Du kannst das wenn überhaupt, dann nur mit Response Header machen, aber das ist auch nur Theorie, weil erstens den no-index Header meines wissens nur Google unterstützt. Und zweitens gibts da ein technisches Problem. Wenn die Filter Funktion genutzt wird und dann augenscheinlich eine neue URL erzeugt wird, dann sind das in der Regel AJAX Requests. Das bedeutet, dass durch den AJAX Request nur die Ansicht in der Listung geändert wird, aber eben nicht die ganze Seite neu geladen wird. Das bedeutet ebenso, dass sich durch den AJAX Request die Header des Haupt Dokuments nicht ändern. Das wäre erst dann möglich, wenn man diese Filter URL direkt aufrufen würde, aber dann ist es schon zu spät. Der no-index Header müsste Bestandteil des AJAX Requests sein, andernfalls hast Du URLs mit und ohne no-index Header je nachdem wie er aufgerufen wird.

[Leo.Zach]

Es ist immer so eine Sache mit dem steuern der Indexierung, da Google das selbst entscheidet. Auch eine Sperre in der robots.txt ist ja nicht in Stein gemeißelt, aber oft der beste Weg. Kannst Du vor die Filter nicht einen prefix setzen, sowas wie filter_...
Dann könntest du alle URLs mit dem prefix in der robots.txt ausschließen.
Die Filterseiten zusätzlich mit canonical und noindex versehen.
Nur so eine erste Idee.

Gruß
Michael

> Dann könntest du alle URLs mit dem prefix in der robots.txt ausschließen.
Die Filterseiten zusätzlich mit canonical und noindex versehen.

Sorry, aber das macht so keinen Sinn. Bei Urls, die via robots.txt ausgeschlossen sind, sieht der Bot nämlich weder die Canonicals noch das "noindex". Die Kombination von Canonicals und "noindex" ist ebenfalls ein Widerspruch.

[nerd]

Online-Shop generiert Millionen URLs durch Filter, da sich die Filter miteinander kombinieren lassen.

Ich würde das Shopystem wechseln, denn es scheint für euer Vorhaben ungeeignet zu sein.

Wieso das? Wenn es pro artikel x verschiedene variationen gibt, dann sollten die ja auch per URL irgendwie erreichbar sein.

[staticweb]

> Sorry, aber das macht so keinen Sinn. Bei Urls, die via robots.txt ausgeschlossen sind, sieht der Bot nämlich weder die Canonicals noch das "noindex". Die Kombination von Canonicals und "noindex" ist ebenfalls ein Widerspruch.

Deshalb sollte jeder die Grundlagen von Crawling, Rendering, Indexierung, Ranking und alle anderen Faktoren die da mit reinspielen immer beachten und bei Bedarf auch noch einmal anschauen. Gerade bei so einem Relaunch kann schnell etwas schief gehen wenn man ein Detail ignoriert.

[staticweb]

> Wieso das? Wenn es pro artikel x verschiedene variationen gibt, dann sollten die ja auch per URL irgendwie erreichbar sein.

Mit dem Hash Bang Pattern und der History API gibt es ja 2 Möglichkeiten auch für AJAX Requests eigene URLs zu erzeugen. Ich finde es auch interessant zu lesen, dass man zu einem Shop-Wechsel rät ohne zu wissen welches Shop-System aktuell verwendet wird. Oder habe ich da was überlesen?

[supervisior]

> Wieso das? Wenn es pro artikel x verschiedene variationen gibt, dann sollten die ja auch per URL irgendwie erreichbar sein.

Mit dem Hash Bang Pattern und der History API gibt es ja 2 Möglichkeiten auch für AJAX Requests eigene URLs zu erzeugen. Ich finde es auch interessant zu lesen, dass man zu einem Shop-Wechsel rät ohne zu wissen welches Shop-System aktuell verwendet wird. Oder habe ich da was überlesen?

Das Shop System ist eigentlich unerheblich, zumal diese Art URLs nicht nur in Filterfunktionen mittlerweilen weitverbreitet sind und zwar erzwungenermaßen, weil nicht nur Shop Systeme, sondern fast jede Art von CMS ansonsten nicht mehr verwendbar wäre. Auch wenn es technische Möglichkeiten gäbe diese URLs in die robots.txt zu schreiben, stellt sich die Frage das zu machen erst gar nicht, eben weil die robots.txt ein ziemlich knappes Limit hat.

[staticweb]

> Auch wenn es technische Möglichkeiten gäbe diese URLs in die robots.txt zu schreiben, stellt sich die Frage das zu machen erst gar nicht, eben weil die robots.txt ein ziemlich knappes Limit hat.

500 Kibibyte (KiB) für eine reine Textdatei halte ich für sehr großzügig.

[supervisior]

500 Kibibyte (KiB) für eine reine Textdatei halte ich für sehr großzügig.

Gemessen an den allgemein üblichen Anforderungen gilt das in jedem Fall. Im konkreten Fall allerdings sind die besagten 500kb nur Peanuts.