Nach meinem Artikel Mehrere Ankertexte durch Canonical Tag erschien gestern auf SEOMoz.org ein Beitrag zum Canonical Tag und dem 301 Redirect, der den Einsatz dieser Techniken kritisch betrachtet und Vorschläge für DO’s and DONT’s gibt. Beide Techniken werden eingesetzt, um Duplicate Content Issues zu vermeiden und den Pagerank-Flow zu konsolidieren. Das wird dadurch möglich, dass die Suchmaschinen den Linkjuice und den Ankertext auf die „richtigen“ Seiten übertragen und diese dort gebündelt werden.
301 Redirect
Unter einem 301 Redirect versteht man eine Weiterleitung, bei der der HTTP Statuscode 301 gesendet wird. Dieser besagt, dass die aktuell aufgerufene URL keine Ressourcen mehr enthält, sondern sich diese stattdessen an einem anderen Ort befindet. Dieser Ort bzw. genauer diese URL wird zusammen mit dem HTTP Response Header verschickt. Für den Browser sieht das dann also so aus wie im Quellcodebeispiel unten:
HTTP/1.1 301 Moved Permanently
Location: http://example.org/i_am_the_new_one
Zur Realisierung mit PHP findet ihr Informationen dazu in diesem PHP redirect Artikel. Das besondere bei diesem Redirect ist, dass man auch physisch auf die neue Seite weitergeleitet wird (die URL im Browser ändert sich also). Aus Suchmaschinensicht wird sowohl PR als auch Ankertext weitergeben wobei die Suchmaschinen dies nicht 100%ig garantieren, wie dieses Video von Matt Cutts zeigt:
Wann benutzt man 301 Redirects?
Die Benutzung von 301 Redirects sollte man in den folgenden Fällen in Betracht ziehen:
- Zusammenlegung von Seiten mit identischem Inhalt (zum Beispiel bei Erreicbarkeit von inhaltsgleichen Seiten mit und ohne www)
- Umstrukturierungen, bei denen alten Seiten eine neue URL erhalten
- Veralteter Content (zum Beispiel veraltete AGB, für die es eine neuere Version unter einer anderen URL gibt)
Fallen und Probleme bei 301 Redirects
- Auf den richtigen Code achten: 301 (Moved Permanently) ist nicht gleich 302 (Found) oder 307 (Temporary Redirect), diese Codes sorgen wahrscheinlich nicht dafür, dass PR oder Ankertext vererbt wird.
- Nicht alles auf eine Seite weiterleiten: Aus Bequemlichkeit wird dies oft gemacht, wenn eine Seite umstrukturiert wird. Das hilft zum einem dem User nicht und kann zum anderen ein Flag bei Google setzen.
rel=“canonical“
Der Canonical Tag ist ein Meta Tag, der im <head> Bereich einer HTML Seite eingesetzt wird. Dadurch ist es möglich, Google mitzuteilen, dass es eine kanonikalisierte Version der aktuell angezeigten URL gibt, die vom Seitenbetreiber als die „richtige“ angesehen wird und in den SERPs auftauchen sollte. Das unten dargestellte Quellcodebeispiel zeigt exemplarisch, wie der Canonical Tag eingesetzt wird:
<html>
<head>
<meta rel="canonical" content="http://example.org/i_am_the_right_one" />
</head>
...
</html>
Zu beachten ist, dass eine Seite, die den Canonical Tag beinhaltet weiterhin existiert (also unter ihrer URL aufgerufen werden kann), sie ihren PR und Ankertext allerdings an das Ziel des Canonical Tags weitergibt. Auch hier geht man von einem gewissen Verlust dieser Werte aus.
Wann benutzt man rel=“canonical“
In Kürze:
- Dort wo 301 nicht eingesetzt werden kann (weil man technisch keinen Zugriff hat zum Beispiel)
- Dort wo es Navigationshintergründe hat (zum Beispiel bei Artikeln, die unter verschiedenen Kategoriepfaden zu erreichen sind: Gartenstühle sind unter „Holzmöbel“ und unter „Gartenzubehör“ zu erreichen)
- Dort, wo die URL erhalten bleiben soll (z.B. bei Druckversionen einer Seite oder Parametern für das Tracking)
Fallen und Probleme bei dem Canonical Tag
- Gleiches wie beim 301er: Nicht alles auf eine Seite weiterleiten bzw. „kanonikalisieren“
- Er ist einfacher zu implementieren als der 301 Redirect – das kann faule Webmaster dazu veranlassen, den Canonical Tag statt des Redirects einzusetzen obwohl es unpassend ist
Im SEOmoz Artikel werden noch die Gründe „bei neuen Seiten“ und „bei Pagination“ (Einteilung in Seiten) genannt, denen ich aber so nicht unbedingt zustimmen kann. Pagination mag ok sein, das kommt auf den Anwendungsfall an, aber „bei neuen Seiten“ halte ich für Blödsinn. Wie gesagt, bei Druckversionen ist es die beste Möglichkeit um den PR auf der „Webversion“ zu konsolidieren, warum also nicht benutzten?
