SharePoint-Seiten auf die Firmenwebseite: Publishing mit Redaktion

Vom Intranet

auf die Webseite.

Foto: StockSnap / Pixabay

Ein Beitrag im Intranet kann ohne Agentur auf der Firmenwebseite erscheinen, geprüft und jederzeit rückholbar. Eine kleine Brücke macht das möglich: Wer im Intranet freigibt, löst den Weg nach aussen aus, mit Redaktion und Knopfdruck.

Das Wichtigste in Kürze

• Ein Beitrag entsteht nur einmal. Der Autor schreibt im SharePoint-Intranet und setzt eine Spalte auf „public“. Alles andere bleibt intern.
• Die Brücke liest nur freigegebene Seiten. Ein Container ruft sie über Microsoft Graph ab, mit Zugriff auf eine einzige Website.
• Ein virtuelles Redaktionsteam bereitet jeden Beitrag auf. Es korrigiert die Rechtschreibung und prüft Titel, Bildformate und Gestaltungsvorgaben.
• Nach aussen geht nur, was ein Mensch freigibt. Ein Klick veröffentlicht, ein Klick zieht zurück und leert den Cache.
• Die IT richtet das einmal ein. Danach schreiben die Autoren wie bisher, ohne neues Werkzeug.

Das Problem: Im Intranet dreht sich das Rad, aussen steht es still

In vielen Firmen läuft die Kommunikation nach innen schnell. Projekte starten, Teams gewinnen Aufträge, Standorte feiern Jubiläen, und alles steht im Intranet. Die öffentliche Webseite sieht dagegen jeden Tag gleich aus, weil jede Änderung einen Umweg nimmt.

Dabei führt der übliche Weg über die Grafikabteilung oder eine Werbeagentur. Jemand schickt Text und Bilder, die Agentur setzt sie um, die Firma prüft, es folgt eine Korrekturschleife. Dieser Weg kostet Geld und Zeit, und das Hin und Her bei der Freigabe ermüdet alle Beteiligten. Deshalb lohnt sich der Aufwand oft nur für grosse Meldungen, und die kleinen guten Geschichten bleiben im Intranet.

Daher setzt die Idee beim Beitrag an, den ein Mitarbeitender ohnehin im Intranet schreibt: Er wird zum Rohstoff für die Webseite. Zwischen beiden steht eine Brücke, die prüft, aufbereitet und erst nach einem Klick veröffentlicht.

Der Ablauf in sieben Schritten

Die Grafik zeigt den ganzen Weg, vom Schreiben bis zum Zurückziehen. Vier Stationen liegen beim Menschen oder im Intranet, drei in der Brücke und auf der Webseite.

Dabei erleben Autoren nur die ersten beiden Schritte. Sie schreiben wie immer und wählen in der Spalte „Visibility“ den Wert „public“. Ab Schritt 3 arbeitet die Brücke, und ab Schritt 5 entscheidet ein Mensch.

So funktioniert die Technik

Die Auswahl: eine Spalte in der Seitenbibliothek

SharePoint speichert Seiten in der Bibliothek „Websiteseiten“. Dort lässt sich eine Auswahlspalte ergänzen, zum Beispiel „Visibility“ mit den Werten „public“ und „internal“. Die Brücke übernimmt nur Seiten, die den Wert „public“ tragen und veröffentlicht sind. Jede andere Seite sieht sie nie.

Damit ist gemeint: Microsoft Graph kennt für jede Seite einen Veröffentlichungsstatus, etwa „draft“ oder „published“. Ist im Seitenbestand ein Genehmigungsablauf aktiv, wird eine Seite laut Microsoft erst veröffentlicht, wenn der Ablauf abgeschlossen ist. So verlängert sich die Kette sinnvoll: Erst genehmigt das Intranet, dann holt die Brücke.

Das Abholen: Microsoft Graph

Die Brücke spricht mit Microsoft Graph, der offiziellen Schnittstelle für Microsoft 365. Drei Aufrufe genügen für den Kern:

GET /sites/{site-id}/pages/microsoft.graph.sitePage
GET /sites/{site-id}/pages/{page-id}/microsoft.graph.sitePage?$expand=canvasLayout
GET /sites/{site-id}/lists/{list-id}/items/delta

So listet der erste Aufruf die Seiten einer Website samt Titel, Adresse und Veröffentlichungsstatus. Der zweite holt eine Seite mit Inhalt: Mit $expand=canvasLayout liefert Graph die Textteile als HTML. Der dritte meldet neue, geänderte und gelöschte Listeneinträge, ohne jedes Mal alles zu lesen.

Der Auslöser: Webhook oder regelmässig nachfragen

Für den Anstoss gibt es zwei Wege. Graph kann Änderungen einer SharePoint-Liste per Webhook melden. Diese einfachen Benachrichtigungen enthalten nur die Kennung des geänderten Objekts, die Brücke fragt dann selbst nach den Einzelheiten. Solche Abonnements laufen laut Microsoft für Listen unter 30 Tage und müssen erneuert werden. Die Meldung trifft im Mittel in unter einer Minute ein, im Höchstfall nach sechs Stunden.

Die Alternative ist die Delta-Abfrage. Die Brücke fragt zum Beispiel stündlich nach und erhält nur, was sich seit dem letzten Mal geändert hat. Gelöschte Einträge kommen mit einer Löschmarke. Damit braucht sie keine von aussen erreichbare Adresse, denn sie ruft nur ab. Für ein Intranet-nahes Werkzeug ist das oft die ruhigere Wahl.

Die Redaktion: virtuelle Rollen mit festen Regeln

Nach dem Abholen geht der Text durch die virtuelle Redaktion. Gemeint ist ein Team aus Programmen und Sprachmodellen mit klaren Aufgaben: ein Reporter oder Autor, der den Rohtext in die Form der Webseite bringt, eine Bildredaktion für Format und Zuschnitt und ein Redaktor, der nach festen Kriterien prüft. Wie ein solches Team aufgebaut ist, steht auf der Seite So arbeitet die Redaktion.

Zudem stammen die Regeln aus der Firma. Dazu zählen Länge und Stil des Titels, Bildformat und Mindestbreite, Schreibweisen, Tonalität und Pflichtangaben. In meinem Blog prüft der Redaktor zum Beispiel, ob ein Titel zwischen 40 und 70 Zeichen liegt. Dasselbe Prinzip lässt sich auf Vorgaben einer Firma übertragen. Wo eine Regel verletzt ist, korrigiert die Redaktion oder meldet den Befund.

Die Webseite: statisch gebaut, schnell, rückholbar

Danach erzeugt ein Generator aus dem geprüften Beitrag fertige HTML-Seiten. Eine statische Webseite braucht keine Datenbank und keinen Anmeldebereich, sie liefert nur Dateien aus. Das ist schnell und bietet wenig Angriffsfläche.

Deshalb ist das Zurückziehen die Umkehrung: Ein Klick nimmt den Beitrag aus der Liste, die Webseite wird neu gebaut, die Seite verschwindet, und der Zwischenspeicher am Rand des Netzes wird geleert, damit niemand die alte Fassung weiter sieht. Meldet SharePoint eine Seite später als gelöscht oder nicht mehr „public“, kann die Brücke sie automatisch zum Zurückziehen vormerken. Auch dann bestätigt ein Mensch.

Wer macht was

Drei Rollen teilen sich die Arbeit. Jede hat eine klare Grenze.

Was die IT einmal einrichtet

Der Aufwand für die IT ist überschaubar und besteht aus vier Handgriffen:

1. App-Registrierung in Microsoft Entra: Die Brücke bekommt eine eigene Identität mit der Berechtigung Sites.Selected.
2. Zugriff auf eine Website: Ein Administrator weist der App die Rolle „read“ für genau die Website mit den Seiten zu (POST /sites/{siteId}/permissions).
3. Container: Die Brücke läuft als Docker-Container, mit Zugangsdaten aus einem Geheimnisspeicher statt aus dem Code.
4. Webseite und Cache: Der Generator und das Leeren des Zwischenspeichers werden mit dem Webhoster oder Netzwerkdienst verbunden.

Zudem sagt Microsoft zu Schritt 2 klar: Selected-Berechtigungen verlangen eine ausdrückliche Zuweisung. Eine App mit Sites.Selected hat zunächst keinen Zugriff auf irgendeine Website. Ein Administrator kann ihn jederzeit entziehen, entweder durch Löschen der Zuweisung oder durch Widerruf der Zustimmung in Entra. Die Seiten-Dokumentation nennt für die Abfrage der Seiten allerdings Sites.Read.All als geringste Berechtigung. Teste deshalb vor dem Start in deinem Mandanten, ob Sites.Selected für alle benötigten Aufrufe genügt.

Datenschutz und Kontrolle

Drei Sicherungen halten die Brücke unter Kontrolle:

• Zwei Schlüssel für „nach aussen“: Eine Seite muss im Intranet als „public“ markiert und von der Redaktion geprüft sein. Dazu braucht es den Klick eines Menschen.
• Internal bleibt intern: Die Brücke sieht Seiten ohne den Wert „public“ gar nicht erst. Der Zugriff ist auf eine Website begrenzt und lesend.
• Rückholbar: Ein Beitrag lässt sich mit einem Klick zurückziehen. Das Protokoll der Brücke zeigt, wer wann freigegeben hat.

Dabei gehören zwei Punkte in die Planung: Texte und Bilder verlassen das Intranet, deshalb brauchen Autoren klare Regeln, was „public“ sein darf. Und Bilder mit Personen verlangen deren Einverständnis, bevor der Beitrag nach aussen geht.

Nutzen gegenüber dem Weg über die Agentur

Die Agentur bleibt für Kampagnen und Markenauftritt sinnvoll. Für laufende Neuigkeiten spricht vieles für die Brücke:

Deshalb nenne ich keine Zahlen, denn sie hängen von der Firma ab. Messbar sind sie leicht: Zähle vor dem Start die Tage zwischen Intranet-Beitrag und Webseite und vergleiche sie danach.

Meine Erfahrung

Ich habe ein SharePoint-Wiki aufgebaut, dessen Seiten eine Spalte „Visibility“ mit den Werten „public“ und „internal“ tragen. Damit soll dieselbe Quelle später nur die öffentlichen Seiten zeigen. Zudem läuft mein Blog mit einer internen Vorschau und einem Freigabeknopf: Neue Artikel erscheinen erst nach dem Klick. Damit liegen zwei Bausteine dieser Brücke vor. Als vollständige Lösung für eine Firma habe ich sie nicht betrieben.

Einordnung: Was das für Kommunikation, Marketing und IT in KMU heisst

Für kleine und mittlere Firmen in der Schweiz liegt der Gewinn in der Aktualität. Die Webseite zeigt, was im Haus passiert, ohne dass jemand jeden Beitrag zweimal baut. Die Kommunikationsabteilung behält die Freigabe und verliert keine Kontrolle. Das Marketing gewinnt Material für Webseite und Kanäle. Die IT trägt einen einzigen Container und eine eng begrenzte App-Berechtigung. Wer klein anfängt, wählt eine Website und eine Rubrik, etwa Neuigkeiten, und lässt die Brücke einen Monat im Vorschaumodus laufen, bevor sie öffentlich schaltet.

Fazit

Eine Brücke zwischen SharePoint und Webseite macht aus Intranet-Beiträgen schnell veröffentlichte Meldungen, ohne die Kontrolle abzugeben. Microsoft Graph liefert die Seiten, Sites.Selected begrenzt den Zugriff, und die virtuelle Redaktion setzt die Vorgaben durch. Entscheidend bleibt der Mensch mit dem Freigabeknopf und dem Klick zum Zurückziehen. Beginne mit einer Website, einer Rubrik und einer klaren Regel für „public“.

Quellen bei Microsoft Learn: Liste der Seiten (sitePage), Seite abrufen mit Inhalt, Seite veröffentlichen, Selected-Berechtigungen, Änderungsbenachrichtigungen, Delta-Abfrage für Listeneinträge. Zuletzt geprüft: 24. Oktober 2026. Die Redaktionsregeln und der Freigabeknopf beschreiben mein eigenes Vorgehen.

Geschrieben von Andreas Brauckmann · So arbeitet die Redaktion