SharePoint Hub Sites: Intranet-Navigation, Site-Hierarchie und Berechtigungskonzept

Wie lassen sich viele SharePoint-Sites zu einem verständlichen Intranet verbinden, ohne eine starre Unterwebsite-Hierarchie aufzubauen? SharePoint Hub Sites bilden eine logische Klammer um eigenständige Sites. Sie können eine gemeinsame Hub-Navigation, ein abgestimmtes Erscheinungsbild und hubbezogene Inhalte oder Suchergebnisse bereitstellen. Die zugeordneten Sites bleiben trotzdem eigenständige Sicherheits- und Verwaltungsbereiche. Eine Hub-Zuordnung vererbt insbesondere nicht automatisch die Berechtigungen des Hubs auf alle verbundenen Sites.

Damit sind SharePoint Hub Sites vor allem ein Werkzeug für Informationsarchitektur: Sie strukturieren, wie Nutzer Inhalte finden und Zusammenhänge erkennen. Sie ersetzen weder ein Berechtigungskonzept noch die Entscheidung, welche Inhalte in welche Site gehören. Wer zuerst alle vorhandenen Sites an einen Hub hängt und erst danach über Navigation, Owner und Suchgrenzen nachdenkt, verschiebt das bestehende Chaos lediglich in eine neue Oberfläche.

Was SharePoint Hub Sites sind und was sie von normalen Sites unterscheidet

Jede moderne Team- oder Kommunikationssite ist zunächst eine eigenständige SharePoint-Site mit eigener URL, eigenen Site-Administratoren, eigenen Gruppen und eigenem Inhalt. Eine berechtigte Administratorrolle kann eine geeignete Site als Hub Site registrieren. Andere Sites werden anschließend diesem Hub zugeordnet.

Die Hub-Verbindung kann folgende gemeinsame Elemente bereitstellen:

• eine Hub-Navigation über den zugeordneten Sites,
• ein gemeinsames Hub-Design,
• News-, Ereignis- oder Inhaltsaggregation aus verbundenen Sites,
• einen Suchbereich, der sich auf den Hub und seine zugeordneten Sites konzentriert,
• einen verständlichen fachlichen Zusammenhang, etwa Unternehmen, Standorte, Qualitätsmanagement oder Projekte.

Die Zuordnung verändert nicht automatisch:

• Mitglieder und Besucher der verbundenen Sites,
• Bibliotheks- oder Ordnerberechtigungen,
• Sensitivitäts- und Freigabeeinstellungen,
• Aufbewahrungsregeln,
• Eigentümerschaft oder Betriebsverantwortung.

Diese Trennung ist ein wichtiges Sicherheitsmerkmal. Eine Personal-Site kann beispielsweise optisch und navigativ zum Unternehmens-Hub gehören, ohne dass alle Intranet-Besucher Zugriff auf Personaldokumente erhalten. Umgekehrt kann eine Site in der Hub-Navigation sichtbar sein, obwohl ein Nutzer beim Öffnen keinen Zugriff besitzt. Sichtbarkeit und Berechtigung müssen deshalb bewusst aufeinander abgestimmt werden.

Vor der Konfiguration: Intranet-Struktur als fachliches Modell planen

Eine belastbare Hub-Architektur beginnt nicht in der SharePoint-Administration, sondern mit einer Liste der fachlichen Bereiche und Nutzungsszenarien.

Pro Bereich fünf Fragen beantworten

1. Wer besitzt den Inhalt? Benennen Sie eine verantwortliche Rolle und mindestens eine Vertretung.
2. Wer soll lesen? Gesamtes Unternehmen, einzelne Standorte, Abteilungen, Projektteams oder Externe?
3. Wer darf veröffentlichen? Redaktionsgruppe, Site-Mitglieder oder nur wenige Owner?
4. Wie lange lebt der Bereich? Dauerhaftes Intranet, zeitlich begrenztes Programm oder einzelnes Projekt?
5. Wie wird der Inhalt gefunden? Navigation, Suche, Zielgruppensteuerung, Verlinkung oder Kombination?

Aus diesen Antworten ergibt sich, ob Inhalte in dieselbe Site, in getrennte Sites oder sogar in getrennte Hubs gehören.

Hub ist keine klassische Baumebene

SharePoint-Hubs bilden eine flache, flexible Verbindung zwischen Sites. Sie sollten nicht als exakte Kopie eines Organigramms verstanden werden. Organigramme ändern sich häufig; Informationsbedürfnisse sind oft langlebiger. Eine Site Arbeitssicherheit kann für mehrere Geschäftsbereiche relevant sein und sollte nicht bei jeder organisatorischen Verschiebung neu aufgebaut werden müssen.

Eine geeignete Struktur orientiert sich deshalb eher an stabilen Informationsdomänen:

Nicht jede Domäne muss ein eigener Hub sein. Zu viele Hubs erzeugen neue Navigationsbrüche und zusätzlichen Verwaltungsaufwand.

Hub-Verbindung: Welche Sites sich eignen und welche getrennt bleiben sollten

Geeignete Kandidaten

Eine Site passt zu einem Hub, wenn sie denselben Informationskontext, eine ähnliche Zielgruppe oder eine gemeinsame Navigation benötigt. Typische Beispiele sind Standort-Sites unter einem Unternehmens-Hub oder Fachbereichs-Sites unter einem Wissens-Hub.

Vor der Zuordnung sollten geprüft werden:

• Ist die Site modern und technisch unterstützt?
• Gibt es aktive Owner?
• Sind Titel, Beschreibung und Logo verständlich?
• Entspricht die externe Freigabe dem Hub-Kontext?
• Gibt es vertrauliche Inhalte, die durch Navigation oder Aggregation unbeabsichtigt sichtbar werden könnten?
• Sind Suchergebnisse für berechtigte Nutzer fachlich sinnvoll?

Bewusst getrennte Bereiche

Eine Trennung ist sinnvoll, wenn Sicherheitsmodell, Lebenszyklus oder Zielgruppe deutlich abweichen. Dazu gehören häufig:

• externe B2B-Portale,
• streng vertrauliche Personal- oder Rechtsbereiche,
• kurzfristige Projekt-Sites,
• Sites mit eigenen regulatorischen Aufbewahrungsregeln,
• Test- und Entwicklungsbereiche,
• persönliche oder experimentelle Team-Sites.

Die Trennung bedeutet nicht, dass keine Links gesetzt werden dürfen. Sie verhindert nur, dass eine gemeinsame Hub-Navigation oder Aggregation einen organisatorischen Zusammenhang suggeriert, der sicherheitstechnisch nicht besteht.

Mehrere Ebenen mit Hub-Zuordnungen

Microsoft unterstützt Hub-Beziehungen und – abhängig von der jeweiligen Konfiguration – auch Verknüpfungen zwischen Hubs. Eine tief verschachtelte Hub-Landschaft sollte dennoch vermieden werden. Jede zusätzliche Ebene erschwert die Frage, welche Navigation, Suche und Redaktion gerade maßgeblich ist.

Eine praxistaugliche Regel lautet: Ein Nutzer sollte von jeder wichtigen Seite mit wenigen verständlichen Schritten zum Ziel gelangen, ohne das technische Site-Modell kennen zu müssen.

Navigation: Hub-Navigation und lokale Navigation zusammenspielen lassen

Globale, Hub- und lokale Navigation unterscheiden

In einem Intranet können mehrere Navigationsschichten vorkommen:

• globale Navigation für organisationsweite Hauptziele,
• Hub-Navigation für Inhalte innerhalb einer Informationsdomäne,
• lokale Site-Navigation für Bibliotheken, Seiten und Funktionen einer einzelnen Site,
• kontextuelle Links innerhalb von Seiten, Karten oder Webparts.

Jede Ebene sollte eine andere Aufgabe erfüllen. Werden identische Links auf allen Ebenen wiederholt, entsteht keine Orientierung, sondern visuelles Rauschen.

Ein Navigationsmodell erstellen

Für jeden Navigationspunkt sollte dokumentiert werden:

Eigenschaft	Frage
Bezeichnung	Versteht die Zielgruppe den Begriff ohne internes Projektwissen?
Ziel	Führt der Link auf eine Einstiegsseite, Site oder einzelne Datei?
Owner	Wer hält Ziel und Bezeichnung aktuell?
Zielgruppe	Ist der Link für alle oder nur bestimmte Gruppen relevant?
Prüfung	Wann wurde der Link zuletzt getestet?
Rückfall	Was passiert, wenn die Ziel-Site archiviert wird?

Links auf einzelne Dateien sind als dauerhafte Hauptnavigation meist ungeeignet. Eine Landingpage kann Kontext, verantwortliche Stelle und alternative Wege bereitstellen.

Zielgruppensteuerung nicht mit Sicherheit verwechseln

Navigation kann für Zielgruppen ein- oder ausgeblendet werden. Diese Funktion verbessert die Übersicht, ersetzt aber keine Zugriffsprüfung. Ein ausgeblendeter Link nimmt keinem Nutzer eine Berechtigung; ein sichtbarer Link gewährt keinen Zugriff. Sicherheit wird an Site, Bibliothek, Ordner oder Element geregelt.

Berechtigungsvererbung und Isolation: Was Hub Sites teilen und was nicht

Die wichtigste Regel

Eine Site erhält durch die Zuordnung zu einem Hub nicht automatisch dieselben Benutzer und Gruppen wie der Hub. Das Berechtigungskonzept jeder Site bleibt eigenständig. Microsoft stellt Funktionen bereit, mit denen Hub-Besucherberechtigungen auf zugeordnete Sites synchronisiert werden können. Diese Funktion muss jedoch bewusst geplant und aktiviert werden; sie ersetzt nicht die Prüfung lokaler Ausnahmen.

Vor einer Synchronisierung sollten folgende Fragen beantwortet werden:

• Soll wirklich jede verbundene Site von derselben Lesergruppe erreichbar sein?
• Gibt es Sites mit vertraulichen Bibliotheken oder abweichenden Besuchern?
• Wie werden externe Gäste behandelt?
• Wer darf lokale Mitglieder hinzufügen?
• Wie wird eine versehentliche Unterbrechung der Vererbung erkannt?

Gruppen statt Einzelberechtigungen

Vergeben Sie Zugriffe möglichst über Entra-ID- oder Microsoft-365-Gruppen beziehungsweise klar benannte SharePoint-Gruppen. Einzelberechtigungen erschweren Audits und Offboarding. Besonders problematisch sind viele individuell freigegebene Dateien und Ordner, weil sie die Zahl eindeutiger Berechtigungsbereiche erhöhen und kaum noch verständlich dokumentiert werden können.

Ein einfaches Rollenmodell pro Site kann so aussehen:

• Site-Owner: technische und fachliche Verantwortliche,
• Site-Mitglieder: Personen, die Inhalte bearbeiten,
• Site-Besucher: lesende Zielgruppe,
• zusätzliche Fachrollen nur bei begründetem Bedarf.

Owner sollten regelmäßig geprüft werden. Eine verwaiste Site ohne aktive Verantwortliche ist ein Betriebsrisiko, unabhängig von der Hub-Zuordnung.

Suchintegration: Hubbezogene Ergebnisse richtig einordnen

SharePoint-Suche berücksichtigt Berechtigungen: Nutzer sollen nur Ergebnisse sehen, auf die sie Zugriff besitzen. Eine hubbezogene Suche kann den Kontext auf den Hub und zugeordnete Sites konzentrieren. Das verbessert die Relevanz, wenn Sites fachlich sauber zugeordnet und Inhalte verständlich ausgezeichnet sind.

Suche braucht Metadaten und redaktionelle Qualität

Eine Hub-Zuordnung behebt keine unklaren Titel, leeren Seitenbeschreibungen oder uneinheitlichen Dateinamen. Für auffindbare Inhalte sind unter anderem wichtig:

• verständliche Seitentitel,
• konsistente Begriffe und Synonyme,
• gepflegte Metadaten,
• passende Inhaltstypen,
• klare Veröffentlichungsstände,
• keine unnötigen Kopien desselben Dokuments.

Für umfangreiche Wissensbereiche kann eine gezielte Suchoberfläche sinnvoll sein. Wie Suchfelder, Filter und Ergebnisdarstellung in SharePoint aufgebaut werden können, zeigt der Beitrag FAQ und Wissensdatenbank mit SharePoint und PnP Search.

Sicherheitsgetrimmte Suche testen

Die Aussage „Suche ist sicherheitsgetrimmt“ darf nicht nur theoretisch vorausgesetzt werden. Testen Sie mit mehreren Rollen:

1. unternehmensweiter Leser,
2. Fachbereichsmitglied,
3. Site Owner,
4. externer Gast,
5. Nutzer ohne Zugriff.

Suchen Sie nach eindeutigen Testbegriffen in öffentlichen und vertraulichen Dokumenten. Prüfen Sie Ergebnis, Vorschau, Linkziel und mögliche Aggregations-Webparts. Beachten Sie, dass Indexierung und Berechtigungsänderungen nicht immer sofort in allen Suchoberflächen sichtbar sind.

Umsetzung in kontrollierten Schritten

Schritt 1: Bestandsaufnahme

Exportieren oder dokumentieren Sie aktive Sites mit URL, Template, Ownern, Mitgliedern, externem Freigabestatus, Speicherverbrauch und letzter Aktivität. Markieren Sie Dubletten, verwaiste Sites und sensible Bereiche.

Schritt 2: Zielarchitektur zeichnen

Erstellen Sie eine einfache Karte mit Hubs, zugeordneten Sites, Zielgruppen und Hauptnavigation. Vermeiden Sie technische Detailtiefe, bevor die fachliche Zuordnung geklärt ist.

Schritt 3: Pilot-Hub auswählen

Nehmen Sie einen Bereich mit überschaubarer Site-Zahl, aktiven Ownern und geringem externem Risiko. Bauen Sie Navigation, Design, Suche und Berechtigungsprüfung vollständig auf.

Schritt 4: Sites schrittweise zuordnen

Ordnen Sie nicht alle Sites gleichzeitig zu. Prüfen Sie nach jeder Gruppe:

• Navigation,
• Design,
• Suchbereich,
• News-Aggregation,
• Besucherzugriff,
• mobile Darstellung,
• vorhandene direkte Links.

Schritt 5: Betriebsmodell festlegen

Dokumentieren Sie, wer Hubs registrieren, Sites zuordnen, Navigation ändern und Owner kontrollieren darf. Definieren Sie einen Review-Zyklus und einen Prozess für Archivierung oder Umzug.

Typische Fehler und konkrete Rückfallwege

Fehler: Der Hub wird zum Berechtigungscontainer erklärt

Symptom: Verantwortliche gehen davon aus, dass eine Hub-Zuordnung Zugriff gewährt oder entzieht.

Korrektur: Berechtigungen jeder Site separat prüfen; optionale Besucher-Synchronisierung dokumentieren und mit Testkonten validieren.

Rückfall: Synchronisierung deaktivieren, lokale Besuchergruppen wiederherstellen und Zugriffe anhand einer freigegebenen Matrix neu setzen.

Fehler: Die Navigation bildet das Organigramm eins zu eins ab

Symptom: Umstrukturierungen führen ständig zu neuen Sites, Links und Namen.

Korrektur: Navigation an stabilen Aufgaben und Informationsdomänen ausrichten.

Rückfall: Weiterleitungen und Übergangsseiten einsetzen, bevor URLs oder Sites geändert werden.

Fehler: Zu viele Hubs

Symptom: Nutzer wechseln zwischen mehreren fast identischen Navigationsleisten und wissen nicht, welcher Bereich maßgeblich ist.

Korrektur: Hubs konsolidieren und gemeinsame Zielgruppen oder Inhalte zusammenführen.

Rückfall: Site-Zuordnungen schrittweise lösen; alte Hubs erst nach Link- und Suchtests stilllegen.

Fehler: Aggregation zeigt ungeeignete Inhalte

Symptom: News oder Ereignisse erscheinen im falschen Kontext.

Korrektur: Quellen, Freigabestatus, Zielgruppen und redaktionelle Prozesse kontrollieren.

Rückfall: Aggregations-Webpart vorübergehend auf ausgewählte Sites begrenzen.

Fehler: Eine Site hat keine aktiven Owner

Symptom: Navigation oder Berechtigungen können nicht fachlich bestätigt werden.

Korrektur: Mindestens zwei verantwortliche Personen oder eine klar definierte Funktionsrolle einsetzen.

Rückfall: Site aus der aktiven Hub-Navigation nehmen, bis Eigentümerschaft und Inhalt geprüft sind.

Abnahmetest für einen SharePoint-Hub

Ein Hub ist erst produktionsreif, wenn mindestens folgende Tests dokumentiert sind:

• Hub-Navigation funktioniert auf Desktop und Mobilgerät.
• Lokale Navigation bleibt verständlich und widerspricht der Hub-Navigation nicht.
• Nutzer ohne Zugriff sehen keine vertraulichen Suchergebnisse.
• Zielgruppensteuerung wurde nicht als Berechtigungsersatz verwendet.
• News und Ereignisse stammen nur aus freigegebenen Quellen.
• Site-Owner und Vertretungen sind benannt.
• Externe Gäste erhalten nur vorgesehene Inhalte.
• Archivierte oder verschobene Sites erzeugen keine toten Hauptlinks.
• Berechtigungsänderungen und Suchindex-Verzögerungen sind im Betriebshandbuch berücksichtigt.
• Ein Rückbau der Site-Zuordnung wurde im Pilot nachvollzogen.

Für projektbezogene Ablagen mit klaren Site-Grenzen bietet der Beitrag Zentrale Projektablage in SharePoint statt Papierplänen zusätzlichen Architekturkontext.

So bleibt die Intranet-Architektur auch bei wachsender Nutzer- und Inhaltszahl beherrschbar

Eine tragfähige Hub-Architektur verbindet Sites über Navigation, Design und Suchkontext, ohne ihre Sicherheitsgrenzen zu verwischen. Entscheidend sind wenige, fachlich verständliche Hubs, aktive Owner, eine dokumentierte Zuordnung, gruppenbasierte Berechtigungen und wiederkehrende Tests mit realen Nutzerrollen. So kann das Intranet wachsen, ohne bei jeder organisatorischen Änderung neu gebaut werden zu müssen.