dies wird natürlich abgestraft wegen doppelten interner content was natürlich alles andere als gut ist für die positionierung bei google.
jetzt die frage wie ich das abstellen kann? Kann man die doppelte indexierung bzw. die indexierung der varianten irgendwie unterbinden? oder kann man es irgendwie machen, dass das system gar nciht erst eine url für die varianten erstellt?
There’s no such thing as a “duplicate content penalty.” At least, not in the way most people mean when they say that.
Wenn es das gäbe, hätten alle Elektronik- und Computershops riesige Probleme, da die ja i.d.R. die Artikelbeschreibungen vom Hersteller oder externen Anbietern solcher Dienste übernehmen.
“Duplicate content” innerhalb derselben Domain ist lt. Google absolut problemlos…
Und wer sollte das besser beurteilen können als Google?
Lass Euch doch nicht jeden Dummquatsch aufschwätzen!..
um ganz sicherzugehen, arbeiten wir mit so genannten Canonical Tags, damit Google weiss, dass es noch ein anderes Produkt mit gleichem Inhalt und etwas anderer URL gibt. In der Variante 50g Eurer Vanille-Soße enthält einen solchen Canonical Tag:
Ich muss das Thema noch mal wieder aufgreifen. Mir ist in meinem Oxid Shop auch diese Thematik gerade aufgefallen. Ich setze einen oxid v 4.4.8 ein.
In dem o.g. Shop funktioniert das ordnungsgemäß mit dem canonical-tag. Wenn eine Variante aufgerufen wird, z.B. aus dem Warenkorb heraus wird im canonical-tag richtig die Vater-Artikel-URL angezeigt.
Bei mir funktioniert das interessanterweise nicht. Die canonical tags zeigen, wenn ich über Hersteller, Kategorie oder Suche auf den Artikel gehe, richtig die Vater-Artikel-URL an, wenn ich aber über den Warenkorb eine Variante des Artikels öffne, steht dort die Varianten-URL drin.
ich denke nicht, dass es über “Einstellungen” gesetzt werden kann. Nutzt Du ggf. ein alternatives Template? Ansonsten hört es sich fast nach einem Bug an. Versuch es doch bitte mal im Demoshop nachzustellen und trag dann einfach in den Bugtracker ein.
Hallo Marco. Danke für deine Rückmeldung. Ja, ich nutze schon ein alternatives bzw. angepasstes Template. Ich werde das mal im Demoshop vergleichen. Gruß Schorty
Moin Leute und frohes Neues!
Das Problem ist nachvollziehbar und evtl. gibt es bereits eine Lösung dafür (habe ich noch nicht getestet, aber wird gleich nachgeholt und dann berichtet): http://www.oxid-esales.com/forum/showthread.php?t=8969
Aber ich muss mal blöde fragen, ob und wie es überhaupt passieren kann, dass eine Suchmaschine Artikel in den Warenkorb legt? Das sind doch immer POST-Formulare hinter den Cart-Buttons und außerdem braucht es zum Speichern ja Session-Cookies. Falls es doch gehen sollte, wäre die Frage, ob nicht eher dies der Bug ist, oder was meint ihr?
Nach einem Test im v. 4.4.8 Demoshop kann ich das Verhalten auch noch mal bestätigen.
@ChristophH: Danke, dass du einen neuen Fall im Bugtracker aufgemacht hast. Bin nicht so der Englisch Crack
@Mitmacher: Bei mir ist ein sitemap Generator Modul im Einsatz, welches eine sitemap.xml erzeugt und die ich in den Google Webmaster Tools angegeben habe. In der xml Datei sind auch die Varianten URL enthalten. Vermutlich weiß Google deswegen von diesen URL. Ich habe den Modulentwickler heute kontaktiert, ob man in dem Modul eine Auswahl nur Vater oder alle Artikel einbauen kann.
Ich halte den Einsatz aber gerade in älteren “Basic”-Shops für etwas fraglich, da man dort mangels JS-Trickserein eher in der Bedienung eingeschränkt wird, wenn man direkte Varianten-Aufrufe zu verhindern versucht. Aber das hängt natürlich vom konkreten Layout ab.
Edit:
So, die beiden neuen Module sind nun auch im Demo-Shop integriert…
Sodalla, jetzt musste ich das Modul leider wieder deinstallieren. Im Backend lässt sich bei Bestellungen bei aktiviertem Modul leider der Reiter Stamm nicht mehr auswählen. Hier wird dann anstatt den Stammdaten das Shopfrontend im unteren Frame dargestellt.
Ups, stimmt, da wird auch noch zig mal getArticle() aufgerufen, aber ohne ID, keine Ahnung warum, aber ich überspringe meinen Code nun bei leerer ID, dann gibt es auch keinen Fehler mehr. Ein Update ist online (siehe unten)…
vielen Dank für das Update. Jetzt funktionieren die Vaterartikellinks leider vom Basket aus nicht mehr. Im Miniwarenkorb hingegen klappt alles einwandfrei, der Link wir entsprechend vom Vaterartikel genommen. Wenn man jetzt allerdings das Modul aus den Systemeinstellungen entfernt, wird das Frontend überhaupt nicht mehr angezeigt (weiße Seite). Schon eigenartig irgendwie…
Nachtrag: Nach dem Löschen der Cookies und öffnen des Frontends in einem neuen Browserfenster behebt das Problem mit dem leeren Frontend.
Owei, sorry, nochmal arg gepennt… :o
Die aktuelle Version 1.0.2 behebt aber auch dieses “Problem”. Und weiße Seiten sind oft Fehler, die der Server nur nicht anzeigt, gerade bei Modul-Tests. Oft hilft in der Tat das Leeren des Caches und /tmp und evtl. Cookies.
