HTML-Seiten in SharePoint oder SPFx-Apps? Was welcher Ansatz kann und wo er endet

In unseren Monatsüberblicken haben wir HTML-Seiten in SharePoint schon mehrfach erwähnt – unter anderem als Neuerung, die eingeschaltet ist und sich nicht für den ganzen Mandanten abschalten lässt. Jetzt gehen sie in die allgemeine Verfügbarkeit, und mit ihnen kommt eine Frage, die wir von Kunden immer häufiger hören: Wenn Copilot in einer Minute eine ansprechende interaktive Seite mit Diagrammen schreibt – wozu brauchen wir dann noch Apps?

Die Frage ist berechtigt. HTML-Seiten können tatsächlich Dinge, für die man früher einen Entwickler brauchte. Sie haben aber auch Grenzen, die auf den ersten Blick nicht sichtbar sind – und manche zeigen sich erst nach einem halben Jahr, wenn es fünfzig Seiten gibt und jede ein bisschen anders aussieht. Dieser Artikel vergleicht beide Ansätze: HTML-Seiten auf der einen Seite und Apps auf Basis des SharePoint Framework (SPFx) – derselben Grundlage, auf der wir unsere EasyPortal 365 Apps bauen – auf der anderen.

Was HTML-Seiten in SharePoint sind

Microsoft hat die Funktion am 25. September 2026 angekündigt (MC1479517). Die Vorschau läuft seit Oktober, die allgemeine Verfügbarkeit wird von Mitte November bis Ende Dezember 2026 ausgerollt. Kurz gefasst:

• Wie eine Seite entsteht: über + Neu → HTML-Seite, mit der schwebenden Copilot-Schaltfläche auf der Website oder durch Hochladen einer fertigen .html-Datei (auch eines ganzen Ordners) in die Bibliothek „Websiteseiten“ (Site Pages).
• Wo sie liegt: in der Bibliothek Site Pages neben den normalen modernen Seiten. Es gelten Berechtigungen der Website, Aufbewahrung, Entwurf und Veröffentlichung, Genehmigung, geplante Veröffentlichung und Analysen. Sie wird mit Kopfzeile, Navigation und Fußzeile der Website angezeigt.
• Wie sie dargestellt wird: der Inhalt läuft in einem isolierten Rahmen (Sandboxed iframe) mit Regeln der Content Security Policy. Die Seite ist vom Rest von SharePoint getrennt.
• Lizenz: eine Microsoft 365 Copilot-Lizenz ist nur für das Erstellen und Bearbeiten mit Copilot nötig. HTML hochladen, Text bearbeiten, veröffentlichen und lesen kann jeder mit der passenden Berechtigung – ohne Lizenz.
• Verwaltung: die Funktion ist standardmäßig eingeschaltet und lässt sich nur auf einzelnen Websites abschalten – Details im nächsten Abschnitt.

Wann Sie die Funktion bekommen und wie Sie sie abschalten

Nicht alle bekommen sie gleichzeitig. Microsoft rollt die Funktion schrittweise nach Mandanten aus. Seit Oktober haben sie Organisationen im Frontier-Programm und mit gezielter Veröffentlichung (Targeted Release); alle anderen bekommen sie mit der allgemeinen Verfügbarkeit – laut Ankündigung von Mitte November bis Ende Dezember 2026, laut einer späteren Antwort von Microsoft in der Diskussion kann sich der Rollout bis Anfang 2027 ziehen. Ob Ihr Mandant sie schon hat, sehen Sie auf jeder beliebigen Website: In der Bibliothek Site Pages erscheint unter Dateitypen der Schalter HTML-Dateien zulassen, und beim Hochladen gibt es die Option HTML-Seite hochladen. (Das Erstellen über + Neu → HTML-Seite knüpft Microsoft an eine Copilot-Lizenz, ohne sie ist auf diesen Menüeintrag kein Verlass.)

Sobald Ihr Mandant sie bekommt, ist sie auf allen Websites eingeschaltet. Niemand muss sie aktivieren. Hochladen und veröffentlichen kann dann jeder, der auf der Website Seiten bearbeiten darf. Mit Copilot erstellen kann nur, wer eine Copilot-Lizenz hat.

Abschalten lässt sie sich nur Website für Website. Auf jeder Website einzeln öffnet der Websitebesitzer die Bibliothek Site Pages, wählt Dateitypen (File types) und schaltet HTML-Dateien zulassen (Allow HTML files) aus. Damit verschwinden das Hochladen von HTML und der Eintrag im Menü + Neu. Für den ganzen Mandanten lässt sich die Funktion weder abschalten noch einschränken, und Microsoft schrieb in der Diskussion, dass das vorerst so bleibt. Den Zustand einzelner Websites prüfen Administratoren mit PnP PowerShell (Get-PnPFeature, Feature HtmlPages). Ein Abschalten für viele Websites auf einmal beschreibt Microsoft nicht.

Der Schalter ist noch nicht dicht. Unabhängige Tests nach dem Start haben gezeigt, dass Copilot auf einer Website mit abgeschaltetem Schalter weiterhin HTML-Seiten erstellte. Ein Nutzer berichtete in der Diskussion zudem, dass Hochladen und Verschieben von Dateien weiter funktionierten. Microsoft antwortete, dass der Copilot-Fall untersucht wird und dass Hochladen und Verschieben bei abgeschaltetem Schalter blockiert sein sollen. Bis das behoben ist, ist der Schalter auf der Website keine verlässliche Grenze.

Was in einer HTML-Seite funktioniert – und was nicht

Hier liegt der Kern des Vergleichs. Die Sandbox ist gut für die Sicherheit, legt aber zugleich genau fest, was eine Seite kann. Laut Microsoft-Dokumentation und ausführlichen Tests aus der Community:

Funktioniert	Funktioniert nicht
eigenes JavaScript direkt in der Datei	Skripte und Styles von anderen Adressen (CDN, <link> auf CSS, Google Fonts)
fünf Bibliotheken aus dem Microsoft-CDN: Chart.js, Mermaid, React, Fluent UI, Babylon	jeglicher API-Aufruf – fetch, SharePoint REST, Microsoft Graph
Animationen, Canvas, SVG, dunkler Modus per CSS	Cookies, localStorage, IndexedDB – die Seite merkt sich nichts
Lesen einer Datei, die der Nutzer auf seinem Computer auswählt	Formular absenden, Datei herunterladen, Druck-Schaltfläche (Drucken über den Browser funktioniert)
Live-Daten zum Lesen aus SharePoint-Listen, Excel und CSV	irgendetwas irgendwohin schreiben
Links innerhalb des Mandanten, externe Links auf zugelassene Domänen	mailto:, tel:, eingebettetes Video, Frames (YouTube, Stream)
Bilder aus dem eigenen Mandanten oder direkt in die Datei eingebettet	Bilder von fremden Websites, SharePoint-Webparts

Die wichtigste Zeile ist die über Daten. Live-Daten funktionieren so, dass die Seite ihre Quellen vorab benennt (eine Liste, eine Excel-Arbeitsmappe, eine CSV-Datei) und SharePoint sie beim Öffnen der Seite lädt und übergibt. Die Seite selbst greift nirgendwohin. Es ist ein Schnappschuss zum Lesen: Was sich in der Liste ändert, während der Nutzer die Seite geöffnet hat, erscheint erst nach dem Aktualisieren. Etwas zurückschreiben – einen Antrag genehmigen, einen Eintrag hinzufügen, ein Formular speichern – kann eine HTML-Seite nicht.

Zwei Details aus den Tests sind gut zu wissen. Erstens werden aus einer Liste alle Spalten an den Browser gesendet, auch die, die die Seite nicht anzeigt – in einem Test 85 Spalten statt der etwa zwölf tatsächlich genutzten. Zweitens indiziert die SharePoint-Suche nur Text, der direkt in der HTML-Datei steht. Was ein Skript darstellt – Diagramme, Tabellen, Zahlen aus Live-Daten – sieht die Suche nicht.

Was eine App auf Basis des SharePoint Framework ist

Das SharePoint Framework ist das Modell, das Microsoft für die Erweiterung von SharePoint, Teams und Viva Connections empfiehlt. Eine SPFx-App ist ein gepacktes Programm (Webparts, Erweiterungen), das ein Administrator im App-Katalog genehmigt und das dann auf SharePoint-Seiten, als Registerkarte in Teams, in Viva Connections und neu auch als Komponenten in Copilot läuft.

Der entscheidende Unterschied zu HTML-Seiten: Eine SPFx-App läuft im Kontext des angemeldeten Nutzers und verfügt über Clients, die für ihn die Anmeldung bei SharePoint, Microsoft Graph und weiteren durch Microsoft Entra ID geschützten APIs übernehmen. Sie kann also lesen und schreiben – immer nur dort, wo der Nutzer Berechtigungen hat, und auf APIs außerhalb von SharePoint nur mit Berechtigungen, die ein Administrator genehmigt.

Die Kehrseite: Eine SPFx-App schreibt Copilot nicht in einer Minute. Sie braucht einen Entwickler, einen Build mit Node.js und TypeScript, Tests, die Bereitstellung im App-Katalog und eine Versionsverwaltung. Und weil sie nicht in einer Sandbox, sondern direkt in der Seite läuft, entscheidet der Administrator über das Vertrauen, indem er die App genehmigt.

Vergleich Punkt für Punkt

	HTML-Seite	SPFx-App
Wer sie erstellt	jeder mit dem Recht, Seiten zu bearbeiten; mit Copilot auch ohne HTML-Kenntnisse	ein Entwickler
Wie lange es dauert	Minuten bis Stunden	Tage bis Wochen
Freigabe durch die IT	keine (auf Mandantenebene auch nicht erzwingbar)	der Administrator genehmigt App und API-Berechtigungen
Daten	nur lesen, Schnappschuss beim Öffnen; Listen, Excel, CSV	lesen und schreiben; SharePoint, Graph, eigene APIs
Wer der Nutzer ist	die Seite weiß es nicht	die App kennt den Nutzer, seine Rollen und Gruppen
Gedächtnis	keines – jeder Besuch beginnt neu	Listen, Einstellungen, Verlauf, Arbeitsstand
Aussehen	was in der Datei steht; Änderungen am Website-Design werden nicht übernommen	folgt dem Design und gemeinsamen Komponenten
Aktualisierung	jede Seite einzeln	eine Veröffentlichung wirkt überall, wo die App läuft
Teams und Smartphone	in der Teams-Desktop-App ja; in den mobilen Apps von Teams und SharePoint noch nicht	Webparts in Teams, Viva Connections, mobile Ansicht
Suche	nur der statische Text der Datei	je nachdem, wo die App Daten speichert (Listen und Bibliotheken werden indiziert)
Sicherheit	Sandbox – die Seite kann keine APIs aufrufen, keine Formulare senden und nichts speichern	voller Zugriff im Rahmen der Nutzerberechtigungen; Vertrauen über Genehmigung durch den Administrator
Lizenz	Copilot nur für das Erstellen mit Copilot	je nach App-Anbieter

Wo HTML-Seiten stark sind

Es wäre ein Fehler, sie zu unterschätzen. Für viele Szenarien sind sie die bessere Wahl als eine App und sogar als eine normale moderne Seite:

• Tempo und gestalterische Freiheit. Eine Zeitleiste für das Onboarding neuer Kollegen, eine Projektübersicht mit Diagrammen, ein visueller Markenleitfaden, eine Microsite zu einer Veranstaltung – all das entsteht an einem Nachmittag und kann genau so aussehen wie gewünscht, ohne Beschränkung auf Abschnitte und Webparts.
• Interaktive Hilfsmittel. Ein Rechner, eine Checkliste, ein interaktives Prozessdiagramm oder die Prüfung einer CSV-Datei vor dem Import. Alles läuft im Browser, nichts verlässt den Computer des Nutzers.
• Übersichten über Daten, die schon in SharePoint liegen. Ein Diagramm aus einer Liste oder aus Excel, das sich bei jedem Öffnen aktualisiert – ohne Power BI und ohne Entwickler.
• Weiterverwendung von vorhandenem HTML. Berichtsexporte, statische Seiten aus alten Systemen, Ausgaben anderer Werkzeuge – hochladen und fertig.
• Sicherheit von Grund auf. Weil die Seite keine APIs aufrufen und keine Formulare senden kann, ist das Risiko durch schlecht geschriebenen Code deutlich kleiner als bei den alten Skript-Editoren, die diese Grenzen nicht hatten.

Schwächen: Standardisierung, Pflege und Governance

Das ist es, was in der Begeisterung über das Tempo leicht untergeht. Keine dieser Schwächen ist ein Fehler – sie ergeben sich direkt daraus, dass jede HTML-Seite eine eigenständige, geschlossene Datei ist.

Jede Seite ist ein Unikat. Copilot schreibt eine Seite nach der Vorgabe und nach dem, was ihm gerade „einfällt“. Ein zweiter Autor auf der Nachbarwebsite bekommt andere Farbtöne, andere Schriften, andere Abstände und eine Tabelle, die sich anders verhält. Moderne Seiten bleiben dank Design und Webparts einheitlich, Apps dank gemeinsamer Komponenten. HTML-Seiten haben keine solche gemeinsame Grundlage – die Einheitlichkeit hängt von jedem Autor einzeln ab.

Das Aussehen friert im Moment der Erstellung ein. Farben und Schriften werden beim Erstellen in die Datei geschrieben. Ändert das Unternehmen das Website-Design oder seine Firmenfarben, ändern sich bestehende HTML-Seiten nicht. Microsoft nennt das eine bekannte Einschränkung „ohne Zusage“ einer Lösung. Hochgeladenes HTML bekommt das Firmendesign ohnehin nicht automatisch. Nach einem Rebranding muss jede Seite von Hand angepasst werden.

Code lässt sich nicht teilen. Weder Styles noch Bibliotheken lassen sich aus einer gemeinsamen Datei laden – ein <link> auf CSS in Site Assets funktioniert laut Tests nicht, alles muss direkt in der Datei stehen. Einen Fehler in einer Tabelle zu beheben, die dreißig Seiten verwenden, heißt dreißig Dateien zu korrigieren. Bei einer App genügt eine Veröffentlichung.

Barrierefreiheit ist nicht garantiert. Microsoft gibt an, dass von Copilot erstellte Seiten die Anforderungen an Barrierefreiheit automatisch erfüllen – bei hochgeladenem HTML aber nicht. Die Prüfung von Überschriften, Kontrast, Bildbeschreibungen und Tastaturbedienung bleibt beim Autor.

Pflege nach dem Weggang des Autors. Eine moderne Seite bearbeitet jeder, der den Editor kennt. Eine HTML-Seite mit Skripten bearbeitet sicher nur, wer den Code versteht, oder Copilot – und das nur für Nutzer mit Lizenz. Tests haben außerdem gezeigt, dass das Bearbeiten einer Seite mit Skripten im visuellen Editor die Skripte beschädigen kann.

Es fehlt, was ein Intranet üblicherweise braucht. Eine HTML-Seite kann nicht als News hervorgehoben werden, hat keine Kommentare oder Reaktionen, lässt sich nicht als Vorlage speichern, kennt keine Zielgruppenadressierung und keine mehrsprachigen Versionen und wird in den mobilen Apps von SharePoint und Teams noch nicht angezeigt (laut Microsoft folgt das in einer späteren Welle).

Governance ohne zentralen Schalter. Die Funktion ist eingeschaltet, lässt sich auf Mandantenebene nicht abschalten, und der Schalter auf der Website stoppt laut Tests Copilot noch nicht. Wer den Überblick behalten will, muss ihn über Regeln und Inhaltskontrolle bekommen, nicht über eine Einstellung.

Wann was passt

Eine HTML-Seite ist die richtige Wahl, wenn:

• es um Präsentation geht, nicht um die Arbeit mit Daten – Inhalte werden gelesen, nicht geschrieben,
• die Seite einmalig oder kurzlebig ist – Veranstaltung, Kampagne, Projekt, Onboarding,
• Daten zum Lesen aus einer Liste, aus Excel oder CSV genügen,
• die Gestaltung wichtiger ist als die Einheitlichkeit mit anderen Seiten,
• es wenige Seiten werden, nicht Hunderte.

Eine SPFx-App ist die richtige Wahl, wenn:

• der Nutzer etwas erledigen soll – ausfüllen, genehmigen, buchen, melden, bestellen,
• die App wissen muss, wer der Nutzer ist, und ihm je nach Rolle anderes zeigt,
• Daten geschrieben werden oder zwischen Besuchen erhalten bleiben sollen,
• dieselbe Funktion auf vielen Websites läuft und überall gleich aussehen und funktionieren muss,
• Teams, Smartphone oder eine Anbindung an Microsoft Graph (E-Mail, Kalender, Profile) nötig sind,
• die Lösung langfristig leben, aktualisiert werden und einen klaren Verantwortlichen haben soll.

Die moderne Seite bleibt die Standardwahl für normale Intranet-Inhalte – News, Abteilungsseiten, Anleitungen. Sie ist einheitlich, jeder kann sie bearbeiten, und sie übernimmt das Design.

Die Ansätze schließen sich zudem nicht aus. Eine sinnvolle Aufteilung: moderne Seiten für Inhalte, Apps für die Arbeit und HTML-Seiten für das, was vor allem gut aussehen und schnell entstehen soll.

Wie Sie im Unternehmen mit HTML-Seiten umgehen

Da die Funktion bereits eingeschaltet ist, lohnt es sich, zu entscheiden, bevor die ersten hundert Seiten entstehen:

1. Legen Sie fest, wo HTML-Seiten sinnvoll sind. Auf den Hauptwebsites des Intranets ist es vernünftig, sie abzuschalten (und zu prüfen, ob das wirklich auch für Copilot gilt); auf Projekt- und Teamwebsites können Sie sie belassen.
2. Stellen Sie eine freigegebene Startvorlage bereit. Eine HTML-Datei mit Firmenfarben, Schriften und Grundelementen, von der Autoren und Copilot ausgehen. Tests haben gezeigt, dass Copilot einen konkreten, in Site Assets gespeicherten Stil genau übernimmt – eine vage Anweisung „passend zum Design“ dagegen nicht.
3. Behalten Sie Domänen und Daten im Blick. Die Liste zugelassener externer Domänen (Websiteeinstellungen → HTML-Feldsicherheit) muss bewusst gepflegt werden. Bei Live-Daten gilt: An den Browser geht die ganze Liste, auch nicht angezeigte Spalten.
4. Bestimmen Sie für jede Seite einen Verantwortlichen. Jemanden, der sie pflegt, wenn sich Daten, Farben oder der Autor ändern.
5. Rechnen Sie mit einem Rebranding. Ändert sich das Firmendesign, gehören HTML-Seiten auf die Liste der Dinge, die von Hand durchgesehen werden müssen.

Wie wir es machen

Unsere EasyPortal 365 Apps bauen wir auf dem SharePoint Framework, und wir sehen HTML-Seiten nicht als Ersatz dafür, sondern als Ergänzung. Der Grund ist die Standardisierung. Alle unsere Apps teilen ein Designsystem und eine Komponentenbibliothek: Tabellen, Formulare, Panels und Kopfzeilen sehen im CRM, in der Dokumentenverwaltung und im Fuhrpark gleich aus und verhalten sich gleich. Eine Korrektur oder Verbesserung in der gemeinsamen Bibliothek nehmen wir einmal vor, und mit der nächsten Veröffentlichung der Apps wirkt sie bei allen Kunden. Die Apps übernehmen die Firmenfarben aus einer zentralen Einstellung, sind auch für das Smartphone ausgelegt (die meisten laufen zudem in Teams), arbeiten mit den SharePoint-Berechtigungen und schreiben Daten in Listen, die sich sichern, durchsuchen und prüfen lassen.

Eine HTML-Seite leistet all das nicht und soll es auch nicht. Für eine schnelle, ansprechende, einmalige Präsentation ist sie aber hervorragend. Deshalb empfehlen wir nicht, sie zu verbieten – nur, ihr einen klaren Platz zu geben.

Das Wichtigste in Kürze

1. HTML-Seiten sind schnell, frei gestaltbar und sicher. Ideal für Präsentationen, Hilfsmittel und Übersichten über Daten zum Lesen.
2. Sie können nicht schreiben, merken sich nichts und wissen nicht, wer zusieht. Für alles, wo der Nutzer etwas erledigt, brauchen Sie eine App.
3. Jede HTML-Seite ist ein eigenständiges Unikat. Ohne Vorlage und Regeln zerfällt das Intranet in Seiten, die jede anders aussehen und nach einer Designänderung einzeln korrigiert werden müssen.
4. Die Funktion ist eingeschaltet und lässt sich auf Mandantenebene nicht abschalten. Es lohnt sich, jetzt zu entscheiden, wo HTML-Seiten entstehen dürfen.

---

Wir helfen Unternehmen, Regeln für das Intranet so aufzusetzen, dass neue Microsoft-Funktionen Nutzen bringen statt Chaos – im Rahmen unseres Governance-Designs. Und wenn Sie Apps suchen, die in SharePoint und Teams einheitlich und langfristig funktionieren, sehen Sie sich die EasyPortal 365 Apps an oder melden Sie sich.

Quellen: Microsoft Message Center MC1479517 (25. 9. 2026); Microsoft Support – Create, upload, edit, and publish HTML pages in SharePoint; Microsoft SharePoint Blog – Publish rich and interactive content with HTML pages in SharePoint (22. 10. 2026, einschließlich der Antworten von Microsoft in der Diskussion); Microsoft Learn – Overview of the SharePoint Framework; unabhängige Tests von Denis Molodtsov – SharePoint HTML pages: what they can and cannot do und Teil 2, Experimente nach GA.