SharePoint als Stadtwebsite? Warum selbst ein Microsoft-Trainer davon abrät

In eigener Sache: Dieser Artikel kommt nicht aus dem Lager der Microsoft-Kritiker. Hinter Webdesign Wolfsburg steht ein Microsoft Certified Trainer (MCT), der Microsoft 365 seit Jahren schult, einführt und betreibt – SharePoint eingeschlossen. Die Websites, die wir bauen, binden Entra ID, Exchange Online und Teams ganz selbstverständlich an. Und trotzdem lautet unser Rat für den Internetauftritt einer Kommune ohne Wenn und Aber: Finger weg von SharePoint. Wer die Plattform von innen kennt, weiß, wofür sie gebaut ist – und wofür nicht.

In fast jedem Gespräch über einen Relaunch fällt irgendwann dieser Satz: „Wir haben doch Microsoft 365. Können wir die Website nicht einfach mit SharePoint machen?“ Die Frage ist verständlich. Die Lizenzen sind bezahlt, das Intranet läuft schon auf SharePoint, die IT kennt die Plattform, und die Redaktion arbeitet ohnehin jeden Tag damit.

Für den öffentlichen Internetauftritt einer Kommune ist SharePoint trotzdem die falsche Wahl, und das hat weniger mit Geschmack zu tun als mit dem, was Microsoft selbst über das Produkt entschieden hat. Dieser Artikel erklärt die Gründe, mit Quellen und Daten, damit Sie die Diskussion im Haus sachlich führen können.

Was Microsoft selbst entschieden hat

SharePoint Online konnte früher tatsächlich öffentliche Websites ausliefern. Microsoft hat diese Funktion bewusst beendet:

1. 9. März 2015: Neue Kund*innen können in SharePoint Online keine öffentliche Website mehr anlegen. Microsoft verweist für öffentliche Websites ausdrücklich auf Lösungen anderer Anbieter.
2. 1. Mai 2017: Der anonyme Zugriff auf bestehende öffentliche SharePoint-Websites endet. Mit Aufschub war spätestens am 31. März 2018 Schluss, danach wurden die Websites gelöscht.
3. Heute: Moderne SharePoint-Seiten und Kommunikationswebsites sind nur für angemeldete Personen sichtbar – für Mitarbeitende oder ausdrücklich eingeladene Gäste. Einen Schalter „für alle im Internet“ gibt es nicht.
4. 1. März 2027: Klassische Publishing-Sites und das Publishing-Feature lassen sich in SharePoint Online nicht mehr neu anlegen oder aktivieren. Das war die letzte Funktion, die überhaupt in Richtung Web-Content-Management ging.
5. 1. Oktober 2028: Alle klassischen, selbst erstellten Seiten – auch Publishing-Seiten und eigene ASPX-Seiten – werden schreibgeschützt. Eigene Skripte werden standardmäßig gesperrt.

Die Richtung ist eindeutig: Microsoft entwickelt SharePoint als Plattform für Zusammenarbeit, Dokumente, Intranet und als Wissensbasis für Copilot weiter. Ein Werkzeug zum Veröffentlichen im offenen Internet soll es ausdrücklich nicht mehr sein.

Die Umwege – und warum keiner trägt

Wer trotzdem mit SharePoint veröffentlichen will, landet bei einem von vier Umwegen. Alle sind technisch möglich, und alle schaffen mehr Probleme, als sie lösen:

Was eine kommunale Website leisten muss

Der eigentliche Maßstab ist nicht, was SharePoint kann, sondern was Bürger*innen, Redaktion und Gesetzgeber von einem Stadtportal erwarten. Daran gemessen fehlt SharePoint das Fundament:

Barrierefreiheit: Verantwortung ohne Kontrolle

Öffentliche Stellen müssen ihre Websites nach BITV 2.0 barrierefrei gestalten, eine Erklärung zur Barrierefreiheit veröffentlichen und für deren Richtigkeit einstehen. Mit SharePoint übernimmt die Kommune diese Verantwortung für ein System, auf das sie kaum Einfluss hat:

• Die Ausgabe gehört Microsoft. Welches HTML eine SharePoint-Seite erzeugt, wie Navigation, Menüs und Fokus funktionieren, legt Microsoft fest – und ändert es mit laufenden Updates. Ihre Prüfung von heute gilt nur bis zum nächsten Release, und vorher testen können Sie nicht.
• Regeln lassen sich nicht erzwingen. Alternativtexte, eine saubere Überschriftenfolge, aussagekräftige Linktexte, ausreichende Kontraste: In SharePoint hängt das am Wissen der jeweiligen Person, die gerade eine Seite bearbeitet. Ein Bild ohne Alternativtext lässt sich trotzdem veröffentlichen.
• PDFs gehen ungeprüft online. Dokumentbibliotheken nehmen jede Datei an. Ob ein Formular oder eine Satzung als barrierefreies PDF/UA vorliegt, prüft niemand – dabei sind Dokumente auf kommunalen Websites oft die größte Barriere.
• Pflichtangebote passen nicht ins Raster. Leichte Sprache, Gebärdensprache, Schriftgröße und Kontrast anpassen, eine Feedback-Möglichkeit für Barrieren: All das muss gut sichtbar und überall gleich erreichbar sein. Die Seitenvorlagen von SharePoint sind dafür nicht gebaut.
• Zusatz-Werkzeuge kaschieren nur. Wer die Lücken mit einem nachträglich eingebundenen Overlay schließen will, verschiebt das Problem – und holt sich eine weitere Drittanbieter-Verbindung auf die Seite.

Google und KI-Assistenten: Was nicht öffentlich ist, wird nicht gefunden

Die meisten Bürger*innen kommen nicht über die Startseite, sondern über eine Suche: „Personalausweis beantragen Wolfsburg“, „Sperrmüll anmelden“, „Kita-Platz“. Immer häufiger fragen sie auch einen KI-Assistenten. Beide finden nur, was öffentlich, schnell und gut strukturiert ist:

• Hinter einer Anmeldung gibt es keine Treffer. Suchmaschinen und KI-Assistenten können SharePoint-Seiten, die eine Anmeldung voraussetzen, nicht lesen. Anonyme Freigabelinks tauchen ebenfalls nicht in Suchergebnissen auf. Für Google existiert die Seite schlicht nicht.
• Keine Werkzeuge für die Trefferliste. Seitentitel und Beschreibung für das Suchergebnis, Vorschaubilder beim Teilen, strukturierte Daten für Verwaltungsleistungen, Termine und Kontakte, eine Sitemap, kanonische Adressen: Das sind Grundfunktionen jedes Web-CMS – in SharePoint sind sie nicht vorgesehen, weil Intranets nicht gefunden werden wollen.
• Lange, technische Adressen. /sites/buergerservice/SitePages/Personalausweis.aspx lässt sich schlecht merken, schlecht drucken und schlecht verlinken. Ändert sich die Struktur, brechen Links, und eine gezielte Weiterleitung auf die neue Adresse ist nicht vorgesehen.
• Ladezeit zählt. Moderne SharePoint-Seiten sind eine umfangreiche JavaScript-Anwendung, ausgelegt auf angemeldete Mitarbeitende am Arbeitsplatz. Für die erste Anfrage vom Smartphone im Mobilfunknetz – den Normalfall auf einer Stadtwebsite – ist das die falsche Architektur. Suchmaschinen bewerten Ladezeit mit.
• KI-Assistenten brauchen eine amtliche Quelle. Wenn ChatGPT, Copilot oder die KI-Übersicht bei Google die Öffnungszeiten des Bürgerbüros nicht auf der Website der Stadt finden, nehmen sie sie von irgendwo anders – im Zweifel falsch.

Unter der Haube: ASPX-Adressen und Inhalte, die erst im Browser entstehen

Angenommen, eine Kommune bekäme SharePoint-Inhalte trotzdem öffentlich – über einen eigenen Server mit anonymem Zugriff oder über Freigabelinks. Dann bleiben zwei technische Probleme, die sich mit keiner Einstellung beheben lassen: die Adressen und die Art, wie Seiten ausgeliefert werden.

Adressen, die niemand lesen, merken oder umziehen kann

Eine Webadresse ist für eine Verwaltung kein Detail. Sie steht auf Bescheiden, Plakaten und Flyern, in Zeitungsartikeln und in den Lesezeichen der Bürger*innen – oft über Jahrzehnte. So sehen typische SharePoint-Adressen aus, und so sollten sie aussehen:

• Nicht die eigene Domain. SharePoint Online läuft unter …sharepoint.com. Eine Adresse unter der Domain der Stadt ist dort nicht vorgesehen – und damit fehlt das wichtigste Vertrauenssignal einer amtlichen Website.
• Die Technik steckt in der Adresse. Endungen wie .aspx, Pfade wie /_layouts/15/ oder /Forms/AllItems.aspx und Kennungen wie {3F2A…} haben in einer Adresse nichts verloren. Wer später das System wechselt, muss jede einzelne davon umleiten.
• Leerzeichen, Umlaute, Parameter. Dateinamen werden zu %20 und kodierten Umlauten, Freigabelinks tragen Prüfparameter. Solche Adressen brechen beim Kopieren in E-Mails, lassen sich nicht vorlesen und nicht abtippen.
• Umbenennen heißt kaputtmachen. Ändert jemand den Dateinamen einer Seite oder verschiebt ein Dokument in eine andere Bibliothek, ändert sich die Adresse. Eine automatische Weiterleitung gibt es nicht – jeder Link auf Plakaten, in Bescheiden und in Suchmaschinen führt ins Leere.
• Eine Seite, mehrere Adressen. Dieselbe Startseite ist über /sites/Buergerservice/ und /sites/Buergerservice/SitePages/Home.aspx erreichbar. Ohne kanonische Adresse wertet eine Suchmaschine das als doppelten Inhalt.

Inhalte, die erst im Browser entstehen

Moderne SharePoint-Seiten werden laut Microsoft bewusst im Browser aufgebaut: Der Server schickt zunächst ein Grundgerüst mit Skripten, Texte, Überschriften und Links setzt JavaScript erst auf dem Gerät der Besucher*innen zusammen. Für Mitarbeitende im Intranet ist das sinnvoll. Für eine öffentliche Website ist es ein Problem:

• Google liest mit Verzögerung. Google kann JavaScript ausführen, stellt solche Seiten aber in eine Warteschlange und rendert sie später, wenn Rechenkapazität frei ist. Neue Inhalte – eine Straßensperrung, eine Unwetterwarnung, eine geänderte Öffnungszeit – erscheinen dadurch später in den Suchergebnissen.
• KI-Crawler sehen eine leere Hülle. Die Crawler von ChatGPT, Claude und anderen KI-Diensten führen nach einer Auswertung von Vercel kein JavaScript aus. Was erst im Browser entsteht, existiert für sie nicht. Fragt jemand einen KI-Assistenten nach dem Termin für den Sperrmüll, kann die amtliche Antwort nicht von der Website der Stadt kommen.
• Keine Vorschau beim Teilen. Teilt jemand eine Seite über Messenger oder soziale Netzwerke, holen deren Vorschau-Dienste Titel, Beschreibung und Bild aus dem ersten HTML. Steht dort nur das Grundgerüst, erscheint ein leerer Kasten statt einer Vorschau.
• Langsam auf dem Smartphone. Bevor der erste Satz zu lesen ist, muss das Gerät eine große Anwendung laden und ausführen – im Mobilfunknetz, auf einem älteren Telefon. Genau das sind die Bedingungen, unter denen viele Menschen eine Stadtwebsite aufrufen.

In unserem Konzept ist es umgekehrt: Seiten werden mit Next.js vorab oder auf dem Server erzeugt. Schon die erste Antwort enthält den vollständigen Text, alle Überschriften, Links, strukturierten Daten und Vorschau-Angaben. Google, Bing, KI-Crawler, Vorschau-Dienste und Screenreader lesen dasselbe – ohne auf ein Skript warten zu müssen. JavaScript kommt nur dort dazu, wo es etwas verbessert, etwa bei der Suche oder einer Karte.

Sicherheit: Ein Intranet-Server gehört nicht ins Internet

Der naheliegende Ausweg – SharePoint im eigenen Haus betreiben und öffnen – ist auch der riskanteste. Das hat sich 2025 sehr konkret gezeigt:

• Juli 2025, „ToolShell“: Eine Schwachstellenkette in selbst betriebenen SharePoint-Servern (CVE-2025-53770, Schweregrad 9,8 von 10) wurde weltweit massenhaft ausgenutzt, bevor ein Patch verfügbar war. Betroffen waren Hunderte Organisationen, darunter Behörden in Nordamerika und Europa. Das BSI warnte ausdrücklich auch deutsche Behörden.
• 14. Juli 2026: Der Support für SharePoint Server 2016 und 2019 ist ausgelaufen. Für diese Versionen gibt es keine Sicherheitsupdates mehr. Wer noch darauf setzt, muss migrieren – auf die Subscription Edition oder in die Cloud.
• Große Angriffsfläche: Ein SharePoint-Server ist eng mit Active Directory, Dateiablagen und Fachverfahren verbunden. Gerät er in falsche Hände, ist nicht nur die Website betroffen, sondern im schlimmsten Fall das Netz der Verwaltung.

Eine öffentliche Website sollte das Gegenteil sein: ein abgeschottetes System, das im Ernstfall schnell neu aufgesetzt werden kann und keinen Weg ins Verwaltungsnetz öffnet. Mit einer statisch ausgelieferten Website und einem getrennt betriebenen Redaktionssystem ist das einfach umzusetzen.

Souveränität und Datenschutz

Ob Microsoft 365 in einer Verwaltung datenschutzkonform eingesetzt werden kann, wird seit Jahren diskutiert. Die Datenschutzkonferenz hat 2022 erhebliche Bedenken formuliert, einzelne Länder erlauben den Einsatz inzwischen unter Auflagen, andere – wie Schleswig-Holstein – stellen ihre Verwaltung auf Open Source um. Für den Internetauftritt ist diese Debatte aber gar nicht entscheidend, denn dort gilt eine strengere Frage:

Wer besucht die Seite, und hat diese Person eingewilligt? Mitarbeitende im Intranet arbeiten auf Grundlage ihres Dienstverhältnisses und der Dienstvereinbarung. Bürger*innen, die nachsehen, wann der Wertstoffhof geöffnet hat, haben nichts unterschrieben. Eine öffentliche Website sollte deshalb ohne Verbindungen zu Drittanbietern auskommen und in einem Rechenzentrum in Deutschland laufen, das die Kommune selbst wählt. Das ist mit einem selbst betriebenen Open-Source-CMS einfach – mit einem US-Cloud-Dienst als Auslieferungsplattform nicht.

Hinzu kommt die strategische Seite: Bund, Länder und viele Kommunen verfolgen Open-Source- und Souveränitätsziele. Den sichtbarsten digitalen Auftritt der Stadt an das Produkt eines einzelnen Herstellers zu binden, der die Weichen in die entgegengesetzte Richtung stellt, passt dazu nicht.

Was unser Konzept leistet – und mit SharePoint nicht erreichbar ist

Für kommunale Websites setzen wir auf Payload CMS und den visuellen Editor Puck, selbst betrieben in Deutschland. Der Unterschied zu SharePoint liegt nicht in einzelnen Funktionen, sondern im Ansatz: Barrierefreiheit, Design und Qualität stecken im Fundament, statt im Alltag erkämpft zu werden. Ziel für Ziel:

Die letzte Zeile ist die wichtigste: Wer sich gegen SharePoint als Website entscheidet, entscheidet sich nicht gegen Microsoft 365. Die Redaktion arbeitet mit demselben Konto, im selben Rechtekonzept, und die IT behält die Kontrolle. Nur die Website selbst läuft dort, wo sie hingehört.

Wie das in der Praxis aussieht, zeigen unsere Demos: der visuelle Baukasten zum Ausprobieren, der Mängelmelder und die Funktionsübersicht mit Selbstcheck.

Die häufigsten Einwände – und die Antworten

Wofür SharePoint die richtige Wahl ist

Nichts davon spricht gegen SharePoint an sich. Im Haus ist es ein starkes Werkzeug:

• Intranet und Mitarbeitenden-Informationen mit Kommunikationswebsites, News und Zielgruppen
• Dokumentenablage und Zusammenarbeit in Teams, mit Versionen und Berechtigungen
• Abstimmung von Inhalten, bevor sie veröffentlicht werden – etwa Pressemitteilungen oder Satzungsentwürfe
• Wissensbasis für Copilot und andere interne KI-Assistenten

Der bessere Weg ist deshalb nicht „SharePoint oder Web-CMS“, sondern beides – sauber verbunden. Die Redaktion meldet sich im Web-CMS mit ihrem Microsoft-Konto per Single Sign-on an, Entra-Gruppen werden zu Rollen, Formulare und Benachrichtigungen laufen über Exchange Online, und freigegebene Dokumente lassen sich über die Graph-Schnittstelle aus SharePoint übernehmen. Die Website selbst bleibt dabei ein eigenständiges, barrierefreies und datensparsames System.

Was ins Lastenheft gehört

Eine Ausschreibung muss produktneutral sein. Sie dürfen SharePoint also nicht namentlich ausschließen – müssen Sie aber auch nicht. Es genügt, die Anforderungen klar zu beschreiben, die ein öffentlicher Auftritt ohnehin erfüllen muss:

• Öffentlicher Zugriffalle Inhalte ohne Anmeldung und ohne Freigabelinks erreichbar
• Kontrolle über das HTMLAusgabe vollständig durch Auftraggeber bzw. Auftragnehmer steuerbar und vor Updates prüfbar
• BITV 2.0 / WCAG 2.2 AAPrüfbericht vor Abnahme und Prüfung im laufenden Betrieb
• Sprechende Adressenfrei definierbar, 301-Weiterleitungen für alle alten Adressen
• Keine Drittanbieter-Verbindungenim Browser der Besucher*innen, kein Einwilligungsbanner nötig
• Betrieb in Deutschlandmit Wahlfreiheit beim Hosting und Vertrag zur Auftragsverarbeitung
• Trennung vom Verwaltungsnetzöffentliche Auslieferung ohne Verbindung zu internen Systemen
• Anbindung an Microsoft 365Single Sign-on über Entra ID, Mailversand über Exchange Online

Wie ein vollständiges, vergabefähiges Lastenheft aussieht, beschreiben wir im Artikel Website ausschreiben und auf der Seite Lastenheft & Konzept.

Stand: Oktober 2026. Quellen: Microsoft Learn – „SharePoint Online Public Websites to be discontinued“ und „Deprecation of Classic SharePoint Pages“ (Stand August 2026), Microsoft-Lebenszyklusangaben zu SharePoint Server 2016/2019, Warnungen des BSI zu CVE-2025-53770 vom Juli 2025. Microsoft kann Funktionen und Termine ändern; maßgeblich sind die jeweils aktuellen Herstellerangaben.