Duplicate Content Case Study – Heute: yigg.de

www.yigg.deEs gibt 1.000 Gründe, wie unerwünschter Duplicate Content entstehen kann: Unkontrollierbare Skripte, mangelndes Verständnis für das eigene CMS, sorglose “Syndizierung” eigener Inhalte und ein paar “typische Probleme” die man stets beachten sollte.

Ich habe den (IMHO coolen) deutschen Digg-Clone yigg.de mal als case study herangezogen, weil hier meiner Meinung nach viel Optimierungsbedarf besteht. Das soll nicht heißen, dass die Entwickler Fehler gemacht haben – es gab sicher wichtigeres zu tun – sondern, dass einfach Tasks, die in den SEO-Bereich fallen, vernachlässigt wurden.

1. Standarddomain definieren

Ein gängiger Fehler ist das Unterlassen der Definition einer Standard-Domain. Das heißt im Fall von Yigg, dass ich die Artikel unter yigg.de aber auch unter www.yigg.de erreichen kann. Tatsächlich erwächst daraus selten eine Strafe, optimal ist der Zustand dass Webseiten sowohl unter der 2nd-Level-Domain als auch unter www.domain.de erreichbar sind mit Sicherheit nicht. Um des Problems Herr zu werden gibt es 2 Möglichkeiten:

1.1 Standard-Domain per .htaccess-Datei definieren

Durch folgenden Eintrag in die .htaccess im Stammverzeichnis zwingt man den Server per mod_rewrite alle Browser und Bots (!) auf die Version mit “www.*” umzuleiten:

RewriteEngine on

RewriteCond %{HTTP_HOST} !^www\.yigg\.de$
RewriteRule ^(.*)$ http://www.yigg.de/$1 [L,R=301]

2.2 Google Webmaster Tools – Preferred Domain

In den Google Webmaster Tools kann man nach erfolgreicher Anmeldung seiner Domain die “preferred Domain” festlegen. Einfach gesagt kann man Google mit einem Klick sagen welche Version man ausschließlich im Index finden will.

2. Dynamische und statische URLs aufruf- und indizierbar

Im Fall von yigg.de ist es mit diesen Maßnahmen leider noch nicht getan. Zusätzlich lässt sich die obige Story immernoch dynamisch aufrufen (und indizieren!): http://www.yigg.de/familiar.php?story=32513

3. Mirrors, Dev-Domains, HTTPS

Insgesamt finden sich schon 8 Varianten der selben Seite im Google-Index. Weitere könnten entstehen wenn Google die Dev-Subdomain devel.yigg.de weiter crawlen darf. Hier wäre eine robots.txt, besser noch Verzeichnisschutz per .htaccess angebracht.

Exkurs: Development-Subdomains, DB-Admin-GUI und Backends

Allein durch die Benutzung der Alexa-Toolbar durch den Admin enttarnt alexa.com oft sämtliche administrativen Subdomains. Daher ist man stets gut beraten soetwas nicht über Subdomains, sondern Verzeichnisse zu lösen und diese oder die Subdomains mit .htaccess zu schützen.

4. Speaking URLs / mod_rewrite richtig einsetzen

Ein weiterer Tipp: Wenn ich eine ID in den sprechenden URLs nutze, ist es meistens sinnvoll diese beim mod_rewrite auszulesen und stets auf die speaking URL umzuleiten. Sonst könnte theoretisch so etwas entstehen:

http://yigg.de/32513_Wikipediaorg_gibt_das_Prinzip_kollektive_Intelligenz_auf

http://yigg.de/32513

Beide URLs sind aufrufbar und indizierbar. Oft befinden sich auch schon beide Versionen im Index. Im schlimmsten Fall kann ein böser Konkurrent sogar derart mit den URLs spielen und sie anlinken, dass er endlich viele Duplikate in die Welt den Index setzt. Daher stets nur die ID auslesen und alles auf eine endgültige URL (Permalink) jagen.

5. Aus Fehlern lernen und das Beste draus machen

In jedem Fall ist oft noch nicht Hopfen und Malz verloren, sondern man kann meistens durch intelligente 301-Umleitungen und rewrite rules den Google-Juice der Dupe-Seiten und auf sie verweisenden Links noch nutzen. Daher gilt im Zweifel: Immer besser umleiten als sterben lassen.

Idealerweise (es sind z.B. IDs vorhanden) leitet man alle Duplikate mittels Server Code 301 (redirect permanent) auf die eine zukünftige URL um, für die man sich entschieden hat. Ich präferiere im Zweifel die kürzeste URL, die außerdem Keywords enthält. Leider ist das nicht immer möglich. Dann ist es ratsam die URLs auf die Startseite umzuleiten oder im schlimmsten fall eine 4xx Statuscode senden zu lassen.

6. Der Klassiker (index.html,index.php)

Huch, hätte ich fast vergessen: Wahrscheinlich DER häufigste Fehler überhaupt: yigg.de und yigg.de/index.php rufen ein und dasselbe Skript auf, stellen aber ebenfalls für Suchmaschinen 2 URLs mit gleichen Inhalten dar. Also wenn ich in der Navigation auf die Startseite verweise, sollte ich einfach auf die Domain bzw. den Stammordner linken.
Sicher gibt es noch andere Standard-Fehler, die ich gerade nicht bedacht habe. Dann gerne in die Kommentare.

7. Nachtrag: Duplicate Domains

Auch ein recht häufig vorkommender Mangel: yigg.co.uk Es ist immer richtig, sich solche Domains frühzeitig zu sichern. Aber entweder sollte man redundante Domains umleiten oder einen Platzhalter einrichten. Wenn es geht nicht einfach alle Domains auf den gleichen Webspace zeigen lassen. Meistens passiert dieser Fehler wenn man sich mehrere Domainendungen sichern muss, oder wenn man beispieldomain.de und beispiel-domain.de kauft.

Schlagworte: , , , , , ,

18 Kommentare zu „Duplicate Content Case Study – Heute: yigg.de“

  1. baynado sagt:

    Eine Frage, wenn Du diese Misstände öffentlich ansprichst, warum hast Du dann dem Entwicklerteam nicht direkt Deine Verbesserungsvorschläge unterbreitet?

  2. pip sagt:

    1. geht kein Sicherheitsrisiko und damit auch kein Grund für ein verdecktes Handeln von den Sachen aus.

    2. geht es ja nicht darum yigg zu dissen, sondern es handelt sich hierbei wirklich um die häufigsten fehler, die du auf ca. 90% aller (auch renommierten) webseiten finden wirst.

    die punkte an die entwickler zu schicken hätte genau 1 Problem gelöst. Das von yigg. Ich bilde mir aber ein, dass auch andere (Entwickler, SEO-Noobs) hier noch was lernen können.

  3. Michael sagt:

    Hi pip,

    vielen Dank für Deinen Beitrag und damit Input. Wir werden uns die Thematik anschauen und entsprechend handeln.

    Beste Grüsse
    Michael

  4. pip sagt:

    Dazu war es gedacht, gern. ;)

  5. Duplicate Content…

    Über die Vermeidung von doppelten Inhalten. Hinweis auf einen guten Überblick bei Philipp vom ice-blog.de
    ……

  6. Christian sagt:

    Guter Beitrag. Aber ich finde es ungünstig, Yigg als Fallbeispiel zu wählen, weil sich das Hauptseitenbeispiel gerade bei Yigg nicht als problematisch erweist.

    Dadurch, dass der Hauptseitescontent quasi volldynamisch generiert wird, ist die Wahrscheinlichkeit relativ gering, dass die Spider in diesem Falle DC feststellen. Schau mal hier.

    Cache ist von “beiden Hauptseiten” stets relativ frisch. Ich denke Yigg sollte diesen technischen Vorteil ruhig weiter nutzen und wenn überhaupt nur Unterseiten auf eine “genormte” Adressvariante umleiten.

  7. soeren onez sagt:

    Ich werde vor allem den Punkt 5 in Zukunft brauchen, wie mache ich denn sowas, bzw. bevor du jetzt einen ganzen Artikel in die kommentare postetst, wo kann ich soetwas nachlesen mit der htaccess solche Probleme lösen zu können. hast du vielelciht einen Link dem ich folgen und mich informieren könnte? Danke

  8. Andy Zmuda sagt:

    @soeren onez

    In den Übersichtsseiten werden die Links zu den Blogeinträgen generiert …. wenn ein Eintrag angezeigt wird, einfach auch nochmal die URL generieren und mit dem Inhalt der URLzeile vergleichen

    function make301($goto)
    {
    header(“HTTP/1.1 301 Moved Permanently”);
    header(“Location: http://$goto“);
    exit;
    }

    $URLserv = ‘domain.tld/blog/hallo.html’;

    if ( $URLserv
    && $URLserv !=
    $_SERVER[HTTP_HOST].$_SERVER[REQUEST_URI] )
    make301($URLserv);

  9. Stefan G. sagt:

    Hmm die hälfte von dem Zeug geht auf yigg nichtmehr, heute zumindest. Auf devel.yigg.de (was war da?) kommt eine Passwortanfrage, und yigg.de leitet auf http://www.yigg.de weiter.

    Ich persönlich finde so einen Pranger hier unter dem Vorwand anderen zu helfen absolut daneben. Du hättest genausogut den Text mit Tips ohne ein Beispiel einer bekannten Website bringen können.

    Das hier halte ich für eine total billige Variante im Fahrwasser anderer zu schwimmen, echt pfui, das ist total daneben. Du stellst hier Leute an die Wand ohne das Du dort mal darauf hingewiesen hast, das ist echt eine Glanzleistung

  10. Sven sagt:

    Ich finde diesen Artikel sehr interessant. Das YiGG als Beispiel genannt wurde, hilft den Jungs dort nur Fehler zu vermeiden und stört mich deshalb nicht. Ein Pranger sieht imho anders aus. Aber früher dachte ich mal, wir würden Seiten/Blogs/Webapplikationen bauen, damit Menschen was davon haben.

    Heute muss man doppelten Content vermeiden, den Pagerank beachten, hippe Keywords in den Texten verwenden, semantische Hilfen geben und so weiter, weil die Suchmaschinenrobots zu blöd sind, die interessanten Inhalte selber zu erkennen. Alles Krücken, die nicht wirklich etwas über den Informationsgehalt eines Artikel aussagen.

    Und das jetzt noch Aufgrund von Regeln, die mehr ins Mystische gehen, temporär von Implementierungen abhängen und von Anbieter zu Anbieter unterschiedlich sind.

  11. Tim sagt:

    @sven
    Es geht darum guten Content so aufzubereiten dass er von Suchmaschinen auch als guter Content erkannt werden kann. Denn wem hilft ein gutes Angebot, Produkt oder ein Forum das nicht gefunden werden kann, weil es sich hinter zich Frames und Javascript versteckt. Diese Aufgabe den Suchmaschinen zuzuschreiben kommt in meinen Augen der Frage nahe warum ein Auto denn nicht auch fliegen könne.

  12. pip sagt:

    das mit dem pranger moechte ich zurueckweisen. yigg war in der tat einfach ein parade-beispiel, was dir jeder der sich mit dem thema beschaeftigt bestaetigen kann.

    letztendlich offenbart es keine ‘fehler’ sondern nur optimierungsbedarf. und der text besteht aus kostenlosen tipps fuer yigg und andere. normalerweise bekommst du solche tipps in einem 50seitigen gutachten fuer 20k euro das dann anfaengt mit ‘wir melden ihre seite bei allen suchmaschinen’ an.

    es geht wirlich nicht darum yigg zu dizzen sondern um einen workaround, der 90% aller seiten gut taete.

  13. Hardy sagt:

    Nun, die Tips sind vielleicht nicht schlecht, allerdings haben sie eine entscheidende Sache einfach unter den Tisch fallen lassen:

    es ist eben dann *kein* Duplicate Content, wenn meine Site zwar unter 1) www. test.de 2) test.de 3) www. test.de/index.php aufzurufen ist, faktisch aber alle Links nur auf http://www.test.de verweisen. Dann sind die anderen Versionen zwar DC, aber nur in der Theorie.

    Faktisch kümmert sich keine Sau, und auch keine Suchmaschine, um diese Doubletten.

  14. pip sagt:

    wenn keine links drauf verweisen würden, wären die seiten nicht im index, oder? ;)

  15. [...] Wie das ganze geht und warum man es machen sollte, beschreibe ich bald im ScoutPress-Blog. Nur zwei Stichworte: Gute URL-Konzepte sind sehr wichtig, nicht zuletzt um Duplicate Content zu vermeiden. [...]

  16. [...] Früher konnte man die groben Fehler noch einzeln analysieren. Eine Bewertung des letzen Relaunch inkl. Verbesserungsvorschlägen würde aber Tage dauern. Daher Kurzurteil: 6, setzen! Alles ist und war besser als das. [...]

  17. helmeloh sagt:

    Zu “Ein gängiger Fehler ist das Unterlassen der Definition einer Standard-Domain” frage ich mich, wieso du dann auf Webmaster Tools von Google folgendes findest:
    “Die bevorzugte Domain ist die Domain, die für die Indizierung der Seiten Ihrer Website verwendet werden soll. Falls Sie Ihre bevorzugte Domain mit http://www.example.de angeben und wir einen Link zu Ihrer Website finden, der das Format http://example.de aufweist, folgen wir diesem Link als http://www.example.de. Darüber hinaus berücksichtigen wir Ihre Einstellung bei der Anzeige der URLs in den Suchergebnissen. Es kann einige Zeit dauern, bis die Änderungen in unserem Index sichtbar werden. ”
    und die bevorzugte Domain einstellen kannst. Naja, SEO’s eben, keine Ahnung von der Materie.

  18. pip sagt:

    lieber helmeloh,

    obwohl ich keine Ahnung von der Materie habe, habe ich damals schon in Punkt 2.2 darauf hingewiesen, dass man dieses auch über die Webmaster-Tools lösen kann:

    2.2 Google Webmaster Tools – Preferred Domain

    In den Google Webmaster Tools kann man nach erfolgreicher Anmeldung seiner Domain die “preferred Domain” festlegen. Einfach gesagt kann man Google mit einem Klick sagen welche Version man ausschließlich im Index finden will.

    Außerdem sollte auch dem Dümmsten auffallen, dass im Artikel ein Beispiel genannt wird, dass beweist, dass yigg KEINE von beiden Lösungen gemacht hat.

    Lies doch erstmal fertig, bevor du meckerst. Im Übrigen würde ich das definieren der Standdarddomain per Apache TROTZDEM noch vorziehen.

    Liebe Grüße

Kommentieren