WordPress an Hochschulen: Warum die Rechtefrage vor der Systemfrage kommt

An Hochschulen teilen sich Fachbereiche, Institute und Pressestelle eine gemeinsame Plattform – einig sind sie sich über ihren Auftritt selten. Wer ein solches System mit WordPress aufsetzt, entscheidet die kritischen Fragen bei Rechtevergabe und Themes lange vor der ersten Zeile Code.

Fachbereiche und Institute teilen sich eine Installation

Eine Hochschul-Plattform ist selten eine einzelne Website. Sie ist ein Geflecht aus Auftritten mit gemeinsamer Dachmarke, aber völlig unterschiedlichen Interessen: die zentrale Hauptdomain mit Studienangebot und Pressebereich, Fachbereiche mit eigenem Profil, Institute mit Drittmittelprojekten sowie Sonderformate für Tagungen und Forschungsverbünde. Rund 2,88 Millionen Studierende in Deutschland nutzen diese digitale Infrastruktur – allein 1,67 Millionen an Universitäten.

Aus dieser Struktur entstehen Anforderungen, die in Unternehmensprojekten selten in dieser Dichte aufeinandertreffen: Dutzende Einheiten publizieren eigenständig, und Zugriffsrechte müssen Personalwechsel schadlos überstehen. Hinzu kommt ein Designsystem, das von Personen bedient wird, die keine Ausbildung in Redaktion oder Gestaltung haben. Und die Barrierefreiheit wird am Ende juristisch belastbar geprüft.

WordPress kann diese Komplexität abbilden. Die eigentliche Arbeit fließt allerdings in das Datenmodell und das Theme – und zwar bevor der erste Inhalt angelegt wird. Gut strukturierte Plattformen wachsen über Jahre problemlos mit. Fehlt dieses Fundament, behelfen sich eure Fachbereiche mit eigenen Schatten-Systemen, sobald die zentrale Vorlage an ihre Grenzen stößt.

Multisite ist kein Rechtemodell

Die technische Basis liefert WordPress Multisite: eine Installation, ein Core, ein Theme-Set, beliebig viele Instanzen. Die organisatorische Logik muss dagegen vor der Installation stehen. Ein Institut, das Forschungsergebnisse veröffentlicht, benötigt direkte Schreibrechte ohne den Umweg über die zentrale Pressestelle. Die Pressestelle wiederum muss die globale Markenführung sichern und schützt zentrale Seitenteile vor ungewollten Anpassungen. Beide Positionen sind berechtigt.

Wenn wir WordPress als Plattform aufsetzen, trennen wir Rechte sauber auf Systemebene: Rechte werden an Netzwerk-Rollen gekoppelt statt an Einzelkonten. Das verhindert verwaiste Zugänge bei Personalwechseln. Globale Seitenelemente wie Header, Footer und das Grundraster sichern wir per templateLock, damit die Layoutstruktur auch bei intensiver Nutzung intakt bleibt.

Für den Redaktionsalltag arbeiten wir mit strukturierten Vorlagen. Wiederkehrende Seitentypen erhalten vordefinierte Block-Patterns, sodass neue Institutsseiten direkt mit einer sauberen Datenstruktur starten. Farben, Typografie und Abstände werden zentral in der theme.json definiert. Das Corporate Design greift dadurch automatisch, ohne dass im Einzelfall nachjustiert werden muss.

Dass solche Strukturen auch bei hohem Volumen stabil skalieren, zeigt unsere Arbeit für das Lernstudio Barbarossa: Dort laufen 165 Standorte über eine zentrale Plattform mit 22.000 neu strukturierten Seiten. Die technische Mechanik ist identisch – an Hochschulen kommen lediglich dezentrale Budgets und komplexe Abstimmungsprozesse als organisatorische Komponente hinzu.

Barrierefreiheit entsteht im Theme

Welche gesetzliche Vorgabe für euch gilt, entscheidet eure Rechtsabteilung: Bundesbehörden unterliegen der BITV, Landeshochschulen dem jeweiligen Landesrecht, und für kostenpflichtige Services wie Ticketing oder Webshops greift das Barrierefreiheitsstärkungsgesetz (BFSG). Für die technische Umsetzung ist die Lage übersichtlich: Alle Vorgaben verweisen auf dieselbe europäische Norm, die EN 301 549.

Der maßgebliche Teil der Barrierefreiheit wird direkt im Theme gelöst. Wir verankern die korrekte Überschriftenhierarchie fest in den Block-Templates, damit sie im Redaktionsalltag nicht aus optischen Gründen übergangen wird. Kontrastwerte hinterlegen wir direkt in der theme.json. Fokusreihenfolge, Tastaturnavigation, sichtbare Fokusringe und ARIA-Labels für Formularfelder werden nativ im Template umgesetzt. Das entlastet eure Redaktion von technischen Entscheidungen.

Overlay-Widgets, die sich per JavaScript über bestehende Seiten legen, versprechen oft eine schnelle Abkürzung. In echten Audits bestehen sie jedoch selten: Sie kaschieren lediglich Symptome und erzeugen häufig neue Fehler im Screenreader-Test. Wie Barrierefreiheit sauber im Designsystem gelöst wird, zeigt der Relaunch für die ABG Frankfurt Holding – eine kommunale Gesellschaft mit ebenso strengen Prüfkriterien.

Das Lastenheft legt die Norm fest

Bei europaweiten Vergabeverfahren ab dem Schwellenwert von 216.000 Euro erhält das Lastenheft juristisches Gewicht: Die Leistungsbeschreibung ist der Maßstab, an dem ihr später abnehmt. Für die Web-Plattform entscheidet hier oft ein einziger Satz über den Prüfmaßstab.

Verbindlich ist aktuell die EN 301 549 in der Version V3.2.1 (basierend auf WCAG 2.1, Stufe AA). Die neuere Version 4.1.1 (mit Bezug auf WCAG 2.2) ist zwar veröffentlicht, aber nicht zwingend im Amtsblatt der EU referenziert. Zwischen Ausschreibung und Abnahme kann sich der geforderte Standard somit verschieben – während Theme und Block-Bibliothek bereits entwickelt sind.

Eine Formulierung, die V3.2.1 als Pflichtstandard festlegt und V4.1.1 als definierte Option berücksichtigt, schafft hier Rechtssicherheit. Der Mehraufwand in der Entwicklung ist gering, da die Zusatzkriterien der WCAG 2.2 (etwa Klickbereichsgrößen und Fokus-Visualisierung) ohnehin im Template gelöst werden. Unkonkrete Formulierungen wie „in der jeweils aktuellen Fassung“ bergen dagegen Konfliktpotenzial bei der finalen Abnahme.

Auch das Backend entscheidet über die Inhalte

In diesem Punkt unterscheiden sich Hochschulen grundlegend von Unternehmensprojekten: Im Unternehmen gibt es feste Online-Redaktionen mit klaren Stellenanteilen. An Hochschulen verteilt sich die Inhaltspflege auf Professuren, Institute, Studiengangskoordinationen und die Pressestelle. Für die meisten Beteiligten ist die Website eine Nebenaufgabe.

Jede Hürde im WordPress-Backend wirkt sich daher direkt auf die Aktualität der Website aus. Eine leere Eingabemaske führt zu unvollständigen Seiten. Vorkonfigurierte Block-Patterns für Institutsseiten, Forschungsprojekte, Personenprofile oder Veranstaltungen werden hingegen verlässlich genutzt, da der Aufwand auf das Reineingeben der Daten reduziert wird.

Nachhaltige Governance erfordert oft überraschend wenig Mechanik: Eine benannte verantwortliche Person pro Einheit, redaktionelle Workflows im Semesterrhythmus statt in starren Projektintervallen sowie eine Nachschulung, die ihr sechs Monate nach dem Launch wiederholt, um die Fluktuation in den Fachbereichen aufzufangen.

Die Größe trennt WordPress von TYPO3

Eine Erhebung auf den Hauptdomains von 420 deutschen Hochschulen zeigte eine klare Verteilung: Rund 53 Prozent nutzten TYPO3, etwa 11 Prozent WordPress. Auch wenn automatisierte Abfragen Unterauftritte nicht vollständig erfassen, spiegelt das Verhältnis die Anforderungen in öffentlichen Ausschreibungen wider.

Für diese Aufteilung gibt es nachvollziehbare Gründe: TYPO3 bietet eine native Mandantenfähigkeit, tief verschachtelte Rechtestrukturen und verlässliche Long-Term-Support-Zyklen. Eine Volluniversität mit zahlreichen Fakultäten, mehrsprachigen Verwaltungsprozessen und komplexer Hierarchie ist ein klassisches TYPO3-Szenario. Das empfehlen wir auch als WordPress-Agentur und arbeiten für solche Fälle innerhalb der Friends Digital Group eng mit Friendventure als zertifiziertem TYPO3 Solution Partner zusammen.

WordPress spielt seine Stärken dort aus, wo klar umrissene Einheiten, hohe Veröffentlichungsfrequenzen und Anbindungen an CRMs, Veranstaltungskalender oder Forschungsdatenbanken gefordert sind: Fachbereiche mit eigenem Profil, An-Institute, Weiterbildungszentren oder Sonderforschungsbereiche. Hier zahlt sich die flache Lernkurve aus, weil neue Bearbeiter ohne lange Einarbeitung publizieren können.

Beide Systeme verlangen dieselbe Hausaufgabe vorab: Wenn ihr im Vorfeld klärt, wer was veröffentlichen darf, wie strikt das Designsystem vorgegeben wird und wie der redaktionelle Betrieb nach dem Go-Live aussieht, habt ihr die Systemfrage meist schon beantwortet.

Weitere Themen zum Weiterlesen

Wie wir skalierbare Plattformen technisch umsetzen – von Custom Design Systems über API-Schnittstellen bis hin zu geschützten Nutzerbereichen – findet ihr auf unserer Seite zur WordPress-Agentur. Technische Details zu Datenmodellen und Block-Systemen beschreiben wir im Artikel zur WordPress Architektur. Einen direkten Systemvergleich bietet unser Beitrag Open Source CMS.