ufreier Posted December 17, 2010 Report Share Posted December 17, 2010 Hi, nach der Aktivierung von SEO-URLs hängt die Software an die Links in der Navigation teilweise irgendwelche (ich denke mal ziemlich sinnfreie) Query-Strings an, also z.B.: www.domain.tld/schoener/seo/url/pfad.html?x7659f=eptjsq3177gc4jv0ctirbctac710d3 Wie bekommt man das denn weg? Ist ja eigentlich nicht im Sinne der SEO-URLs. Gruß, Uwe Link to comment Share on other sites More sharing options...
mzanier Posted December 17, 2010 Report Share Posted December 17, 2010 das sind session ids, je nach browser einstellungen müssen diese angehängt werden. Auf die indexierung bei Google hat dies aber keine auswirkungen, da hier die session ids nicht angezeigt werden. (außer severeinstellungen sind falsch). Link to comment Share on other sites More sharing options...
amelie Posted December 17, 2010 Report Share Posted December 17, 2010 das sind session ids, je nach browser einstellungen müssen diese angehängt werden. Auf die indexierung bei Google hat dies aber keine auswirkungen, da hier die session ids nicht angezeigt werden. (außer severeinstellungen sind falsch). Hallo Herr Zanier, das ist so nicht ganz richtig das das keine Auswirkungen auf den Index z.B. bei Google hat. Die Frage die hier ja immer wieder zu den Session IDs auftaucht ist berechtigt da, wenn man nicht umfassende vorkerhungen im System trifft (z.B. in Google Webmaster Tools diese Session IDs blockiert) diese sehr wohl zu massiven Problemen mit Google fürhren können. Eine Aussage wäre hier denke ich auch mal angebracht was genau Sie mit "Servereinstellungen" meinen damit man das umsetzen kann. Zudem gibt es bei den Session IDs immer noch das massive Problem das diese, auch bei aktiviertem Coockies, wenn ein Besucher zum ersten mal auf die Seite kommt, trotzdem an jeden ersten Klick angehängt werden. --> Normalerweise sollte diese ID NUR im Cookie gespeichert werden wenn wenn Cookies aktiviert - dies ist nicht der Fall und wir fragen uns wieso nicht? Session IDs sind bei Veyton ein Leidiges Thema wie man auch an den Beiträgen hier erkennen kann: http://www.xt-commerce.com/forum/fragen-zur-software/81608-export-ohne-session-mit-cronjob.html http://www.xt-commerce.com/forum/fragen-zur-software/81591-link-s-ohne-session-erzeugen.html Für das Problem das bei einem Cronjob Export auch Session IDs mit exportiert werden gibt es nach wie vor z.B. keine Lösung - obwohl das Ticket hierzu glaube ich schon gute 2 Monate alt ist. Es steht jetzt einfach auf "On Hold" - was für mich und uns hier so gar keine Aussagekraft hat...Wird sich darum aktiv gekümmert? Sind andere Projekte wichtiger? Wann ist hier eine Lösung des Bugs in Sicht? Man weis es einfach nicht. Und für uns ist das ein Problem da wir die Exportfunktion nutzen müssen - und das automatisiert. Was auch noch ein Problem ist das der Shop interne Links auf die Home Seite rezeugt und zwar nicht auf die www . domain . de/ sondern auf www . domain . de/ index . Dies führt 1. zu einem Doppeltem Content Problem für Google und ist 2. für die User auch irreführend. Ich hatte hier einen Post zu dem Thema aufgemacht und würde mich auch hier über hilfe freuen. Bzw. sollte mal erläutert werden was hier der Sinn ist - das verstehe ich nämlich nicht. Ich denke hier sind alle sehr an diesen Themen interessiert und würden sich detaillierte Lösungsvorschläge vom Hersteller wünschen. Ist dies Möglich liebes XTC Team? Uns würde so neben sehr vielen anderen kleinen Problemchen die wir mit Veyton haben doch sehr weitergeholfen werden. Herzlichen Dank, Amelie Link to comment Share on other sites More sharing options...
giller Posted December 17, 2010 Report Share Posted December 17, 2010 Herr Zainer, Sie können sich drauf verlassen das ich die richtigen Servereinstellung sofort vornehme wenn sie bekannt gegeben werden. (außer severeinstellungen sind falsch). Nach diesen Server einstellung betell ich und viele andere schon seit Monaten Link to comment Share on other sites More sharing options...
mzanier Posted December 17, 2010 Report Share Posted December 17, 2010 Die Frage die hier ja immer wieder zu den Session IDs auftaucht ist berechtigt da, wenn man nicht umfassende vorkerhungen im System trifft (z.B. in Google Webmaster Tools diese Session IDs blockiert) diese sehr wohl zu massiven Problemen mit Google fürhren können. Nein das ist falsch. 4.0.13 erzeugt für den google bot und einige hundert andere bots KEINE session id am link oder cookie. Nach diesen Server einstellung betell ich und viele andere schon seit Monaten dies steht zig male im Forum, der Server/php darf von selbst keine Sessions anhängen (content links etc). Parameter hierfür zb session trans sid. Für weitere Fragen bitte an den Helpdesk wenden (Support). Link to comment Share on other sites More sharing options...
ufreier Posted December 17, 2010 Author Report Share Posted December 17, 2010 Hallo Herr Zanier, das sind session ids, je nach browser einstellungen müssen diese angehängt werden. Warum das denn? Ich programmiere selbst in PHP und wüßte jetzt nicht, warum bei den SEO URLs eine Übergabe der session ids in den URLs benötigt werden sollte. Das wäre aber wichtig zu klären! Ansonsten als Quick + Dirty Lösung für das Problem: Man erweitere sein .htaccess um folgende Zeilen: Direkt nach "RewriteEngine on" RewriteCond %{REQUEST_URI} ^(.*)\.html$ RewriteCond %{QUERY_STRING} !^$ RewriteRule ^(.*)$ [shop-URL]%1.html? [R=301,L] Bitte anstelle von [shop-URL] schon die echte Shop-URL reinschreiben! :-) Achtung: Geht natürlich nur dann, wenn in den Query-Strings keine wirklich notwendigen Infos stehen - deshalb oben die Bitte um Erläuterung. außer severeinstellungen sind falsch Was ist da genau falsch bzw. was muss man am Server ändern, damit das Phänomen verschwindet? Ich habe auf dem gleichen Server mehrere PHP-Applikationen laufen, die mit mod_rewrite arbeiten, dabei aber keine Übergabe der session ids in der URL brauchen. dies steht zig male im Forum, der Server/php darf von selbst keine Sessions anhängen (content links etc). Parameter hierfür zb session trans sid. Eine Suche nach "session trans id" bringt genau 2 Fundstellen, diesen Thread und einen, in dem steht, dass "session.use_trans_sid = 0" gesetzt werden soll. Nachdem das die default-Einstellungen sind, habe ich sie und werden viele haben. 4.0.13 erzeugt für den google bot und einige hundert andere bots KEINE session id am link oder cookie. Falsch, 4.0.13 erzeugt (teilweise, nicht immer) irgendwelche Query-Parameter an den Links in der Navigation. @Amelie: wie sperrt man denn am besten diese URL-Anhängsel in den Google WMT? Gruß, Uwe Link to comment Share on other sites More sharing options...
giller Posted December 17, 2010 Report Share Posted December 17, 2010 session trans sid wird ja jetzt auch bei der Installation von 4.0.13 geprüft. Dies sind die Einstellung bei mir bei PHP mit Session warum macht er beim Aufruf eines Cronjobs mit cronjobs.de eine Session mit am export Ich glaube jetzt ist mir was eingefallen mal in den logs schauen was cronjob.de im header sendet ob man das in die bots.txt packen kann. Link to comment Share on other sites More sharing options...
mzanier Posted December 17, 2010 Report Share Posted December 17, 2010 Warum das denn? Ich programmiere selbst in PHP und wüßte jetzt nicht, warum bei den SEO URLs eine Übergabe der session ids in den URLs benötigt werden sollte. Das wäre aber wichtig zu klären! ist aus vielen gründen erforderlich. zb wenn kein session cookie gesetzt werden kann. oder für wechseln von http auf https über einen ssl proxy, da nicht für fremnde domains im vorfeld cookies gesetzt werden können. Falsch, 4.0.13 erzeugt (teilweise, nicht immer) irgendwelche Query-Parameter an den Links in der Navigation. Nochmals, 4.0.13 erzeugt KEINE session parameter wenn der aufruf durch einen suma bot erfolgt, hier wird weder ein cookie gesetzt noch eine session id an den link gehängt. Dies sind die Einstellung bei mir bei PHP mit Session warum macht er beim Aufruf eines Cronjobs mit cronjobs.de eine Session mit am export Das hat nichts mit dem Thema hier zu tun, hierzu bitte an den Support wenden, dafür gibt es bereits einen fix. Link to comment Share on other sites More sharing options...
giller Posted December 17, 2010 Report Share Posted December 17, 2010 dafür gibt es bereits einen fix. Das ist ja schön da werde ich gleich den Support belästigen. Aber als Tip fürs XTC Team. Veröffentlicht doch solche fixes über alle Kanäle die Ihr zur verfügung habt (Newsletter, Blog, Facebook, Im Forum) den hättet Ihr weniger Arbeit mit nörgelden Kunden. Bei BUI ist es genau so schlim mit der Informationt Politik. Anstat das sie das mit in den Newsletter schreiben das es eine Neue version von einem Plugin gibt. Soll man das auf der Seite selber finden. Ich mache auch nichts anderes als über Seiten zu Surfen und nach updates zu suchen den ganzen Tag. Link to comment Share on other sites More sharing options...
mzanier Posted December 17, 2010 Report Share Posted December 17, 2010 Veröffentlicht doch solche fixes über alle Kanäle Wird seit monaten bereits: xt:Commerce - Powered By Kayako SupportSuite Kann man sogar abonnieren! Das Fix für export ist noch nicht freigegeben für alle, darum auch nicht in der liste. Link to comment Share on other sites More sharing options...
giller Posted December 17, 2010 Report Share Posted December 17, 2010 Da könnte man ja nee Umfrage starten wer ausser mir hat davon nicht gewust. (das man da information abonieren kann) [Alle Kanäle sind das ja noch nicht und wie man an mir sieht geht das woll an einigen vorbei] Link to comment Share on other sites More sharing options...
amelie Posted December 17, 2010 Report Share Posted December 17, 2010 Also irgendwie kommt ja keinen Schritt weiter hier... Ich erwarte mir eigentlich von einem Anbieter kostenpflichter Software hier wie auch schon geschrieben eine etwas bessere Informationspolitik. Wir haben hier schon für 2 Projekte über 2.000 Euro an Lizenzkosten ausgegeben und ich denke hier sollte man seine Kunden etwas besser beträuen. Ein gutes Beispiel: Ich hatte vor ich glaube 2 Monaten hier ein Ticket an den Support gestellt wegen der fehlerhaften Exportfunktion über Cronjob. Das steht bis heute auf "On Hold" - keine Info wann sich hier etwas tut etc... Jetzt schreibt Herr Zanier das es hier eine Lösung gibt? Da Frage ich mich ernsthaft warum mir dieser Bugfix vorenthalten wird owbohl ich das Problem reportet habe auch wenn er erst Beta ist - ich habe im Ticket mehrfach nachgeakt und gesagt das diese Sache für uns extrem wichtig ist? Zu den anderen Sachen: Prinzipiell kann es ja sein das Herr Zanier bei vielen Sachen Recht hat - das ändert aber rein gar nichts daran das es anscheinend massive Probleme z.B. bei uns Nutzern von Veyton mit Session IDs gibt. Sich hier einfach hinzustellen und zu sagen das das kein Problem ist finde ich ist nicht die Richtige Lösung. Konstruktiver fände ich einen fundierten Beitrag zu dem Thema der uns Usern gerecht wird. MfG Amelie Link to comment Share on other sites More sharing options...
ufreier Posted December 17, 2010 Author Report Share Posted December 17, 2010 Nochmals, 4.0.13 erzeugt KEINE session parameter wenn der aufruf durch einen suma bot erfolgt, hier wird weder ein cookie gesetzt noch eine session id an den link gehängt. Ich glaube wir reden ein bisschen aneinander vorbei, ich versuche das mal zu ordnen. Das (oder besser: mein) Problem ist doch letztendlich, dass in einem Shop, der auf "SUMA-freundlich" gestellt ist, Links existieren, die eben nach dem ".html" noch einen Rattenschwanz an Parametern besitzen. Diese URLs werden so von Google indiziert und immer wieder aufgerufen/besucht (also meine access_log ist jedenfalls voll damit). Das ist unschön, weil hier DC en masse produziert wird. Sie sagen jetzt - wenn ich das richtig interpretiere - sofern ein Bot den Shop in der 4.0.13 aufruft, enthält sie keinen Rattenschwanz. Das passiert quasi nur, wenn ein menschlicher User unter bestimmten Umständen den Shop aufruft. Die URLs mit Rattenschwanz, die Google indiziert hat (leider hat er das wohl, sonst würde er sie nicht immer wieder besuchen), stammen aus Versionen < 4.0.13. Ist das richtig so? Wen dem so ist, wäre die Ursache des Problems behoben - dann stellt sich lediglich die Frage, wie man Google die "alten URLs" austreibt, was dann alllerdings nicht mehr Ihre Sache ist. Gruß, Uwe Link to comment Share on other sites More sharing options...
amelie Posted December 17, 2010 Report Share Posted December 17, 2010 Ich glaube wir reden ein bisschen aneinander vorbei, ich versuche das mal zu ordnen. Das (oder besser: mein) Problem ist doch letztendlich, dass in einem Shop, der auf "SUMA-freundlich" gestellt ist, Links existieren, die eben nach dem ".html" noch einen Rattenschwanz an Parametern besitzen. Diese URLs werden so von Google indiziert und immer wieder aufgerufen/besucht (also meine access_log ist jedenfalls voll damit). Das ist unschön, weil hier DC en masse produziert wird. Sie sagen jetzt - wenn ich das richtig interpretiere - sofern ein Bot den Shop in der 4.0.13 aufruft, enthält sie keinen Rattenschwanz. Das passiert quasi nur, wenn ein menschlicher User unter bestimmten Umständen den Shop aufruft. Die URLs mit Rattenschwanz, die Google indiziert hat (leider hat er das wohl, sonst würde er sie nicht immer wieder besuchen), stammen aus Versionen < 4.0.13. Ist das richtig so? Wen dem so ist, wäre die Ursache des Problems behoben - dann stellt sich lediglich die Frage, wie man Google die "alten URLs" austreibt, was dann alllerdings nicht mehr Ihre Sache ist. Gruß, Uwe Hallo Uwe, wir nutzen .13 und auch hier tritt standardmäßig das Problem mit den Session-IDs auf bzw. wir hatten unsere Seiten auch en mass mit Session IDs im Google Index. Das ist ja genau das was ich gemeint habe. Wir konnten das Problem teilweise mit der Robots.txt lösen in dem man hier z.B. folgendes einträgt: Disallow: /*xaf26a* Disallow: /*xfd067* Disallow: /*x91c95* Disallow: /*x6e7d3* Disallow: /*x09b85* Disallow: /*x$* Das führt dazu das Webmaster Tools bei uns über 8.000! URLs mit Session Ids findet und sperrt - ob das so toll ist bezweifle ich jetzt mal! Zudem kann man in Webmaster Tools unter "Website Konfiguration" "Einstellung" "Parameterbehandlung" die Parameter angeben die nicht indiziert werden sollen. Genau das sind die Punkte die ich mit ausführlichst vom Hersteller erwarte um das Problem mit Session IDs endgültig zu lösen. Was man genau wo einzutragen hat und welche IDs überhaupt erzeugt werde. Leider gibt es hier ja von XTC keinerlei Anleitung oder Vorgehensweise - ich verstehe das nicht. Stattdessen baut man wohl darauf das hier im Forum alles irgendwie gelöst wird... Für mich keine professionelle Begegnung eines massiven Problems. MfG Amlie Link to comment Share on other sites More sharing options...
ufreier Posted December 17, 2010 Author Report Share Posted December 17, 2010 Hi Amelie, Wir konnten das Problem teilweise mit der Robots.txt lösen in dem man hier z.B. folgendes einträgt: [...] Zudem kann man in Webmaster Tools unter "Website Konfiguration" "Einstellung" "Parameterbehandlung" die Parameter angeben die nicht indiziert werden sollen. Ach du liebe Zeit. Alles zu Fuß? Alles manuell eintragen? Oweh, da wirst Du ja nie fertig! Ich glaube nicht, dass die Parameterbehandlung in den WMT reguläre Ausdrücke versteht, insofern bleibt bei diesem Weg ja gar nichts anderes übrig. Schöne Bescherung. Leider gibt es hier ja von XTC keinerlei Anleitung oder Vorgehensweise - ich verstehe das nicht. Stattdessen baut man wohl darauf das hier im Forum alles irgendwie gelöst wird... Nun, ich sehe die xt:Commerce GmbH eher als ein Paradebeispiel für Gewinnoptimierung. Haben ein schickes Shopsystem mit entsprechend geschickter Vertriebsstrategie - insbes. mit einer Modularität, mit der sich zusätzlich gut Geld verdienen lässt. Der Shop funktioniert auch eigentlich gut, jedenfalls so gut, dass es genug Leute gibt, die ihn zu einem im Vergleich mit anderen kommerziellen eCommerce-Produkten eher günstigen Preis kaufen. Und damit ist das Ziel erreicht. Sicherlich hat die Software Haken und Ösen und funkioniert nicht zu 100%, und sicherlich gibt es auch jede Menge Kunden, die damit unzufrieden sind und sich beschweren - das interessiert aber doch den Hersteller nicht, solange er noch genug davon verkauft. Und gerade Support ist kaufmännisch ein Kosten-Faß ohne Boden. Wozu also, wenn es mit minimale(re)m Aufwand auch geht? Solange sich an der Marktsituation für XTC nichts ändert, ändert sich auch nichts an deren Verhalten. Uns Anwendern bleibt i.d.R. dabei nichts anderes übrig als uns bestmöglich selbst zu helfen und dafür ist so ein Forum schon eine nette Geschichte. Oder um es kurz zu sagen: Stattdessen baut man wohl darauf das hier im Forum alles irgendwie gelöst wird... Ja. Gruß, Uwe Link to comment Share on other sites More sharing options...
asatdu Posted December 18, 2010 Report Share Posted December 18, 2010 http://www.xt-commerce.com/forum/fragen-zur-software/80639-mandanten-duplicate-content-search-engine-optimization-2.html#post369313 Das Plugin sollte helfen die URL's aus dem index zu kicken... (Funktioniert natürlich auch bei "nicht Master/Slave-Artikeln") Link to comment Share on other sites More sharing options...
ufreier Posted December 18, 2010 Author Report Share Posted December 18, 2010 Hi, ja - so einfach kann es sein. Den anderen Thread habe ich leider nicht gefunden, sonst hätte ich diesen hier natürlich nicht aufgemacht. Vielen Dank nochmal dafür! Gruß, Uwe Link to comment Share on other sites More sharing options...
ReAct Posted November 17, 2013 Report Share Posted November 17, 2013 Ich bin von vielen der Posts hier verwirrt und erkenne keinen Lösungsansatz. Außer der über .htaccess Allerdings werden bei uns im Shop QueryStrings stellenweise eingesetzt. Ich kann diese Lösung also nicht anwenden. Bitte erklärt mal hier jemand Schritt für Schritt, wie man diese Session-IDs abschaltet/entfernt. Das wäre sehr nett. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.