Wenn eine Organisation wie die NASA ihre zentrale Website auf WordPress umstellt, ist das kein Zufall und kein Experiment. Es ist eine bewusste Entscheidung für ein System, das auch unter höchsten Anforderungen funktioniert. Das NASA WordPress steht damit exemplarisch für eine Entwicklung, die viele immer noch unterschätzen: WordPress ist längst im Enterprise angekommen.
Die NASA betreibt eine der meistbesuchten Regierungswebsites der Welt. Millionen Zugriffe, hohe Sicherheitsanforderungen, strenge Barrierefreiheitsvorgaben und komplexe redaktionelle Prozesse gehören zum Alltag. Genau in diesem Umfeld setzt die Behörde heute auf WordPress. Nicht als Blog-System, sondern als skalierbare Plattform für Inhalte, Services und Schnittstellen. Umgesetzt wurde das Projekt gemeinsam mit spezialisierten Partnern wie Lone Rock Point, einer auf Enterprise WordPress fokussierten Agentur aus dem WordPress-VIP-Umfeld.
Für Unternehmen ist das ein wichtiges Signal. Wer WordPress noch als einfache Lösung für kleine Websites einordnet, übersieht, wie flexibel und belastbar das System geworden ist. Richtig umgesetzt, mit sauberer Architektur, klarer Governance und technischer Tiefe, kann WordPress auch komplexe Enterprise-Setups tragen. Genau hier setzt eine spezialisierte WordPress Agentur an, die nicht mit Templates arbeitet, sondern Systeme baut, die wachsen können.
Der Blick auf das NASA WordPress ist deshalb mehr als ein prominentes Beispiel. Er zeigt, wie große Organisationen heute denken: weniger Spezial-CMS, mehr modulare Plattformen. Weniger starre Templates, mehr redaktionelle Freiheit. Und vor allem weniger Technik um der Technik willen. Auch Themen wie E-Commerce oder datengetriebene Inhalte lassen sich auf dieser Basis sauber integrieren, etwa mit Lösungen, wie sie eine erfahrene WooCommerce Agentur umsetzt.
Ausgangslage bei NASA: Warum ein Relaunch nötig wurde
Über Jahrzehnte wuchs die Weblandschaft der NASA organisch. Seit den frühen 1990er-Jahren entstanden hunderte Websites, Subdomains und Microsites. Jede Mission, jedes Forschungszentrum und jede Abteilung betrieb eigene Auftritte, wodurch die technische und redaktionelle Steuerung zunehmend komplex wurde.
Ein zentrales Problem war die Fragmentierung der Inhalte. Themen verteilten sich auf mehrere Domains, während sich die Navigation stark an internen Organisationsstrukturen orientierte. Nutzer fanden gesuchte Informationen deshalb häufig über Suchmaschinen statt über die Website selbst. Für eine Organisation, die als autoritative Quelle wahrgenommen werden muss, war das langfristig nicht tragfähig.
Hinzu kam der technologische Druck. Die zentrale Plattform basierte auf Drupal 7, einer Version, deren offizielles End of Life für Januar 2025 angesetzt war. Bereits Jahre zuvor war klar, dass Wartung, Sicherheitsupdates und Weiterentwicklung zunehmend aufwendig werden würden. Eine reine Migration auf eine neuere Drupal-Version hätte einen massiven Umbau erfordert und nahezu denselben Aufwand verursacht wie ein kompletter Systemwechsel. NASA selbst beschreibt diesen Moment ausdrücklich als strategischen Wendepunkt, um die gesamte CMS-Landschaft neu zu bewerten. Details dazu finden sich unter anderem in der Berichterstattung von WP Tavern.
Parallel verschärften sich die regulatorischen Anforderungen. Mit dem 21st Century Integrated Digital Experience Act wurden US-Behörden verpflichtet, ihre Websites konsequent barrierefrei, sicher, mobil nutzbar und nutzerzentriert auszurichten. In einer stark zersplitterten Drupal-7-Landschaft ließ sich das nur mit hohem Aufwand und vielen Sonderlösungen umsetzen.
Am Ende ergab sich ein klares Bild. Zu viele Systeme liefen parallel. Inhalte wuchsen ohne saubere thematische Ordnung. Governance, Qualitätssicherung und Skalierung waren kaum noch kontrollierbar. Der Relaunch war daher kein kosmetisches Redesign, sondern eine notwendige technische und strukturelle Neuausrichtung. Erst auf dieser Basis konnte entschieden werden, welches CMS langfristig geeignet ist und wie Inhalte künftig stabil, wartbar und nutzerorientiert organisiert werden sollen.
CMS-Entscheidung: Warum die NASA WordPress gewählt hat
Die Entscheidung für ein neues CMS fiel bei der NASA nicht aus dem Bauch heraus. Sie war das Ergebnis eines strukturierten Evaluationsprozesses, der sich über rund ein Jahr erstreckte. Ausgangspunkt war die Erkenntnis, dass ein Weiterbetrieb von Drupal 7 keine nachhaltige Option mehr darstellte und ein Upgrade auf Drupal 8 oder 9 einem Neubau gleichgekommen wäre. Damit öffnete sich bewusst der Raum, Alternativen neu zu bewerten.
Im ersten Schritt analysierte das Web-Modernization-Team den gesamten CMS-Markt. Mehr als hundert Systeme wurden gesichtet. In die engere Auswahl schafften es schließlich vier Kandidaten, darunter Open-Source- und proprietäre Lösungen. Diese wurden nicht nur technisch bewertet, sondern auch in Prototypen getestet. Besonders entscheidend war dabei das Feedback der späteren Nutzer, also der Redakteure und Content-Verantwortlichen innerhalb der NASA, wie der detailliert dokumentierte Auswahlprozess auf WP Tavern zeigt.
Der Block Editor als Kriterium
WordPress setzte sich in dieser Phase aus mehreren Gründen durch. Ein zentraler Faktor war der Gutenberg Block Editor. Im Vergleich zu klassischen, templatebasierten CMS bot er deutlich mehr Flexibilität für redaktionelles Arbeiten, ohne Design- oder Qualitätsstandards aufzugeben. Inhalte lassen sich modular aufbauen, wiederverwenden und anpassen, ohne dass Redakteure in Code eingreifen müssen. Genau diese Balance aus Freiheit und Kontrolle war für die NASA ausschlaggebend.
Hinzu kam die bereits vorhandene WordPress-Nutzung innerhalb der Organisation. Schon vor dem Relaunch liefen rund hundert NASA-Websites auf WordPress, wenn auch meist noch mit dem klassischen Editor. Dieses bestehende Know-how reduzierte Schulungsaufwand und Projektrisiken spürbar. Gleichzeitig sprach das große Open-Source-Ökosystem für WordPress. Langfristige Wartbarkeit, ein breites Plugin-Angebot sowie eine aktive Entwickler-Community wogen schwerer als einzelne Spezialfunktionen.
Auch strategisch passte WordPress besser als viele Spezial-CMS. Statt ein hochkomplexes System für alle Anforderungen zu erzwingen, entschied sich die NASA für eine Plattform, die sich über klare Governance, Designsysteme und Schnittstellen steuern lässt. Der Fokus lag nicht auf maximaler technischer Tiefe im Kern, sondern auf Erweiterbarkeit, Integration und nachvollziehbaren Prozessen.
Skalierbarkeit und Governance als Entscheidungskriterien
Am Ende entschied sich die NASA nicht für die einfachste, sondern für die robusteste Lösung. In einem mehrstufigen Evaluationsprozess wurden über hundert CMS geprüft und mehrere Systeme in Prototypen getestet, bevor WordPress ausgewählt wurde. Ausschlaggebend war dabei nicht ein einzelnes Feature, sondern die Kombination aus redaktioneller Flexibilität, klarer Governance und technischer Erweiterbarkeit.
WordPress überzeugte vor allem deshalb, weil es sich kontrolliert anpassen und standardisieren lässt. Über ein zentrales Designsystem, eigens entwickelte Gutenberg-Blöcke und definierte Rollenmodelle entstand eine Plattform, die skalierbar bleibt, ohne redaktionelle oder technische Wildwüchse zuzulassen. Die Umsetzung dieser Architektur basiert auf einem blockbasierten Designsystem und einer klaren Trennung von Inhalt, Struktur und Darstellung, wie sie im NASA-Flagship-Projekt von Lone Rock Point dokumentiert ist.
Damit markiert die Entscheidung einen klaren Bruch mit der verbreiteten Annahme, dass Enterprise-Websites zwangsläufig auf schwergewichtige Speziallösungen setzen müssen. Das NASA WordPress Projekt zeigt, dass langfristiger Betrieb, Integrationstiefe und Governance nicht aus der Komplexität des CMS-Kerns entstehen, sondern aus einer sauberen Systemarchitektur, klaren Prozessen und dem bewussten Einsatz von Open-Source-Technologie.
Gutenberg und Designsystem: Wie NASA WordPress skalierbar macht
Ein zentraler Baustein der neuen Plattform ist der konsequente Einsatz des Gutenberg Block Editors. Die NASA nutzte WordPress nicht als klassisches Seiten- oder Template-System, sondern als blockbasierte Arbeitsumgebung, in der Inhalte modular aufgebaut werden. Diese Entscheidung zielte darauf ab, redaktionelle Freiheit zu ermöglichen, ohne Konsistenz und Kontrolle zu verlieren.
Grundlage dafür ist ein eigenes Designsystem mit dem Namen Horizon. Es übersetzt gestalterische und funktionale Regeln in klar definierte Bausteine. Farben, Typografie, Abstände und Komponenten sind festgelegt und werden direkt im Editor abgebildet. Statt freier Gestaltung greifen Redakteure auf vorgegebene Blöcke und Block-Patterns zurück, die sich kombinieren lassen, jedoch innerhalb klarer Leitplanken bleiben. Dieses Zusammenspiel aus Designsystem und Block-Editor ist ein Kernprinzip der neuen NASA-Website.
Technisch wurde das Designsystem über eigens entwickelte Gutenberg-Blöcke umgesetzt. Diese Blöcke bilden nicht nur einfache Layout-Elemente ab, sondern auch komplexere Module wie strukturierte Teaser, Missionsübersichten oder inhaltsreiche Landingpages. Dadurch entstehen Seiten nicht mehr aus starren Templates, sondern aus wiederverwendbaren Komponenten. Die konkrete Umsetzung dieser Block-Architektur ist im Rahmen des NASA-Flagship-Projekts detailliert dokumentiert.
Ein weiterer Vorteil dieses Ansatzes liegt in der Skalierbarkeit. Neue Seitentypen lassen sich erstellen, ohne neue Templates oder Sonderlogik zu entwickeln. Gleichzeitig bleibt die redaktionelle Arbeit beherrschbar, da jede Seite denselben technischen und gestalterischen Regeln folgt. Genau diese Balance aus Flexibilität und Standardisierung machte Gutenberg für die NASA zu einem tragfähigen Enterprise-Werkzeug.
Migration und Informationsarchitektur: Von Legacy zu Themen-Hubs
Die technische Migration war nur ein Teil des Projekts. Mindestens genauso entscheidend war die Neustrukturierung der Inhalte. Über Jahre hinweg hatten sich bei der NASA tausende Seiten angesammelt, verteilt auf unterschiedliche Subdomains und Websites. Diese Struktur folgte internen Zuständigkeiten, nicht den Fragen der Nutzer. Genau hier setzte die neue Informationsarchitektur an.
Im ersten Schritt wurden bestehende Inhalte inventarisiert und bewertet. Ein Großteil der Seiten konnte automatisiert aus dem bisherigen Drupal-Setup übernommen werden. Dazu gehörten zehntausende Inhaltsseiten sowie eine sehr große Anzahl an Medienassets, die im Rahmen der Web-Modernisierung migriert wurden. Der Umfang dieser Migration und der technische Ansatz sind im Projektbericht zum NASA WordPress Flagship dokumentiert.
Gleichzeitig zeigte sich, dass eine reine 1:1-Übernahme nicht ausreicht. Viele Inhalte waren mehrfach vorhanden, veraltet oder thematisch falsch verortet. Statt bestehende Strukturen zu konservieren, entschied sich die NASA für einen Neustart auf Ebene der Informationsarchitektur. Inhalte wurden entlang von Nutzerinteressen gebündelt und in thematische Hubs überführt, wie sie heute auf der neu strukturierten NASA Website sichtbar sind.
Diese Neuausrichtung hatte direkte Auswirkungen auf Auffindbarkeit und Pflege. Inhalte, die zuvor auf verschiedenen Domains lagen, wurden konsolidiert und über saubere Redirects erreichbar gemacht. Themen sind nun an einem Ort gebündelt, statt über mehrere Websites verteilt zu sein. Dieser Ansatz ist ein zentraler Bestandteil der gesamten Web-Modernisierung.
Architektur: WordPress als Content-Hub für Web, NASA+ und Apps
Die neue Plattform ist nicht als isolierte Website gedacht. WordPress übernimmt bei der NASA die Rolle eines zentralen Content-Hubs, der Inhalte für unterschiedliche Kanäle bereitstellt. Neben der klassischen Website werden Inhalte auch für mobile Apps, externe Services und den Streaming-Dienst NASA+ genutzt. Damit verschiebt sich die Aufgabe des CMS von der reinen Seitenausgabe hin zur strukturierten Bereitstellung von Inhalten.
Technisch setzt die NASA dabei auf eine hybride Architektur. Teile der Plattform laufen klassisch als WordPress-Website, andere Bereiche sind bewusst entkoppelt umgesetzt. Inhalte werden über die WordPress REST API bereitgestellt und in unterschiedlichen Frontends ausgespielt. Dieser Ansatz erlaubt es, neue Ausgabekanäle anzubinden, ohne das CMS jedes Mal neu zu denken. Die Rolle von WordPress als zentrales Content-System wird dabei klar definiert.
Ein gutes Beispiel dafür ist NASA+. Der Streaming-Dienst nutzt WordPress als redaktionelles Backend zur Verwaltung von Programmen, Metadaten und thematischen Zusammenstellungen. Die eigentlichen Medien liegen in separaten Systemen, werden jedoch über Schnittstellen mit WordPress verknüpft. Dadurch bleibt die redaktionelle Pflege zentral, während Ausspielung und Performance unabhängig skaliert werden können. Dieser Architekturansatz ist Teil der offiziellen NASA-Web-Modernisierung.
Auch bestehende Systeme wurden integriert, statt ersetzt. Dazu gehören unter anderem die zentrale Bild- und Mediendatenbank, Suchfunktionen auf Basis von search.gov sowie Single-Sign-On für interne Nutzer. WordPress fungiert hier als verbindende Schicht zwischen bestehenden Diensten. Der CMS-Kern bleibt schlank, während die Komplexität über klar definierte Schnittstellen ausgelagert wird.
Diese Architektur ist bewusst pragmatisch gewählt. Statt auf ein vollständig headless Setup zu setzen, kombiniert die NASA klassische WordPress-Stärken mit API-basierter Erweiterbarkeit. Das reduziert Komplexität im Betrieb und erhöht gleichzeitig die Zukunftsfähigkeit. Das NASA WordPress zeigt an dieser Stelle, dass Enterprise-Architektur nicht aus maximaler Abstraktion entsteht, sondern aus klaren Verantwortlichkeiten, stabilen Schnittstellen und einem CMS, das diese Rolle zuverlässig erfüllt.
Redaktion und Change Management: Was bei der NASA WordPress den Unterschied macht
Die technische Plattform war nur ein Teil der Web-Modernisierung. Mindestens genauso entscheidend war die Frage, wie mehrere hundert Redakteure künftig mit dem System arbeiten. Die NASA betreibt keine zentrale Redaktion, sondern ein stark verteiltes Modell über Missionen, Forschungszentren und Fachabteilungen hinweg. Entsprechend hoch waren die Anforderungen an Prozesse, Schulung und Governance, wie sie im Rahmen der offiziellen Web-Modernisierung der NASA beschrieben sind.
Statt WordPress einfach auszurollen, setzte das Web-Modernization-Team früh auf aktives Change Management. Redakteure wurden bereits in der Evaluationsphase eingebunden und konnten Prototypen testen. Dieses frühe Feedback floss direkt in die Systemgestaltung ein und reduzierte spätere Akzeptanzprobleme, wie der dokumentierte Entscheidungsprozess bei der CMS-Auswahl zeigt, der unter anderem von WP Tavern aufgearbeitet wurde.
Konkret wurden klare Rollenmodelle definiert. Autoren, Editoren und Administratoren erhielten abgegrenzte Verantwortlichkeiten. Ergänzend dazu etablierte die NASA sogenannte Web Content Producers als zentrale Ansprechpartner. Diese Power-User fungieren als Schnittstelle zwischen Technikteam und Redaktion und sorgen für konsistente Qualität über alle Bereiche hinweg. Dieses Organisationsmodell ist Teil der beschriebenen Umsetzungsstrategie im NASA-Flagship-Projekt von Lone Rock Point.
Ein weiterer Schwerpunkt lag auf Schulung und Dokumentation. Statt punktueller Trainings entstand ein dauerhaft verfügbares internes Toolkit mit Anleitungen, Best Practices und Beispielen. Ergänzt wurde dies durch regelmäßige Workshops, Sprechstunden und interne Austauschformate. Ziel war nicht nur Bedienwissen, sondern ein gemeinsames Verständnis für Struktur, Qualität und Nutzerorientierung.
Auch das WordPress-Backend wurde gezielt angepasst. Dashboards, Vorlagen und vordefinierte Block-Patterns erleichtern den Einstieg und reduzieren Fehlerquellen. Redakteure beginnen ihre Arbeit nicht auf einer leeren Seite, sondern innerhalb klarer Leitplanken. Dieser Ansatz senkt die Einstiegshürde und erhöht gleichzeitig die Konsistenz der Inhalte.
Accessibility als Engineering-Disziplin
Barrierefreiheit war bei der NASA kein nachgelagerter Prüfpunkt, sondern eine technische Kernanforderung. Als US-Bundesbehörde unterliegt die NASA strengen Vorgaben, unter anderem aus dem 21st Century Integrated Digital Experience Act sowie den Section-508-Richtlinien. Diese Anforderungen betreffen nicht nur das Frontend, sondern auch redaktionelle Workflows und interne Systeme.
Entsprechend wurde Accessibility von Beginn an in das Designsystem integriert. Farben, Kontraste, Typografie und Komponenten wurden so definiert, dass sie die relevanten WCAG-Kriterien erfüllen. Diese Regeln sind nicht optional, sondern technisch im System verankert. Redakteure können Inhalte nur innerhalb dieser Leitplanken erstellen, was die Fehlerquote deutlich reduziert.
Auch im WordPress-Editor selbst spielt Barrierefreiheit eine aktive Rolle. Inhalte werden bereits während der Erstellung geprüft, etwa auf fehlende Alternativtexte, unklare Überschriftenstrukturen oder problematische Kontraste. Ergänzt wird diese automatisierte Unterstützung durch manuelle Tests auf Block-Ebene. Jeder eigens entwickelte Gutenberg-Block wurde geprüft, bevor er produktiv eingesetzt wurde, wie im Rahmen der technischen Umsetzung des NASA-Flagship-Projekts beschrieben.
Was KMU in München von der NASA mitnehmen können
Der Maßstab der NASA lässt sich nicht direkt auf kleine und mittlere Unternehmen übertragen. Die zugrunde liegenden Prinzipien dagegen schon. Das Projekt zeigt sehr klar, dass nachhaltige Websites nicht durch Spezialsoftware entstehen, sondern durch Struktur, klare Regeln und saubere technische Grundlagen.
Ein zentrales Learning ist der Fokus auf Systeme statt Einzelmaßnahmen. Die NASA hat kein CMS gesucht, das alles kann. Sie hat eine Plattform gewählt, die sich kontrolliert erweitern lässt. Designsysteme, feste Bausteine und klare Rollen sorgen dafür, dass Inhalte wachsen können, ohne das System zu überfordern. Genau dieser Ansatz hilft auch KMU, wenn mehrere Abteilungen, Standorte oder Themen auf einer Website zusammenkommen.
Ein weiterer Punkt ist die Trennung von Inhalt, Gestaltung und Technik. Durch blockbasierte Inhalte arbeiten Redakteure selbstständig, ohne Layout oder Qualität zu gefährden. Das spart Abstimmung, reduziert Abhängigkeiten und erhöht die Geschwindigkeit. Für Marketing-Teams oder wachsende Unternehmen ist das ein echter Vorteil. Konkrete Anwendungsfälle finden sich auch in unseren WordPress Beispielen.
Der NASA-Fall zeigt außerdem, dass Skalierung nicht aus technischer Schwere entsteht. Sie entsteht aus klarer Governance und wartbarer Architektur. Diese Perspektive deckt sich mit vielen Projekten im Mittelstand und wird auch im Vergleich WordPress vs TYPO3 deutlich. Entscheidend ist nicht, wie komplex ein System ist, sondern wie gut es sich steuern lässt.
Das NASA WordPress zeigt, was wirklich zählt
Das NASA WordPress macht deutlich, dass Enterprise nicht vom Budget abhängt, sondern von Entscheidungen. Klare Informationsarchitektur, saubere Prozesse und eine Plattform, die sich langfristig betreiben lässt, sind wichtiger als Spezialfunktionen oder technische Exzesse. WordPress erfüllt diese Anforderungen, wenn es konsequent gedacht und sauber umgesetzt wird.
Genau hier trennt sich Standard-Umsetzung von professioneller Arbeit. Eine erfahrene WordPress Agentur sorgt dafür, dass Architektur, Redaktion und Technik zusammenspielen. Gleiches gilt für komplexere Anforderungen wie E-Commerce, bei denen eine spezialisierte WooCommerce Agentur Struktur und Wartbarkeit sicherstellt.
Der Blick auf die NASA zeigt am Ende vor allem eines: Große Organisationen setzen nicht auf das schwerste System, sondern auf das sinnvollste. Wer diesen Anspruch teilt und ihn sauber umsetzt, baut Websites, die funktionieren. Heute und langfristig. Unterstützt durch Partner, die digitale Systeme ganzheitlich denken, wie eine erfahrene Werbeagentur München.
Mehr lesen und Quellen
Wer tiefer in Hintergründe, Entscheidungslogik und technische Umsetzung einsteigen möchte, findet in den folgenden Quellen weiterführende und belastbare Einblicke:
- Detaillierte Analyse der CMS-Entscheidung und der Gründe für WordPress im Enterprise-Kontext: Why NASA Chose WordPress for Revamping Its Flagship Website – WP Tavern
- Technische Projektdokumentation zur Umsetzung des NASA-Flagship-Auftritts durch Lone Rock Point: NASA Flagship Website on WordPress – Lone Rock Point
- Offizielle Case Study zur Web-Modernisierung der NASA auf WordPress VIP mit Fokus auf Architektur, Skalierung und Betrieb: NASA Web Modernization on WordPress VIP
- UX- und Designperspektive auf das NASA-Redesign von Blink UX: NASA Case Study – Blink UX
- Visuelle und konzeptionelle Einordnung des Relaunchs mit Fokus auf Design und Nutzerführung: NASA Redesign – Super Six Seven
- Vortrag zur NASA Web Modernization mit Einblicken aus erster Hand aus dem WordPress-Umfeld: For All Userkind: NASA Web Modernization and WordPress – YouTube
- Aktuelle Umsetzung und Informationsarchitektur der neuen Plattform direkt auf der offiziellen Website: NASA.gov
