Informationsarchitektur: Sites, Bibliotheken, Listen

Bevor irgendjemand über Inhaltstypen, Suche oder Migration redet, muss eine Frage geklärt sein: Wie ist der Laden überhaupt geschnitten? Informationsarchitektur ist das Fundament unter allem, was dieser Kompetenzbereich behandelt — und gleichzeitig das Thema, bei dem die meisten SharePoint-Umgebungen ihre Erbsünde begehen: gewachsene Subsite-Bäume, Container-Wildwuchs, Excel-Dateien als Datenbankersatz. Dieser Grundsatzartikel sortiert die Bausteine, erklärt, warum flach das neue tief ist, und liefert den Entscheidungsweg für die ewige Frage: neue Website, neue Bibliothek — oder reicht eine Ansicht?

Die Bausteine: was wofür da ist

SharePoint hat erstaunlich wenige Grundbausteine — das Chaos entsteht nicht durch ihre Anzahl, sondern durch ihre Verwechslung. Die Website ist der Container mit Rechte- und Lebenszyklusgrenze, die Bibliothek beherbergt Dokumente mit Versionierung und Metadaten, die Liste hält strukturierte Daten ohne Datei, und Inhaltstypen mit ihren Spalten definieren, was in beiden liegt. Der Hub klammert oben alles zusammen — aber nur optisch und navigatorisch, nicht rechtlich:

Skizze 1: Der Baukasten vom Mandanten bis zu Inhaltstypen und Spalten — der Hub verbindet Navigation und Suche, die Rechte-Grenze bleibt die Website.

Für den Alltag die Kurzfassung als Spickzettel:

Flach statt tief: das Ende der Subsite-Ära

Wer SharePoint aus der Server-Zeit kennt, hat gelernt: Struktur baut man mit Unterwebsites. Ein Portal, darunter Abteilungen, darunter Teams, darunter Projekte — ein schöner Baum, und ein einziges Kopplungsdesaster. Subsites teilen sich Navigation, Vorlagen und oft genug Berechtigungsvererbung mit ihrem Elternteil; sie lassen sich weder einzeln archivieren noch sauber umziehen, und jede Umorganisation des Unternehmens wird zur URL-Operation am offenen Herzen.

Die moderne Antwort ist radikal flach: Jedes Thema, jedes Team, jedes Projekt bekommt eine eigene, eigenständige Website — und Hubs liefern die Klammer für Navigation, Design und übergreifende Suche. Der entscheidende Gewinn ist die Entkopplung: Eine Website lässt sich per Klick von einem Hub an den nächsten hängen, einzeln archivieren oder löschen, ohne dass irgendetwas anderes bricht. Die Organisation ändert sich? Websites umhängen, fertig — keine Migration, keine toten Links.

Die Grenzen richtig ziehen: Website, Bibliothek oder Ansicht?

Die häufigste Alltagsfrage der Informationsarchitektur klingt harmlos: „Wir brauchen was Neues für unsere Dokumente.“ Die teuerste Antwort darauf ist der Reflex, sofort einen neuen Container zu bauen. Denn jeder Container — ob Website oder Bibliothek — will berechtigt, benannt, gepflegt und irgendwann archiviert werden. Deshalb gilt das Sparsamkeitsprinzip: erst prüfen, ob eine Ansicht reicht, dann über eine Bibliothek nachdenken, und erst bei echtem Rechte- oder Lebenszyklusbedarf eine Website anlegen:

Skizze 2: Der Entscheidungsweg — Rechte ziehen die härteste Grenze, Lebenszyklus die zweithärteste, alles andere ist nur eine Sicht.

Und die vierte Antwort im Entscheidungsweg verdient einen eigenen Absatz, weil sie chronisch übersehen wird: die Liste. Überall dort, wo strukturierte Daten ohne Datei gebraucht werden — Vertragsregister, Inventarlisten, Anträge, Maßnahmen-Tracker — ist die SharePoint-Liste das richtige Werkzeug: mit Ansichten, Versionierung, Berechtigungen und Power-Automate-Anschluss. Was stattdessen in freier Wildbahn lebt, ist die geteilte Excel-Datei in der Bibliothek. Die kann vieles, aber nichts davon gleichzeitig mit fünf Leuten, versioniert und filterbar.

Das Fundament für alles Weitere

Informationsarchitektur ist kein Selbstzweck — sie ist die Voraussetzung dafür, dass alle anderen Themen dieses Kompetenzbereichs überhaupt funktionieren. Inhaltstypen brauchen Bibliotheken mit klarem Sachgebietsschnitt, die Taxonomie aus dem Terminologiespeicher liefert die Spaltenwerte, die Suche lebt von beidem, und die Ordner-Metadaten-Frage entscheidet sich innerhalb jeder einzelnen Bibliothek. Auch die Betriebsthemen hängen daran: Eine Migration ist nur so gut wie die Zielarchitektur, Berechtigungen bleiben nur beherrschbar, wenn die Website die Rechte-Grenze ist, und Governance heißt am Ende nichts anderes, als diese Architekturregeln dauerhaft durchzusetzen. Wer hier sauber schneidet, hat in jedem Folgethema die halbe Arbeit schon erledigt.

FAQ zur Informationsarchitektur

Was ist der Unterschied zwischen einer Teamwebsite und einer Kommunikationswebsite?

Die Teamwebsite ist für Zusammenarbeit gebaut: ein Personenkreis, gemeinsame Ablage, Microsoft-365-Gruppe — sie steckt auch hinter jedem Microsoft Team. Die Kommunikationswebsite ist für Publishing gedacht: wenige Autoren, viele Leser, ansprechende Seiten. Faustregel: Arbeiten Menschen miteinander, Teamwebsite; informieren wenige viele, Kommunikationswebsite.

Sollte ich noch Unterwebsites (Subsites) verwenden?

Nein, für neue Strukturen nicht mehr. Microsoft führt Subsites als Altlast-Muster und empfiehlt eigenständige Websites, verbunden über Hubs. Bestehende Subsites musst du nicht panisch auflösen — aber jede neue Struktur, die du heute als Subsite baust, ist die Migrationsbaustelle von übermorgen.

Wie viele Websites sind normal — ist viel schlimm?

Viele Websites sind kein Problem, viele ungeplante schon. Die flache Architektur lebt geradezu davon, dass jedes Thema seine eigene Website bekommt — entscheidend ist, dass Anlage und Stilllegung einem Prozess folgen: Namenskonventionen, Besitzer, Lebenszyklus. Genau das ist Governance-Arbeit, und die hat ihren eigenen Artikel im Cluster.

Wann nehme ich eine Liste statt einer Bibliothek?

Immer dann, wenn die Information selbst der Inhalt ist und keine Datei: Vertragsregister, Geräteinventar, Urlaubsanträge, Maßnahmenlisten. Die Bibliothek ist für Dokumente da, die Liste für strukturierte Datensätze — und praktisch jede „geteilte Excel-Tabelle“ in einer Bibliothek ist in Wahrheit eine Liste, die noch nicht befreit wurde.

Verbindet ein Hub auch die Berechtigungen der zugeordneten Websites?

Nein — und das ist die wichtigste Eigenschaft, die man über Hubs wissen muss. Die Zuordnung wirkt auf Navigation, Design und übergreifende Suche; jede Website behält ihr eigenes Berechtigungsmodell. Wer gemeinsame Rechte braucht, regelt das über Gruppen auf Website-Ebene, nicht über die Hub-Struktur.

Wie fange ich bei einer gewachsenen Umgebung mit der Aufräumarbeit an?

Mit einer Bestandsaufnahme statt einem Bauplan: Welche Websites und Bibliotheken existieren, wer besitzt sie, wann wurde zuletzt etwas geändert? Erfahrungsgemäß ist ein erheblicher Teil des Bestands inaktiv und lässt sich archivieren, bevor auch nur eine Struktur angefasst wird. Danach die Zielarchitektur entwerfen — flach, mit Hubs — und Sachgebiet für Sachgebiet umziehen, nicht alles auf einmal.