Du befindest Dich im Archiv vom ABAKUS Online Marketing Forum. Hier kannst Du Dich für das Forum mit den aktuellen Beiträgen registrieren.

rel=prev/next oder "canonical view all page" für O

Dieses Forum ist für Informationen über Google gedacht (Ausser PageRank!).
Manu v6
PostRank 5
PostRank 5
Beiträge: 306
Registriert: 01.02.2011, 12:20

Beitrag von Manu v6 » 20.11.2013, 14:11

für mich immer noch nicht ganz klar, welche Methode im Hinblick auf DC für eine Kategorie mit mehreren Seiten am besten ist: rel=prev/next oder canonical auf die "view all" Seite.

Laut onpage (Video: https://de.onpage.org/wiki/rel%3D%22next ... %22prev%22) ist das rel=prev und next auch gegen DC. Weiterhin empfiehlt google es selbst für Inhalt, der über mehrer Seiten verteilt ist. google empfiehlt aber auch das canonical für die view all Seite. Meine Bedenken hierbei: wenn ich eine Kategorie mit 300 Artikel vom gleichen Hersteller habe, dann geht das doch sicher in Richtung Keywordspam, oder? (300 x z.B. das Key Bosch auf dieser Seite).

Thomas B.
PostRank 4
PostRank 4
Beiträge: 137
Registriert: 11.09.2013, 21:04
Wohnort: München

Beitrag von Thomas B. » 20.11.2013, 22:30

Rel=prev|next und canonical sind zwei völlig verschiedene Dinge.

Prev und next dienen mehr für einen Navigation zwischen Artikeln die in einem Zusammenhang stehen. Next hat nichts mit weiterlesen oä. zu tun.

Canonical setzt man ein wenn eine URL Parameter hat, wodurch DC entstehen könnte. Damit kennzeichnet man die URL unter der die Inhalte ausschließlich erreichbar sind.

imwebsein
PostRank 9
PostRank 9
Beiträge: 1979
Registriert: 25.09.2011, 23:44

Beitrag von imwebsein » 21.11.2013, 08:40

rel=prev/next nutzt du dür Produktseiten usw. Also immer dann wenn du mehr Produkte hast als Seiten und sich dadurch weitere Seiten öffnen. Und dies vermeidet dann den DC auch in Hinsicht auf Metadaten etc.

So wie ich deine Anfrage verstehe geht es in die Richtung rel=prev/next. Und dann ist es eben kein Spam etc. Wenn du nun mal 300 Bosch Produkte hast dann ist es so, dass weiß ja auch Google. Und das rel=prev/next sorgt sozusagen, dass Sie bildlichgesprochen alle auf einer Webseite liegen und nicht verteilt auf zB. 30 Unterseiten (Mal 10 Anzeigen)

Manu v6
PostRank 5
PostRank 5
Beiträge: 306
Registriert: 01.02.2011, 12:20

Beitrag von Manu v6 » 21.11.2013, 15:49

Ich weiß natürlich dass canonical und rel=next/prev zwei völlig unterschiedliche Dinge sind. Mir geht es hier um die sinnvollste Lösung um DC entgegen zu wirken: canonical ist ganz klar gegen DC, laut onpage.org dient dazu aber (unter anderem) auch das rel=next/prev. (also erfüllen sie dennoch [unter anderem auch] den gleichen Zweck, wenn auch nur bei paginierten Seiten. Bei Kategorien mit Parametern bringt das rel=next/prev natürlich nichts, hier mus das canonical her oder die Paramenter in den WMT ausgeschlossen werden)

@imwebsein: meine Bedenken bezogen sich auf den Einsazt des canonical tag mit Verweis auf die "view all" Ansicht einer Kategorie.

Noch mal vereinfacht: Eine Kategorie in einem Onlinshop hat z.b. 300 Produkte verteilt 10 Seiten. Da die Kategorie auch eine Beschreibung hat und diese auf jeder Kategorie seite angezeigt wird, ist dies ohne canonical oder rel=next/prev ein klarer DC Fall. Was aber am besten machen? Eigentlich ja das canonical tag, jedoch nur wenn es auf die "view all Ansicht" verweist, denn ein Verweis auf z.B. die erste Kategrieseite ist nicht korrekt, denn Kategorieseite 2 ist kein 100% DC zur ersten Seite usw.. Bei umfangreichen Kategorien hat der Kunde dann aber eine fast endlose Liste (wenn er über die google Suche auf diese Kategrie kommt) Und dann sind da noch meine Bedenken mit dem Keywordstuffing/Spam bei sehr umfangreichen Kategorien.

Edit: rel=next/prev gegen DC:

"... dass die Seiten als Duplicate Content gewertet werden, was dann zwar nicht unbedingt automatisch auch gleich ein “Panda-Problem” werden muss, aber den verlinkten Artikeldetailseiten Probleme bereiten kann. Hier kann rel=”prev/next” dabei helfen, die Abfolge sehr ähnlicher Seiten in´s rechte Licht zu rücken." (suchmaschinenland.de, leicht gekürzt)

sweih
PostRank 5
PostRank 5
Beiträge: 304
Registriert: 20.02.2006, 12:16

Beitrag von sweih » 22.11.2013, 12:52

Bei mir ging beides auf.
Was technisch möglich ist. Die Empfehlung von Google war meine ich canonical auf die view-all. Stell dann aber sicher, dass die schnell lädt.

luzie
PostRank 10
PostRank 10
Beiträge: 4228
Registriert: 12.07.2007, 13:43
Wohnort: Hannover, Linden-Nord

Beitrag von luzie » 22.11.2013, 14:21

Manu v6 hat geschrieben:... laut onpage.org dient dazu aber (unter anderem) auch das rel=next/prev.
Tja, dann haben sie das eben einfach falsch verstanden (oder falsch ausgedrückt)

jhm
PostRank 1
PostRank 1
Beiträge: 4
Registriert: 05.07.2013, 09:27
Wohnort: München

Beitrag von jhm » 14.12.2013, 19:09

luzie hat geschrieben:
Manu v6 hat geschrieben:... laut onpage.org dient dazu aber (unter anderem) auch das rel=next/prev.
Tja, dann haben sie das eben einfach falsch verstanden (oder falsch ausgedrückt)
Nein, es wird ja nicht gesagt, dass es ein Ersatz für nen Canonical ist.

Wir haben uns länger mit der Thematik beschäftigt und darauf aufbauend das Tool angepasst. Unterm Strich kann man sagen, dass die Einführung von rel=prev / rel=prev genau so eine Fehlleistung von Google war wie bei rel=nofollow (Link Attribut). Warum? Weil die Webmaster einfach nicht verstanden haben, wofür das Ding da ist.

Gemacht wurde der Tag um bei mehrseitigen Artikel, die erste Seite ranken zu lassen (sprich der Inhalt von Seite 5 wird ebenfalls Seite 1 zugeordnet, da nur diese ranken soll, damit der Benutzer den richtigen Einstieg zu dem Artikel hat). Damit verhält sich die ursprüngliche geplante Arbeitsweise sehr ähnlich wie der Canonical Tag ("Seite X soll ranken, nicht Seite Y").

Da bei der Erklärung aber immer von "Pagination" gesprochen wurde, was bei der Mehrzahl der Webmaster eher in Context von Produktlistings gesehen wurde (mehrseitige Artikel sind ja eher ne Ausnahme bei Content Pages), hat Google dort Verwirrung gestiftet. Das hat dazugeführt, dass immer mehr Shops ihre paginierten Seiten mit rel=prev/next ausgestattet - dieser Use Case ist whrs noch halb mit dem Ursprungsgedanken kompatibel und macht damit sogar u.U. Sinn, sollte wohl aber dennoch mit einem Canonical unterstrichen werden.

Die viel größere Misinterpretation war allerdings, das die Leute gedacht haben, die Meta Angabe rel=prev/next sei zur Crawlersteuerung gedacht - von wegen "Lieber Crawler, als nächstes schau dir bitte Seite X an". Das hat das Ursprungskonzept vollends übern Haufen geworden und würde Google den eigtl Algo dafür anwenden, würden sich einige Seiten komplett selbst aus dem Index kegeln, weil sie Side-Wide diesen Tag benutzen.

Lange Rede kurzer Sinn: Doch, wir bei OnPage.org wissen wofür der Tag steht, allerdings scheint es in dem Wiki Artikel noch nicht 100%ig rüber zu kommen, wird angepasst :)

Gruß, Merl

PS: Wir haben übrigens für die Leute die sich gerne selbst ins Bein schießen die ursprüngliche "harte Bewertung" des Tags ins Tool implementiert, damit die Kunden merken, dass da ne kleine schlummernde Zeitbombe bei ihnen tickt (evtl schaltet Google die Bewertung ja doch nochmal um).

Thomas B.
PostRank 4
PostRank 4
Beiträge: 137
Registriert: 11.09.2013, 21:04
Wohnort: München

Beitrag von Thomas B. » 14.12.2013, 21:36

jhm hat geschrieben:...
Gemacht wurde der Tag um bei mehrseitigen Artikel, die erste Seite ranken zu lassen (sprich der Inhalt von Seite 5 wird ebenfalls Seite 1 zugeordnet, da nur diese ranken soll, damit der Benutzer den richtigen Einstieg zu dem Artikel hat).
...
Das ist nicht ganz richtig, diese Relationen wurden für den Browser gemacht. Wenn ich nicht falsch liege war es der Netscape? Dort wurde eine zusätzliche Navigation eingeblendet, damit der User leichter zwischen den Artikeln navigieren konnte. Es gab auch Relationen für die Übergeordnete Kategorie, Copyright, Startseite und so weiter. Die Suchmaschinen haben sich das nur zu nutze gemacht.

jhm
PostRank 1
PostRank 1
Beiträge: 4
Registriert: 05.07.2013, 09:27
Wohnort: München

Beitrag von jhm » 15.12.2013, 00:18

Thomas B. hat geschrieben: Das ist nicht ganz richtig, diese Relationen wurden für den Browser gemacht.
vgl: https://googlewebmastercentral.blogspot. ... lprev.html

Thomas B.
PostRank 4
PostRank 4
Beiträge: 137
Registriert: 11.09.2013, 21:04
Wohnort: München

Beitrag von Thomas B. » 15.12.2013, 12:07

jhm hat geschrieben:
Thomas B. hat geschrieben: Das ist nicht ganz richtig, diese Relationen wurden für den Browser gemacht.
vgl: https://googlewebmastercentral.blogspot. ... lprev.html
Diese Relationen wurden mit HTML 2.0 eingeführt, das war 1995. Da gab es Google noch gar nicht ...

Beloe007
PostRank 10
PostRank 10
Beiträge: 2928
Registriert: 05.03.2009, 10:31

Beitrag von Beloe007 » 15.12.2013, 12:47

@jhm
Ich habe sowohl view-all und prev/next getestet, das prev/next musste ich wegen Firefox wieder rausschmeißen: https://developer.mozilla.org/en-US/doc ... tching_FAQ Weil der Firefox leider noch alle "Next"-Seiten vorlädt, kann man auch nicht aus stellen.

Funktioniert ansonsten beides wie es soll und beschrieben wird, aber große Seiten mit vielen Firefoxnutzern sollten meiner Ansicht nach auf Prev/Next verzichten, bis Firefox das vielleicht mal abstellt, sofern die NEXT-Seiten nicht wirklich von den meisten als nächstes geklickt werden. Das macht nicht nur Serverlasst sondern verlangsamt auch die Ladezeiten für den User nicht unerheblich.

Vielleicht als Hinweis für eure Leser noch sinnvoll.

@Manu v6
Rel Prev/Next ist kein Mittel gegen DC sondern um die Inhalte vernünftig miteinander zu Verknüpfen, als technischer Hinweis, als roter Faden über verschiedene Seiten sozusagen.

jhm
PostRank 1
PostRank 1
Beiträge: 4
Registriert: 05.07.2013, 09:27
Wohnort: München

Beitrag von jhm » 15.12.2013, 13:40

Thomas B. hat geschrieben:Diese Relationen wurden mit HTML 2.0 eingeführt, das war 1995. Da gab es Google noch gar nicht ...
ja, heißt ja trotzdem nicht, dass Google sich an den ursprünglichen Sinn dessen hält - die haben halt eine eigene Interpretation gemacht und darüber in ihrem Blog mit dem Thema "Crawling und Indexing Sites" geschrieben - sprich aus der Seitenarchitektursicht sollte erst einmal vernachlässigt werden, welche Browserspielerei damit möglich sind und viel mehr sollte man drauf achten, dass man nicht aus Versehen die Seite "zerhaut".

@Beloe007: Danke für den Hinweis - wird mit aufgenommen. Aber dass der Tag dazu da ist, Inhalte logisch zu verknüpfen, war vll mal ursprünglich so gedacht, allerdings sollte man halt aufpassen, welche Schlüsse Google daraus zieht:

"Consolidate indexing properties, such as links, from the component pages/URLs to the series as a whole (i.e., links should not remain dispersed between page-1.html, page-2.html, etc., but be grouped with the sequence).
Send users to the most relevant page/URL—typically the first page of the series."

Sprich, ursprünglich war der Tag als eine Art Canonical von Google ausgelegt (siehe vorherige Beiträge bzw. Blog Post von Google), aber aktuell wird er scheinbar eh nicht ausgewertet, weil zu viele Leute es aus Googles Sicht falsch benutzen, sprich sie haben eingesehen, dass es so wie von Ihnen geplant nicht klappt (was whrs damit zusammenhängt, dass der Tag schon seit Jahren anders benutzt wurde).

Will sagen: Was im OnPage.org Blog steht, ist die "harte" Auslegung des Google Announcements, nicht die Historie des Tags selbst. Aber wir werden das ergänzen, damit man bisschen mehr Einblick über die alternativen Verwendungszwecke erhält. Dennoch würde ich vorsichtshalber von der Verwendung des Tags abraten, außer man hat wirklich einen mehrseitigen Artikel und eine "view-all" Variante. Dann kann man den Tag in der semantischen Funktion, wie sie Google auslegen wollte, verwenden und läuft nicht Gefahr, dass es früher oder später doch mal Probleme gibt.

Pschemi
PostRank 5
PostRank 5
Beiträge: 237
Registriert: 11.08.2010, 14:36

Beitrag von Pschemi » 19.12.2013, 09:32

Ne kurze Frage dazu:

Wenn der Text auf den paging Seiten immer gleich bleibt (also wie auf der ersten Katego Seite) ist rel prev / rel next keine Lösung für den entstandenen DC, oder? In dem Fall müsste man den Kategorietext dann auf den paging Seiten entfernen, stimmts?

Oder view all canonical.
Oder einfach Noindex der paging Seiten (dann ohne rel prev und co)

Sehe ich das so richtig?

Grüße.

Miquel
PostRank 8
PostRank 8
Beiträge: 768
Registriert: 04.07.2013, 14:44

Beitrag von Miquel » 19.12.2013, 09:56

Ich kann dir nur sagen, wie ich es gelöst habe - vlt leitest du darauf deine eigene Lösung ab

1. Wir verwenden grundsätzlich canonical für doppelte Inhalte
2. Bei Mehrsprachigkeit (DE für mehrere Länder) wird noch ein rel lang eingebunden
3. Wenn wir eine inhaltliche Pagination vornehmen, bedeutet gleicher Text, wechselnde Produkte da die Produktlistung über die maximale Anzahl geht & dabei die URL wesentlich gleich bleibt (nur ein Parameter z.B. Seite 1, Seite 2, ...) mit gleicher Kategoriebeschreibung vorliegt, dort arbeiten wir mit rel prev / next.
zu 3. Die Canonical bei uns läuft dann übrigens auch auf der Einstiegsseite der Pagination, nicht eine canonical für jede subseite der pagination.

Wie hier mehrfach erwähnt dient rel prev natürlich zur Definition einer Anfangsseite eines Contentbereiches der über mehrere Seiten geht. Mehrseitige redaktionelle Artikel bei z.B. Focus sind das beste Beispiel. Man kann es aber auch eben wie obig adaptieren.
  • <br />
  • E-Commerce SEO & Online Marketing (B2C) since 2001
    <br /><br /><br />
  • Schwerpunkte: Retail / Gaming / Gambling
    <br /><br /><br />
  • Stationen in Europa & Asien
    <br /><br /><br />
  • Aktuell in der Presse: https://www.onlinemarketingrockstars.de/ ... moga-exit/
    <br /><br /><br />

Pschemi
PostRank 5
PostRank 5
Beiträge: 237
Registriert: 11.08.2010, 14:36

Beitrag von Pschemi » 19.12.2013, 11:31

Das heißt, du setzt auf jede Pagi-Seite einen Canonical tag auf die jeweilige "Startseite der Kategorie (Bsp: Seite-1)"

also
Seite-2 (canonical auf Seite-1)
Seite-3 (canonical auf Seite-1)
...

plus noch rel pref / next?

und alles auf Index oder dann noindex?

Antworten
  • Vergleichbare Themen
    Antworten
    Zugriffe
    Letzter Beitrag