ABAKUS

Nimmt einfach das canonical tag und lass dann gut sein.

Ich würde alles, was mit SessionID in der URI von einem externen Referer aus ankommt an die bereinigte URI per 301 weiter leiten. (Hab ich hier detailierter beschrieben: https://blog.dnaber.de/2009/seofreundli ... ng-in-php/ )

Evtl. noch den Cannonical-metatag einbauen.

Ob man einzelne URIs manuel entfernen kann, weis ich nicht, aber da würde ich mir nicht so ein Kopf drum machen, irgendwann fliegen die schon raus.

xAaron hat geschrieben:Google hat mehrere URLs 5 fach gespeichert, jeweils mit einer unterschiedlichen PHPSESSID-Variable.

Solche Daten haben in der URL nichts verloren - warum, merkst du gerade selbst.

Wie du die URLs aus dem Index kriegst, wurde hier schon genannt und sollte auch dutzendfach im Board zu finden sein. Damit ist aber nicht die Ursache deines Problems beseitigt. Schalte diese nutzlose Funktion am besten ab. Die Anzahl der Besucher, die keine Cookies akzeptieren und nicht in der Lage sind, diesen Umstand bei Bedarf zu ändern, dürfte gegen Null tendieren.

xAaron hat geschrieben:Gibt es dafür einen Königsweg?

Mein Vorschlag:
Bist Du Google? Ja... dann 301 auf URL ohne Session.

Mork vom Ork hat geschrieben:Schalte diese nutzlose Funktion am besten ab. Die Anzahl der Besucher, die keine Cookies akzeptieren und nicht in der Lage sind, diesen Umstand bei Bedarf zu ändern, dürfte gegen Null tendieren.

Nein, leider gegen 2%. Meine Lösung für die Probleme dürfte wirklich der canonical Tag sein. Denn google wird die Seiten die jetzt doppelt im index sind in naher Zukunft mit einer anderen PHPSESSID crawlen, dann feststellen, dass es eine Orginal-Seite gibt und dann sämtliche anderen Dateien mit PHPSESSID aus dem Index schmeißen, da er ja jetzt die Orginal-seite kennt. So weit die Theorie.

Ok, Denkfehler. Aber er könnte sich zumindest bemüßigt fühlen auch die anderen Seiten mit Variable nochmal in Augenschein zu nehmen.

Würde ich auch nicht abschalten. Ich habe mehrere User bei mir in den Communities, die von der Arbeit aus surfen und wo der Arbeitgeber Cookies gänzlich deaktiviert hat.

xAaron hat geschrieben:

Mork vom Ork hat geschrieben:Schalte diese nutzlose Funktion am besten ab. Die Anzahl der Besucher, die keine Cookies akzeptieren und nicht in der Lage sind, diesen Umstand bei Bedarf zu ändern, dürfte gegen Null tendieren.

Nein, leider gegen 2%.

Wie, und die hast du alle gefragt, ob sie nicht in der Lage sind, Cookies bei Bedarf einzuschalten? Oder geht das eher in die Richtung „Die bekommen PHPSESSID zugewiesen, also nehme ich an, dass sie nicht wissen, was Cookies sind“ (obwohl eigentlich andersrum ein Schuh draus wird)?

In der Regel wird aus der ganzen Cookie-Geschichte ein Problem gemacht, das keines ist.

Ein Beispiel habe ich Dir gerade genannt. Und Du wirst es kaum glauben, aber es gibt auch viele, die mit Ihrem Browser nicht umgehen können und die Einstellungen niemals anfassen, weil sie Angst haben was falsch zu machen. Dank 100.000 Mitgliedern aus diversen Foren, habe ich schon meine gewissen Erfahrungen

meint ihr nicht, dass google "PHPSESSID" in der url erkennen und 'ignorieren' kann? zumal das die default einstellung ist und php ja nicht gerade exotisch ist...?

Mork vom Ork hat geschrieben: Wie, und die hast du alle gefragt, ob sie nicht in der Lage sind, Cookies bei Bedarf einzuschalten?

Ich maße mir nicht an, meinem Besucher vorzuschreiben, dass er für mich doch mal bitte seine Einstellungen ändern soll, wenn er denn hier was sehen will. Das hat nix damit zu tun, ob und wie er mit seinem Browser umgehen kann.

nerd hat geschrieben:meint ihr nicht, dass google "PHPSESSID" in der url erkennen und 'ignorieren' kann?

Ob Google es könnte ist doch unwichtig. De facto bleiben die URLs bis heute doppelt im Index, wie ja schon im Ausgangspost steht.

@alle, warum eigentlich die Diskussion über Cookies, das verwirrt ja den armen xaron nur... Die Sumas haben doch *genau* zur Vermeidung solcher Fälle das canonical tag eingeführt. Einbauen und fertig, finde ich.

ishmael hat geschrieben:

Mork vom Ork hat geschrieben:Wie, und die hast du alle gefragt, ob sie nicht in der Lage sind, Cookies bei Bedarf einzuschalten?

Ich maße mir nicht an, meinem Besucher vorzuschreiben, dass er für mich doch mal bitte seine Einstellungen ändern soll

Nun, wenn du nicht fragst, kann dir auch nicht bekannt sein, ob der Besucher sich das vielleicht überlegen würde. Damit wäre die Behauptung, man müsse die ID in den URL-Parametern transportieren, weil die Besucher nicht anders können, ohne Grundlage. Das ist ungefähr so, als wenn man behauptet, alle die mit dem Fahrrad unterwegs sind, können kein Auto fahren.

Man muss natürlich je nach Einsatzzweck abwägen, was sinnvoll ist.
Für ein CMS-Backend oder sicherheitsrelevante Sachen ist das setzen auf Cookies sicher angebracht. Wenn es sich aber um simple Warenkörbe oder ähnliches handelt, warum soll ich die SID nicht in der URI mitgeben, wenn ich merke, dass keine Cookies akzeptiert werden?

Ich gehe immer davon aus, dass der Besucher weis, was er tut und warum er es tut. Dass das nicht immer der Fall ist, das weis ich, aber gegenteiliges Anzunehmen führt zur Bevormundung und zu schlechten Websites.

ishmael hat geschrieben:warum soll ich die SID nicht in der URI mitgeben, wenn ich merke, dass keine Cookies akzeptiert werden?

Weil du in der Masse lediglich Suchmaschinen mit dem Ding belästigst und daraufhin den Ärger hast, den du gerade hast. Natürlich ist es dein Ärger und deine Arbeit und die möchte ich dir auch gerne lassen, wenn sie es dir wert ist; so bin ich ja nun nicht ;)
Ich halte diese Arbeit lediglich für überflüssig, die Begründungen sind falsch oder werden zumindest nicht konsequent eingehalten (siehe unten).

Ich gehe immer davon aus, dass der Besucher weis, was er tut und warum er es tut.

Eben. Wer sich über Nutzen wie auch Missbrauch von Cookies bewusst ist, dürfte auch in der Lage sein, mit einem Klick Cookies nach Bedarf ein- und auszuschalten. Er kennt die Konsequenzen, akzeptiert sie und hat sich darauf eingerichtet.

Das Ganze ist eine Abwägung zwischen dem betreiberseitigen Ärger mit Suchmaschinen und der Annahme eines Maßes der Unfähigkeit seitens des Besuchers, mit seinem Browser umzugehen.

führt zur Bevormundung und zu schlechten Websites.

Cookies vorauszusetzen hat nichts mit Bevormundung oder Anmaßung zu tun. Ich halte sowas für vorgeschobene Begründungen, eigentlich geht es nicht um die Benutzerwünsche, sondern um die Angst des Betreibers, Umsatz zu verlieren.

Warum? Es gibt nur einen Grund, Cookies zu verweigern: Datenschutz. Wer sich rühmt, er handele im Sinne seiner Cookie-verweigernden Besucher, wenn er ihnen die Sitzungs-ID per URL verpasst, der muss das auch konsequent zuende denken und den Datenschutz (und Sicherheit sowieso) ernstnehmen:

1. Keine Vergabe einer ID, solange sie nicht benötigt wird, d.h. solange noch nichts im Warenkorb gelandet ist.
2. Keine Protokollierung der IP-Adresse der Besucher.
3. Koppelung der ID bzw. der Sitzung mit IP-Adresse und Browserkennung. Eine ID in der URL ist grundsätzlich ein Sicherheitsrisiko, denn falls Besucher so eine URL weitergibt, gibt er damit auch den Zugang zu seiner gerade aktiven Sitzung weiter. Nicht gekoppelte IDs in der URL abzulegen ist einfach nur fahrlässig.
4. Gilt nicht für Cookie-Verweigerer, aber dennoch: Keine Verwendung von „temporären“ Cookies (die bei Leuten, die über Tage ihren Browser nicht schließen, das Attribut temporär nicht mehr verdienen), sondern explizites Setzen eines Verfallsdatums.

Das ist dann ordentlicher, durchdachter Schutz im Sinne der Besucher. Anmaßung ist es nur, wenn jemand diese dreieinhalb Punkte nicht beachtet, aber behauptet, er handele mit einer ID-URL im Sinne seiner Besucher. Bevormundung ist es, Besuchern eine ID aufzuzwingen, obwohl sie ausdrücklich keine haben wollen.