Google – Duplicate Content nicht mehr mit robots.txt sperren
Duplicate Content ist nach wie vor eins der großen Themen im Bereich der Suchmaschinenoptimierung und kann u.a. zu Problemen führen favorisierte Inhalte in den Serps gut zu positionieren. Oft produzieren Shops und Content Systeme auf grund Ihrer Struktur tonnenweise Duplicate Content und das meist ohne das der, nicht so versierte, Seitenbesitzer davon etwas mitbekommt. WordPress kann zum Beispiel zu einer waren DC-Schleuder werden, wenn man nicht an den richtige Stellen die Bremse zieht.
Ich möchte hier jedoch nicht im Detail auf die Vorgehensweise einer guten On-Page-Optimierung eingehen (die im optimalen Fall vor der Onlinestellung eines Projektes stattfinden soll), sondern etwas über die aktuelle Google-Sicht zum DC schreiben. Folgend eine kleine Zusammenfassung.
Die übliche empfohlene Vorgehensweise zur Vermeidung von DC (das wichtigste kurz zusammengefasst):
1. Erkennt DC und behebt ihn. Wenn eure Site schon online ist, nutzt hierfür zum Beispiel den Google site:-Operator.
2. Legt eure bevorzugte Domain in den Webmaster-Tools und per .htaccess fest (z.B. mit oder ohne www, oder bei mehreren Domains die auf ein Ziel verweisen).
3. Nutzt das Tag rel=”canonical” um den Sumas mitzuteilen wo das Original liegt.
4. Nutzt das Tool zur Parameterbehandlung in den Webmaster-Tools für Sites die den gleichen Content über verschiedene URLs ausgeben.
4.1. Am besten sorgt für im Rahmen der On-Page-Optimierung schon vorab für eine suchmaschinenfreundliche Ausgabe der URLs z:b. per mod_rewrite
Und dann kommt da noch die berühmte robots.txt in der Anweisung für die Bots stehen, bestimmte Inhalte nicht zu crawlen und zu indexieren. Das setzt jedoch voraus, das man weiß wo sich DC befindet, bzw. er produziert werden kann. Jetzt kommt allerdings das aktuelle Google-Statement, das ich hier 1:1 wiedergebe:
“Wir empfehlen mittlerweile, den Zugriff auf Duplicate Content auf eurer Site nicht zu blockieren – egal ob mittels robots.txt oder anderer Methoden.”
Hallo, wie bitte? Das ist ja mal was ganz neues! Google empfiehlt ganz klar, DC nicht mehr für den Crawler per robots.txt zu blockieren, sondern sich nur noch auf die oben erwähnten Mittel zu beschänken. Die Begründung liest sich ein wenig so, als währe der Crawler eigentlich total doof. Google sagt, dass wenn DC durch die robost.txt blockiert wird, die Suchmaschine diese URLs als eigenständige Seiten ansieht, da der Crawler nicht erkennen kann, dass es sich hierbei nur um verschiedene URLs für den gleichen Inhalt handelt. Hatte Google nicht vor eniger Zeit gesagt, das sie kein Problem damit hätten?
Google dreht es nun um und möchte das der Crawler freien Zugang zum möglichen DC bekommt und unter der Verwendung oben genannter Möglichkeiten durch leraning by doing selber entscheiden lernt wo DC anhand eurer URL bzw. des zur URL-Ausgabe genutzen Systems produziert wird und diese Bereiche in Zukunft dann auch gar nicht mehr besucht.
Hat die robots.txt also ausgedient? Sieht so aus! Zumindest was DC angeht, wird halt auch schlauer die Tante 
Und für die dies interessiert, hier meine mini robots.txt die ich für dieses Blog nutze:
Sitemap: http://www.collis.de/sitemap.xml
User-agent: *
Disallow: /mail/
Disallow: /wp-content/themes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/ads/
Disallow: /wp-content/tmp/
Disallow: /wp-content/uploads/
# disable duggmirror
User-agent: duggmirror
Disallow: /
User-agent: Googlebot-Image
Disallow: /
Verwandte Artikel:
» Linknachbarschaft im Linkbuilding - Was ist zu beachten?
» Optimierungskonzepte für Topic Pages
» Software-Tipp - Advanced Web Ranking
» Software-Tipp - Advanced Link Manager
» Latent Semantische Optimierung - LSO
Francis Collis
Sonntag, 25. Oktober 2009
Ich habe gerade mit meinem Shop ein schönes Session ID Erlebnis, das mich zur Weißglut bringt. Denn trotzdem dass die Session IDs per Robots.txt gesperrt sind, landen sie zahlreich im Google Index.
So komme ich momentan gar nicht drum herum alle paar Tage alle Session ID URLs über die URL entfernen Funktion in den Webmaster Tools manuell rauszuwerfen, denn je nachdem wie viele gerade mal wieder im Index sind, leiden auch die entsprechenden Rankings darunter.
Das einfachste wäre natürlich der Session ID Auslieferung an Google ein Ende zu setzen, doch leider habe ich hier noch keine Lösung gefunden, denn so wie mein Shop seit Jahren eingestellt ist, liefert er gar keine Session IDs an Google aus. Wo Google die nun herhat, bzw. mit welchen “neuen unbekannten Bot” die sich in meinem Shop verlustieren ist mir seit Wochen ein großes Fragezeichen
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.
Montag, 26. Oktober 2009
Dann muss deine Shop-System doch irgendwo noch Session-Ids ausspucken
Klappt es aus irgendwelchen Gründen nicht (was für ein Shop-System nutzt Du denn?) das in den Griff zu bekommen, wäre es möglich mit rel=”canonical” zu arbeiten oder die Parameterbehandlung in den Webmaster-Tools nutzen. Letzteres schon mal versucht?
Montag, 26. Oktober 2009
Ich nutze XT Commerce 3.04, also schon ziemlich alt (kein SP). Es sieht auch so aus, als ob der Shop richtig läuft, nur scheint Google wieder mal alles mögliche zu veranstalten. Wie sollen die denn sonst an Session IDs kommen, die dem Googlebot gar nicht ausgeliefert werden?
Seit Wochen experimentiere ich jetzt schon wieder damit rum. Übrigens die Canonical bringt gar nichts, so ist das zumindest bei einem Bekannten von mir zu sehen, der trotz Spider Sessions vermeiden + Canonical URL über 7000 Session IDs im Index hat und natürlich auch enorme Ranking Probleme.
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?
Montag, 26. Oktober 2009
Ah, XTC das Programmierer Monster
Wer das die Finger dran hatte gehört … Na ja, ich setzte auch noch einige XTC Shops ein – nicht mehr lange da gibt es besseres. Aber gut, versuche mal folgendes: Eine 301 Weiterleitung auf die Url ohne Session ID.
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
Dienstag, 27. Oktober 2009
Der Tipp funktioniert bei mir leider nicht:
parse error, unexpected T_LNUMBER in /home/www/web44/html/shop/includes/application_top.php
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
Mittwoch, 28. Oktober 2009
Der parse error, unexpected T_LNUMBER könnte ein nicht escaptes Hochkomma im String sein.
Zum Bleistift:
$string = “Juni” 14, 2009″; //error
$string = “Juni\” 14, 2009″; //ok
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 …
Donnerstag, 29. Oktober 2009
Ah stimmt, das könnte an den Hochkommas liegen, richtig. Aber durch meine htaccess Lösung ist dieser Zusatz ja nicht wirklich notwendig. Wenn Du den übrigens testest, dann achte auf / und ?, bei mir werden die Session IDs ja mit / und nicht mit ? angehängt.
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.
Donnerstag, 29. Oktober 2009
Eben mal bei einem Shop nach Ids gesucht und tatsächlich EINE gefunden
Hmm, aber wo kommt die denn her??
Donnerstag, 29. Oktober 2009
Daher, dass die robots.txt Session ID Sperre ignoriert wird von Google, sobald sich ein externer oder interner Link dorthin befindet. Wenn Session IDs ausgeliefert werden gibt es massenhaft interne Links und damit zieht die robots.txt Sperre nicht mehr. Auslöser ist wahrscheinlich die xtc_check… der ein paar entsprechende Googlebots fehlen
Ich bin ja schon froh, dass mich diesbezüglich hin und wieder einer ernst nimmt. Die meisten meinen nämlich ich ticke nicht ganz richtig und kucken nicht mal nach ihren Session IDs…
Donnerstag, 29. Oktober 2009
Ich schau heute Abend mal bei den anderen Shops. Ich sag nur: Voodoo!
Donnerstag, 29. Oktober 2009
Ich kämpfe jetzt schon seit Wochen mit diesem Vodoo
Vor allem war ich äußerst begeistert, als ich zufällig darüber stolperte und mein Shop scheinbar irgendwann von ?XTCsid auf /XTCsid umgestellt hatte. Keiner weiß warum und wieso. Natürlich war bei mir alles nur mit ? gefiltert und via 310 umgeleitet, so dass ich Double Content von der allerfeinsten Sorte hatte.
Ein Bekannter von mir kam jetzt durch meine Aktion darauf und der hat robots.txt, 301 Umleitungen und canonical urls. Der hat sage und schreibe über 7000 Session IDs seines Shops im Index. Zwar alle durch die robots.txt ohne Titel und ohne Beschreibung aber sie sind immerhin da und wirken sich höchstwahrscheinlich auch negativ aus.
Übrigens, kleiner Tipp am Rande: Wenn Du hier das Plugin NoSpamNX nutzt, dann sparst Du Dir den Einsatz der Captchas.
Donnerstag, 29. Oktober 2009
Also bei dem Shop-System Deines Bekannten muss da doch irgendwo etwas extrem schief laufen. Aber Tante G ist nicht so doof wie man oft denkt und bin mir sicher das sie den DC durch Session Ids inzwischen recht gut im Griff hat, d.h das es sich nicht negativ auf das Ranking auswirkt. Wie passt denn sein Ranking zu seinen Off-Page Optimierungen? Steht es in einem guten Verhältnis zum Ranking? Ist sein Ranking eh schon im Eimer (evtl. auch aus anderen Gründen?) würde ich an seiner Stelle mal Tante G einige Zeit freien Lauf lassen und beobachten was dann passiert. Aber by the way, ich kenne einige Shops die nur das allernötigste On-Page gemacht haben und die ranken trotzdem extrem gut unter den Hauptkeys.
*spässeken gemacht*
NoSpamNX kenn ich noch nicht, danke für den Wink! Auf der anderen Seite finde ich es immer sehr lustig wie sich viele bei den Captchas nen Wolf lesen
Donnerstag, 29. Oktober 2009
Zum Ranking meines Bekannten würde ich einfach nur “Eimer” sagen
Dass Tante G die Session ID Thematik nicht so gut im Griff hat wie allgemein angenommen konnte ich bei mir feststellen. Gut, ich hatte astreinen DC damit, aber sobald ich die Session IDs über die WMTs in den letzten Wochen alle manuell schnell entfernt hatte (URL entfernen) ist mir das Ranking einiger Keys wieder extrem nach vorne gesprungen. Es war seit Monaten Stückchen für Stückchen abgesackt. Am heftigsten war z.B. das Key ‘Aminosäuren’, von Seitw 6 auf Seite 1 unten…
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
Donnerstag, 29. Oktober 2009
Ah, EnergyTrend
Vielleicht sollte Dein Bekannter mal von vorne Anfangen, d.h den Index bereinigen, am Shop schrauben und Off-Page reinklotzen. Irgendetwas läuft da ja wohl verdammt schief. Aber solange ich das Projekt nicht kenne, halte ich mich mit aus den Bauch-Tipps zurück 
NoSpamNX: Nun, Askimet arbeitet recht gut, Captcha macht den Rest und alles was im Spam landet, landet halt da und später im Müll, da moderiere ich nix. Wäre auch bei einem Sack voller Blogs etwas zu viel des guten. Aber ich werde das Plug mal testen!
Donnerstag, 29. Oktober 2009
Ich denke, hoffe, mein Bekannter ist gut versorgt (nicht von mir)
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
Donnerstag, 29. Oktober 2009
Dein Shop ist doch recht schnell zu finden!
Klar nutze ich Askimet, funktioniert meiner Meinung nach recht gut und soll von mir aus dahin telefonieren wo es will. Das sich dahin mal ein Blogger verirrt kann sicherlich schon mal passieren, ist aber recht selten. Hat allerdings mal jemand einen Blog auf dem Kicker, ist Askimet recht schwach auf der Brust, in so einem Fall gebe ich Dir recht. Wie gesagt, werde mal das Plug in die Angriffszone werfen und schauen wie es sich bewährt
Samstag, 31. Oktober 2009
Ich denke du bist schon mitten drin im Test, oder? Zumindest ist das Captcha schon weg und ich muss nicht mehr ständig aktualisieren, weil ich was nicht lesen kann
Samstag, 31. Oktober 2009
Genau, ich teste
Dieses Blog hatte aber auch in der Vergangenheit nie sonderlich viel mit Spam zu kämpfen. Wenn es hier gut funktioniert (auch ohne Askimet), dann schicke ich es mal an die Spamfront 
Mittwoch, 16. Dezember 2009
Hi Francis, ich bin auf der Suche nach xtcsid über Dein Blog gestolpert. Das trifft sich auch gut, da ich der “Bekannte” von Crazy Girl bin, bei dem einiges schief läuft…
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
Mittwoch, 16. Dezember 2009
Hi Chris, ach Du bist das
Alles in allem ist das eine recht komplexe Angelgenheit zu der ich mehr Informationen benötige, um Dir hier evtl. helfen zu können. Das Deine Hauptkeys jenseits der 500 ranken macht mich jedoch schon etwas stutzig. Hier scheint SEO mäßig (On wie Off Page) etwas schief zu laufen. Zu den Session IDs würde ich mir erst einmal keine so großen Gedanken machen, Google kann schon sehr gut unterscheiden was wichtig ist und was nicht. Vorausgesetzt das Google Deinen Shop auch kennt um das beurteilen zu können, hier kann eine Sperrung durch die Robots auch manchmal kontraproduktiv sein. Aber wie gesagt, einen Tipp in der Art “Mach dies und das und alles wird gut” ist ohne mehr Infos und einer Analyse zu Deiner bisherigen Optimierungsarbeit kaum möglich.
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
Samstag, 26. Dezember 2009
Also ich habe auch ein paar URLs mit der PHPSESSID im index drin. Ich habe diese nun einmal unter den WMT mit Hilfe des Tools zur Parameterbehandlung in den Webmaster-Tools so eingestellt, das diese ignoriert werden solln. Mal sehen ob das hilft.
Samstag, 26. Dezember 2009
Hallo Stefan, erst einmal herzlich willkommen
Die Parameterbehandlung hat sich als recht brauchbar herausgestellt. Unabhängig davon kann Google inzwischen recht gut mit Session Ids umgehen und weiß die entsprechend einzuordnen. Die Parameterbehandlung unterstützt hierbei Google bei der zügigen Identifizierung. Wegen ein paar SIDs, wie Du schreibst, würde ich mir so oder so keine Sorgen machen.
Sonntag, 3. Januar 2010
Hier ein Link zur offiziellen Stellungnahme des Google Mitarbeiters John Mu zu den XTC Sessions. Wie schon von mir erwähnt: Crawlen lassen, nicht sperren, in den WMTs die Parameter einstellen, evtl. noch etwas 301 oder canoncial. Am wichtigsten ist jedoch: Session IDs beeinflussen nicht das Ranking!
http://www.google.de/support/f.....#038;hl=de
Montag, 4. Januar 2010
Interessant interessant
Doch ganz so würde ich nicht sagen, dass Session IDs nicht das Ranking beeinflussen, John Mu schrieb ja selbst “…dass die Original-Seiten u.U. nicht so gut dastehen wie sie eigentlich koennten…”. Genau das habe ich ja auch erlebt. Es waren kleine Rankingunterschiede da, sie sich auf max. 5-10 Plätze beliefen. Große Ranking Beeinflussungen gibt es aber definitiv nicht.
Montag, 4. Januar 2010
Ein paar Plätze rauf und runter ist ja auch “normal”. Bei Dir lag es aber auch daran das Google Deinen Shop nicht kannte, da der Crawler nicht überall dran kam. Aber falls Du in einer Top 10 Position mal 10 Plätze nach hinten gekickt wurdest, hat das auch nichts mit Sessions zu tun gehabt. Evtl. optimiert ein Mitbewerber besser, schlechter böser Backlink, zuviel Shopgefummele, weniger Backlinks, Husten, Schluckauf, Magenweh oder Lust und Laune eines Google Mitarbeiters mal das KeyRanking nicht nur dem Algo zu überlassen, sondern auch selbst mal Hand anzulegen
Montag, 4. Januar 2010
@Francis: Ich habe es gerade jemanden erklärt und dabei selbst gerafft. Es ist so:
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.
Montag, 4. Januar 2010
Jenau so ist das
Wie ich schon sagte, Google alles crawlen lassen, dann weiß Google auch was zu gebrauchen ist und was nicht. Aber schön das es nun auch bei Dir *plöng* gemacht hat 
Montag, 4. Januar 2010
Richtiges *plöng* kam auf die Nachfrage: Die indizierten Session IDs beeinflussen also ganz und gar nicht das Ranking? öh… nein… öh doch… also… nur nicht, wenn Google schön alles crawlen darf, wenn nicht, dann schon
Montag, 4. Januar 2010
Ein hoch auf das “Plöng”!
Samstag, 5. Juni 2010
Zur Not kann auch per PHP auf das www. weitergeleitet werden um den duplicate Content zu vermeiden.
Dienstag, 6. Juli 2010
Wie kann man Testen ob der .htaccess Befehl…
RewriteCond %{HTTP_USER_AGENT} Googlebot
RewriteRule ^(.*[^/])?/?XTCsid/[^/]+$ http://%{HTTP_HOST}/$1 [L,R=301]
…auch funktioniert.
Dienstag, 6. Juli 2010
Ich gehe davon aus das es darum geht die XTC Sessions aus dem Index zu bekommen. Falsch ist es auf die Startseite weiter zu leiten, richtig und effektiv löst man das Problem z.B. in den WMTs. Dort den Parameter XTCsid setzten, nach einiger Zeit sind die Session IDs dann raus. Dann noch im XTC Backend Spider-Sessions vermeinden aktivieren! Auf der anderen Seite ist Google schlau genug URLs mit Session IDS zu erkennen und richtig damit umzugehen…