Unternehmen und Angebote verändern sich – die zugehörigen Internetauftritte meist auch. Doch der so genannte Relaunch birgt neben einer Vielzahl von technischen Herausforderungen auch aus der Sicht der Suchmaschinenoptimierung eine Vielzahl von Tücken und Stolpersteinen. Insbesondere bereits bestehende Suchmaschinenrankings können sich nachhaltig verschlechtern oder gar ganz verschwinden, wenn nicht die richtige Strategie gewählt wird.

Die Wahl des richtigen CMS

Die häufigsten Probleme bringt meist der Wechsel des Content-Management-Systems (CMS) mit sich. Hier empfiehlt es sich, vorab zu prüfen, ob das CMS auch grundlegende Anforderungen für eine Suchmaschinenoptimierung erfüllen kann:

1. URL Struktur
   • Sind „sprechende“, frei definierbare URLs möglich?
   • Werden die URLs ohne Session IDs abgebildet?
2. Accessibility
   • Ist es grundsätzlich möglich, die Seite ohne das „zwingende“ Annehmen eines Cookies zu betreten?
   • Generiert das CMS „sauberes“ HTML Mark-up, basierend auf den offiziellen Standards des W3C?
   • Verzichtet das CMS bei der Einbindung wichtiger Elemente – wie z.B. der Navigation – auf Flash und JavaScript (oder wird eine alternative Version für Crawler generiert)?
3. Meta Tags & Seitentitel
   • Ist es möglich, den Seitentitel pro URL frei zu definieren?
   • Können Meta Description (und Keywords) sowie das Robots Meta Tag pro Seite verwendet werden?

Migration von bestehenden URLs

Im Regelfall verändert sich bei einem Relaunch meist auch die URL-Struktur der Website und dies kann die Suchmaschinen vor große Probleme stellen. Optimal wäre es aus Sicht der Suchmaschinen, wenn sich eine URL niemals ändert, denn sie dient für Suchmaschinen als eindeutiges Identifikationsmerkmal im WWW – mit ihr sind direkt Rankings sowie auch Verlinkungen verknüpft.

Ändert sich eine URL, ist es also erforderlich, die Suchmaschinen hier zu unterstützen. Grundsätzlich empfiehlt es sich, alle alten URLs mittels eines HTTP 301-Redirects auf das jeweilige, neue Pendant umzuleiten. Dies kann z.B. mittels „mod_rewrite“ (Apache Webserver) oder „ISAPI Rewrite“ (Microsoft IIS Webserver) realisiert werden. Ein Beispiel:

RewriteEngine on
RewriteRule ^/alte/produkte/([0-9]+)/?$ /produkte/$1 [R=301]

Der Apache Webserver würde in diesem Fall alle Anfragen der Form http://domain.de/alte/produkte/1234/ auf http://domain.de/produkte/1234/ umleiten.

Dieses Vorgehen empfiehlt sich für alle bekannten und aktiv auf der Seite verwendeten URL Muster. Wenn Sie nicht sicher sind, welche URLs Ihrer Website Google bereits bekannt sind, empfiehlt sich auf jeden Fall ein Blick in die Google Webmaster Tools (dort könnten Sie z.B. die extern verlinken URLs verwenden) oder in den Yahoo! Site Explorer.

Außerdem hilft auch Google selbst. Eine Suchanfrage der Form „site:domain.de“ verrät Ihnen, welche Seiten Ihrer Website Google kennt – werden dort mehr als 1.000 Ergebnisse angezeigt, sind weitere Einschränkungen bzw. Verfeinerungen z.B. mittels Kombination von zusätzlichen Suchparametern möglich: „site:domain.de inurl:pfad“, etc.

Trifft der Webcrawler nun nach dem Relaunch auf eine solche URL-Weiterleitung, wird die URL im Suchindex aktualisiert – gleiches gilt für die Meta Description sowie auch den Seitentitel. Bitte beachten Sie: Die Redirects jetzt dennoch keinesfalls abschalten! Warum fragen Sie? Externe Verlinkungen werden mittels der Redirects an die neue Seite weitervererbt – sie profitieren also nach wie vor von der externen Verlinkung. Auch Dinge, wie z.B. der Google PageRank werden mittels des Redirects weitervererbt.

404 Error Handling
Insbesondere bei einem Relaunch empfiehlt sich die Verwendung einer eigenen 404-Fehlerseite, denn oftmals passiert es auch, das URLs bei der Umstellung z.B. vergessen werden und die Rewrite-Regeln nicht auf alle gewünschten Muster passt. Aus diesem Grund ist es erforderlich, die Fehlerseite mit dem Tracking Code Ihrer Web-Analytics Software zu versehen, um bei häufigen Fehlern schnell reagieren zu können. Dazu empfiehlt sich die folgende Vorgehensweise:

• Erstellen einer neuen HTML Seite, welche einen entsprechenden Hinweis beinhaltet, dass die gewünschte Seite nicht gefunden wurde
• Die HTML Seite wird mit einem Robots Meta Tag versehen, um die Indizierung zu verhindern: <meta content=”noindex,follow” />
• Das Tracking wird auf der Fehlerseite angepasst, um auch Informationen wie Ursprungs-URL sowie Referer zu speichern

Verwenden Sie z.B. Google Analytics, so muss die Funktion pageTracker._trackPageview(); entsprechend modifiziert werden:

pageTracker._trackPageview("/error/404.html?page=" + document.location.pathname + document.location.search + "&from=" + document.referrer);

Mehr dazu bei Google in der Hilfe. Vergessen Sie am Ende nicht, per .htaccess oder direkt in der Apache-Konfiguration die Fehlerseite zu definieren:

ErrorDocument 404 http://domain.de/error/404.html

Aktualisieren der Sitemap

Eine weitere Hilfe, um die Neu-Indizierung zu beschleunigen, sind die so genannten XML-Sitemaps. Innerhalb dieser Sitemap(s) werden die einzelnen URLs einer Website in maschinenlesbarer Form aufgelistet. Es empfiehlt sich, einige Tage vor dem Relaunch die vorhandene XML-Sitemap offline zu nehmen (löschen Sie diese auch aus den Google Webmaster Tools) und übermitteln sie direkt nach dem eigentlichen Relaunch eine neue Sitemap an Google und die anderen Suchmaschinen. Die Crawler besuchen dann oftmals in relativ kurzer Zeit weitaus mehr neue URLs, wo hingegen der normale Crawling-Vorgang meist deutlich länger dauert, da die Suchmaschinen die neuen URLs ja erst einmal finden müssen.

Die Live-Schaltung

Abschließend noch einige Worte zur eigentlichen Live-Schaltung bzw. dem Parallelbetrieb einer Test Version („Pre-Release“): In den meisten Fällen, ist es gängige Praxis, dass die neue Seite bereits vor dem eigentlichen Start unter einer anderen (Sub-) Domain im WWW verfügbar ist. Grundsätzlich ist das völlig unproblematisch – allerdings sind Suchmaschinen sehr „neugierig“ und selbst wenn diese Pre-Release Domain nicht verlinkt ist, kommt es vor, dass die Inhalte ab und an ungewollt in den Suchmaschinen auftauchen und damit Duplicate Content Probleme verursachen.

Nutzen Sie also entweder einen Passwortschutz auf der Testdomain oder sperren Sie die Seite mittels einer eigenen robots.txt Datei („Disallow: /“) für die Indizierung durch die Webcrawler.

Website Relaunch richtig gemacht! ist ein Beitrag von Bastian Grimm.

Doppelte Inhalte („Duplicate Content“ oder kurz „DC“) stellen Webmaster immer wieder vor Probleme. Auch wenn die Auswirkungen oft andere sind – denn in vielen Fällen sind andere Ursachen dafür verantwortlich, dass die eigene Website nicht so erfolgreich ist, wie gewünscht – DC sollte tunlichst vermieden werden, um bestmögliche Suchmaschinenplatzierungen zu erzielen.

Was ist Duplicate Content?
Als DC bezeichnet man identische oder fast identische Inhalte bzw. Seiten, welche unter verschiedenen URLs zu erreichen sind. Suchmaschinen nutzen zur eindeutigen Identifikation einer Seite die URL, was zur Folge hat, dass es sich bei den folgenden Beispielen – aus der Sicht der Suchmaschinen – um verschiedene Seiten handelt:

• http://www.domain.de/ vs. http://domain.de/ (Die Domain mit und ohne www)
• http://www.domain.de/ vs. http://www.domain.de/index.html (Die Startseite mit und ohne Dateiname)
• http://domain.de/inhalt/ vs. http://domain.de/inhalt/?print=1 (Die Druckansicht einer Website)
• http://domain.de/inhalt.html vs. http://domain.de/inhalt.html?affili=123 (Affiliate Tracking ID / Parameter)
• http://domain.de/datei.php vs. http://domain.de/datei.php?PHPSESSID=987654321 (Dynamische Session IDs)

Neben den oben genannten Beispielen gibt es etliche mehr, seien es nun Sortierungen von bestimmten Listen, Kampagnen Tracking oder gar ganze Versionen einer Website, erreichbar unter verschiedenen Domains. All dass ist aus Sicht der Suchmaschinen DC und grundsätzlich zu vermeiden.

Warum ist Duplicate Content problematisch?
Das Hauptaugenmerk der Suchmaschinen liegt darauf, dem Suchenden immer nur eine Version einer Seite in den Suchergebnissen anzuzeigen und eine möglichste breite Variation von verschiedenen Ergebnissen zu präsentieren. Aus diesem Grund haben sich die Suchmaschinen – und insbesondere Google – in der Vergangenheit bereits verstärkt diesem Problem gewidmet und in vielerlei Fällen klappt eine automatische Erkennung (und Filterung) dieser doppelten Inhalte auch sehr gut. Die Suchmaschinen versuchen also mittels automatisierter Erkennung und unter Hinzuziehung von verschiedenen Faktoren (Welche Seite wurde zuerst veröffentlicht? Welche URL hat die meisten Backlinks? Welche URL steht in der XML-Sitemap? etc.) eine sog. Canonical URL zu bestimmen, welche fortan in den Suchergebnissen präsentiert wird.

Das klingt erst einmal gut – in der Praxis funktioniert es aber nicht immer, wie gewünscht. Nimmt man hier als Seitenbereiter nicht aktiv Einfluss, kann es z.B. passieren, dass Google womöglich eine URL mit Affiliate Tracking ID wichtiger einschätzt, als die eigentliche URL der Portals… und diese Seite dann auch in den Suchergebnissen anzeigt – sicher nicht das gewünschte Ergebnis!

Ein weiteres Problem ist die „Verschwendung“ von Crawler Ressourcen der Suchmaschinen, denn um die Seiten als DC zu erkennen, müssen diese erst einmal besucht und anschließend analysiert werden. Bei massivem DC kann dies dazu führen, dass die eigene Seite nicht mehr vollständig von den Suchmaschinen indiziert wird, da pro Domain immer nur eine gewisse Anzahl von Unterseiten abgerufen und dann indiziert wird.

Außerdem soll nicht unerwähnt bleiben, dass DC auch im Zusammenhang mit externer Verlinkung problematisch ist: Wenn eine Seite unter mehreren URLs erreichbar ist, können externe Links auch auf diese verschiedene URLs zeigen – und nicht auf eine einzige URL. Dies führt dazu, dass keine der URLs die maximale Stärke (und damit die bestmögliche Platzierung) erreicht, da die Linkpower hier nicht gebündelt wird.

Das Canonical-Tag
Um hier Abhilfe zu schaffen und es dem Seitenbetreiber gezielt zu ermöglichen, Einfluss auf die Bestimmung der Canonical URL zu nehmen, haben die Suchmaschinen Google, Yahoo! und MSN/Live Anfang Februar 2009 die Unterstützung des Canonical-Tags bekannt gegeben. Es handelt sich dabei um ein HTML-Tag, welches im Kopfbereich der Seite – also innerhalb des -Tags – definiert werden kann. Die Syntax ist denkbar einfach:

Mit dem „href“-Attribut wird angegeben, welche die „richtige“ Canonical-URL ist. Die Vorteile liegen klar auf der Hand: Einfache Verwendung, leicht zu implementieren und zusätzlich wird die „richtige“ URL verwendet – eigentlich perfekt. Eigentlich… denn der größte Nachteil ist, dass nach wie vor doppelte Inhalte existieren und das kann, wie oben beschrieben, dazu führen, dass die Website nicht vollständig indiziert wird, da die Crawler vorher alle Seiten abrufen müssen.

Welche Lösungen gibt es also?
Die definitiv beste Lösung ist sicher, eine solide Informationsarchitektur – kombiniert mit einer „sauberen“ URL Struktur – aufzubauen. Dies ist aber insbesondere bei fertigen Systemen wie Shops oder auch CMS eher selten der Fall sowie bei bereits bestehenden Websites oftmals nicht ohne großen Aufwand möglich. Hier empfiehlt es sich – von Fall zu Fall – verschiedene Lösungen zu implementieren:

1. 301-Redirects
Serverseitiges Umleiten aller doppelten URLs auf die „richtige“ URL – Suchmaschinen folgen diesen 301-Redirects und bestimmten die „richtige“ URL als Canonical.

2. Sperren von Parametern
Nutzen Sie entweder die robots.txt Datei, um einen Parameter vollständig für Suchmaschinen zu sperren (z.B. via: Disallow: /*parameter=) oder implementieren Sie eine Abfrage in Ihre Seite, welche auf die Existenz eines „ungewollten“ URL-Parameters prüft – wird dieser gefunden, nutzen Sie das Robots Meta Tag mit dem Wert „noindex“, um eine Indizierung zu verhindern. Ein großer Nachteil ist allerdings, dass möglicherweise Linkjuice verloren geht…

3. Hash-Tag als URL Trennzeichen verwenden
Suchmaschinen ignorieren das Hash-Tag in der URL: http://domain.de/datei.html#tracking=1 – hier würde „#tracking=1“ von den Suchmaschinen abgeschnitten werden. Ein JavaScript innerhalb der Website könnte diese Daten allerdings auslesen und weiterverarbeiten.

Fazit
Es ist nach wie vor unumgänglich, eine „saubere“ Website zu entwickeln und bereits von Beginn an darauf zu achten, dass doppelte Inhalte vollständig vermieden werden. Da der Einsatz des Canonical Tags nicht schaden kann, wäre es sicher nicht falsch, dass Tag direkt mit einzubauen – sozusagen als „Vorsorge“. Dabei sollte dann das „href“-Attribut des Tags einfach den Wert der richtigen Seite beinhalten – auch wenn dieses dann eigentlich immer mit der aufgerufenen URL übereinstimmt. Der Vorteil ist hier, wenn mal „versehentlich“ ein neuer Parameter eingeführt bzw. auf der Website verwendet wird oder gar jemand mit den URL Parametern „herumspielt“, kann hier kein Schaden durch DC entstehen.

Eine nützliche Firefox-Extension mit dem Namen Wahanda Canonical Tag Viewer spart bei der Implementierung und anschließenden Prüfung enorm viel Zeit. Die Software extrahiert die Canonical-URL aus dem Quelltext und zeigt diese direkt im Browser an – somit müssen Sie nicht für jede Seite den Quelltext öffnen und nach dem Tag suchen. Auch für die populäre Blogsoftware WordPress (hier) oder das Shop-System Magento (hier) gibt es bereits vorgefertigte Plugins, die die Verwendung des Tags ermöglichen und Ihnen eine Menge Arbeit abnehmen können.

Abhilfe gegen Doppelte Inhalte: Das Canonical-Tag ist ein Beitrag von Bastian Grimm.

Mitte 2008 verkündete Google einmal mehr, dass sie nun in der Lage seien, Flash Inhalte zu indizieren – obwohl eigentlich nicht neu, sorgte diese Ankündigung für einiges an Aufregung. Meiner Meinung nach völlig zu unrecht, denn nach wie vor ist Flash etwas komplett anderes, als sauber strukturiertes HTML und daher für effektive Suchmaschinenoptimierung kaum geeignet.

Schauen wir uns zu Beginn einmal die Top-3 Gründe an, warum ich glaube, dass es mit Flash Inhalten zum aktuellen Zeitpunkt nicht möglich ist, so erfolgreich zu ranken, wie mit einer sauber optimierten HTML-Seite:

1. Unterschiedliche Inhalte nutzen die gleiche URL

Oftmals bestehen Flash Seiten aus einem einzigen Flash-Film, der zum Beispiel bei Klick auf ein Navigationselement zu einer bestimmten Stelle im Film springt – man bewegt sich also innerhalb dieses einen Flash-Films vor und zurück, obwohl die Inhalte grundverschieden sein können. Dies bedeutet, dass einzelne Unterseiten keine eigene URL besitzen und somit nicht direkt von extern verlinkt werden können. Sicher ist es so, dass man dieses Problem mit einigem Mehraufwand in der Flash-Entwickelung lösen könnte, dennoch besteht ein weiteres Problem: Die Inhalte in diesem Flash-Film können grundverschieden sein – dies macht es den Suchmaschinen nahezu unmöglich, den Schwerpunkt der Seite zu erkennen und die Seite einem Themencluster zuzuordnen.

2. Flash wird eingebunden und nicht direkt verlinkt

Ein weiteres Problem ist die Art und Weise, wie Flash-Filme zugängig gemacht werden: Flash wird in mehr als 99% aller Fälle in eine HTML-Datei eingebunden. Diese Tatsache hat zur Folge, dass externe Links auch nicht direkt auf das Flash-File zeigen, sondern eigentlich immer auf die HTML-Datei, welche den Flash-Film beinhaltet. Damit würde sich maximal das Ranking für die HTML-Datei verbessern, nicht aber das, der Flash-Datei. Insbesondere Google ist hier aber so clever, diese HTML-Dateien auszusortieren bzw. nicht zu ranken, da meist kein weiterer Inhalt (in Textform) vorhanden ist.

3. Inhalte / Text ist nicht strukturiert

Der „normale“ Inhalt eines Flash-Films ist nicht mit einem sauber strukturierten HTML Quelltext zu vergleichen, denn Elemente wie Überschriften (<h1>Überschrift</h1>) oder auch Attribute für Bilder (alt=“Bildbeschreibung“) sind meist nicht vorhanden. Google extrahiert damit lediglich alle Wörter aus dem Flash-Film und erstellt daraus einen unstrukturierten Text.

Weitere Probleme sind außerdem:

• Die Technologie, mit der Goolge arbeitet, ist properitär. Dies bedeutet, es ist nicht klar, was Google eigentlich aus einem solchen Flash-Film verarbeiten kann und was nicht – hingegen gibt es für HTML Seiten vielerlei Tools (sog. „Spider-Viewer“, z.B. dieses oder das), die es ermöglichen, die Seite aus der Sicht eines Crawlers zu betrachten.
• Weiterhin gibt Google an, dass externe JavaScript Aufrufe oder externe Inhalte die von Flash-Filmen aus aufgerufen werden, nicht verarbeitet werden – dieses Konzept wird aber unglücklicherweise von einem großen Teil alle Flash-Filme derzeit verwendet.
• Andere Suchmaschinen unterstützen keine Indizierung von Flash – HTML wird von allen verarbeitet.

Was heißt das also in der Praxis?

Verwenden Sie kein Flash! OK – so dramatisch ist es nicht, denn selbstverständlich hat Flash seine Daseinsberechtigung, z.B. als „Eye-Catcher“ Element oder zur Darstellung anderer, interaktiver Inhalte. Befinden sich in dem Flash Film allerdings Inhalte, die Sie in den Suchmaschinen platzieren wollen, sollten Sie zusätzlich eine HTML Seite erschaffen und die Flash-Inhalte dort sauber strukturiert den Suchmaschinen zugängig machen. Im gleichen Zuge – zur Vermeidung von Doppelten Inhalten („Duplicate Content“) – verbieten Sie die Indizierung von Flash-Dateien für alle Suchmaschinen mittels Anweisung in der robots.txt, welche z.B. folgendermaßen aussehen kann:

User-Agent: *
Disallow: /*.swf$

Mit diesem Eintrag wären alle Flash-Dateien (*.swf) für alle Crawler gesperrt. Die Anweisung können Sie natürlich auch auf den Googlebot und den Flash-Film „mein-flash-film“ beschränken:

User-Agent: Googlebot
Disallow: /mein-flash-film.swf

Tipp: Nutzen Sie unbedingt die Google Webmaster Tools, um Ihre robots.txt Datei auf Fehler zu prüfen, bevor Sie die Datei auf den Server laden!

Ähnliche Probleme mit AJAX & JavaScript

Bei der Verwendung von JavaScript innerhalb einer Website kann es auch häufig zu Problemen mit Suchmaschinen kommen. Bedingt durch die Tatsache, dass JavaScript zu großen Teilen nicht verarbeitet wird, sind oftmals große Teile einer Website für die Crawler gar nicht zugängig. Die Folge: Inhalte sind über die Suchmaschinen nicht auffindbar! Achten Sie also unbedingt darauf, dass insbesondere Verlinkungen nicht mit JavaScript, sondern mit dem dafür vorgesehenen <a>-Tag realisiert werden.

Das Gleiche gilt im Prinzip für AJAX – Asynchronous Javascript And XML. Hier entstehen Probleme meist bei der Auslieferung von Seiteninhalten, denn AJAX nutzt verschiedene Methoden, Inhalt abzurufen und auszuliefern, ohne die Seite dabei neu zu laden. Dies resultiert normalerweise darin, dass Suchmaschinen den Inhalt nicht lesen können.

In beiden Fällen gilt: Schaffen Sie alternative Wege – im Falle von einfachem JavaScript bietet sich oftmals die Möglichkeit, mit dem <noscript>-Tag zu arbeiten. Achten Sie bei der Verwendung darauf, auch wirklich nur Dinge in diesem Tag abzubilden, welche auch in dem JavaScript selbst zu finden sind. Außerdem ist zu beachten, dass das <noscript>-Tag im HTML Quelltext direkt nach dem JavaScript platziert wird, z.B. folgendermaßen:

<script type="text/javascript">
// <![CDATA[
document.write("JavaScript Content...");
// ]]>
</script>

<noscript>Alternativer Crawler Content...</noscript>

Als AJAX- Alternative empfiehlt es sich meist, die komplette Seitenstruktur noch einmal, in Suchmaschinen freundlicher Form, zu erschaffen. Hierbei ist natürlich darauf zu achten, dass diese Seiten vollständig für die Crawler optimiert werden (Verlinkung, strukturierter Text, etc.) aber auch, dass diese „zweite“ Variante in jedem Fall auch für die Besucher der Seite zugängig ist – ansonsten läuft man schnell die Gefahr, gegen die Richtlinien der Suchmaschinen zu verstoßen (denn diese erlauben keine Produktion von Seiten, die ausschließlich für Suchmaschinen gemacht sind).

Warum SEO & Flash bzw. AJAX nicht zusammen passen! ist ein Beitrag von Bastian Grimm.

Das Prinzip “Content gegen Links” machen sich auch die so genannten Artikelverzeichnisse (kurz “AVZ“) zu nutze. Der Autor oder Webmaster verfasst einen Text und darf als Gegenleistung diesen mit einigen Backlinks zu seiner Domain versehen. Auf den ersten Blick ein fairer Deal, mag man denken – doch der Teufel steckt hier im Detail… Aber von vorne: Bevor ein Artikel in einem solchen Verzeichnis platziert werden kann, muss also erst einmal etwas geschrieben werden. Fast alle Artikelverzeichnisse verlangen sog. “Unique Content“, d.h. für jeden Verzeichnis-Eintrag muss ein neuer Artikel erstellt werden (oder zumindest ist ein starkes Umformulieren notwendig), damit dieser überhaupt akzeptiert wird – dies bedeutet also in jedem Falle Aufwand und / oder Kosten. Ein gängiger Artikel sollte außerdem mindestens 250 Wörter umfassen, bei einigen liegt die Minimalwortanzahl sogar noch höher. Mit einem Einzeiler klappt es in der Regel nicht, da diese Artikel in fast allen Verzeichnissen von Hand frei geschaltet werden. Dies ist insbesondere auf Grund des großen Spam-Aufkommens notwendig.

Als Gegenleistung für die Arbeit des Autors wird dann – meist je nach Wortanzahl – eine bestimmte Anzahl an Links innerhalb des Textes zugelassen – mal zwei, mal mehr. Die Anchortexte sowie auch die Linkziele bestimmen Sie dabei selbst. Belegt man das ganze nun mit Zahlen, könnte eine Rechnung folgendermaßen aussehen: Pro Text (mit 250 Wörtern) rechnen wir 6 EUR – bei durchschnittlich zwei Backlinks pro Text ergibt das einen effektiven Linkpreis von einmalig 3 EUR – nicht sonderlich viel, mag man denken

Oberflächlich betrachtet also sehr günstige Links – dennoch stößt man bei genauerer Betrachtung der Thematik gleich auf mehrere Probleme:

1. Keine Garantie auf Aufnahme
   Die Artikelverzeichnisse geben keine Garantie darauf, dass ein Artikel auch tatsächlich aufgenommen wird – im schlechtesten Fall wird der Artikel nicht frei geschaltet und vom AVZ-Betreiber anderweitig (selbst) verwendet.
2. Kein klarer Themenfokus
   Auf Grund der Tatsache, dass die Themen zu breit gestreut sind (jeder kann ja beliebige Texte zu beliebigen Themen veröffentlichen), gibt es keinen klaren Fokus – d.h. die Backlinks sind nur begrenzt relevant.
3. Zu viele ausgehende Links
   In Relation zu der großen Mengen ausgehender Links haben die meisten Artikelverzeichnisse im Verhältnis viel zu wenig Backlinks auf das eigene Angebot. Die kann ein klares Signal (z.B. für Google) sein, dass es sich hier um eine Linkfarm handelt – und diese sind ja bekanntlich auch zu vermeiden…
4. Schwarze Schafe („nofollow“-Links, Fake PageRank)
   Wie in jedem Bereich gibt es auch hier immer wieder Betreiber, die wenig seriös an das Thema herangehen. Häufige Fallen sind z.B. gefälschter PageRank, der vortäuschen soll, dass das AVZ stark ranked bzw. wertvolle Links zurück gibt oder gar „nofollow“-Backlinks, welche faktisch keinen Wert haben – damit profitieren die Betreiber von Ihrem Content, geben aber keinen Gegenwert zurück.
5. Abwertung von Artikelverzeichnissen durch Google
   Insbesondere in Deutschland ist Google stark dazu übergegangen, den AVZs die Power zu nehmen – sei es nun durch manuelle PageRank Herabstufungen (um die AVZs uninteressant zu machen) oder auch durch Diskreditierung der ausgehenden Links – sprich die Links bringen keinerlei Rankingverbesserung mit sich.

Auf Grund oben genannter Probleme, ist die breite Masse der Artikelverzeichnisse für einen effektiven Linkaufbau in Deutschland nicht geeignet. Allenfalls themenrelevante Artikelverzeichnisse können Sinn machen, doch auch hier empfiehlt sich vorab eine genaue Prüfung, damit Sie Ihren Content nicht umsonst dort platzieren. Insbesondere die folgenden Kriterien sollten für jede Eintragung beachtet und vorher geprüft werden:

• Wie sieht das Backlink Profil des AVZs aus? Gibt es qualitativ hochwertige Seiten, die auf das AVZ verlinken oder „lebt“ das AVZ selbst noch von Social Bookmarks Backlinks, die keinen bis sehr geringen Wert haben?
• Ist das AVZ bei Google ausreichend stark (auch Unterseiten, etc.) indiziert? Wie sieht ein Abbild des Google Cache’s aus?
• Gibt das AVZ saubere Links zurück? Non-„nofollow“ (auch den Header prüfen)?
• Können die Artikel von den Crawlern überhaupt erreicht und indiziert werden (interne Verlinkung & robots.txt prüfen)?
• Ist der angezeigte PageRank echt oder wird hier bereits getäuscht?

Sind oben genannte Kriterien geprüft und das themenrelevante AVZ für gut befunden worden, steht einer Nutzung nichts im Wege. Dennoch sollten Sie sich nicht allein auf solche Links verlassen!

Meiner Meinung nach ist die Nutzung von AVZs in Deutschland von vielen (Hobby-) SEOs einfach völlig übertrieben worden – insbesondere aus diesem Grund musste Google hier reagieren und (manuelle-) Herabstufungen vornehmen. Ich selbst nutze Artikelverzeichnisse in Deutschland (bis auf wenige, themenrelevante Ausnahmen für Nischenmärkte) gar nicht. In anderen Ländern, wie zum Beispiel Frankreich sieht der Markt völlig anders aus: Es gibt insgesamt vielleicht zehn französische AVZs (vgl. Deutschland: mehrere hundert), welche selbst hervorragend ranken und demnach auch qualitativ wertvolle Backlinks liefern – die Situation ist also auch pro Land zu betrachten.

Dieser Artikel stammt aus dem Januar 2009 und wurde in der Februar-Ausgabe der WEBeLINE veröffentlicht.

Artikelverzeichnisse sind tot! Oder doch nicht? ist ein Beitrag von Bastian Grimm.

I know it’s all in German – sorry for that

Interviewed by WEBeLINE ist ein Beitrag von Bastian Grimm.