Seit vier Monaten läuft der Relaunch. Das neue CMS ist ausgewählt, die Agentur hat 38 Designmodule gebaut, die Staging-Umgebung sieht hervorragend aus. Im Projektmeeting fragt die Projektleitung nach dem Stand der Inhalte. Es wird still.
Von 600 Seiten sind 40 überarbeitet. Niemand weiß genau, welche alten Seiten wegfallen. Die Produktverantwortlichen sollen Texte freigeben, haben aber keine Zeit. Und die Länder fragen, wann sie ihre Fassungen bekommen. Der Livegang wird um drei Monate verschoben, nicht wegen der Technik, sondern wegen des Contents.
Ein Website-Relaunch scheitert selten an der Technik, sondern fast immer am Content: an fehlenden Zuständigkeiten, an ungeklärten Freigaben, an der Migration des Bestands und daran, dass niemand festgelegt hat, wo Inhalte künftig entstehen. Deshalb gehören vor die CMS-Auswahl fünf Klärungen: wer Inhalte erstellt und freigibt, für welche Kanäle und Länder sie gebraucht werden, welche Inhaltstypen es gibt, was mit dem Bestand passiert und ob das CMS Arbeitsort oder Ausspielkanal sein soll. Wer diese Fragen zuerst beantwortet, wählt das passendere System und geht pünktlicher live.
Warum scheitern Website-Relaunches selten an der Technik?
Weil die Technik ein klar abgegrenztes Projekt mit Dienstleister, Zeitplan und Abnahme ist, der Content aber nicht. Inhalte entstehen verteilt, brauchen Zuarbeit aus Fachabteilungen und Freigaben von Menschen, die andere Prioritäten haben. Wenn diese Abläufe nicht vor dem Relaunch geklärt sind, werden sie im Relaunch zum Engpass.
In Gesprächen mit Marketing- und Kommunikationsteams begegnet mir derzeit auffallend häufig dieselbe Situation: Ein Relaunch oder eine CMS-Migration läuft, und parallel wird klar, dass der Content-Prozess dahinter nicht trägt. Die Auslöser sind unterschiedlich. Mal ist das alte CMS am Ende seiner Lebensdauer, mal steht ein Wechsel auf ein Headless-System an, mal sollen viele Länderseiten zusammengeführt werden. Das Muster dahinter ist immer gleich: Die Organisation investiert erheblich in die Ausspielung und kaum in die Entstehung.
Das hat Folgen, die weit über den Livegang hinausreichen. Ein neues CMS mit alten Abläufen produziert dieselben Probleme wie vorher, nur auf einer moderneren Oberfläche. Texte werden weiter per Copy-Paste eingepflegt, Freigaben laufen weiter per E-Mail, und nach zwei Jahren ist die neue Website so uneinheitlich wie die alte.
CMS-Auswahl, Designmodule, Entwicklung. Der Content wird gegen Ende als Migrationsaufgabe behandelt. Freigaben und Zuständigkeiten werden im Projekt improvisiert. Ergebnis: verschobener Livegang und alte Abläufe im neuen System.
Zuständigkeiten, Freigaben, Inhaltstypen und Bestand werden vor der Systemauswahl geklärt. Das CMS wird danach ausgewählt, wie gut es diesen Prozess unterstützt. Ergebnis: realistischer Zeitplan und ein Ablauf, der nach dem Livegang weiter trägt.
Welche Fragen klärt ihr vor der CMS-Auswahl?
Fünf Fragen: Wer erstellt und wer gibt frei? Für welche Kanäle, Marken und Länder werden Inhalte gebraucht? Welche Inhaltstypen gibt es und wie sind sie aufgebaut? Was passiert mit dem Bestand? Und soll das CMS der Ort sein, an dem Inhalte entstehen, oder der Ort, an dem sie ausgespielt werden? Die Antworten ergeben die Anforderungen, an denen ihr Systeme messt.
| Frage | Was ihr klärt | Was daraus für das System folgt |
|---|---|---|
| Wer erstellt und gibt frei? | Rollen in Marketing, Fachabteilungen, Agenturen, Recht und Geschäftsführung | Rechte- und Rollenmodell, Freigabeworkflows, Zugriff für Externe |
| Für welche Kanäle, Marken und Länder? | Website, Shop, Newsletter, Social, Apps, Sprachversionen | Mehrsprachigkeit, Mandantenfähigkeit, Wiederverwendung von Inhalten |
| Welche Inhaltstypen? | Produktseiten, Fachartikel, Landingpages, Referenzen, Stellenanzeigen | Content-Modell mit Feldern und Komponenten statt freier Textflächen |
| Was passiert mit dem Bestand? | Behalten, überarbeiten, zusammenführen, löschen | Migrationsweg, Weiterleitungen, Importschnittstellen |
| Wo entstehen Inhalte? | Im CMS selbst oder in einem vorgelagerten Werkzeug | Redaktionsfunktionen im CMS oder Schnittstellen für die Übergabe |
Diese Klärungen dauern bei einer mittelgroßen Website zwei bis vier Wochen und ersparen später Monate. Sie sind außerdem die beste Grundlage für das Briefing an Agenturen und Systemanbieter, weil diese dann nicht Funktionen anbieten, sondern auf konkrete Abläufe antworten müssen.
Soll das CMS Arbeitsort oder Ausspielkanal sein?
Das hängt davon ab, wie viele Kanäle ihr bespielt und wie viele Menschen beteiligt sind. Wenn Inhalte vor allem für die Website entstehen und wenige Personen sie pflegen, kann das CMS der Arbeitsort sein. Wenn dieselben Themen auf Website, Social Media, Newsletter und in mehreren Ländern erscheinen, sollte die Entstehung vorgelagert sein und das CMS als einer von mehreren Ausspielkanälen dienen.
Diese Frage wird bei Relaunches fast nie gestellt, obwohl sie die Systemwahl stark prägt. Klassische CMS bieten oft eigene Redaktionsfunktionen. Headless-Systeme sind darauf ausgelegt, Inhalte strukturiert zu speichern und in viele Kanäle auszuliefern, haben aber für die Entstehung, Abstimmung und Freigabe von Inhalten meist weniger zu bieten. Wer ein Headless-System wählt, ohne zu klären, wo Inhalte entstehen, verlagert die Redaktionsarbeit unbemerkt in E-Mails, Textdokumente und Tabellen.
Wenn die Entstehung vorgelagert ist, wird die Übergabe ins CMS zur entscheidenden Schnittstelle. Hier hat sich in den letzten Monaten viel bewegt: Mit Anbindungen über MCP lassen sich freigegebene Inhalte strukturbewusst als Entwurf in das CMS übergeben, passend zu Feldern und Komponenten. Wie diese letzte Meile ohne Copy-Paste funktioniert, beschreibt der Beitrag Die letzte Meile: Content ohne Copy-Paste ins CMS. Wann eine klassische Schnittstelle und wann MCP passt, steht in MCP oder API.
Headless oder klassisch: was der Content-Prozess über die Wahl verrät
Ein klassisches CMS passt, wenn die Website der Hauptkanal ist, ein überschaubares Team pflegt und die Redaktion direkt im System arbeiten soll. Ein Headless-System passt, wenn Inhalte in viele Kanäle, Apps oder Länder ausgespielt werden, Entwicklungskapazität vorhanden ist und die Redaktionsarbeit an einem anderen Ort stattfinden kann. Die Entscheidung folgt aus dem Prozess, nicht aus dem Trend.
| Kriterium | Spricht eher für klassisch, etwa WordPress oder TYPO3 | Spricht eher für Headless, etwa Storyblok oder Contentful |
|---|---|---|
| Kanäle | Website ist der zentrale Kanal | Website, Apps, Shop, Displays und weitere Kanäle aus einer Quelle |
| Team | Wenige Redakteurinnen und Redakteure, die direkt im System arbeiten | Viele Beteiligte, Redaktion arbeitet zum Teil außerhalb des CMS |
| Entwicklung | Begrenzte Entwicklungskapazität, Agentur pflegt | Eigene oder dauerhaft verfügbare Entwicklungskapazität |
| Inhaltsstruktur | Seiten mit freien Inhaltsbereichen reichen aus | Strenges Content-Modell mit wiederverwendbaren Bausteinen gewünscht |
| Länder und Sprachen | Wenige Sprachversionen | Viele Märkte mit gemeinsamen und lokalen Inhalten |
Ein Hinweis aus der Praxis: Die Komplexität eines Headless-Systems wird regelmäßig unterschätzt. Jede neue Komponente braucht Entwicklung, jede Änderung am Content-Modell eine Abstimmung. Das ist kein Argument gegen Headless, aber ein Argument dafür, Komplexität bewusst gering zu halten und nur die Bausteine zu bauen, die der Content-Prozess wirklich braucht.
Warum kommt das Content-Modell vor den Designmodulen?
Weil Designmodule beschreiben, wie Inhalte aussehen, das Content-Modell aber, woraus sie bestehen. Wer zuerst Module gestaltet, baut Gefäße, ohne zu wissen, was hineingehört. Das Ergebnis sind schöne Seiten mit freien Textfeldern, in denen jede Redakteurin anders arbeitet, und Inhalte, die sich weder wiederverwenden noch sauber an andere Kanäle übergeben lassen.
Ein Content-Modell legt fest, welche Inhaltstypen es gibt und aus welchen Feldern sie bestehen. Eine Produktseite hat etwa einen Nutzen in einem Satz, technische Daten, Anwendungsbeispiele, häufige Fragen und eine Zielgruppe. Ein Fachartikel hat eine Kernaussage, eine Kurzantwort, Abschnitte, Quellen und ein zugeordnetes Thema. Wenn diese Felder feststehen, können Designmodule sie gezielt darstellen, Suchmaschinen und KI-Systeme sie besser verstehen, und andere Kanäle können sie automatisch übernehmen.
Besonders wertvoll sind Metadaten, die nicht sichtbar sind, aber steuern: Zielgruppe oder Persona, Thema, Phase in der Customer Journey, Markt, Freigabestatus. Sie entscheiden später darüber, ob ihr auswerten könnt, welche Themen wirken, und ob sich Inhalte für Länder und Kanäle automatisch ableiten lassen. Wer sie im Relaunch nicht anlegt, muss sie später mühsam nachpflegen.
- Schritt 1Inhaltstypen sammelnAlle Arten von Seiten und Inhalten auflisten, die es heute gibt und künftig geben soll. Meist sind es acht bis fünfzehn Typen.
- Schritt 2Felder festlegenFür jeden Typ die Pflicht- und Kannfelder definieren. Frage dabei: Welche Information braucht die Zielgruppe, und welche braucht ein anderer Kanal?
- Schritt 3Metadaten ergänzenThema, Zielgruppe, Journey-Phase, Markt und Status als feste Felder anlegen, nicht als freie Schlagworte.
- Schritt 4Erst dann gestaltenDesignmodule auf Basis der Felder entwickeln. Jedes Modul zeigt bestimmte Felder, statt beliebige Inhalte aufzunehmen.
Was passiert mit dem Bestand?
Er wird vor der Migration gesichtet und jede Seite bekommt eine Entscheidung: behalten, überarbeiten, zusammenführen oder löschen. Seiten mit Besuchern, Rankings oder externen Verweisen werden mit Weiterleitungen gesichert. Wer den Bestand ungeprüft eins zu eins migriert, überträgt alte Probleme ins neue System. Wer ihn ungeprüft löscht, verliert Sichtbarkeit.
Die Bestandsaufnahme ist der Teil, der in Relaunch-Projekten am häufigsten zu spät beginnt. Sie braucht Daten aus Webanalyse und Search Console, eine Einschätzung der Fachabteilungen und eine klare Entscheidungsregel. Gleichzeitig ist sie eine große Chance: Bei vielen Websites lässt sich ein erheblicher Teil der Seiten zusammenführen oder streichen, was Pflegeaufwand dauerhaft senkt. Wie ihr die Inventur strukturiert, beschreibt der Beitrag Content-Inventur: was ihr habt, bevor ihr Neues plant. Die technische und organisatorische Seite der Überführung steht in Migration planen.
| Entscheidung | Wann | Was zu tun ist |
|---|---|---|
| Behalten | Seite hat Besucher oder Rankings und ist inhaltlich aktuell | In neues Content-Modell übertragen, URL möglichst beibehalten |
| Überarbeiten | Seite hat Besucher oder Rankings, ist aber veraltet oder unvollständig | Vor der Migration aktualisieren, Fachabteilung einbinden |
| Zusammenführen | Mehrere Seiten behandeln dasselbe Thema | Zu einer stärkeren Seite verbinden, alte URLs weiterleiten |
| Löschen | Kaum Besucher, keine Rankings, keine externen Verweise, kein Zweck | Entfernen, bei Bedarf auf passende Seite weiterleiten |
Wie regelt ihr Rollen und Freigaben für den Relaunch und danach?
Mit einer klaren Zuständigkeit pro Inhaltstyp, festen Fristen für Freigaben und einer Regel, was bei Fristablauf passiert. Diese Regeln gelten nicht nur für das Projekt, sondern sind der Betriebsmodus danach. Ein Relaunch ist der beste Anlass, sie einzuführen, weil ohnehin alle Beteiligten an einem Tisch sitzen.
Im Relaunch kommen viele Freigaben gleichzeitig zusammen: Produktmanagement, Recht, Länder, Geschäftsführung. Ohne Fristen staut sich alles in den letzten Wochen vor dem Livegang. Bewährt hat sich, die Freigabe pro Inhaltstyp festzulegen statt pro Seite und Personen ohne regelmäßige Redaktionsarbeit als Beobachter einzubinden, die kommentieren und freigeben, ohne selbst im System arbeiten zu müssen. Wie ihr Freigaben verkürzt, ohne Sorgfalt aufzugeben, steht im Beitrag zu Freigabeprozessen. Welche Rollen ein Content-Team dauerhaft braucht, beschreibt Wer macht was im Content-Team.
Arbeitet ihr mit mehreren Ländern oder Vertriebsgesellschaften, gehört eine weitere Frage dazu: Was erstellt die Zentrale, was die Länder, und wer darf was verändern? Die Antwort prägt das Rechtemodell im CMS ebenso wie den Arbeitsablauf. Ein bewährtes Modell beschreibt der Beitrag Ein Headquarter, viele Länder.
Wie plant ihr KI und Sichtbarkeit in KI-Suchen von Anfang an mit ein?
Indem ihr Inhalte strukturiert anlegt, KI-Crawler bewusst zulasst oder ausschließt und den Einsatz von KI in der Erstellung als Teil des Content-Prozesses plant statt als späteres Zusatzthema. Ein Relaunch ist die günstigste Gelegenheit dafür, weil Struktur, Technik und Abläufe ohnehin neu gesetzt werden.
Drei Punkte gehören in jedes Relaunch-Konzept. Erstens ein Content-Modell mit klaren Feldern, Kurzantworten und häufigen Fragen, weil KI-Suchen solche Strukturen besser auswerten. Zweitens eine bewusste Entscheidung über KI-Crawler, die mit IT und Datenschutz getroffen und im neuen System dokumentiert wird. Drittens ein Plan, wie KI bei Erstellung, Übersetzung und Prüfung eingesetzt wird, mit hinterlegter Markensprache statt individueller Prompts. Was Inhalte zitierfähig macht, steht im Beitrag Sichtbar in ChatGPT, Perplexity und AI Overviews. Wie ihr die Markensprache so hinterlegt, dass sie in jedem Entwurf greift, beschreibt Wissensbasis aufbauen.
Wie sieht ein realistischer Zeitplan mit zwei Arbeitssträngen aus?
Technik und Content laufen als zwei getrennte Arbeitsstränge mit eigenen Verantwortlichen, aber gemeinsamen Meilensteinen. Der Content-Strang beginnt vor der Systemauswahl und endet nicht mit dem Livegang, sondern mit einem eingespielten Betrieb danach.
| Phase | Content-Prozess | Technik |
|---|---|---|
| 1 Klären | Rollen, Freigaben, Kanäle, Inhaltstypen, Entstehungsort | Anforderungen aus dem Content-Prozess ableiten |
| 2 Auswählen | Content-Modell entwerfen, Inventur starten | CMS und Dienstleister auswählen, IT und Datenschutz einbinden |
| 3 Bauen | Bestand überarbeiten, neue Inhalte im Zielmodell erstellen, Workflows testen | Content-Modell umsetzen, Designmodule entwickeln, Schnittstellen bauen |
| 4 Migrieren | Inhalte übertragen, Freigaben abschließen, Weiterleitungen prüfen | Import, Tests, Performance, Weiterleitungen einrichten |
| 5 Betreiben | Regelbetrieb mit Themenplan, Freigaberegeln und Reporting | Wartung, Weiterentwicklung nach Bedarf |
Die fünfte Phase entscheidet darüber, ob sich die Investition lohnt. Eine neue Website ist nach dem Livegang nicht fertig, sondern beginnt erst zu wirken. Wenn der Betrieb danach nicht geklärt ist, beginnt der Verfall am ersten Tag. IT und Datenschutz solltet ihr übrigens schon in Phase 2 einbinden, nicht erst bei der Vertragsunterzeichnung. Wie ihr dabei Wochen spart, steht in IT und Datenschutz früh einbinden.
Fünf Fehler beim Website-Relaunch
- Das CMS vor dem Prozess auswählenWer zuerst das System wählt, passt später den Prozess an das System an statt umgekehrt. Das führt zu Umwegen, die jahrelang bleiben.
- Content als Migrationsaufgabe behandelnInhalte sind kein Umzugsgut, das am Ende verladen wird. Sie brauchen eigene Verantwortliche, eigene Zeit und einen eigenen Strang im Projektplan.
- Designmodule ohne Content-Modell bauenSchöne Module mit freien Textfeldern führen zu uneinheitlichen Seiten und verhindern Wiederverwendung in anderen Kanälen.
- Den Bestand eins zu eins übernehmenVeraltete und doppelte Seiten werden im neuen System nicht besser. Die Inventur vor der Migration spart dauerhaft Pflegeaufwand.
- Den Betrieb nach dem Livegang nicht planenOhne Themenplan, Freigaberegeln und Zuständigkeiten nach dem Livegang beginnt die neue Website sofort zu veralten.
Wann ist es trotzdem richtig, mit der Technik zu beginnen?
Wenn das alte System ein akutes Sicherheitsrisiko ist oder seine Unterstützung kurzfristig endet. Dann hat der technische Umzug Vorrang. Auch in diesem Fall lohnt es sich aber, parallel einen kleinen Content-Strang zu starten, der Zuständigkeiten und Freigaben für den Betrieb danach klärt.
Ein zweiter Fall sind sehr kleine Websites mit wenigen Seiten und einer einzigen verantwortlichen Person. Dort ist der Content-Prozess überschaubar, und die Klärung dauert Stunden statt Wochen. Ehrlich ist auch: Ein Relaunch mit Content-Strang dauert in der Vorbereitung länger. Die Zeit holt er aber meist in der Umsetzung wieder herein, weil der Livegang nicht mehr an fehlenden Inhalten und Freigaben hängt.
In eigener Sache
Ich arbeite für contentbird. Die Plattform ist auf genau die Situation ausgelegt, in der Inhalte vorgelagert entstehen und das CMS einer von mehreren Ausspielkanälen ist: Themenplanung, KI-gestützte Erstellung mit hinterlegter Markensprache, Workflows und Freigaben an einem Ort. Freigegebene Inhalte lassen sich per MCP als Entwurf nach WordPress, TYPO3, Contentful und Storyblok übergeben. Die Klärung von Rollen, Content-Modell und Bestand nimmt euch keine Software ab, und für ein kleines Team mit einer einfachen Website ist eine zusätzliche Plattform oft nicht nötig.
Selbstcheck: Ist euer Relaunch auf Content vorbereitet?
Setzt Haken bei allem, was auf euch zutrifft.
kurzer Vorschlag für unseren Website-Relaunch:
Erfahrungsgemäß verzögern sich Relaunches selten wegen der Technik, sondern wegen der Inhalte: fehlende Zuständigkeiten, Freigaben, die sich am Ende stauen, und ein Bestand, der zu spät gesichtet wird.
Ich schlage vor, vor der finalen CMS-Entscheidung zwei bis vier Wochen in die Klärung des Content-Prozesses zu investieren: Rollen und Freigaben je Inhaltstyp, Kanäle und Länder, Content-Modell, Umgang mit dem Bestand und die Frage, ob Inhalte im CMS oder davor entstehen. Daraus leiten wir die Anforderungen an das System ab.
Im Projektplan führen wir Content als eigenen Arbeitsstrang mit eigenen Meilensteinen, der auch den Betrieb nach dem Livegang umfasst.
Fazit: Die Website ist nur so gut wie der Prozess dahinter
Ein Website-Relaunch ist eine der größten Investitionen in die Außendarstellung eines Unternehmens. Er lohnt sich aber nur, wenn danach auch die Inhalte besser werden, und das hängt weniger am System als an den Abläufen dahinter. Wer zuerst klärt, wer Inhalte erstellt, freigibt und pflegt, wo sie entstehen und was mit dem Bestand passiert, wählt das passendere CMS und geht pünktlicher live.
Der wichtigste Satz für die nächste Projektsitzung lautet deshalb: Bevor wir über das System sprechen, klären wir den Prozess. Das kostet einige Wochen am Anfang und erspart Monate am Ende.
Häufige Fragen
Wie lange dauert ein Website-Relaunch?
Für eine mittelgroße Unternehmenswebsite sind sechs bis zwölf Monate realistisch, bei vielen Ländern oder Marken auch länger. Der Content-Strang ist dabei häufiger der zeitkritische Pfad als die Technik. Wer ihn früh startet, verkürzt die Gesamtdauer.
Wann sollten wir die Inhalte für den Relaunch erstellen?
So früh wie möglich, sobald das Content-Modell steht. Inhalte können bereits im Zielformat entstehen, während die Technik noch gebaut wird. Wer erst nach Fertigstellung der Module beginnt, verschiebt fast immer den Livegang.
Headless CMS oder klassisches CMS: was ist besser?
Keines ist grundsätzlich besser. Headless passt, wenn Inhalte in viele Kanäle und Märkte ausgespielt werden und Entwicklungskapazität vorhanden ist. Ein klassisches CMS passt, wenn die Website der Hauptkanal ist und die Redaktion direkt im System arbeitet. Entscheidend ist, wo eure Inhalte entstehen sollen.
Wie vermeiden wir Rankingverluste beim Relaunch?
Durch eine Inventur mit Daten aus Search Console und Webanalyse, durch möglichst stabile URLs für wichtige Seiten und durch vollständige Weiterleitungen für geänderte oder zusammengeführte Seiten. Nach dem Livegang solltet ihr Rankings und Fehlerseiten einige Wochen eng beobachten.
Wer sollte den Content-Strang im Relaunch verantworten?
Eine Person aus Marketing oder Kommunikation mit Entscheidungsbefugnis über Inhalte, nicht die Agentur und nicht die IT. Sie koordiniert Fachabteilungen, Freigaben und Bestand und ist auch nach dem Livegang für den Betrieb zuständig.
Sollten wir KI schon im Relaunch einsetzen?
Ja, wenn die Markensprache hinterlegt ist und Freigaben feststehen. KI hilft beim Überarbeiten des Bestands, beim Ableiten von Sprachversionen und beim Prüfen gegen Vorgaben. Ohne hinterlegte Regeln erzeugt sie dagegen uneinheitliche Texte, die später nachbearbeitet werden müssen.
Wie lässt sich euer Marketingalltag einfacher machen?
In 30 Minuten schauen wir gemeinsam darauf, wo euch heute unnötige Abstimmungen, manuelle Aufgaben, Toolwechsel oder wiederkehrende Content-Arbeit Zeit kosten.
Wenn bei euch ein Relaunch oder eine CMS-Migration ansteht, gehen wir eure Rollen, Freigaben und Inhaltstypen durch und klären, welche Anforderungen sich daraus für das System ergeben.
Alles an eurem tatsächlichen Marketingalltag.
30 Minuten, um deinen Marketingalltag zu vereinfachen Kostenfrei. Du nimmst konkrete Ansatzpunkte mit, die ihr intern direkt weiterverwenden könnt.
Dennis Gumprich
Dennis begleitet Marketing- und Kommunikationsteams bei der Frage, wie generative KI in bestehende Content-Prozesse passt, ohne Qualität, Markensprache und Freigaben zu untergraben. Schwerpunkte: Content Operations, KI-Governance und Toolauswahl in Mittelstand und Konzern.
Transparenzhinweis: Dennis arbeitet für contentbird, einen Anbieter von KI-gestützter Content-Software. Produkterwähnungen sind im Beitrag gekennzeichnet. Mehr über Dennis · LinkedIn
Weiterlesen
Entstehung dieses Beitrags
Dieser Beitrag ist unter Einsatz von KI entstanden. Struktur und Formulierungsentwürfe wurden KI-gestützt erarbeitet. Fachliche Einordnung, Prüfung der Aussagen und die finale Fassung liegen bei Dennis Gumprich.
Zur Belastbarkeit der Aussagen
Klärungsfragen, Entscheidungsregel, Systemvergleich und Phasenmodell sind Arbeitsmodelle aus der Beratungspraxis. Die Beobachtung, dass Relaunches häufig am Content und nicht an der Technik hängen, stammt aus Gesprächen mit Marketing- und Kommunikationsteams im Jahr 2026. Der Systemvergleich ist eine Orientierung und keine Bewertung einzelner Produkte.
