ABAKUS

Verfasst: **16.03.2009, 23:13**

Einen schönen guten Abend und hallo zusammen,

ich weiß nicht so recht in welches Themengebiet meine Frage passt, deswegen am besten hier

.

Als unsere Seite die ersten Male indexiert worden ist mir aufgefallen, dass die Seiten mit unterschiedlichen Session IDs gecrawlt wurden.

Wie auch immer, das Problem wurde danach sofort beseitigt nur sehe ich jetzt das Problem, dass viele Seite im Google Index mehrfach auftauchen, da diese ja zuvor mit einer Session ID gecrawlt wurden und dann eben auch richtig nach das Problem behoben wurde.

Da ja Seiten im Index mit einer Session ID Duplicate Content ist sollte dieses Problem schnellstmöglich aus der Welt geschaffen werden.

Nun meine Frage, kann ich das über die WMT durchführen, sprich Anträge stellen um Seiten aus dem Index zu nehmen? Wenn ja, wie wirkt sich das ganze auf die Seite aus? Hier meine ich nicht das natürlich Seiten aus dem Index fliegen

...

Ich meine, die Seite ist ja mehrfach im Index

yourdomain*com/contenta?session1
yourdomain*com/contenta?session2
yourdomain*com/contenta

usw. . Wenn ich die ersten beide Einträge zum löschen aus dem Index freigebe sollte rein theoretisch der letzte erhalten bleiben .. gibt es weiter nachteile außer das DC vorkam?

BTW, die ersten beiden Einträge sind immer noch erreichbar ...

Gibt es andere Wege oder Lösungen?

Danke für eure Hilfe im voraus!

Grüße

PSyc

Content Erstellung von ABAKUS Internet Marketing
Ihre Vorteile:

einzigartige Texte
suchmaschinenoptimierte Inhalte
eine sinnvolle Content-Strategie
Beratung und Umsetzung

Jetzt anfragen: 0511 / 300325-0

Verfasst: **16.03.2009, 23:46**

Sperr das per robots.txt, ist am einfachsten... Bei mir sind daraufhin, ohne Anträge zu stellen, die Pages aus dem Index geflogen.

Verfasst: **16.03.2009, 23:58**

das neu eingeführte canonical tag wird hier bestens weiterhelfen.

Verfasst: **17.03.2009, 07:57**

chris21 hat geschrieben:das neu eingeführte canonical tag wird hier bestens weiterhelfen.

Der beseitigt aber nicht die Ursache sondern doktert an den Auswirkungen herum. Lieber direkt richtig machen.

Verfasst: **17.03.2009, 10:27**

Per robots.txt kriegt man sie nicht aus den SERPs. Hier und hier sind ein paar Lösungsvorschläge.

Viele Grüße

Verfasst: **17.03.2009, 10:43**

turgay hat geschrieben:Per robots.txt kriegt man sie nicht aus den SERPs. Hier und hier sind ein paar Lösungsvorschläge.

Viele Grüße

natürlich geht das !

User-agent: *
Disallow: *?PHPSESSID*

Verfasst: **17.03.2009, 10:51**

Nein, nicht unbedingt. Meistens führt diese Anweisung nur dazu, dass im Index nur ein Link und keine Description gezeigt wird. So bei einigen Projekten bei mir.

TBT hat geschrieben: natürlich geht das !

User-agent: *
Disallow: *?PHPSESSID*

Verfasst: **17.03.2009, 11:06**

Bei bekannten User robots wird serverseitig keine Session erzeugt, fertig. Hierzu wird der User-agent geprüft und dann entschieden ob es ein Robot oder ein Benutzer ist.

Das nachträgliche Umschreibung / Abschneiden der Session, damit verlagert man die Problemlösung in eine höher gelegene Ebene. Ist nicht gerade optimal. Wenn man selbst nicht die Möglichkeit hat, auf den Programm-Code einzuwirken wohl aber ein probates Mittel. Auf die Lösung nur Session-Cookies zu akzeptieren, wer's sich erlauben kann

Verfasst: **17.03.2009, 11:38**

Ich kann dir garantieren, dass diese Robots.txt zu dem oben genannten Ergebnis geführt hat...

User-Agent: *
Allow: /
Disallow: /admin/
Disallow: /marca/
Disallow: /documentos/
Disallow: /*/sid/
Disallow: /*?sid=
Disallow: /*&sid=
Disallow: /*cnid/
Disallow: /*anid/

@ Proit: Zustimmung!

Verfasst: **17.03.2009, 14:35**

Hallo zusammen,

danke für die raschen Antworten!

Ich glaube ich habe mich falsch ausgdrückt oder ich verstehe etwas nicht!

Wenn ich per robots.txt gewisse sachen aussperre, löst das doch m.E. nicht mein Problem mit den bereits im Google Index gecrawlten URLs mit Session ID.

Das Problem an meinem System, sprich das komplette deaktivieren der Session IDs ist bereits passiert .. war wenn ich genauer in Detail gehen darf, eine Inkompatibilität zwischen CMS, PHP4 und der SEF Komponente ..

Was ich jetzt eigentlich möchte ist, das der Dupilcated Content im Google Index verschwindet ..

Grüße

Verfasst: **17.03.2009, 14:51**

Ja doch, genau das passiert durch die Sperrung in der Robots.txt. Wenn du dies schon so, oder ähnlich, gemacht hast, dann musst du noch ein wenig warten. Bei mir hat dieser Prozess mehrere Monate gedauert.

Verfasst: **17.03.2009, 15:12**

So jetzt nochmal zum Verständnis ..

URLs bei Google sehen wie folgt aus:

www*meinedomain*.org/contentA?SessionID1
www*meinedomain*.org/contentA?SessionID2
www*meinedomain*.org/contentA

Ich sperre

www*meinedomain*.org/contentA?SessionID1
www*meinedomain*.org/contentA?SessionID2

per robots.txt, richtig?

Damit fliegen die URLs mit der Session ID aus dem Index und die "richtige" bleibt im Index.

Bleibt die Frage w/ dem DC, wirkt sich das ganze extrem negativ aus?

Danke erstmal an alle !! Ein wirklich cooles Forum

..

Verfasst: **17.03.2009, 17:22**

Wenn man alle Seiten mit SID per 301 auf die ohne SID umleitet sollte es keine Probleme mit DC geben...

Verfasst: **17.03.2009, 19:36**

Ich fasse noch mal kurz zusammen, weil es jetzt doch durcheinandergeht:

1) *Nicht* in der robots.txt sperren
2) 301-Umleitung einrichten (für die URLs die schon bei Google liegen)
3) CMS richtig konfigurieren. Entweder für nicht-eingeloggte User auf die sid verzichten, oder (nicht so schöner aber oft genutzter workaround per Cloaking): beim Aufruf durch bekannte Crawler die sid rausschmeissen.

Verfasst: **17.03.2009, 20:11**

Ähm...

1) Wieso *nicht* in der robots.txt sperren?
2) Wie leitet man eine als Session ID gecrawlte URL per 301 um? Kann man auf diese "so" überhaupt zugreifen?
3) Hat er schon gemacht, es geht nur noch um die bestehenden indexierten Seiten...

ABAKUS

Session IDs in Serps

Session IDs in Serps