RewriteCond %{HTTP_USER_AGENT} Googlebot
RewriteRule ^(.*[^/])?/?XTCsid/[^/]+$ http://%{HTTP_HOST}/$1 [L,R=301]

…auch funktioniert.

Mit disallow: XTCSid in der robots.txt haben die indizierten Session IDs Auswirkungen aufs Ranking (das erklärt John Mu ja auch mit dem Satz “…dass die Original-Seiten u.U. nicht so gut dastehen wie sie eigentlich koennten…”).
Hat man aber stattdessen die Session IDs nicht in der robots.txt blockiert und handelt sie über die Parameterbehandlung sowie den Canonical URLs dann haben die paar, die in den Index kommen (hin und wieder passiert das vereinzelt) keinen Einfluß aufs Ranking.

Die Schwankungen im Ranking die ich beobachtete waren ausschließlich aus der Zeit in der ich die Session IDs noch über die robots.txt blockierte und sie dann immer mal wieder über URL entfernen kickte. Waren sie dadurch wieder weg, war das Ranking wieder um einige Plätze besser. Waren wieder neue da, war das Ranking wieder abgesackt. Das ging über mehrere Wochen ständig hin und her. Seitdem ich sie nicht mehr über die robots.txt blockiere kommen zwar immer noch Session IDs vereinzelt in den Index, aber das Ranking ist bis auf natürliche Schwankungen stabil.

Ist ja auch irgendwie logisch. robots.txt blockierte Seiten kann Google nicht als DC verstehen und dadurch sind sie DC und wirken auch so. Nicht über die robots.txt blockierte Seiten kann Google durch die Parameter und Canonical als DC verstehen und entsprechend entschärfen, sie haben keine DC Auswirkungen mehr.

http://www.google.de/support/f.....#038;hl=de

Wenn Du möchtest können wir gerne mal miteinander telefonieren. Schick mir hierzu doch bitte Deine Kontaktdaten an francis at collis de, ich melde mich dann bei Dir sobald ich hier etwas Luft habe.

Gruß
Francis

Ich kann Dir sagen, das deprimiert ziemlich. Nebenkeys ranken ganz gut. Die Hauptkeys die optimiert werden, sind jetzt alle jenseits der 500…

Du hast geschrieben: “den Index bereinigen, am Shop schrauben und Off-Page reinklotzen.”
Wie kann man “index bereinigen”?

canonical haben wir drin, Die Parameter im WMT sind hinterlegt, die Seiten, die WMT ständig wegen der Sperrung per robots.txt bemängelt hat, haben wir zum größten Teil per Metatag: „noindex, nofollow“ ausgeschlossen. Dennoch nehmen die bei google angezeigten Sitelinks eher zu. Momentan sind wir bei 11.800. Klickt man sich durch die tatsächlich aufrufbaren Ergebnisse, landen wir jedoch nur bei 393 Ergebnissen. Bei 560 Produkten und einem Blog auf dieser Domain, wohl eindeutig zu wenig.

Hast Du eine Idee, wie das zu Stande kommt? Die Domain siehst Du in der Emailadresse.

VG Chris

Du kennst meinen Shop oder hast du das jetzt nur wegen dem Key geschrieben (ah… energytrend)?

Sag blos Du nutzt Akismet? Da wundert es mich sehr, dass Du mich nicht aus dem Spam-Ordner fischen musstest, denn da lande ich, wie auch viele andere Blogger, bei Akismet für gewöhnlich. Das ist neben dem ständigen “nach Hause telefonieren” der zweite große Nachteil von Akismet, leider

NoSpamNX ist in meinen Augen das beste Anti-Spambot Plugin das es gibt. Auf “blockieren” einstellen und schon können sich die Spambots woanders austoben gehen und Du kriegst so ganz und gar nichts davon mit, außer einer Zeile im Dashboard, die z.B. besagt “NoSpamNX hat seit seiner letzten Aktivierung 1559 dumme Spambots gestoppt”. Du hast natürlich auch die Wahl das zu moderieren, aber das willst Du Dir ehrlich nicht antun

Übrigens, kleiner Tipp am Rande: Wenn Du hier das Plugin NoSpamNX nutzt, dann sparst Du Dir den Einsatz der Captchas.

Prüfe doch einfach mal ein paar Deiner XTC Shops auf Session IDs im Index. Ich bin auch nur durch Zufall drauf gekommen, dass das jetzt wieder so ist. Wenn diese Shops Session IDs nutzen, dann müsstest Du sie auch im Index haben, zwar ohne Titel und Beschreibung aber immerhin indexiert.

Mit den User Agents bin ich übrigens scheinbar auf die Lösung gestoßen. Diese in die xtc_check… aufgenommen und schon sind seitdem keine neuen Session IDs mehr im Index aufgetaucht. Um aber endgültig das behaupten zu können, muss ich wohl noch ein paar Wochen abwarten. Ich werde aber demnächst einen etwas detaillierteren Artikel darüber schreiben. Denn das Problem bezieht sich so ziemlich auf das nicht-mehr-richtig-funktionieren der robots.txt.

Dein .htaccess Schnipsel ist ja prima, werde ich mal testen! Danke für den Wink!

Das Problem mit Deinen Sessions IDs ist ja wirklich merkwürdig, da ich es von meinen XTC Shops (einige noch SP1) her nicht kenne. Hmmm …

Dafür habe ich aber in meiner htaccess folgendes stehen:
RewriteCond %{HTTP_USER_AGENT} Googlebot
RewriteRule ^(.*[^/])?/?XTCsid/[^/]+$ http://%{HTTP_HOST}/$1 [L,R=301]

(bei mir werden die Session IDs nicht mit ?, sondern mit / ausgegeben)

Die Parameterbehandlung habe ich dank Dir jetzt auch gefunden und dort mal XTCsid eingegeben. Vielleicht hilft das ja auch ein bißchen.

Ansonsten bin ich immer noch auf der Suche nach der Ursache. Das alles unterbindet ja nur die Auswirkungen, aber eigentlich sollte man lieber an der Ursache schrauben und irgendwie muss Google ja an die Session IDs kommen, was ja nur über die xtc_check_agent… sein kann. Die SP2.1 Version hat mir diesbezüglich nicht viel weitergeholfen, dafür aber die User Agent Statistik auf meinem Webserver sowie jetzt auch eine Angabe in den WMTs. Und zwar steht unter Website-Konfiguration/Crawler Zugriff/robots.txt testen ganz unten ein Auswahlfeld für User Agents und da sind folgende angegeben:
- Googlebot
- Googlebot-Mobile
- Googlebot-Image
- Mediapartners-Google
- Adsbot-Google
Der “googlebot” ist ja schon drin in der xtc_check… aber die anderen nicht. Deswegen habe ich die plus den Googlebot/2.1, den Feedfetcher-Google und Google.com (die letzteren sind aus meiner Webserver Statistik) einfach mal hinzugefügt und harre jetzt der Dinge die so kommen

Datei includes/application_top.php
nach: // include the language translations

require(DIR_WS_LANGUAGES . $language . ‘.php’);

einfügen:

if ( $truncate_session_id == true ) {
if ( eregi(xtc_session_name(), $_SERVER['REQUEST_URI']) ){
$location = xtc_href_link(basename($_SERVER['SCRIPT_NAME']), xtc_get_all_get_params(array(xtc_session_name())), ‘NONSSL’, false);
header(”HTTP/1.0 301 Moved Permanently”);
header(’Location: $location’);
}
}

Sollte auch mit Deiner Version klappen, am besten aber erst mal auf einen Testsystem checken!

Die Parameterbehandlung findest Du in den WMTools unter Website-Konfig/Einstellungen ganz unten. Hier kannst Du verschiedene Parameter wie z.B. “sid” ausklammern, die zu einen effektiveren Crawling führen, bzw. den von XTC produzierten Rotz ausklammern.

Tipp (aber kennst Du sicherlich): ecombase.de hat gute XTC Tipps auf Lager.

Die SP2.1 xtc_check schicke ich Dir per Mail rüber

Momentan fahre ich gerade einen Test, indem ich einem Bereich meines Shops, wenn Session IDs ausgegeben werden, das meta tag noindex hinzufüge. Theoretisch müsste das klappen, praktisch könnte mir das Ranking abrotzen. Wenn ich aber z.B. meine Log Dateien ansehe, dann werden dem Googlebot wirklich auch keine Session IDs in den URLs angeboten. Na, mal abwarten. Wird sich rausstellen ob das eine gute oder eine blöde Idee war.

Ansonsten bin ich noch auf der Suche nach einer neueren Version der xtc_check_agent.inc.php. Meine ist aus 2005 und seitdem hat sich sicherlich schon einiges verändert.

Die Parameterbehandlung in den Webmaster Tools kenne ich nicht. Was ist das, bzw. wo finde ich die?

Bei meinem Wordpress Blog habe ich diese DC Problematik bis dato noch nicht nachvollziehen können. Ein paar einzelne Artikel sind zwar doppelt drin gewesen, doch da hat mich mit hoher Wahrscheinlichkeit von Spinner dämlich angelinkt. Der entsprechende 301 schafft die Lösung.