Dass der duplicate content in den letzten Monaten gesteigerte Bedeutung erlangte, hat nicht zuletzt mit der steigenden Verbreitung von Splogs, also Spam-Blogs, zu tun*. Man muss jedenfalls eine Menge Vorkehrungen treffen, damit unter der eigenen Domain jeder Artikel nur einmal aufscheint. Duplicate Content Cure oder Meta Robots lösen die gröbsten Troubles (ich verwende beide Erweiterungen), effektivere Resultate erreicht man mit der direkten Aussperren von Bots in der robots.txt: diese Datei liegt gemeinhin im Rootverzeichnis und enthält Anweisungen für Crawler — und die Big Three (Google, MS, Yahoo) halten sich auch dran.

Word of Warning: Mit Manipulationen an der robots.txt-Datei kann man sich eine gut funktionierende SERP-Struktur im Nu abfucken. Außerdem spielt die Frage, ob man z.B. in der Tag– und Category-Ansicht Exzerpte verwendet eine beträchtliche Rolle — ebenso wie die Entscheidung, welche Einzelpages gut indiziert werden sollen. An Impressum und Kontaktformular möchte ich z.B. lieber keinen Linkjuice verschwenden. In solchen Fällen machen interne nofollow-Links hochgradig Sinn, aber das ist eine andere SEO–Geschichte und soll ein andermal erzählt werden…

Word of even more Warning: Die nachfolgende angegebenen Tipps beziehen sich auf *meine* Permalinkstruktur. Wer keine sprechenden Permalinks verwendet oder stark abweichende Einstellungen, kann mit den folgenden php-Wildcards Crawlern den Zugriff auf Beiträge komplett verunmöglichen. Also in jedem Fall ein Backup der robots-Datei anlegen und testen, testen, testen! Sehr hilfreich dabei: das kürzlich erwähnte Crawler-Tracker Plugin.

Exclusions im robots.txt

Einige reguläre Ausdrücke sind im robots.txt erlaubt, $ steht in Regex-Terminologie dabei für das Ende des Dateinamens. Die Syntax “.php$” erfasst also alle Dateien, die auf *.php enden. Man kann damit zum Beispiel den Crawler-Zugriff auf alle pdfs, exe-Dateien und Bilder sperren:

Disallow: /*.pdf$
Disallow: /*.jpeg$
Disallow: /*.jpg$
Disallow: /*.gif$
Disallow: /*.png$
Disallow: /*.exe$

Daraus ergeben sich zahlreiche weitere Möglichkeiten, die man ja nach eigener Präferenz frei kombinieren kann:

Disallow: /*? — alle URLs mit Fragezeichen drin werden geblockt. Kann natürlich nur dann verwendet werden, wenn in den Standard-URLs kein Fragezeichen vorkommt.

Disallow: /*.php$ — blockiert alle php-Files
Disallow: /*.inc$ — verhindert den Zugriff auf include-Dateien.
Disallow: /*.css$ — verbirgt Stylesheet-Dateien (falls mehr als eine in Verwendung ist.)
Disallow: */feed/ — verhindert das Einlesen des Feeds.
Disallow: */trackback/ — verhindert das Indizieren der Trackback–URLs.
Disallow: /tag/ — Tag-Pages ausschließen
Disallow: /category/ — Kategorie-Seiten ausschließen.
Disallow: /2006/ — Disallow: /2007/ — Disallow: /2008/ — Zugriff auf Jahresarchive verbieten

Möchte man nun aus irgendwelchen Gründen den Zugriff auf eine der oben ausgeschlossenen Seite explizit erlauben, kommt dazu folgende Syntax zum Einsatz:

Allow: /category/meineseite.php — erlaubt den Zugriff auf die angegebene Adresse, auch wenn /category/ als Pfad gesperrt ist.

Sollte man nun besser die oben angegebenen Plugins oder die robots.txt-Methode verwenden? Um die Unterschiede zu verstehen, muss man ein weniger tiefer in SEO-Welten abtauchen: während die beschriebenen Plugins die von Google vorgesehene Syntax noindex bzw. nofollow in den Header der betreffenden Dateien einfügen, sorgt die robots.txt-Variante dafür, dass überhaupt nie auf die betreffenden Seiten zugegriffen wird. Ob die beiden Varianten in der Praxis einen Unterschied machen, darüber streiten derzeit die SEO-Experten — siehe auch die Diskussion zum betreffenden Eintrag bei Shoemoney.

Außerdem ist davon auszugehen, dass Google mittlerweile WP-Installationen erkennt und selbst Vorkehrungen gegen Duplicate Content trifft — aber diese Gleichung enthält eine Menge Variablen, und nachteilig ist’s ganz gewiss nicht, wenn man sich als Seitenbetreiber selbst drum kümmert, dass der Crawler ausschließlich unique content serviert bekommt.