Gastartikel: Inhalt statt Technik – Was gute URLs von schlechten unterscheidet

Die URL-Struktur einer Seite zu bestimmen, gehört zu den zentralen Bestandteilen der OnPage-Optimierung. Fehler in diesem Bereich können sich negativ auf die Crawlability auswirken oder führen zu Duplicate Content. Einen guten Überblick über typische Probleme und mögliche Lösungen bietet der ausführliche Artikel über perfekte SEO-URLs, den Pascal Landau vor einiger Zeit bei SEO Scene veröffentlichte. Ich will das Thema in diesem Beitrag aus einer etwas anderen Perspektive beleuchten. Mir geht es dabei vor allem darum, statt der bekannten Details eher allgemeine Überlegungen vorzustellen, die dabei helfen, auch in komplexen Systemen eine gute URL-Struktur zu finden und bestehende URL-Strukturen zu hinterfragen. Statt „inhaltlicher“ Überlegungen zur URL (Länge, Keywords, Lesbarkeit) geht es deshalb vor allem um die Logik, nach der URLs aufgebaut werden.

Warum es so viele schlechte URLs gibt

Perfekte SEO-URLs begegnen uns nur selten in Systemen, die nicht aktiv optimiert wurden. Die URLs vieler Seiten sind erst einmal unübersichtlich und bergen Probleme durch dynamische Parameter. Warum das so ist, wird klar, wenn wir uns den Grundkonflikt zwischen der Dokumentensuchmaschine Google und dynamischen Webanwendungen klar machen:

• Dokumentensuchmaschinen verwalten statische Dokumente, die eindeutig identifizierbar sind und einen bestimmten, relativ stabilen Inhalt haben. Am besten kommen sie daher mit statischen Seiten klar. URLs sollten aus ihrer Perspektive jeweils einzelne solcher statischen Seiten bezeichnen.
• Webandwendungen wie Blogs, Foren oder Shopsysteme stellen dagegen aus technischer Sicht vor allem eine Schnittstelle zu einer Datenbank dar. Die eigentlichen Inhalte werden erst beim Aufruf dynamisch aus der Datenbank und in ein Template geladen. Die URLs dieser Webanwendungen bezeichnen daher ausführbare Skripte und übergeben Argumente, die dem Skript mitteilen, welche Datensätze es anzeigen soll.

Wie Webanwendungen URLs nutzen, wird gut an einem typischen Beispiel deutlich:

http://www.dfb.de/index.php?id=30

In dieser URL wird auf dem Server des DFB das Skript mit dem Namen „index.php“ angesprochen. Als Argument wird ihm hinter dem Fragezeichen im sogenannten „Query-String“ der Parameter „id“ mit dem Wert 30 übergeben. Wir können uns vorstellen, dass die URL für jede Seite auf dem Server auf ähnliche Weise aufgebaut ist und wir nur den Wert der id ändern müssen, um andere eindeutige Inhalte zu erhalten. Die Logik scheint also einfach.

Stoßen wir dagegen später auf diese URL, wird die Sache komplizierter:

http://www.dfb.de/index.php?id=500014&tx_dfbnews_pi1[showUid]=30079&tx_dfbnews_pi4[cat]=56

Bei einer solchen URL wird wohl jeder SEO aufmerksam. Hier sprechen wir zwar immer noch dasselbe Skript an und übergeben ihm auch wieder eine id, zusätzlich finden wir im Query-String noch zwei weitere Parameter („tx_dfbnews_pi1[showUid]“ und „tx_dfbnews_pi4[cat]“), die sich ebenfalls entscheidend auf den Inhalt auswirken.
Die einfache Logik, dass jeder id ein eindeutiger Inhalt zugeordnet werden kann, geht also für die id 500014 nicht auf. Um aus einer gegebenen URL die kanonische URL abzuleiten, müssen für alle Seiten mit der id 500014 noch weitere Parameter beachtet werden, und wir haben keine Garantie dafür, dass dies die einzige Ausnahme ist. Das verkompliziert natürlich die Kommunikation im Team. Missverständnissen zwischen SEOs und Entwicklern, die zu falschen Canonical-Links oder Duplicate Content führen, werden so Tür und Tor geöffnet.
Auch wenn wir als SEOs solchen URLs nichts abgewinnen können, sollten wir uns klar machen, dass sie aus technischer Sicht durchaus Sinn ergeben. Sie spiegeln genau wider, wie das System aufgebaut ist. Um die eigentlichen Inhalte kümmern sie sich aber genauso wenig wie das Skript, das die Inhalte verarbeitet, oder die Datenbank, die sie speichert.

Die Logik guter URLs

Bei den oben gezeigten URLs bestimmt die technische Implementierung das Aussehen, nicht die logische Verknüpfung der Inhalte. Ein System zu nutzen, das solche URLs produziert, ist, als würden wir ein Auto mit aufgeklappter Motorhaube fahren: Hier liegt die Technik ohne Verkleidung offen. Das funktioniert, der Motor läuft, aber das Fahrzeug ist alles andere als aerodynamisch. Richtig Fahrt werden wir so nie aufnehmen.
Was wir brauchen, ist eine stromlinienförmige Motorhaube, unter der wir die technische Implementierung verbergen. Statt der Technik sollen Inhalte, die für Nutzer (und Suchmaschinen) geschaffen wurden, die URLs bestimmen.
Wenn wir uns überlegen, was Einfluss auf den Inhalt der angezeigten Seite haben kann, kommen wir auf drei Aspekte, die in der URL beziehungsweise im HTTP-Request an die Seiten abgebildet werden müssen:

• Ressourcen: Was wird auf der Seite dargestellt? Was ist der Inhalt?
• Modifikatoren: Wie wird der Inhalt dargestellt?
• Nutzerperspektive: Wer sieht den Inhalt an? Wo steht derjenige gerade?

Die wichtigsten Bestandteile aus SEO-Sicht sind die Ressourcen. Hierbei handelt es sich um alle Inhalte, von denen wir wollen, dass Google sie als einzelne Dokumente indiziert. Das können beispielsweise Produktgruppen, Blogartikel oder Forendiskussionen sein. Wir sollten sie am besten im Pfad der URL abbilden. Der Pfad ist der Abschnitt in der URL hinter www.domainname.de bis zum Ende der URL oder bis zum Fragezeichen. Dort können wir die Ressourcen hierarchisch anordnen und sie sinnvoll benennen. Die Kategorie „Hemden für Herren“ als Unterkategorie von „Hemden“ bekäme dann beispielsweise diese URL:

http://www.example.de/hemden/herren/

Aus SEO-Sicht eher problematisch sind dagegen die Modifikatoren. Sie bestimmen, wie die Ressource dargestellt wird. Sollen die Produkte in der Liste sortiert oder gefiltert werden? Handelt es sich um die Ansicht für den Desktop, für ein mobiles Gerät oder für den Ausdruck? Sollen die Daten zur Weiterverarbeitung in einem maschinenlesbaren Format wie XML oder JSON ausgegeben werden? All das sind Fragen, die zwar das Aussehen der Zielseite massiv beeinflussen, die aber auf den eigentlichen Inhalt keinen Einfluss haben. Jeder dieser Modifikatoren stellt dadurch eine potentielle Quelle für Duplicate Content dar, weil eine URL, in der er auftaucht, im Grunde denselben Inhalt produziert wie jede andere URL, die dieselbe Ressource bezeichnet.
Eigentlich wäre es am besten, wenn wir die Modifikatoren komplett aus der URL heraushielten, indem wir die unterschiedlichen Ansichten erst dynamisch per JavaScript erzeugen oder die Filter per POST-Request an den Server senden (warum wir das tun sollten und wie das geht, erklärt Tobias Schwarz in diesem Artikel: Häufig auftretende Strukturfehler erkennen und beheben). Allerdings verlangen die Anforderungen an Shop-Systeme in der Regel, dass die unterschiedlichen Ansichten auch jeweils eine eigene URL besitzen, über die wir sie per GET-Request (dem übliche Weg, auf dem Browser eine Seite vom Server zu erhalten) abfragen können. Nur so lassen sie sich nämlich als Bookmark speichern und auf anderen Seiten teilen.
Es bietet sich an, die Modifikatoren als Query-String-Parameter an die URL anzuhängen. Der Query-String ist der Abschnitt in der URL hinter dem Fragezeichen. Hier können wir verschiedene Parameter, denen wir per Gleichheitszeichen einen Wert zuweisen, an den Server übermitteln. Auf diese Weise unterscheiden wir schon im Aufbau der URL klar zwischen Ressourcen und Modifikatoren und können in den Webmaster Tools für jeden einzelnen Modifikator genau bestimmen, wie Google ihn behandeln soll. Die URL einer sortierten Liste von Herrenhemden sieht dann beispielsweise so aus:

http://www.example.de/herren/hemden/?sort_by=price&order=desc

Aus einer solchen URL können wir auch leicht die kanonische URL für diese Seite ableiten: Die kanonische URL ist nämlich einfach die ursprüngliche URL ohne die Parameter.
Als drittes beeinflusst noch die Nutzerperspektive des aktuellen Besuchers die Seite. Dabei handelt es sich beispielsweise um Fälle, wo die Seite einem angemeldeten Besucher anders angezeigt wird als einem Gast, wo die Breadcrumb-Navigation den genauen Klickpfad darstellt oder personalisierte Empfehlungen eingeblendet werden. All diese Aspekte mögen für unsere Nutzer interessant sein, die Suchmaschinen verwirren sie nur. Sie haben in der URL nichts zu suchen, vor allem da es auch keinen Grund gibt, eine bestimmte Perspektive als Bookmark zu speichern oder per Link zu verbreiten. Diese Ansicht gilt nur für den einzelnen Besucher und sollte alleine in seiner Session gespeichert werden, die per Cookie identifiziert wird.

Ressourcen, Modifikatoren und Nutzerperspektive in der Praxis

Wenn wir alle Elemente, die Einfluss auf eine Seite haben nach Ressourcen, Modifikatoren und Perspektiven unterscheiden, können wir bei zukünftigen Erweiterungen unseres Systems schnell entscheiden, wie sie in der URL dargestellt werden:

• Produkte sollen auch nach Verfügbarkeit sortiert werden können? Es handelt sich um einen Modifikator, da nur die Darstellung der Liste geändert wird. Die Sortierung wird also per Parameter adressiert.
• Die Produktdetailseite soll eine Vorschau auf das nächste Produkt aus der Liste anzeigen, über die der Nutzer auf die Detailseite kam? Es handelt sich um eine spezielle Nutzerperspektive, weil die Änderung im Inhalt nur für den aktuellen Nutzer gilt. Der Hinweis auf die Produktliste wird also in der Session gespeichert.
• Nach Marken gefilterte Produktlisten sollen eigene Seiten bilden und von Google indiziert werden? Jede Marke erzeugt eine neue Ressource, die Google indizieren soll. Der Markenfilter wird also zu einem Teil des Pfades.

Selbstverständlich gibt es auch problematische Fälle, in denen einzelne Aspekte nicht ganz so klar als Ressource, Modifikator oder Perspektive eingeordnet werden können. Hier gilt es, die bestmögliche Lösung in der jeweiligen Situation zu finden. Zwei Beispiele sind die Paginierung und Sprachparameter:

• Paginierung: Stellt die einzelne Folgeseite einer Produktliste eine eigene Ressource oder nur eine Modifikation dar? Ich würde sie als Modifikation bezeichnen, weil die eigentliche Ressource – die gesamte Produktliste – zur besseren Darstellung auf mehreren Seiten verteilt wurde. Daher würde ich in der Regel die Angabe zur Paginierung ab der zweiten Seite als Parameter übertragen. Wenn kein Parameter angegeben ist, wird per default die erste Seite angezeigt. Auf Folgeseiten sollten wir zudem auf die Angabe der Canonical-URL verzichten und nur das Robots-Meta-Tag auf „noindex, follow“ setzen.
• Sprache: Viele CMS (bspw. TYPO3) bieten die Möglichkeit, auf einer Seite alternative Inhaltelemente anzulegen, die je nach gewählter Sprache angezeigt werden. Auf diese Weise wird die Sprache zum Modifikator, da sie alternative Ansichten für dieselbe Ressource erzeugt. Das ist logisch, wenn man annimmt, dass es um den Gedanken geht, der nur auf verschiedene Weisen verbal dargestellt wird (als wäre die Wahl zwischen Französisch und Deutsch keine andere als die zwischen JSON und XML). Suchmaschinen kümmern sich aber nicht um gedankliche Inhalte, sondern um Worte. Deshalb sollten wir die Sprache unbedingt als Teil der Ressource behandeln, d.h. im Pfad oder sogar im Hostnamen abbilden.

Fazit

Die Beispiele zeigen, wir hilfreich es ist, unabhängig von konkreten Features eine klare Logik anzugeben, nach der sich die URL-Struktur richtet. Das wird möglich, indem wir erst einmal von den Details einzelner URLs absehen und uns stattdessen Gedanken über so grundlegende Unterscheidungen wie die zwischen Ressourcen und Modifikatoren machen. Gerade in größeren Projektteams erleichtern diese Begrifflichkeiten zudem allen Beteiligten, besser darüber zu kommunizieren, wie URLs strukturiert sein müssen.

Über den Autor

Nikolas Schmidt-Voigt arbeitet als Consultant SEO für die dmc digital media GmbH (http://www.dmc.de). Hier betreut er vor allem Kunden aus dem Bereich e-Commerce. Zusammen mit seinen Kollegen schreibt er über Themen rund um Online-Marketing, e-Commerce und digitalen Handel unter http://www.kawumba.de.