Canonical Tag Duplicate Content

[Werner]

Hallo zusammen,

ich habe eine (1) webseite, die unter

• www.beispiel.de und unter
• http://www.beispiel.de zu erreichen ist.

Im Google-Webmastertool habe ich www.beispiel.de als bevorzugte Domain festgelegt.

In meiner Startseite 'index.html' steht folgender auf sich selbst verweisende canonical tag:

       <link rel="canonical" href="http://www.beispiel.de/index.html">

Bei einer SEO-Prüfung wird immer Duplicate Content angemeckert, weil meine webseite 'auch unter .... index.html' erreichbar sei. Ich kann im Netz leider nicht herausfinden, wie ich es richtig machen muß.

Darf in der Startseite 'index.html' vielleicht gar kein canonical tag stehen? Oder muß er <link rel="canonical" href="http://www.beispiel.de"> heißen - also ohne 'index.html'?

Vielleicht kann mir (Nicht-Profi) ja einer von Euch Profis helfen!

Vielen Dank!

Grüße Werner

[Rolf B]

Hallo Werner,

www.example.org/index.html und http://www.example.org/index.html sind erst einmal kein Duplikate. Die eine URL ist mit Protokoll, die andere ohne Protokoll, das ist kein Unterschied. Unterschiede kann es hier nur geben, wenn Du sowohl über https: als auch über http: erreichbar bist, ich würde aber mal hoffen, dass Google sich nicht an Protokollen stört.

Der eigentliche Zweck der canonical Angabe ist, zu vermeiden, dass Links auf parametrierbare Seiten als Duplicates angesehen werden, d.h. dass

http://www.example.org/index.html und http://www.example.org/index.html?foo=bar

als Duplikat gesehen werden.

Oder http://www.example.org/index.html?foo=bar und http://www.example.org/index.html?foo=bar&filter=c

Wenn sowas vorkommen kann, dann gibst Du die Version ohne Parameter als kanonische Adresse an.

Hast Du das hier schon gelesen?

Rolf

[Mitleser]

Unterschiede kann es hier nur geben, wenn Du sowohl über https: als auch über http: erreichbar bist, ich würde aber mal hoffen, dass Google sich nicht an Protokollen stört.

Das ist nicht nur Google, sondern auch für den Nutzer eine verwirrende Situation.

Warum sollte man heute noch http erlauben, wo https möglich ist?

Wenn man "https" "hat", dann sollte man alles "http" per 301 nach "https" schicken. Thema erledigt.

Nicht nur für den User ist https wünschenswert. Google sagt selbst seit einiger Zeit, dass es sich positiv auf das Ranking auswirken soll.

[pl]

Hi,

der canonical Link zeigt auf eine Seite die exakt denselben Inhalt liefert -- so die g-Empfehlung. D.h., eine der Duplicate-Content Seiten hat diesen Link nicht und alle anderen Seite mit Duplicate Content zeigen canonisch auf diese eine Seite. Vielleicht kann das G ja auch besser erklären, dort also nachlesen. MfG

[Mitleser]

Ist bei Dir übrigens immer noch falsch. Du willst

<link href="http://rolfrost.de/kueche" rel="canonical">

statt

<link href="http://rolfrost.de/kueche?xds" rel="canonical">

Nachtrag: eigentlich willst Du http://www.rolfrost.de/* per 301 nach http://rolfrost.de/* schicken und für http://rolfrost.de/kueche?xds dann den Canonical auf http://rolfrost.de/kueche ausgeben.

[pl]

Das hat schon seine Richtigkeit auf meinen Seiten. Selbstverständlich gibt es auch kanonische URLs mit Parameter, denn viele Anwendungen laufen mit gleichen Inhalten auf unterschiedlichen Domänen. Und da gleiche Parameter gleiche Inhalte erzeugen, sind meine kanonischen Links entsprechend gesetzt. MfG

[Mitleser]

Das hat schon seine Richtigkeit auf meinen Seiten.

Nee.

Selbstverständlich gibt es auch kanonische URLs mit Parameter

Grundsätzlich kannst Du das so machen, es erschwert aber durchaus den korrekten Umgang mit Canonicals.

Und da gleiche Parameter gleiche Inhalte erzeugen, sind meine kanonischen Links entsprechend gesetzt.

Da Du bei Aufrufen von www.rolfrost.de die REQUEST_URI stumpf für den Canonical auf rolfrost.de übernimmst, erzeugst Du unendliche viele, falsche Canonicals, die alle denselben Inhalt ausgeben:

• http://www.rolfrost.de/kueche?a
• http://www.rolfrost.de/kueche?b
• http://www.rolfrost.de/kueche?c
• ...

Duplicate Content ohne Ende. Nicht weiter schlimm, dafür gibt Du ja Canonicals aus (auch wenn in dem Fall 301 angebrachter wäre). Nur, die Canonicals die Du ausgibst, sind eben falsch, weil sie erneut auf Duplicate Content verweisen. Fail.

[pl]

Nur, die Canonicals die Du ausgibst, sind eben falsch, weil sie erneut auf Duplicate Content verweisen. Fail.

Das ist sicher richtig aber nur ein Lateralschaden. Die Lösung ist eine ganz Andere und hat mit canonical gar nichts zu tun. Der canonische Link auf dieser Seite hier ist völlig korrekt.

Danke und Grüße!

[markk]

Moin Hotti,

ich habe eine Frage zu deiner SPA: http://rolfrost.de/spa.html

Dort steht:

Sobald diese Seite in den Browser geladen wurde, werden sämtliche Links zu anderen Seiten von JavaScript übernommen. [..] Interaktive Anwendungen sind davon jedoch ausgenommen

Aber interaktive Anwendungen sind doch genau der Anwendungsfall für single page applications?

Klicke ich auf irgendeinen Link deiner Seite, so werden u.a. folgende Resourcen erneut geladen:

• xjs.js
• alib.js
• logger.js

Diese wurden aber bereits beim Aufruf der Seite spa.html geladen. Zudem erhalten die Resourcen beim erneuten Laden einen Timestamp, so dass das Caching des Browsers umgangen wird - und das obwohl sich die Dateien nicht geändert haben.

Ich bin ein wenig verwirrt. Was genau verstehst du denn unter einer SPA?

VG markk

[Mitleser]

Das ist sicher richtig aber nur ein Lateralschaden. Die Lösung ist eine ganz Andere und hat mit canonical gar nichts zu tun.

Deine "Lösung" hat mit Canonicals nix zu tun ;-)

Der canonische Link auf dieser Seite hier ist völlig korrekt.

Der hier hingegen ist dann wohl falsch.

[pl]

Das ist sicher richtig aber nur ein Lateralschaden. Die Lösung ist eine ganz Andere und hat mit canonical gar nichts zu tun.

Deine "Lösung" hat mit Canonicals nix zu tun ;-)

Na endlich. Weil es über canonical Links nämlich gar keine Lösung gibt für das Problem.

Der canonische Link auf dieser Seite hier ist völlig korrekt.

Der hier hingegen ist dann wohl falsch.

Technisch sind beide korrekt, auch wenn ein unbekannter Parameter anghängt wurde. Aber auch das hat mit canonical nichts zu tun sondern mit der Prüfung von Benutzereingaben. Würde der kanonische Link nämlich auf die Anwendung ohne Parameter zeigen, wäre der Inhalt ein Anderer und die kanonische Link nicht richtig.

MfG

[Mitleser]

https://www.youtube.com/watch?v=Qw7s1nMO4yA

[pl]

https://www.youtube.com/watch?v=Qw7s1nMO4yA

    # Nur bestimmte Parameter erlauben
    my %valipar = ();
    my @inpar = $self->param;
    @valipar{@inpar} = @inpar;
    # erlaubte Parameter löschen
    delete @valipar{qw(find week year)};    
    # was übrigbleibt ist bad request
    return $self->noparam 
        if keys %valipar;

Und wie löst Du sowas? MfG

[Mitleser]

    # Nur bestimmte Parameter erlauben
    my %valipar = ();
    my @inpar = $self->param;
    @valipar{@inpar} = @inpar;
    # erlaubte Parameter löschen
    delete @valipar{qw(find week year)};    
    # was übrigbleibt ist bad request
    return $self->noparam 
        if keys %valipar;

Und wie löst Du sowas? MfG

Wie schon erwähnt: überhaupt nicht. Ich baue die URLs so auf, dass mir überflüssige Parameter (im übrigen müsstest Du bei Deinem Ansatz sogar für die gültigen die Reihenfolge beachten) völlig wurscht sind, weil ich einen passenden Canonical ausgeben kann.

[pl]

    # Nur bestimmte Parameter erlauben
    my %valipar = ();
    my @inpar = $self->param;
    @valipar{@inpar} = @inpar;
    # erlaubte Parameter löschen
    delete @valipar{qw(find week year)};    
    # was übrigbleibt ist bad request
    return $self->noparam 
        if keys %valipar;

Und wie löst Du sowas? MfG

Wie schon erwähnt: überhaupt nicht. Ich baue die URLs so auf, dass mir überflüssige Parameter (im übrigen müsstest Du bei Deinem Ansatz sogar für die gültigen die Reihenfolge beachten)

Seit wann spielt denn die Reihenfolge der Parameter eine Rolle?

völlig wurscht sind, weil ich einen passenden Canonical ausgeben kann.

Und der wäre welcher bei einem Bad Request? MfG

[Mitleser]

Seit wann spielt denn die Reihenfolge der Parameter eine Rolle?

Für Deine Serverseitige Auswertung (vermutlich) nicht. Aber bzgl. Duplicate Content sehr wohl. Folgende drei Kandidaten:

http://rolfrost.de/daysinkw.html?year=2017&week=50&find=1

http://rolfrost.de/daysinkw.html?year=2017&find=1&week=50

http://rolfrost.de/daysinkw.html?week=50&find=1&year=2017

liefern alle erwartungsgemäß denselben Output = Duplicate Content, you lose.

Und der wäre welcher bei einem Bad Request?

Nix Bad Request, den Unsinn hast Du Dir ausgedacht. Am obigen Beispiel: Canonical auf

http://rolfrost.de/daysinkw.html

und fertig. Rolf B hat das von Anfang an die Richtung geschubst.

[pl]

Das Entscheidende für den canonical Link ist nicht wie er sich zusammensetzt, sondern daß er zu einer Seite führt die exakt denselben Inhalt liefert. MfG

[Mitleser]

Das Entscheidende für den canonical Link ist nicht wie er sich zusammensetzt, sondern daß er zu einer Seite führt die exakt denselben Inhalt liefert.

https://www.youtube.com/watch?v=FRpq7o1mKXY

[dedlfix]

Tach!

Das Entscheidende für den canonical Link ist nicht wie er sich zusammensetzt, sondern daß er zu einer Seite führt die exakt denselben Inhalt liefert.

Das entscheidende ist, dass alle Seiten mit gleichem Inhalt auf eine einzige Seite verweisen, die das Original darstellt, für das alle anderen Kopien sind.

So wie du das formuliert hast, könnten die Kopien untereinander auf andere Kopien zeigen. Das wäre nicht der Sinn hinter kanonischen Links.

dedlfix.

[Mitleser]

Das entscheidende ist, dass alle Seiten mit gleichem Inhalt auf eine einzige Seite verweisen, die das Original darstellt, für das alle anderen Kopien sind.

Zusatz: es muss nicht einmal komplett der gleiche Inhalt sein, bereits hinreichende Ähnlichkeit kann einen Canonical auf "die Hauptseite" sinnvoll machen. Hottis Kalender ist da m.E. ein gutes Beispiel:

http://www.handwerkzeugs.de/daysinkw.html?find=1;week=49;year=2017

http://www.handwerkzeugs.de/daysinkw.html?year=2017&week=50&find=1

usw... sollten m.E. alle kanonisch auf

http://www.handwerkzeugs.de/daysinkw.html

verweisen.

[pl]

Das entscheidende ist, dass alle Seiten mit gleichem Inhalt auf eine einzige Seite verweisen, die das Original darstellt, für das alle anderen Kopien sind.

Zusatz: es muss nicht einmal komplett der gleiche Inhalt sein, bereits hinreichende Ähnlichkeit kann einen Canonical auf "die Hauptseite" sinnvoll machen. Hottis Kalender ist da m.E. ein gutes Beispiel:

http://www.handwerkzeugs.de/daysinkw.html?find=1;week=49;year=2017

http://www.handwerkzeugs.de/daysinkw.html?year=2017&week=50&find=1

usw... sollten m.E. alle kanonisch auf

http://www.handwerkzeugs.de/daysinkw.html

verweisen.

Nein, das wäre komplett verkehrt. G*Webmastertools weisen ausdrücklich darauf hin, daß Parameter mitzunehmen sind damit die Bedingung, daß die Zielseite exakt denselben Inhalt, genauer gesagt denselben <body> liefert erfüllt ist. Im Fehlerfall jedoch ist es absolut korrekt, den kanonischen Link ohne Parameter zu setzen. Ich habe diesen ganzen Komplex mal hier zusammengefasst.

Somit ist er kanonische Link auch eine Folge der Fehlerbehandlung und nicht etwa die Lösung für eine Solche.

Schönes Wochenende, MfG

[pl]

Tach!

Das Entscheidende für den canonical Link ist nicht wie er sich zusammensetzt, sondern daß er zu einer Seite führt die exakt denselben Inhalt liefert.

Das entscheidende ist, dass alle Seiten mit gleichem Inhalt auf eine einzige Seite verweisen, die das Original darstellt, für das alle anderen Kopien sind.

Richtig!

So wie du das formuliert hast, könnten die Kopien untereinander auf andere Kopien zeigen. Das wäre nicht der Sinn hinter kanonischen Links.

Richtig! Kopien können auf andere Kopien zeigen wenn man das Anhängen von Parametern erlaubt und das beim Einbau des kanonischen Links nicht prüft. Duplikate Content hat man jedoch bereits schon vorher, also wenn sich infolge angehängter Parameter kein anderer Inhalt ergibt. MfG

[pl]

    # Nur bestimmte Parameter erlauben
    my %valipar = ();
    my @inpar = $self->param;
    @valipar{@inpar} = @inpar;
    # erlaubte Parameter löschen
    delete @valipar{qw(find week year)};    
    # was übrigbleibt ist bad request
    return $self->noparam 
        if keys %valipar;

Und wie löst Du sowas? MfG

Wie schon erwähnt: überhaupt nicht. Ich baue die URLs so auf, dass mir überflüssige Parameter (im übrigen müsstest Du bei Deinem Ansatz sogar für die gültigen die Reihenfolge beachten)

Seit wann spielt denn die Reihenfolge der Parameter eine Rolle?

völlig wurscht sind, weil ich einen passenden Canonical ausgeben kann.

Und der wäre welcher bei einem Bad Request? Im Übrigen, wenn Dir angehängte Parameter wurscht sind, hast Du den Duplicate Content schon bevor Du einen kanonischen Link gesetzt hast.

MfG

[Mitleser]

[...]

Du wiederholst Dich.

Im Übrigen, wenn Dir angehängte Parameter wurscht sind, hast Du den Duplicate Content schon bevor Du einen kanonischen Link gesetzt hast.

Warum denn dieses, mein SEO/Canonical-Guru?

[pl]

Hi noche mal,

Da Du bei Aufrufen von www.rolfrost.de die REQUEST_URI stumpf für den Canonical auf rolfrost.de übernimmst, erzeugst Du unendliche viele, falsche Canonicals, die alle denselben Inhalt ausgeben:

• http://www.rolfrost.de/kueche?a
• http://www.rolfrost.de/kueche?b
• http://www.rolfrost.de/kueche?c
• ...

Duplicate Content entsteht in dem Moment, wenn beim Anhängen von Parametern, wodurch sich ja der URL ändert, derselbe Inhalt ausgegeben wird. Natürlich kann man das Spielchen bis zur Unendlichkeit treiben. Aber es hat 1. mit canonical nichts zu tun und dürfte 2. sehr viele Seitenbetreiber betreffen. Unter Letzteren ist auch dieses Forum davon befallen.

Schöne Grüße 😉

[Mitleser]

Duplicate Content entsteht in dem Moment, wenn beim Anhängen von Parametern, wodurch sich ja der URL ändert, derselbe Inhalt ausgegeben wird.

Das ist eine Möglichkeit. Daher war ich mit den Ausführungen von Rolf B nicht ganz glücklich, aber der Satz "Der eigentliche Zweck der canonical Angabe ist, zu vermeiden, dass Links auf parametrierbare Seiten als Duplicates angesehen werden" ist einfach die häufigste Situation.

Natürlich kann man das Spielchen bis zur Unendlichkeit treiben.

Exakt. Daher hat Rolf B explizit auf die Canonicals hingewiesen, die das Problem lösen.

Aber es hat 1. mit canonical nichts zu tun

Doch, doch!

und dürfte 2. sehr viele Seitenbetreiber betreffen

Das stimmt.

[pl]

Hi,

Aber es hat 1. mit canonical nichts zu tun

Doch, doch!

Sei doch mal so gut und setze ein Struktogramm auf oder Pseudocode einer Kontrollstruktur, wie Du dieses komplexe Problem angehen würdest. Also einmal haben wir Seiten wo es unerwünscht ist, Parameter anzuhängen. Dann haben wir Anwendungen, bei denen bestimmte Parameter über den URL geschleift werden. Bei Request Method GET überschneiden sich die Problematik der Validierung von Parametern mit der Problematik korrekte kanonische Links einzubauen.

Auf jeden Fall weist G* darauf hin, daß der Kanonische Link auf eine Seite mit exakt gleichem Inhalt zeigen muss, einschließlich an URL angehängter Parameter. D.h., wenn die Anwendungen nur POST verwenden, haben die kanonischen links verständlicherweise auch keine angehängten Parameter aber es könnten Parameter sein, die in der Anwendung nicht erlaubt, also zu prüfen sind. Und kanonische Links die auf die Seite selbst zeigen darf es auch nicht geben.

Also bitte, zeige mal hier eine entsprechende Kontrollstruktur. MfG

[Mitleser]

Sei doch mal so gut und setze ein Struktogramm auf oder Pseudocode einer Kontrollstruktur, wie Du dieses komplexe Problem angehen würdest…

Nicht nötig, DU hast diesen kaputten, zum scheitern verurteilten Ansatz in den Raum geworfen, also habe ich Dir viel Spaß dabei gewünscht. Dein Ansatz ist kaputt, Rolf B hat beschrieben, wohin die Reise geht.

Auf jeden Fall weist G* darauf hin, daß der Kanonische Link auf eine Seite mit exakt gleichem Inhalt zeigen muss, einschließlich an URL angehängter Parameter.

Quatsch. Quelle?

Und kanonische Links die auf die Seite selbst zeigen darf es auch nicht geben.

Quatsch. Quelle?