Eine Sitemap ist keine Strategie

Ein Kunde kommt zum ersten Termin und bringt eine Excel-Tabelle mit: fünfzig Zeilen, jede Zeile ein Seitentitel, sauber nach Ebenen eingerückt. Startseite, Über uns, Leistungen, Aktuelles, Kontakt, darunter die Verästelungen. Die Tabelle wird auf den Tisch gelegt wie eine Anzahlung. Die Struktur steht schon, jetzt fehlt nur noch die Website drumherum.

Die Geste ist verständlich. Eine Sitemap ist eines der ersten Dokumente, die sich in einem Webprojekt ohne fremde Hilfe herstellen lassen, und sie fühlt sich nach Arbeit an, weil sie Entscheidungen abbildet: Was kommt ins Hauptmenü, was in die zweite Ebene, was fliegt raus. Nur beantwortet dieses Dokument in seiner reinen Form vor allem eine Frage, nämlich wo etwas liegen soll. Warum es dort jemand suchen würde, was er dort verstehen soll und was er danach tun soll, steht in keiner dieser fünfzig Zeilen. Genau diese Fragen entscheiden aber darüber, ob eine Website funktioniert.

Der Begriff selbst trägt zur Verwirrung bei, weil er zwei völlig verschiedene Dinge bezeichnet. Die eine Sitemap ist eine technische Datei, die XML-Sitemap, ein Verzeichnis kanonischer URLs für Suchmaschinen. Die andere ist ein Planungsdokument, die hierarchische Seitenstruktur aus dem Kickoff. Beide leiden unter demselben Missverständnis: Man traut ihnen strategische Kraft zu, die sie nicht haben. Bei der XML-Datei glauben manche, ein priority-Wert von 1.0 mache eine Seite wichtig, obwohl Google diesen Wert schlicht ignoriert. Beim Planungsdokument glauben manche, eine durchdachte Einrückung mache eine Website durchdacht. In beiden Fällen wird eine Behauptung über Wichtigkeit mit Wichtigkeit selbst verwechselt.

Die Nielsen Norman Group hat den Unterschied auf eine präzise Formel gebracht: Die Informationsarchitektur einer Website ist eine Abstraktion, die Sitemap ist ein Artefakt (1). Die Architektur umfasst die Entscheidungen darüber, wie Inhalte organisiert, benannt und aufeinander bezogen werden. Die Sitemap ist eine Momentaufnahme dieser Entscheidungen, ein Foto. Als Planungswerkzeug kann sie durchaus mehr leisten, etwa inhaltliche Lücken sichtbar machen. Aber wer mit dem Foto beginnt, bevor die Architektur geklärt ist, hat nicht entschieden. Er hat eine Vermutung gezeichnet.

Jesse James Garrett hat in seinem Standardwerk zur User Experience ein Modell aus fünf Ebenen beschrieben, das seit über zwanzig Jahren erstaunlich gut gealtert ist (2). Ganz unten liegt die Strategie: Nutzerbedürfnisse und Ziele der Organisation. Darüber der Umfang: welche Inhalte und Funktionen es überhaupt geben soll. Erst auf der dritten Ebene folgt die Struktur. Dort wird aus den vorherigen Entscheidungen eine belastbare Sitemap. Darüber liegen noch Skelett und Oberfläche, Navigation und Gestaltung.

Das Modell macht sichtbar, was im Kickoff mit der Excel-Tabelle passiert: Das Projekt beginnt auf Ebene drei von fünf. Die beiden tragenden Ebenen darunter, die Frage nach den Menschen und die Frage nach den Inhalten, gelten als erledigt, obschon niemand sie gestellt hat. Die Sitemap wirkt wie ein Fundament und ist in Wahrheit ein Zwischengeschoss. Was eine Strategie stattdessen klären muss, beginnt bei der Frage, warum jemand auf die Website kommt und was er von dort mitnehmen soll. Und welche Aufgabe ein einzelner Inhalt dabei übernimmt, ob er orientieren, erklären, belegen, aktivieren oder binden soll, entscheidet sich ebenfalls, bevor die Struktur gezeichnet wird. Keine dieser Fragen lässt sich durch Einrücken beantworten.

Woher kommt die Struktur in der mitgebrachten Tabelle dann? Meist aus der Organisation selbst. Der Informatiker Melvin Conway formulierte schon 1968 die Beobachtung, dass Organisationen beim Entwurf von Systemen ihre eigenen Kommunikationsstrukturen nachbilden (3). Conway meinte damit Software, aber die Übertragung auf Websites drängt sich auf, und sie lässt sich auf fast jeder Verbands- und Unternehmenswebsite besichtigen: Die Hauptnavigation folgt den Abteilungen, die zweite Ebene den Referaten, und die Reihenfolge der Menüpunkte verrät, wer sich in der letzten Sitzung durchgesetzt hat.

Wie weit dieses Selbstporträt von den Bedürfnissen der Besucher entfernt sein kann, hat Gerry McGovern über Jahre in seinen Top-Tasks-Studien vermessen (4). Als der Liverpool City Council 2009 untersuchen ließ, was die Bürger auf seiner Website tatsächlich erledigen wollten, lagen sehr konkrete Alltagsaufgaben vorn: Arbeit finden, Freizeitangebote nutzen, Müll entsorgen, Bibliotheken und Schulen erreichen. Der Abgleich mit den tatsächlich publizierten Inhalten ergab eine nahezu perfekte Umkehrung: Je wichtiger eine Aufgabe den Bürgern war, desto weniger wurde dazu veröffentlicht, und je unwichtiger, desto mehr (5). Von rund 4.000 Seiten zogen etwa 200 ganze 85 Prozent des Traffics an, und am Ende konnte das Team über 80 Prozent des Bestands löschen. Die Erfahrung für die Bürger wurde dadurch besser, nicht schlechter. Viele dieser kleinen Aufgaben hängen eng am Ego der Organisation. Eine Sitemap, die im Konferenzraum entsteht, konserviert genau dieses Verhältnis. Sie ist dann kein Plan für die Besucher, sondern ein Protokoll der internen Machtverhältnisse.

Warum ist die Sitemap trotzdem so beliebt? Aus demselben Grund, aus dem der Relaunch als Großprojekt so beliebt ist: Beide simulieren Kontrolle. Über eine Sitemap lässt sich trefflich diskutieren, ohne dass jemand unbequeme Entscheidungen treffen müsste. Ob „Aktuelles„ oder „News“, ob drei oder vier Hauptmenüpunkte, ob der Mitgliederbereich links oder rechts steht: Das sind Fragen, zu denen jeder im Raum eine Meinung hat, ohne seine eigentlichen Interessen offenlegen zu müssen. Die strategischen Fragen sind unbequemer. Welche Zielgruppe hat Vorrang, wenn zwei kollidieren? Welche Inhalte werden gestrichen, obschon eine Abteilung an ihnen hängt? Wer trägt die Verantwortung dafür, dass die Struktur in zwei Jahren noch stimmt?

Die Sitemap-Diskussion ersetzt diese Verhandlung durch eine Sortierübung. Das fühlt sich produktiv an, ohne eine strategische Entscheidung zu erzwingen, und genau darin liegt die Verführung. Eine Sitemap ohne vorausgegangene Strategie ist die freundlichste Form, ein Projekt zu beginnen, ohne es zu denken.

Nichts davon spricht gegen Sitemaps. Es spricht gegen ihren Status. Eine Sitemap ist ein hervorragendes Werkzeug, wenn sie als Ergebnis der ersten strategischen Entscheidungen entsteht und nicht als deren Voraussetzung auf dem Tisch liegt: nach dem Audit, das zeigt, welche Inhalte tatsächlich Wert erzeugen, nach der Klärung der Zielgruppen und ihrer Aufgaben, nach der Entscheidung, welche Funktion jeder Inhaltsbereich erfüllen soll. Sie darf dabei früh auftauchen, als Skizze, als Hypothese. Sie darf nur nicht früh als fertige Vorgabe behandelt werden.

Denn eine Hypothese lässt sich prüfen. Card Sorting macht sichtbar, welche Zusammenhänge Nutzer selbst herstellen (6); Tree Testing zeigt, ob die daraus entwickelte Hierarchie sie tatsächlich ans Ziel führt (7). Beides sind Methoden, die eine Struktur an der Realität messen und nicht am Sitzungsprotokoll. Aus der geprüften und überarbeiteten Hypothese wird ein wertvolles Arbeitsdokument, weil es getroffene Entscheidungen sichtbar, prüfbar und verteidigbar macht.