Kann ein Self-Service-Website-Baukasten für Unternehmen die Rechteverwaltung einer offiziellen Website erfüllen?

Ob dies erfüllt werden kann, hängt davon ab, ob das System lediglich „Backend-Konten“ oder ein tatsächlich umsetzbares Berechtigungssystem bereitstellt. Unternehmenswebsites benötigen in der Regel kein so komplexes Berechtigungsmodell wie Geschäftssysteme. Sobald jedoch mehrere Abteilungen zusammenarbeiten, mehrsprachige Inhalte verwaltet werden, externe Dienstleister eingebunden sind, Werbe-Landingpages genutzt werden und Kundendaten verarbeitet werden, geraten einfache zweistufige Konten für Administratoren und Redakteure schnell außer Kontrolle.

Bei der Bewertung eines Enterprise-Self-Service-Website-Baukastens für Unternehmenswebsites sollte die Berechtigungsverwaltung nicht nur daran gemessen werden, ob mehrere Konten erstellt werden können. Entscheidend ist, ob Berechtigungen Inhalte, Websitestruktur, Veröffentlichungsprozesse, Marketingdaten und risikoreiche Vorgänge abdecken können. Das System sollte verschiedenen Personen ermöglichen, ihre Aufgaben innerhalb ihres jeweiligen Verantwortungsbereichs zu erledigen und zugleich verhindern, dass Seiten versehentlich gelöscht, fehlerhafte Inhalte veröffentlicht, Anfragedaten offengelegt oder der Suchtraffic beeinträchtigt werden.

Zunächst unterscheiden: Kontenstaffelung ist nicht gleich Berechtigungsverwaltung

Viele Website-Baukastenprodukte unterstützen die beiden Rollen „Administrator“ und „Redakteur“. Damit lassen sich jedoch nur grundlegende Probleme der Zusammenarbeit lösen. Administratoren verfügen über sämtliche Funktionen, Redakteure können die meisten Seiten bearbeiten. Für repräsentative Unternehmenswebsites mit wenigen Seiten, die langfristig von ein oder zwei Personen gepflegt werden, kann diese Methode ausreichend sein. Sobald die Website jedoch der internationalen Kundengewinnung, der Veröffentlichung von Produktinformationen oder dem Betrieb mehrsprachiger Inhalte dient, reicht sie für eine stabile Verwaltung nicht mehr aus.

Was Unternehmen tatsächlich kontrollieren müssen, ist nicht „wer sich anmelden darf“, sondern „wer welche Aktionen an welchen Objekten ausführen darf“. Beispielsweise können Marketingmitarbeiter Kampagnen-Landingpages erstellen, sollten jedoch nicht die globale Navigation der gesamten Website ändern dürfen. Regionale Teams im Ausland können Inhalte in der lokalen Sprache pflegen, dürfen jedoch die englische Hauptwebsite des Hauptsitzes nicht überschreiben. Inhaltsredakteure können Artikel zur Prüfung einreichen, doch die Veröffentlichung sollte vom Markenverantwortlichen oder dem Plattformverantwortlichen bestätigt werden. Externe Dienstleister können bestimmte Website-Module einsehen, sollten jedoch keinen Zugriff auf Formularanfragen und Administratorkonten erhalten.

Daher sollten Berechtigungen bei der Bewertung in vier Dimensionen unterteilt werden: Objektumfang, Aktionsart, Datenumfang und Aktivierungsprozess. Nur wenn diese vier Punkte kombiniert konfigurierbar sind, entspricht die Funktion eher der für Unternehmenswebsites erforderlichen Berechtigungsverwaltung.

Der Schwerpunkt der Berechtigungsverwaltung von Unternehmenswebsites liegt häufig im Veröffentlichungsprozess

Für die meisten Unternehmen sind Veröffentlichungsberechtigungen wichtiger als Bearbeitungsberechtigungen. Fehler bei der Seitenbearbeitung können in der Regel noch im Backend korrigiert werden. Sobald fehlerhafte Inhalte jedoch online sind, können sie von Suchmaschinen indexiert, von Besuchern von Werbeanzeigen gesehen oder auf mehrsprachigen Websites zu fehlerhaften Produkt- und Compliance-Aussagen führen.

Ein praktikabler Prozess sieht üblicherweise so aus: Redakteure erstellen einen Entwurf und reichen ihn ein, Geschäfts- oder Markenverantwortliche prüfen den Inhalt, und eine Rolle mit Veröffentlichungsberechtigung überträgt den Inhalt auf die Live-Website. Dabei sollten insbesondere zwei Details geprüft werden.

Erstens: Bezieht sich die Prüfung auf eine „konkrete Version“? Wenn Redakteure dieselbe Seite nach der Einreichung zur Prüfung weiter bearbeiten können, stimmen die vom Prüfer bestätigten Inhalte möglicherweise nicht mit den letztlich veröffentlichten Inhalten überein. Ein zuverlässigeres System behält den Versionsstatus bei oder verlangt, dass Änderungen erneut in die Prüfung gehen.

Zweitens: Werden Wiederherstellung und Versionshistorie unterstützt? Bei einem Website-Relaunch, dem Austausch von Produktinformationen oder der Anpassung von Seitentemplates ist es besonders problematisch, wenn bei Fehlern keine schnelle Wiederherstellung möglich ist. Aus der Versionshistorie sollte zumindest hervorgehen, wer wann was geändert hat, und sie sollte die Wiederherstellung einer zuvor nutzbaren Version ermöglichen. Wenn lediglich Anmeldeprotokolle, nicht jedoch Inhaltsänderungen aufgezeichnet werden, ist ihr Nutzen für die Fehleranalyse begrenzt.

Mehrsprachige Websites dürfen nicht allein durch „Kopieren von Seiten“ verwaltet werden

Wenn Außenhandelsunternehmen und international expandierende Marken Self-Service-Website-Baukastensysteme einsetzen, erhöhen mehrsprachige Inhalte die Komplexität der Berechtigungen erheblich. Sprachversionen können Übersetzungen derselben Seite sein, müssen jedoch aufgrund unterschiedlicher Märkte, Produktmodelle, Zertifizierungsdarstellungen und Kontaktdaten möglicherweise auch unabhängig gepflegt werden. Wenn das System alle Sprachseiten in denselben Bearbeitungsbereich legt, können regionale Teams versehentlich Inhalte anderer Märkte ändern, und die Zentrale kann nur schwer feststellen, welche Seiten bereits korrekturgelesen wurden.

Ein geeigneterer Ansatz besteht darin, Sprache, Website oder Region als berechtigungsfähige Objekte zu behandeln: Die Zentrale behält die Kontrolle über Templates, globale Komponenten, Domainkonfigurationen und Markenrichtlinien; die regionalen Teams pflegen nur die ihnen zugewiesenen Sprachversionen, Länderwebsites oder Produktkategorien. Bei gemeinsam genutzten Inhalten wie Kopfzeilen, Fußzeilen, Links zu Datenschutzrichtlinien und globalen Formularen muss außerdem klar festgelegt werden, ob sie einheitlich von der Zentrale veröffentlicht werden oder lokale Überschreibungen zulässig sind.

Ein in technischen Bewertungen leicht zu übersehender Punkt ist, ob Übersetzungsberechtigungen und Veröffentlichungsberechtigungen voneinander getrennt sind. Übersetzer können Übersetzungen eingeben oder ändern, was nicht bedeutet, dass sie diese direkt online veröffentlichen sollten. Insbesondere bei technischen Parametern, Preisangaben, Kundendienstzusagen oder Werbetexten bedeutet sprachliche Korrektheit nicht automatisch, dass die geschäftliche Aussage veröffentlicht werden darf.

Zugriffsrechte für Marketingtools und das Website-Backend nicht vermischen

Integrierte Plattformen für Website- und Marketingservices verbinden häufig gleichzeitig Formulare, SEO-Tools, Werbekanäle, Social-Media-Konten und Datenanalysen. Diese Integration kann Wechselvorgänge reduzieren, erfordert jedoch klarere Berechtigungsgrenzen. Website-Redakteure müssen nicht unbedingt Werbebudgets einsehen können, und Social-Media-Operatoren sollten nicht zwangsläufig Berechtigungen für Website-Code, Domains oder Zahlungskonfigurationen besitzen.

Bei der Bewertung können insbesondere folgende Fragen gestellt werden:

• Können Zugriffsrechte auf Formularanfragen nach Website, Formular oder Verantwortlichem zugeteilt werden, und wird der Export kontrolliert?
• Sind SEO-Einstellungen wie Titel, Weiterleitungen, Sitemaps, robots-Regeln und strukturierte Daten von den gewöhnlichen Bearbeitungsberechtigungen für Textinhalte getrennt?
• Können Werbe-Landingpages von Mitarbeitern für die Anzeigenschaltung gepflegt werden, während deren Änderungen an globalen Modulen der offiziellen Unternehmenswebsite eingeschränkt bleiben?
• Kann nach Beendigung der Zusammenarbeit mit einem Drittanbieter dessen Konto einzeln deaktiviert, die Berechtigung entzogen und ein Aktivitätenprotokoll beibehalten werden?
• Sind risikoreiche Funktionen wie Domains, DNS, Code-Injektion, Zahlungskonfigurationen und Datenexport nur wenigen kontrollierten Rollen zugänglich?

Insbesondere Code-Injektion und Weiterleitungskonfigurationen sollten separat eingeschränkt werden. Sie werden häufig für Statistikskripte, die Einbindung von Marketingtools und Seitenmigrationen verwendet, doch Konfigurationsfehler können zu Seitenfehlern, Problemen bei der Suchindexierung oder sogar zur Einbindung ungeprüfter Drittanbieter-Skripte führen. Solche Funktionen in gewöhnliche Rollen zur Inhaltsbearbeitung einzubinden, ist ein häufiger Fehler bei der Gestaltung von Berechtigungen für Unternehmenswebsites.

Die Granularität von Berechtigungen ist nicht umso besser, je feiner sie ist

Je feiner Berechtigungen aufgeteilt sind, desto präziser ist die Kontrolle, aber desto höher sind auch Konfigurations- und Wartungsaufwand. Wenn jede Kategorie, Komponente und jedes Feld einzeln berechtigt werden muss, erstellen Administratoren leicht eine große Zahl temporärer Regeln, die nach Personalwechseln noch schwieriger zu überblicken sind. Für Unternehmenswebsites empfiehlt es sich in der Regel, mit einer kleinen Anzahl stabiler Rollen zu beginnen und den Umfang anschließend nach Website und Sprache zu erweitern.

Ein umsetzbares Basismodell kann Folgendes umfassen: Der Plattformadministrator ist für Konten, Domains, Sicherheit und globale Konfigurationen verantwortlich; der Website-Administrator für Struktur und Veröffentlichung einer bestimmten Unternehmenswebsite; der Inhaltsredakteur für Seiten- und Artikelentwürfe; der Prüfer und Veröffentlichungsverantwortliche für die formelle Liveschaltung; der Marketingoperator für autorisierte Landingpages, Formulare und Kampagnendaten; externe Mitwirkende erhalten nur einen zeitlich begrenzten Zugriff auf bestimmte Websites oder Module.

Ob das System benutzerdefinierte Rollen unterstützt, ist nicht das einzige Kriterium. Wichtiger ist, ob die Standardrollen die bestehende Arbeitsteilung des Unternehmens abdecken und ob bei der Hinzufügung neuer Berechtigungen klar erkennbar ist, welche Websites, Daten und Vorgänge davon betroffen sind. Für kleinere Teams sind wenige Rollen mit klaren Grenzen in der Regel langfristig leichter umzusetzen als ein Berechtigungssystem mit komplexen Funktionsbezeichnungen.

Bei der technischen Bewertung empfiehlt sich eine Abnahme anhand realer Szenarien

Dass in einer Produktdemonstration „mehrere Rollen unterstützt“ werden, beweist nicht, dass die Berechtigungen die Anforderungen erfüllen. Die Prüfung sollte anhand von Kooperationsszenarien erfolgen, die dem späteren Live-Betrieb nahekommen, statt lediglich die Seite zur Berechtigungskonfiguration zu betrachten. Der Anbieter kann in einer Testumgebung einige Vorgänge durchführen: ein Konto erstellen, das nur chinesische Produktseiten bearbeiten darf; dieses Konto versuchen lassen, englische Seiten, die globale Navigation und SEO-Weiterleitungen zu ändern; einen prüfungsbedürftigen Artikel einreichen; die Veröffentlichung und Wiederherstellung einer Version durch eine andere Rolle veranlassen; nach dem Entzug eines Kontos bestätigen, dass dieses weder weiter auf das Backend zugreifen noch Anfragen exportieren kann.

Eine solche Prüfung zeigt direkt, ob Berechtigungen nur auf der Benutzeroberfläche verborgen werden oder ob sie im Backend tatsächlich wirksam eingeschränkt sind. Bei Ersterem sind Menüs oft nicht sichtbar, aber der Zugriff ist möglicherweise weiterhin über Links, Schnittstellen oder freigegebene Ressourcen möglich; bei Letzterem sollten an allen Zugriffspunkten dieselben Autorisierungsregeln gelten.

Bei Enterprise-Website-Plattformen auf Cloud-SaaS-Basis sollte außerdem geprüft werden, ob der Kontolebenszyklus vollständig abgedeckt ist: Können Konten beim Ausscheiden von Mitarbeitern, bei Positionswechseln oder nach Ende einer externen Zusammenarbeit schnell deaktiviert werden? Wird ein einheitliches Identitätsmanagement unterstützt oder zumindest eine zuverlässige Kontoverwaltung bereitgestellt? Werden kritische Vorgänge in Auditprotokollen festgehalten? Berechtigungsverwaltung ist keine einmalige Konfiguration, sondern ein Mechanismus, der zusammen mit Veränderungen bei Personal und Geschäft kontinuierlich gepflegt werden muss.

Wann ein Self-Service-Website-Baukastensystem nicht ausreicht

Wenn ein Unternehmen nur Inhaltszusammenarbeit, abgestufte Veröffentlichung und grundlegende Datentrennung benötigt, kann ein Self-Service-Website-Baukastensystem mit Rollen-, Freigabe-, Versions- und Protokollfunktionen die Verwaltungsanforderungen einer Unternehmenswebsite in der Regel erfüllen. Bei Plattformen wie Yiyingbao, die auf mehrsprachige Unternehmenswebsites, eigenständige Websites für Auslandsmärkte und Marketing-Kollaborationsszenarien ausgerichtet sind, sollte bei der Bewertung besonders darauf geachtet werden, ob zwischen Websites, Sprachversionen, Inhaltsveröffentlichung und Marketingdaten klare Berechtigungsgrenzen geschaffen werden können, statt die Entscheidung allein anhand der Geschwindigkeit beim Website-Aufbau oder der Anzahl der Templates zu treffen.

Wenn die Unternehmenswebsite jedoch tief mit internen Stammdaten, Händlerportalen, komplexen Mitgliedersystemen, regulierten Dokumentenarchiven oder stark individualisierten Workflows verbunden werden muss, reicht das native Berechtigungsmodell eines Website-Baukastensystems möglicherweise nicht aus. In diesem Fall sollte erwogen werden, es durch ein einheitliches Identitätsmanagement, eine Schnittstellenschicht oder ein spezialisiertes Content-Management- und Berechtigungssystem zu ergänzen, anstatt im Website-Backend fortlaufend Ausnahmekonten hinzuzufügen.

Die abschließende Beurteilung lässt sich in einem Satz zusammenfassen: Das System sollte den richtigen Personen ermöglichen, ihre Arbeit im richtigen Umfang zu erledigen, und gleichzeitig risikoreiche Vorgänge prüfbar, nachvollziehbar und widerrufbar machen. Erst ein Enterprise-Self-Service-Website-Baukastensystem, das dies leisten kann, ist nicht nur ein praktisches Werkzeug zum Aufbau einer Unternehmenswebsite, sondern kann auch Verantwortung für die Berechtigungsverwaltung im laufenden Betrieb übernehmen.