Ein Website-Relaunch wird belastbarer, wenn strategische, redaktionelle und technische Fragen vor dem ersten Designentwurf beantwortet sind. Dieser Beitrag zeigt, welche Entscheidungen früh getroffen werden sollten, wo typische Fehler entstehen und wie sich Anforderungen für Inhalte, Migration, Barrierefreiheit, Sicherheit und Betrieb systematisch erfassen lassen.
Hinweis zur Audio-Zusammenfassung
Audio-Zusammenfassung
Dauer: 4:54
Ein Website-Relaunch sollte nicht mit dem Design beginnen. In diesem Beitrag geht es darum, welche Ziele, Inhalte, technischen Anforderungen und Betriebsfragen vorher geklärt werden sollten.
Ein Website-Relaunch wird häufig mit einem neuen Erscheinungsbild verbunden. In der Praxis entscheidet sich der Erfolg aber meist früher: bei der Zieldefinition, der Inhaltsplanung, den technischen Anforderungen und der Frage, wie die Website später gepflegt und weiterentwickelt werden soll.
Wer direkt mit Layouts oder der Auswahl eines Content-Management-Systems beginnt, legt oft Entscheidungen fest, bevor die eigentlichen Anforderungen bekannt sind. Das kann zu unnötigen Korrekturschleifen, fehlenden Funktionen, Problemen bei der Migration oder höheren Betriebskosten führen.
Ich empfehle deshalb, den Relaunch zunächst als Klärungs- und Planungsprojekt zu behandeln. Design und Programmierung bauen anschließend auf diesen Ergebnissen auf.
1. Ziele und Anlass des Relaunchs konkret formulieren
Am Anfang sollte nicht die Frage stehen, wie die neue Website aussehen soll. Wichtiger ist: Was soll nach dem Relaunch besser funktionieren als heute?
Ein Relaunch kann unterschiedliche Anlässe haben:
- Die bestehende Website ist technisch schwer zu pflegen oder nicht mehr sicher aktualisierbar.
- Inhalte werden nicht gefunden oder sind für verschiedene Zielgruppen schlecht strukturiert.
- Die Website ist auf mobilen Geräten, mit Tastatur oder mit assistiven Technologien nur eingeschränkt nutzbar.
- Interne Abläufe wie Anfragen, Terminbuchungen oder Veröffentlichungen sind unnötig aufwendig.
- Die Website soll neue Sprachen, Standorte, Leistungen oder digitale Services abbilden.
- Die bisherige Plattform passt nicht mehr zu den Anforderungen von Redaktion, Verwaltung oder Vertrieb.
Diese Anlässe sollten in überprüfbare Ziele übersetzt werden. Ein Ziel wie „moderner wirken“ ist als Orientierung zu ungenau. Besser sind Formulierungen wie: „Besucherinnen und Besucher sollen die zuständige Ansprechperson in höchstens drei Schritten finden“ oder „Redaktionsteams sollen Inhalte ohne technische Unterstützung veröffentlichen können“.
Zusätzlich sollte festgehalten werden, woran die Zielerreichung später erkannt wird. Das können qualitative Kriterien, Nutzertests, technische Prüfungen oder ausgewählte Kennzahlen sein. Nicht jede Kennzahl ist automatisch sinnvoll. Entscheidend ist, ob sie eine relevante Verbesserung des Angebots beschreibt.
2. Zielgruppen, Aufgaben und Nutzungssituationen untersuchen
Eine Website richtet sich selten an eine einzige Zielgruppe. Bei Unternehmen können beispielsweise Interessierte, Bestandskunden, Bewerberinnen und Bewerber, Partner sowie Presse oder Fachpublikum unterschiedliche Erwartungen haben. Kommunale und öffentliche Websites müssen zusätzlich verschiedene Lebenslagen, Informationsbedürfnisse und Zugangsvoraussetzungen berücksichtigen.
Für jede wichtige Zielgruppe sollten Sie klären:
- Welche Aufgabe soll die Person auf der Website erledigen?
- Welche Informationen werden dafür benötigt?
- Welche Begriffe verwendet die Person selbst?
- Welche Geräte, Verbindungssituationen oder assistiven Technologien können eine Rolle spielen?
- Was verhindert heute, dass die Aufgabe schnell und sicher erledigt wird?
Hilfreich sind konkrete Nutzungssituationen statt abstrakter Zielgruppenbeschreibungen. „Eine Bürgerin möchte einen Antrag vorbereiten“ ist für die Informationsarchitektur aussagekräftiger als „Bürgerinnen und Bürger“. „Ein potenzieller Auftraggeber möchte Leistungsumfang und Ansprechpartner vergleichen“ führt zu anderen Anforderungen als eine allgemeine Imagebeschreibung.
Die wichtigsten Aufgaben sollten anschließend priorisiert werden. Nicht jede Unterseite und nicht jede Funktion ist gleich relevant. Diese Priorisierung hilft später bei Navigation, Startseite, Suchfunktion, Inhaltsstruktur und Aufwandsschätzung.
- ZieleWas soll nach dem Relaunch besser funktionieren?
- ZielgruppenWelche Aufgaben und Nutzungssituationen sind entscheidend?
- InhalteWas wird übernommen, überarbeitet, zusammengeführt oder entfernt?
- TechnikWelche Plattform, Schnittstellen und Betriebsanforderungen werden benötigt?
- QualitätWie werden Barrierefreiheit, Sicherheit, Performance und SEO berücksichtigt?
3. Bestehende Website und Inhalte systematisch erfassen
Vor dem Relaunch sollte bekannt sein, was derzeit vorhanden ist. Dazu gehört mehr als eine Liste sichtbarer Unterseiten. In vielen Projekten existieren zusätzlich PDFs, Formulare, Downloads, Kampagnenseiten, eingebettete Dienste, Weiterleitungen, alte Subdomains oder Inhalte, die nur über Suchmaschinen gefunden werden.
Ein Bestandsaudit kann unter anderem folgende Informationen erfassen:
- URL und Seitentitel
- Inhaltstyp, etwa Nachricht, Leistungsseite, Ansprechpartner oder Download
- verantwortliche Redaktion oder Fachabteilung
- Aktualität und fachliche Gültigkeit
- eingehende Links und Bedeutung für die Suche
- technische Besonderheiten wie Formulare, Filter oder externe Einbindungen
- Entscheidung: übernehmen, überarbeiten, zusammenführen, ersetzen oder entfernen
Besonders wichtig ist die letzte Entscheidung. Ein Relaunch ist keine automatische Pflicht, alle alten Inhalte unverändert mitzunehmen. Veraltete oder doppelte Inhalte erschweren die Orientierung und erhöhen den späteren Pflegeaufwand. Gleichzeitig dürfen relevante Inhalte nicht allein deshalb entfallen, weil sie in der bisherigen Navigation schwer auffindbar sind.
Für die Content-Migration sollte es eine verbindliche Zuordnung geben: Welche alte URL führt zu welcher neuen URL? Welche Inhalte werden neu erstellt? Welche Weiterleitungen sind erforderlich? Diese Arbeit gehört in die Planung und nicht erst in die letzten Tage vor dem Go-live.
4. Informationsarchitektur und Inhalte vor dem visuellen Design klären
Die Informationsarchitektur beschreibt, wie Inhalte gruppiert, benannt und miteinander verbunden werden. Sie ist nicht nur eine Navigationsfrage. Sie beeinflusst auch Seitentypen, interne Verlinkung, Suchfunktion, Suchmaschinenverständlichkeit und redaktionelle Abläufe.
Vor dem Design sollten mindestens diese Punkte geklärt sein:
- Welche Hauptbereiche gibt es?
- Welche Inhalte gehören zusammen?
- Welche Begriffe verstehen die vorgesehenen Zielgruppen?
- Welche Inhalte müssen direkt erreichbar sein?
- Welche Seiten benötigen eigene Seitentypen oder strukturierte Daten?
- Welche Inhalte werden über Suche, Filter oder thematische Einstiege erschlossen?
Ein grober Inhalts- und Navigationsentwurf kann zunächst als Sitemap oder als einfache Textstruktur entstehen. Für zentrale Aufgaben sind zusätzlich Wireframes oder Nutzungsszenarien sinnvoll. Sie helfen, Funktionen und Inhalte zu prüfen, bevor Farben, Bildwelten und typografische Details die Diskussion dominieren.
Auch die redaktionelle Verantwortung muss feststehen. Für jede wichtige Inhaltsgruppe sollte klar sein, wer Inhalte erstellt, wer sie fachlich prüft und wer sie veröffentlichen darf. Ohne diese Rollen bleibt eine neue Website oft nur so aktuell wie die alte.
5. Anforderungen an Funktionen, Schnittstellen und Prozesse beschreiben
Funktionen sollten nicht als Wunschliste mit einzelnen Schlagworten erfasst werden. Die Aussage „Wir brauchen einen Veranstaltungskalender“ beantwortet noch nicht, wie Veranstaltungen angelegt, wiederholt, abgesagt, gefiltert oder archiviert werden.
Für jede Funktion sind mindestens folgende Fragen sinnvoll:
- Welche Person nutzt die Funktion und mit welchem Ziel?
- Welche Eingaben und Ausgaben gibt es?
- Welche Rollen und Freigaben werden benötigt?
- Welche Daten stammen aus anderen Systemen?
- Was passiert bei Fehlern, fehlenden Daten oder Abbrüchen?
- Welche Anforderungen gelten für Datenschutz, Sicherheit und Barrierefreiheit?
- Wer wartet die Funktion nach dem Start?
Typische Schnittstellen betreffen beispielsweise Warenwirtschaft, CRM, Newsletter, Bewerbungsverwaltung, Veranstaltungsdaten, Karten- oder Bezahldienste. Jede externe Verbindung erhöht die technische und organisatorische Abhängigkeit. Deshalb sollten Datenflüsse, Verantwortlichkeiten und Ausfallverhalten früh dokumentiert werden.
Wenn die Website Teil eines größeren digitalen Angebots ist, kann eine individuelle Webanwendung oder ein separates Backend sinnvoller sein als eine überladene CMS-Installation. Umgekehrt sollte nicht jede Sonderfunktion individuell entwickelt werden, wenn eine einfache und wartbare Standardlösung ausreicht.
6. Technische Basis und Betriebsmodell festlegen
Das technische System sollte sich aus den Anforderungen ergeben. Vor der Auswahl oder Festlegung der Plattform sind deshalb Fragen zu Betrieb, Wartung und Weiterentwicklung zu beantworten:
- Wer administriert das System?
- Wie viele Personen arbeiten redaktionell damit?
- Welche Rollen und Freigabeprozesse werden benötigt?
- Wie häufig werden Aktualisierungen und Sicherheitsupdates eingespielt?
- Welche Entwicklungs-, Test- und Produktivumgebungen gibt es?
- Wie werden Backups erstellt und Wiederherstellungen geprüft?
- Welche Protokollierung und Überwachung ist für den Betrieb notwendig?
- Wie wird mit Erweiterungen, individuellen Anpassungen und Drittanbieter-Diensten umgegangen?
Ein System kann im ersten Projekt günstig erscheinen und später durch Pflege, Sonderlösungen oder Abhängigkeiten hohe Folgekosten verursachen. Umgekehrt ist eine individuell entwickelte Lösung nicht automatisch wartbarer. Entscheidend sind klare Verantwortlichkeiten, nachvollziehbare Strukturen, dokumentierte Schnittstellen und ein realistisches Wartungsmodell.
Für sensible Bereiche sollten Sicherheitsanforderungen ausdrücklich beschrieben werden. Dazu gehören unter anderem Rechtekonzepte, sichere Authentifizierung, Schutz vor typischen Webangriffen, Umgang mit Protokolldaten und ein Verfahren für Sicherheitsvorfälle. Rechtliche Bewertungen, insbesondere zu Datenschutz und Einwilligungen, sollten mit den zuständigen Fachstellen oder qualifizierter Beratung abgestimmt werden.
- 1. Ziele und AufgabenZiele, Zielgruppen und priorisierte Nutzungssituationen festlegen.
- 2. Inhalte und StrukturBestand prüfen, Sitemap entwickeln und Seitentypen definieren.
- 3. Funktionen und ProzesseRollen, Schnittstellen, Datenflüsse und Fehlerfälle beschreiben.
- 4. Qualität und BetriebBarrierefreiheit, Sicherheit, Performance, Wartung und Tests planen.
7. Barrierefreiheit, Performance und SEO als Grundanforderungen behandeln
Barrierefreiheit sollte nicht als abschließende Prüfroutine verstanden werden. Sie betrifft bereits die Inhaltsstruktur, Navigation, Formulare, Sprache, Kontraste, Tastaturbedienung und Fehlermeldungen. Wenn diese Anforderungen erst nach dem visuellen Design berücksichtigt werden, sind Korrekturen häufig aufwendiger.
Planen Sie daher frühzeitig:
- semantische Überschriften und verständliche Linktexte
- vollständige Bedienbarkeit ohne Maus
- sichtbare Fokuszustände
- zugängliche Formulare mit klaren Fehlermeldungen
- Alternativen für nichttextliche Inhalte
- ausreichende Kontraste und veränderbare Textdarstellung
- verständliche Sprache und nachvollziehbare Orientierung
Die konkreten rechtlichen Pflichten hängen unter anderem von Organisation, Angebot und Einsatzbereich ab. Für Kommunen und öffentliche Einrichtungen sollten die geltenden Anforderungen sowie interne Prüf- und Veröffentlichungsvorgaben früh in das Projekt aufgenommen werden.
Auch Suchmaschinenoptimierung und technische Performance sind keine nachträglichen Dekorationen. Eine klare Seitenstruktur, dauerhafte URLs, sinnvolle Metadaten, schnelle Auslieferung und strukturierte Inhalte müssen mit Informationsarchitektur und Technik zusammenpassen. Beim Relaunch ist außerdem zu prüfen, welche bestehenden Suchzugriffe erhalten bleiben müssen. Eine Übersicht zu SEO und GEO kann diese Planung ergänzen.
8. Migration, Tests und Go-live realistisch planen
Ein Relaunch ist erst abgeschlossen, wenn Inhalte, Weiterleitungen, Funktionen und Betrieb geprüft sind. Der Go-live sollte deshalb nicht als einzelner Termin ohne Zwischenstufen geplant werden.
Bewährt hat sich eine Abfolge aus:
- fachlicher und technischer Bestandsaufnahme
- Festlegung von Struktur, Inhalten und Anforderungen
- Entwicklung in einer getrennten Umgebung
- Migration oder Neuerstellung der Inhalte
- redaktioneller, technischer und barrierebezogener Prüfung
- kontrollierter Veröffentlichung
- Beobachtung und Fehlerkorrektur nach dem Start
Die Testplanung sollte konkrete Fälle enthalten. Dazu gehören etwa Kontaktformulare, Suchfunktionen, Downloads, Filter, Benutzerrechte, Weiterleitungen, Fehlermeldungen, mobile Darstellung, Tastaturbedienung und das Verhalten bei fehlenden oder ungültigen Eingaben.
Für die Veröffentlichung braucht es außerdem einen Rückfallplan. Vor dem Umschalten sollten Backups, Zugänge, DNS- oder Hosting-Zuständigkeiten und Ansprechpartner geklärt sein. Eine kurze Phase erhöhter Beobachtung nach dem Go-live hilft, unerwartete Fehler bei Zugriffen, Formularen oder Weiterleitungen schnell zu erkennen.
9. Budget, Zuständigkeiten und Entscheidungen dokumentieren
Eine belastbare Aufwandsschätzung ist erst möglich, wenn Umfang und Qualitätsanforderungen ausreichend geklärt sind. Neben Design und Programmierung werden häufig folgende Leistungen unterschätzt:
- Bestandsaufnahme und Inhaltsmigration
- Texterstellung, Überarbeitung und redaktionelle Abstimmung
- Bildauswahl und Aufbereitung
- Schnittstellen und Datenbereinigung
- Barrierefreiheits- und Sicherheitstests
- Schulungen, Dokumentation und redaktionelle Einführung
- laufende Wartung, Hosting und Weiterentwicklung
Benennen Sie außerdem eine Person oder ein Gremium, das fachliche Entscheidungen verbindlich trifft. Wenn jede Detailfrage an eine große Runde zurückgegeben werden muss, verlängert sich das Projekt und Anforderungen widersprechen sich leichter.
Alle wesentlichen Entscheidungen sollten nachvollziehbar dokumentiert werden: Zielsetzung, Zielgruppen, Seitenstruktur, Funktionsumfang, technische Annahmen, Ausschlüsse, Verantwortlichkeiten und Abnahmekriterien. Das schafft keine unnötige Bürokratie, sondern reduziert Missverständnisse.
Eine sinnvolle Reihenfolge für die Vorbereitung
Für viele Projekte ist folgende Reihenfolge praktikabel:
| Schritt | Ergebnis |
|---|---|
| Ziele und Zielgruppen | Priorisierte Aufgaben und überprüfbare Ziele |
| Bestandsaufnahme | Inhalts-, Technik- und URL-Inventar |
| Informationsarchitektur | Sitemap, Seitentypen und Navigationslogik |
| Anforderungen | Funktionen, Rollen, Schnittstellen und Qualitätskriterien |
| Technik und Betrieb | Plattform, Hosting, Wartung, Sicherheit und Backups |
| Umsetzung | Design, Entwicklung, Migration und Tests |
Diese Reihenfolge ist kein starres Schema. Erkenntnisse aus Tests oder Prototypen können frühere Entscheidungen verändern. Wichtig ist, dass Änderungen bewusst getroffen und ihre Auswirkungen auf Aufwand, Inhalte und Betrieb geprüft werden.
Fazit
Ein gut geplanter Website-Relaunch beginnt mit Klarheit: über Ziele, Zielgruppen, Inhalte, Prozesse, technische Abhängigkeiten und den späteren Betrieb. Erst wenn diese Grundlagen ausreichend beschrieben sind, kann das Design seine Aufgabe erfüllen und eine passende technische Umsetzung entstehen.
Wenn Sie die bestehende Website zunächst fachlich und technisch einordnen möchten, kann der Beitrag Woran Sie erkennen, dass Ihre Website technisch und inhaltlich überholt ist als Ausgangspunkt dienen. Für die weitere Projektstruktur finden Sie außerdem Hinweise zum Website-Relaunch und zur Neuentwicklung.
- ProjektzielePriorisierte Ziele und Kriterien zur späteren Bewertung.
- InhaltsinventarÜbersicht über URLs, Inhalte, Verantwortlichkeiten und Migrationsentscheidungen.
- SitemapGeplante Navigations- und Inhaltsstruktur.
- AnforderungslisteFunktionen, Rollen, Schnittstellen und Qualitätsanforderungen.
- BetriebskonzeptHosting, Updates, Backups, Sicherheit und Zuständigkeiten.
