Wer auf einer Website etwas sucht und es nicht findet, verursacht Datenverkehr ohne Gegenwert. Nimm eine Seite mit 1 MB Gewicht: Ein Besucher, der über fünf Zwischenstationen zum Ziel stolpert statt über zwei, überträgt 3 MB umsonst. Bei 10.000 solcher Besuche im Jahr sind das 30 GB, die nichts bewirkt haben außer Frust. Das ist die unsichtbare Hälfte der Nachhaltigkeitsdiskussion: Wir reden über die Größe einzelner Seiten und selten über die Anzahl der Seiten, die jemand aufrufen muss, um ans Ziel zu kommen. Guideline 2.4 adressiert genau diese zweite Größe.
Die drei Erfolgskriterien von Guideline 2.4
Effiziente Wege: Mache Aufgaben einfach und effizient erledigbar. Hilf den Nutzern zu verstehen, was zu Beginn einer Aufgabe von ihnen verlangt wird, reduziere unnötige Auswahlmöglichkeiten und zeige an, wie lange längere Abläufe voraussichtlich dauern.
Muster für Effizienz: Gestalte Nutzerwege klar und effizient. Nutze etablierte Design-Muster, die Menschen bereits kennen.
Inhalte auffindbar machen: Stelle eine menschenlesbare Sitemap bereit, insbesondere bei großen, komplexen oder gewachsenen Websites, deren Navigation nicht selbsterklärend ist. Halte sie regelmäßig aktuell. Biete klare und zugängliche Navigation sowie Suchfunktionen an, damit Nutzer die benötigten Inhalte oder Dienste schnell finden. Nutze leichtgewichtige und effiziente Wege, um Nutzern neue Inhalte und Angebote zugänglich zu machen, etwa Neuigkeitenseiten, Updates und Changelogs.
Meine Einordnung
Das dritte Kriterium ist neu und in seiner Klarheit bemerkenswert. Eine Suchfunktion und eine menschenlesbare Sitemap stehen hier nicht als Komfortmerkmale, sondern als Nachhaltigkeitsanforderungen. Das ist die richtige Einordnung, und sie widerspricht einem verbreiteten Reflex: „Unsere Seite hat nur 40 Unterseiten, da braucht niemand eine Suche.“
Doch, braucht er. Die Person, die auf Deiner Seite landet, kennt Deine Menüstruktur nicht. Sie kennt ihre eigene Frage. Und die passt in ein Suchfeld, aber selten in Deine Kategorienlogik. Ich habe bei datensm.art bewusst mehrere parallele Zugänge gebaut: Navigation, Verschlagwortung und eine Volltextsuche. Hugo macht das einfach, weil Taxonomien zum Kern des Systems gehören. Jeder zusätzliche Weg ist ein potenzieller Kurzschluss zwischen Frage und Antwort, und jeder Kurzschluss spart Seitenaufrufe.
Das zweite Kriterium wirkt banal und ist es nicht: etablierte Design-Muster nutzen. Ein Burger-Menü auf dem Desktop, eine Suche ohne erkennbares Suchfeld, eine Navigation, die erst beim Überfahren erscheint. Jede dieser Eigenwilligkeiten kostet den Besucher Sekunden und häufig einen zusätzlichen Seitenaufruf zum Ausprobieren. Vertrautheit ist deshalb eine Sparmaßnahme: Sie verlagert Verstehensarbeit in Muster, die jemand schon kennt, und genau diese Arbeit schlägt sich sonst in Klicks, Ladezeit und Energieverbrauch nieder.
Interessant finde ich auch, dass die Guideline „Changelogs“ und „Neuigkeitenseiten“ ausdrücklich als leichtgewichtige Entdeckungswege nennt. Das ist eine leise Absage an den Standardansatz, Aufmerksamkeit über Push-Benachrichtigungen und algorithmische Feeds zu erzeugen. Der leichteste Entdeckungsweg, den das Web kennt, ist übrigens weiterhin RSS: ein paar Kilobyte, kein Tracking, kein Account, und die Aktualisierung geht vom Nutzer aus.
Das erste Kriterium fordert, unnötige Auswahlmöglichkeiten zu reduzieren. Hier lohnt eine Unterscheidung, an der ich viele Projekte scheitern sehe.
Wo ich weiter gehe
Weniger Auswahl ist nicht pauschal besser. Entscheidend ist, worüber gewählt wird.
In einem Ablauf, den jemand erledigen will, also Formular, Bestellung, Anmeldung, ist jede zusätzliche Option ein Hindernis. Da gilt die Regel uneingeschränkt. Beim Auffinden von Inhalten gilt sie nicht. Dort sind mehrere Wege kein Ballast, sondern Redundanz im technischen Sinn: Fällt ein Zugang aus, weil jemand anders denkt als der Designer, greift der nächste. Wer Navigation auf einen einzigen Pfad reduziert, optimiert das Aussehen und verschlechtert die Trefferquote.
Der Unterschied lässt sich sogar messen: Suchanfragen ohne Ergebnis sind Deine wertvollste Kennzahl. Sie zeigen exakt, wo Menschen etwas erwarten, das sie nicht finden.
Allerdings darf die Lösung nicht teurer sein als das Problem.
Meine Empfehlung ist deshalb eine Suche, die im Browser läuft und nur die tatsächlich benötigten Teile eines vorab erzeugten Index nachlädt. Bei statisch generierten Seiten funktioniert das ausgezeichnet: Der Index entsteht einmal beim Build, der Server beantwortet keine einzige Suchanfrage, und es verlässt kein Suchbegriff die Seite. Bei datensm.art nutze ich genau diesen Ansatz. Eine Suche kostet dort einige Kilobyte statt eines Serverprozesses.
Das ist der Suffizienzgedanke in seiner nützlichsten Form: nicht auf die Funktion verzichten, sondern die Version wählen, die die wenigsten Ressourcen dauerhaft bindet.
Dein erster Schritt heute
Du brauchst keine Neustrukturierung. Du brauchst eine Liste der Fehlversuche.
Falls Du noch gar keine Suche hast, ist das Dein erster Schritt. Und ergänze eine schlichte HTML-Seite, die alle wichtigen Bereiche verlinkt. Das kostet Dich eine Stunde und ersetzt für Menschen wie für Maschinen eine Menge Ratearbeit.
Der sparsamste Seitenaufruf ist der, den niemand machen muss, weil der vorherige schon zum Ziel geführt hat.
Quelle: W3C-Fassung von Guideline 2.4