Das klassische Strukturmodell einer Website ist der hierarchisch verzweigte Baum mit der Homepage als Wurzel. Jedes Content-Objekt nimmt einen bestimmten Platz in dieser Hierarchie ein. Zusätzliche Querverweise erleichtern die Navigation zwischen verwandten Elementen in unterschiedlichen Ästen. Dieses Modell ist vielfach bewährt, aber nicht besonders flexibel. Wikis verzichten meist völlig auf eine vom System vorgegebene hierarchische Ordnung. Das klingt nach einem Rezept für Chaos, und genau das ist es.

Der Mangel an Struktur scheint das größte Problem beim praktischen Einsatz eines Wikis zu sein.^[20] Je größer die Zahl der Seiten, desto schwerer wird es, den Überblick zu behalten und bestimmte Informationen zu finden. Inhalt wird doppelt eingegeben, die Links zwischen den Seiten sind planlos und zufällig, Links zeigen auf Seiten, die inzwischen ganz andere Informationen enthalten.

Natürlich erlauben es die Wiki-Bordmittel, eine hierarchische Struktur durch menüartige Überblicksseiten nachzubilden, und dies ist auch die empfohlene Vorgehensweise.^[21] Doch das Anlegen neuer und das Verändern bestehender Seiten führen zu beständiger Erosion der einmal angelegten Sitestruktur. Diesem Prozess muss durch sogenannte „Refactorings“ entgegengewirkt werden. Darunter versteht man die Neustrukturierung bestehenden Inhalts, im Gegensatz zur Schaffung neuen Inhalts.^[22] Dies umfasst Tätigkeiten wie das Erstellen und Aktualisieren von menüartigen Überblicksseiten, das Umbenennen von Seiten, die Schaffung neuer Links, die Zusammenfassung doppelter Informationen, die Aufspaltung zu großer und Löschung überflüssiger Seiten. Dies ist ein nötiger Mehraufwand, um die vorhandene Informationsmenge in nützlicher und strukturierter Form zu halten.

Während in traditionellen Web-Publishing-Verfahren bereits in der Design-Phase eine Struktur festgelegt wird, in die sich der Content einpassen muss, entsteht in einem Wiki diese Struktur erst durch den Content und kann sich demnach leichter an veränderte Bedürfnisse anpassen. Das hat Vorteile, wenn Art des Contents und Verwendung der Website vorher nicht genau absehbar sind. Oft entstehen aus dem Einsatz eines Wikis neue Verwendungsmöglichkeiten, die von den Initiatoren nicht vorgesehen waren.^[23]

Es ist interessant, wie die Einfachheit der Erzeugung von Hyperlinks deren Gebrauch in Wiki verändert. Eine Reihe von Aufgaben, die in anderen Umgebungen die aufwändige Einführung von Metainformationen erfordert hätten, werden in Wiki durch Hyperlinks erledigt. Einfaches Beispiel ist die gängige Praxis des Signierens von Beiträgen mit dem eigenen Namen als WikiWord, beispielsweise WardCunningham. Ein Klick auf den Name führt zu einer Seite, auf welcher der Autor weitere Informationen über sich hinterlegt. Eine andere interessante Verwendung sind die sogenannten „WikiBadeges“ oder „WikiTags“,^[24] wie DeleteMe, AnswerMe, PleaseComment, BrokenLink. Sie zeigen beispielsweise den Bedarf von Refactoring an, und dienen als administratives Werkzeug, da man über die Backlink-Funktion leicht an eine Liste aller Stellen gelangt, die mit einem WikiTag gekenzeichnet sind.

Damit stellen die Links in einem Wiki nicht nur einen Ersatz für Metainformationen, sondern gleichzeitig ein generisches Werkzeug zur Meisterung verschiedener administrativer Probleme dar. Ein einziger einfacher Mechanismus erfüllt Funktionen, die in einer anderen Umgebung jeweils einzeln implementiert worden wären, mit eigenen Regeln und eigener Lernkurve für den Anwender. Dazu braucht es einige Konventionen über die Verwendung dieses Hilfsmittels. Diese Vereinbarungen können sich durchaus im Laufe der Zeit entwickeln und verändern. Damit wird Verantwortung aus den Händen des Programms bzw. dessen Entwicklers zurück in die Hände der Anwender und Autoren gelegt.

Ein Blick auf die große Welt des WWW zeigt zwei Beispiele, die darauf hindeuten, dass solche Strukturinformationen im Content nützlicher und aussagekräftiger als Metainformationen sein können. Das erste Beispiel ist die WWW-Suchmaschine Google. Während sich ältere Suchmaschinen auf explizite Metainformationen der untersuchten Seiten stützten, führte Google sehr erfolgreich^[25] ein Verfahren ein, dass die Links zwischen den Seiten analysiert^[26] und damit deutlich bessere Ergebnisse erzielt.

Das zweite Beispiel ist die Entwicklung der Hypertext Markup Language HTML. Seit den frühesten Entwürfen von HTML^[27] war neben dem allseits bekannten Hyperlink (dem A-Element von HTML) ein weiterer Mechanismus zur Herstellung von Beziehungen zwischen Dokumenten vorgesehen: das LINK-Element. Dieses ist optionaler Bestandteil des HEAD-Abschnitts (Abschnitt für Metainformationen) eines HTML-Dokuments und ermöglicht eine genaue Klassifizierung der Art der Beziehung. Autoren können damit ausdrücken, dass ein Dokument beispielsweise Nachfolger in einer Reihe von Dokumenten, übergeordnet in einer Hierarchie, Inhaltsverzeichnis, Index oder Übersetzung eines anderen Dokuments ist.^[28] Webbrowser können diese Beziehungen beispielsweise als eine Toolbar mit Buttons, die zu den entsprechenden Seiten führen, darstellen.^[29] Trotz der umfangreichen Möglichkeiten des LINK-Elements hat es sich bisher nicht durchsetzen können und ist von Webbrowser-Entwicklern weitgehend ignoriert worden.

Eine breitere Unterstützung des LINK-Elements würde die Navigation im WWW zweifellos vereinfachen.^[30] Dennoch zeigt das Beispiel, dass im Kontext des WWW der im Content integrierte „klassische“ Hyperlink dem typisierten, strukturfördernden Metainformations-Link klar überlegen ist. Ohne den ersten wäre das WWW nicht vorstellbar. Ohne den zweiten kommen wir sehr gut zurecht, auch wenn er bei der Navigation durch stark strukturierten Content eine Hilfe sein könnte.

Um den Abschnitt zusammenzufassen: Betrachtet wurden zwei verschiedene Möglichkeiten, dem Content einen Mehrwert zu verleien. Die eine Möglichkeit ist es, den Content mit Metainformationen zu beschreiben. Die andere ist es, den Content durch verschiedene Links eng mit relevanten anderen Objekten zu verknüpfen, also Kontext herzustellen. Die zweite Methode wird im Bereich des Dokumenten- und Content-Management eher weniger eingesetzt. Beide Möglichkeiten überschneiden sich teilweise, ergänzen sich, und haben ihre Vorteile:

Traditionelle CMS verlassen sich mehr auf Metainformationen, Wikis verlassen sich mehr auf die Herstellung von Kontext durch Links. Wikis können dadurch mit wesentlich einfacheren Mitteln gute Resultate erzielen und sind deutlich flexibler, leiden aber an einem Mangel an klarer Struktur.