Wie planen Sie ein Relaunch-Projekt für die Unternehmenswebsite? Umfang, Content-Inventar und Migrations-Checkliste

Ein Relaunch-Projekt für eine Unternehmenswebsite beginnt in den meisten Firmen wie eine Designaufgabe und endet wie eine Datenmigration. In der Designphase sind alle begeistert: neue Farben, neue Bilder, eine modernere Startseite. Zwei Wochen nach dem Livegang ändert sich die Tagesordnung. Der organische Traffic ist gesunken, einige Formulare landen nicht im CRM, und wenn das Vertriebsteam den Link einer alten Produktseite verschickt, landet der Kunde auf einer 404-Seite.

Dieser Beitrag soll Ihnen helfen, das Redesign nicht als visuelle Auffrischung zu planen, sondern als Kombination aus drei getrennten Aufgaben: Entscheidung über den Projektumfang, Content-Inventar und URL- beziehungsweise technische Migration. Fehlt eine dieser drei, wird das Projekt entweder nie fertig oder es kostet nach Abschluss mehr, als es einbringt.

Die im Text verwendeten Zahlen, Tabellen und Szenarien sind ausdrücklich hypothetisch. Seitenanzahl, Traffic-Verteilung und technische Infrastruktur Ihrer eigenen Website verändern diese Werte erheblich. Ziel ist es, die Entscheidungslogik zu vermitteln, nicht ein fertiges Budget oder einen fertigen Zeitplan zu liefern.

Worauf sollten Sie die Relaunch-Entscheidung stützen?

Die erste Frage lautet nicht „wie erneuern wir“, sondern „was ist kaputt“. Projekte, die darauf keine klare Antwort geben, reproduzieren die alten Probleme in der neuen Website.

In der Praxis entsteht der Wunsch nach einem Redesign meist aus einem der folgenden fünf Gründe, und jeder erfordert einen anderen Projektumfang:

Visuelle Alterung und Markeninkonsistenz. Die Website spiegelt die heutige Corporate Identity des Unternehmens nicht wider. Das Logo wurde geändert, die Farbpalette aktualisiert, aber die Website ist im alten Erscheinungsbild geblieben. Das ist meist die Aufgabe mit dem engsten Umfang: Die Designebene wird erneuert, die Informationsarchitektur bleibt weitgehend erhalten. Diese Erwartung an Übereinstimmung zwischen Corporate Identity und Website verlangt, dass die Website zur physischen Präsenz des Unternehmens und zur angebotenen Leistung konsistent ist.

Änderung von Positionierung und Produkt. Das Unternehmen hat ein neues Segment erschlossen, das Produktportfolio hat sich verändert oder es ist vom Einzelprodukt zur Plattform übergegangen. In diesem Fall liegt die eigentliche Arbeit in Botschaft und Informationsarchitektur. Das Design verändert sich als Ergebnis dieser neuen Struktur. Bei solchen Projekten ist es der größte Fehler, die Seitenstruktur unverändert zu übernehmen.

Conversion-Performance. Traffic ist vorhanden, aber Formulare werden nicht ausgefüllt, es kommen keine Demo-Anfragen. Hier ist Vorsicht geboten: Ein Conversion-Problem hat nicht immer seine Ursache im Design. Das Angebot kann falsch positioniert sein, die Zielgruppe kann falsch sein, im Formular kann ein unnötiges Feld stehen. Die im Mochatouch-Beitrag zur Conversion-Rate-Optimierung aufgeführten Analysequellen zeigen, wo man vor einer Entscheidung hinschauen sollte: Analytics-Daten, A/B-Tests, Nutzerbefragungen und Heatmaps (Conversion Rate Optimierung). Ohne einen Blick auf diese Daten zu sagen „erneuern wir die Website, dann steigt die Conversion“, ist eine teure Vermutung.

Technische Schulden. Das CMS ist alt, erhält keine Updates, die Seitengeschwindigkeit ist niedrig, das mobile Erlebnis ist fehlerhaft, Sicherheitsupdates verzögern sich. Das ist eine Entscheidung über einen Plattformwechsel, unabhängig vom Design, und sie führt meist zur riskantesten Migration, weil URL-Struktur, Formular-Integrationen und Analytics-Setup gemeinsam geändert werden.

Operative Langsamkeit. Das Marketingteam muss für eine einzige Landingpage zwei Wochen warten, das Veröffentlichen von Inhalten erfordert eine Entwicklerin oder einen Entwickler. Das ist ein Geschwindigkeitsproblem, und die Lösung ist keine neue visuelle Sprache, sondern ein Komponentensystem, mit dem Redakteure selbstständig Seiten aufbauen können.

Der praktische Nutzen dieser Unterscheidung: Sie legen von Anfang an fest, woran Sie den Erfolg am Projektende messen. Von einem Relaunch, der wegen technischer Schulden durchgeführt wurde, zu erwarten, dass sich die Lead-Zahl verdoppelt, ist der einfachste Weg, das Projekt für gescheitert zu erklären.

Relaunch oder schrittweise Verbesserung?

Nicht jedes Problem erfordert einen vollständigen Relaunch. Eine grobe Unterscheidung lässt sich so treffen:

Die Unterscheidung in der Tabelle ist nicht scharf. In echten Projekten gelten mehrere Zeilen gleichzeitig. Dennoch verzögert diese Frage den Reflex „machen wir alles von vorn“ um einen Schritt und klärt, wohin das Budget fließt.

Weiterführende Lektüre: Corporate-Identity-Handbuch (Brand Guideline): Wie Sie es erstellen und von Teams anwenden lassen

Den Umfang definieren: was das Projekt umfasst und was nicht

Die häufigste Budget- und Zeitplanabweichung in Redesign-Projekten entsteht daraus, dass der Umfang nicht schriftlich festgehalten wurde. Der Ausdruck „Website-Relaunch“ entspricht im Kopf verschiedener Personen einer jeweils anderen Aufgabenbeschreibung.

Das Umfangsdokument sollte mindestens auf folgende Punkte eine klare Antwort geben:

Seitenmenge. Die Liste der zu erneuernden Seiten, einzeln aufgeführt. „Unternehmenswebsite“ zu sagen genügt nicht. Ist der Blog inbegriffen? Karriereseiten? Sprachen außer der Hauptsprache? Alte Kampagnen-Landingpages? Das Hilfecenter? Das Erstellen dieser Liste ist gleichzeitig der Anfang des Content-Inventars im nächsten Abschnitt.

Anzahl der Templates. Die Designkosten skalieren nicht mit der Seitenanzahl, sondern mit der Anzahl der Templates. Eine typische B2B-Unternehmenswebsite hat 8 bis 12 Templates, etwa Startseite, Lösungs- beziehungsweise Produktseite, Branchenseite, Über uns, Blog-Übersicht, Blog-Detail, Ressourcencenter, Kontakt und Landingpage-Template. Von Anfang an zu besprechen, aus welchen Komponenten die Templates bestehen, reduziert Diskussionen der Art „diese Seite sieht anders aus als die andere“.

Verantwortung für Inhalte. Wer schreibt die Texte? Das ist die Stelle, an der Projekte am meisten in Verzug geraten. Das Design ist fertig, die Entwicklung ist fertig, sechs Seiten warten mit Lorem ipsum. Liegt die Content-Produktion bei der Agentur, beim Unternehmen oder gemischt? Ist im Zeitplan festgehalten, wie viele Stunden die Produktexpertin oder der Produktexperte einplant?

Technischer Umfang. CMS-Auswahl, Hosting, Formular-Infrastruktur, CRM-Integration, Analytics-Setup, Mehrsprachigkeit, Barrierefreiheitsziel, Performanceziel. Jeder dieser Punkte ist eine eigene Arbeitsposition.

Was außerhalb des Umfangs liegt. Dieser Abschnitt ist mindestens so wichtig wie die anderen. Produktinterne Oberflächen, Kundenportal, E-Commerce-Modul, Neuschreiben alter Blogbeiträge, Videoproduktion. Alles, was nicht schriftlich aus dem Umfang ausgeschlossen wird, kommt mitten im Projekt als „das machen Sie doch auch noch, oder?“ zurück.

Team und Entscheidungsmechanismus

In Unternehmenswebsites ist die Zahl der Beteiligten hoch, und das ist der Hauptgrund, warum sich Designrunden endlos in die Länge ziehen. Drei Rollen müssen von Anfang an definiert sein:

• Entscheider: Wer gibt Design und Botschaft frei? Es sollte eine einzelne Person sein. Freigabe durch ein Komitee produziert eine durchschnittliche Website.
• Beitragende: Vertrieb, Produkt, HR, Recht. Diese äußern Meinungen, geben aber keine Freigabe. Es muss klar sein, in welcher Phase ihre Rückmeldungen eingesammelt werden.
• Umsetzende: Design, Content, Entwicklung, SEO.

Es ist ebenfalls hilfreich, die Anzahl der Designrunden von Anfang an zu begrenzen. Zum Beispiel zwei Revisionsrunden pro Template, die dritte Runde wird als Zusatzaufwand berechnet. Das ist keine Starrheit, sondern eine Methode, Feedback zu disziplinieren.

Zeitplan: was wann zu erwarten ist

In Projekten mit einer Agentur ist Erwartungsmanagement genauso wichtig wie der Zeitplan selbst. Der Ansatz im Mochatouch-Beitrag zum Digitalmarketing-Onboarding empfiehlt, für jede Phase sowohl das erwartbare Ergebnis als auch das nicht zu Erwartende zu notieren (Die ersten 90 Tage mit einer Digitalmarketing-Agentur). Dieselbe Logik auf ein Redesign-Projekt zu übertragen, erleichtert Gespräche mit der Führungsebene deutlich.

Der folgende Zeitplan ist vollständig beispielhaft und beruht auf der Annahme einer mittelgroßen B2B-Unternehmenswebsite (etwa 40 bis 60 Seiten, Blog inbegriffen, eine Sprache). Seitenanzahl, Anzahl der Sprachen, Komplexität der Integrationen und Kapazität der Content-Produktion verschieben diese Tabelle in beide Richtungen.

Besonders die letzte Zeile ist wichtig. Der Livegang ist nicht das Ende des Projekts, sondern der Anfang der Monitoring-Phase. Teams, die diese Phase nicht von Anfang an in Zeitplan und Budget aufnehmen, müssen Probleme, die nach dem Livegang auftreten, als „Zusatzaufwand“ verhandeln.

Content-Inventar: der am häufigsten übersprungene, aber entscheidendste Schritt

Ein Content-Inventar bedeutet, jede URL Ihrer Website in einer einzigen Tabelle aufzulisten und für jede eine Entscheidung zu treffen. Dieser Schritt ist langweilig, deshalb wird er übersprungen. Wird er übersprungen, ist das Ergebnis: Die neue Website geht live, niemand weiß, wohin die 80 Seiten der alten Website gewandert sind, der Traffic aus Suchmaschinen verschwindet, die Links, die der Vertrieb jahrelang geteilt hat, sind defekt.

Welche Spalten sollte die Inventartabelle enthalten?

Das Minimum ist Folgendes:

• URL: Vollständige Adresse.
• Seitentitel und Typ: Produktseite, Blog, Ressource, Unternehmensseite, Landingpage.
• Organischer Traffic der letzten 12 Monate: Aus Ihrem Analytics-Werkzeug. Werkzeuge wie Google Analytics werden genutzt, um zu zeigen, welche Seiten den meisten Traffic erhalten.
• Anzahl der Conversions: Wie viele Formulare, wie viele Demo-Anfragen kamen über diese Seite.
• Einstiegsseite oder nicht: Steigen Nutzer über diese Seite in die Website ein oder kommen sie von innen.
• Externe Verlinkungen vorhanden: Haben andere Websites auf diese Seite verlinkt.
• Content-Verantwortliche: Wer ist für die Richtigkeit dieser Seite zuständig.
• Datum der letzten Aktualisierung.
• Entscheidung: Übernehmen, neu schreiben, zusammenführen, löschen, weiterleiten.
• Neue URL: Die Zieladresse, sofern die Entscheidung nicht „löschen“ lautet.

Diese Tabelle wird meist in einer Tabellenkalkulation geführt und zum einzigen Referenzdokument des Projekts. Design, Entwicklung und Texterstellung schauen alle hierauf.

Welche der fünf Entscheidungen wann treffen?

Übernehmen. Die Seite ist aktuell, ihre Performance ist gut, ihre Botschaft stimmt. Sie wird unverändert in das neue Design übertragen, die URL bleibt erhalten. Das ist die günstigste Entscheidung und sollte so oft wie möglich gewählt werden.

Neu schreiben. Die Seite ist nötig, aber ihr Inhalt ist alt, ihre Botschaft passt nicht zur neuen Positionierung oder sie ist sehr schwach. Die URL kann erhalten bleiben, der Inhalt ändert sich.

Zusammenführen. Wenn es drei Seiten gibt, die dasselbe Thema in unterschiedlicher Tiefe behandeln, ist es meist sowohl für Nutzer als auch für Suchmaschinen besser, diese zu einer starken Seite zusammenzufassen. Die URLs der zusammengeführten Seiten werden auf die Zielseite weitergeleitet. Bei der Entscheidung über die Zusammenführung ist es ein vernünftiger Ausgangspunkt, jene URL als Hauptseite zu behalten, die den höchsten Traffic und die meisten externen Verlinkungen hat.

Löschen. Die Seite ist nicht mehr gültig: ein eingestelltes Produkt, eine vergangene Veranstaltung, eine irrelevante Mitteilung. Wenn sie keinen Traffic und keine externen Verlinkungen hat, kann sie gelöscht werden. Hat sie Traffic, wird sie nicht gelöscht, sondern auf eine passende Seite weitergeleitet.

Weiterleiten. Die Seite wird entfernt, hat aber Traffic, externe Verlinkungen oder eine Vorgeschichte als vom Vertrieb geteilter Link. Sie wird auf die inhaltlich nächstliegende sinnvolle Seite weitergeleitet.

Ein hypothetisches Inventarbeispiel

Die folgende Tabelle ist ein Beispiel, das so gedacht ist, als käme es von der Website eines fiktiven B2B-SaaS-Unternehmens. Die Zahlen sind zu Lehrzwecken erfunden und beruhen auf keinen Kundendaten.

Die praktische Lehre aus dieser Tabelle ist, dass die Verteilung der Entscheidungen selten gleichmäßig ist. Auf einer typischen Website konzentriert sich der überwiegende Teil von Traffic und Conversions auf wenige Seiten. Die wichtigste Funktion des Inventars ist, diese Seiten zu identifizieren und dafür zu sorgen, dass Sie sie im restlichen Projekt mit besonderer Aufmerksamkeit behandeln. Die URL eines Blogbeitrags mit 6.800 Sitzungen innerhalb von 12 Monaten zu ändern, damit es „ordentlicher aussieht“, bedeutet, ein erhebliches Risiko einzugehen, ohne irgendetwas dafür zu gewinnen.

Vom Inventar zur Informationsarchitektur

Die Seitenliste, die nach Abschluss des Inventars übrig bleibt, ist der Rohstoff der neuen Menüstruktur. Hier gibt es zwei Fallen.

Die erste ist, das alte Menü unverändert zu kopieren. Das alte Menü spiegelt möglicherweise das alte Organigramm des Unternehmens. Ein B2B-Einkäufer kennt die Abteilungsstruktur Ihres Unternehmens nicht, er sucht nach seinem eigenen Problem. Das Menü danach aufzubauen, welche der Achsen Problem, Lösung, Branche oder Rolle für Ihren Einkäufer sinnvoller ist, führt meist zu besseren Ergebnissen.

Die zweite ist, für jede Seite einen Platz im Menü schaffen zu wollen. Ein Menü ist kein Archiv, sondern ein Navigationswerkzeug. Seiten im Hintergrund werden über interne Verlinkungen, Suche und das Ressourcencenter erreicht.

Bei der Festlegung der Websitestruktur ist das Ziel, dass Besucher schnell zur gesuchten Information kommen. Diese Strukturentscheidung bildet auch die Grundlage der XML-Sitemap; im Bereich Unternehmens-SEO zählt das Erstellen einer Sitemap und das Erleichtern des Website-Verständnisses für Suchmaschinen zu den ersten technischen SEO-Schritten.

URL-Migration und technische Vorbereitung

Das ist der technischste und riskanteste Teil des Projekts. Ein Fehler im Design lässt sich nachträglich korrigieren. Ein Fehler in der Weiterleitungskarte kostet jeden Tag Traffic, bis er behoben ist.

Wie erstellt man eine Weiterleitungskarte?

Die Weiterleitungskarte ist die natürliche Fortsetzung der Inventartabelle: alte URL, neue URL, Weiterleitungstyp.

Grundprinzipien:

Ändern Sie die URL nicht, solange es nicht nötig ist. Jede Weiterleitung ist ein kleines Risiko und ein Eintrag, der verwaltet werden muss. Ein neues Design erfordert keine URL-Änderung. Eine URL sollte sich nur ändern, wenn sich die Informationsarchitektur wirklich geändert hat oder die bestehende Struktur sinnlos ist (etwa in der Form ?p=1847).

Verwenden Sie permanente Weiterleitungen. Wenn eine Seite dauerhaft umgezogen ist, wird 301 verwendet. Für temporäre Fälle gibt es 302, aber bei einer Redesign-Migration liegt selten ein temporärer Fall vor. (Weiterleitungen und die Google Suche – Google Search Central)

Vermeiden Sie Weiterleitungsketten. Wenn Seite A auf B und B auf C weiterleitet, sollte A direkt auf C verweisen. Das kommt besonders häufig bei Websites vor, die schon einmal umgezogen sind; auch die alten Weiterleitungsregeln müssen geprüft werden.

Leiten Sie nicht alles auf die Startseite. Alle 30 gelöschten Seiten auf die Startseite weiterzuleiten ist einfach, aber aus Nutzersicht ein schlechtes Erlebnis. Wer eine Produktseite sucht und auf der Startseite landet, springt meist zurück. Wenn es keine inhaltlich nächstliegende sinnvolle Seite gibt, ist eine ordentliche 404-Seite die ehrlichere Lösung.

Testen Sie die Weiterleitungen vor dem Livegang. Sie in der Staging-Umgebung oder in einer Tabelle einzeln zu prüfen ist günstiger, als in der Nacht des Livegangs Überraschungen zu erleben.

Technische Punkte, die geprüft werden müssen

Neben den Weiterleitungen gibt es Themen, die bei der Migration übersehen werden und später teuer zu stehen kommen:

• Formular- und CRM-Integration: Erzeugt jedes Formular mit den richtigen Feldern den richtigen CRM-Eintrag? Ohne ein Testformular abzuschicken und den Eintrag im CRM zu sehen, sollte nicht live gegangen werden.
• Analytics und Conversion-Tracking: Ist der Tracking-Code auf der neuen Website auf jeder Seite vorhanden? Wurden die Conversion-Ziele an die neuen URLs angepasst? Wurden die Conversion-Tags der Werbeplattformen übertragen? Wird dieser Punkt übersprungen, findet die Performancediskussion nach dem Livegang ohne Daten statt.
• Robots.txt und noindex: Wurden die Regeln, die in der Staging-Umgebung zum Blockieren von Suchmaschinen gesetzt wurden, beim Livegang entfernt? Das ist die klassische Katastrophe von Redesign-Projekten: Die Website geht live, das noindex-Tag wird vergessen, innerhalb weniger Wochen fallen die Seiten aus dem Index.
• XML-Sitemap: Wurde sie nach der neuen URL-Struktur erzeugt und an die Search Console übermittelt?
• Seitengeschwindigkeit und mobile Tauglichkeit: Seitengeschwindigkeit, mobile Tauglichkeit und die Nutzung von HTTPS zählen zu den Grundpunkten des technischen SEO. Die schweren Bilder des neuen Designs können ein langsameres Ergebnis als die alte Website erzeugen; das sollte vor dem Livegang gemessen werden.
• HTTPS und Zertifikat: Besonders wenn das Hosting wechselt, sollte geprüft werden, dass das Zertifikat auf dem neuen Server funktioniert.
• Seitentitel und Meta-Beschreibungen: Bleiben die bestehenden Titel der übernommenen Seiten erhalten, oder überschreibt das Template automatisch alle?
• Interne Verlinkungen: Wurden Links im Fließtext, die auf alte URLs zeigen, aktualisiert? Sie funktionieren über Weiterleitungen, bilden aber mit der Zeit Ketten.
• Mehrsprachige Struktur: Sind die Beziehungs-Tags zwischen den Sprachen (hreflang) korrekt eingerichtet, zeigt jede Sprachvariante auf die richtige Seite?
• Barrierefreiheit: Farbkontrast, Navigation per Tastatur, Alternativtexte für Bilder. Bei Unternehmenskunden, besonders in Einkaufsprozessen der öffentlichen Hand und großer Firmen, kann dieser Punkt abgefragt werden.

Zusätzliche Risiken bei einem Plattformwechsel

Ein CMS-Wechsel erhöht das Risiko des Relaunch-Projekts deutlich. Beim Massenimport von Blogbeiträgen können Bilder verloren gehen, Tabellen zerfallen, spezielle Formatierungen verschwinden. Nach dem Import sollten mindestens die Seiten mit dem meisten Traffic einzeln visuell geprüft werden.

Außerdem kann es Integrationen geben, die auf der alten Plattform liefen und an die sich niemand erinnert: die Formularverbindung eines E-Mail-Tools, ein Live-Chat-Widget, ein Kalender-Einbettungscode, den der Vertrieb nutzt. Ein Inventar dieser Dinge ist genauso notwendig wie das Seiteninventar.

Checkliste für den Livegang

Die folgende Liste enthält die Prüfungen, die am Tag des Livegangs und danach der Reihe nach empfohlen werden. Das ist ein Vorschlagsrahmen; je nach Komplexität Ihrer Website sollten Punkte ergänzt oder gestrichen werden.

Vor dem Livegang (in der Staging-Umgebung):

1. Alle Templates wurden auf Desktop und Mobil durchgesehen.
2. Von jedem Formular wurde eine Testübermittlung gemacht und im CRM gefunden.
3. Automatische E-Mails (Dankesnachricht, interne Benachrichtigung) funktionieren.
4. Der Analytics-Code ist auf allen Seiten vorhanden und im Echtzeitbericht sichtbar.
5. Conversion-Ziele und Werbe-Tags wurden an die neuen URLs angepasst.
6. Die Weiterleitungskarte ist fertig und mindestens für Seiten mit hohem Traffic getestet.
7. Die 404-Seite ist gestaltet und enthält nützliche Links.
8. Seitentitel und Meta-Beschreibungen wurden geprüft.
9. Die Seitengeschwindigkeit wurde gemessen und mit der alten Website verglichen.
10. Ein Backup wurde erstellt und ein Rollback-Plan geschrieben.

Zum Zeitpunkt des Livegangs:

11. Das noindex-Tag und die Staging-Robots-Regeln wurden entfernt.
12. Die Weiterleitungen wurden aktiviert.
13. HTTPS und Zertifikat wurden verifiziert.
14. Die XML-Sitemap wurde aktualisiert und an die Search Console übermittelt.
15. Startseite, die fünf Seiten mit dem meisten Traffic und alle Conversion-Seiten wurden live einzeln geprüft.

Erste Woche nach dem Livegang:

16. Crawling-Fehler und Indexierungsstatus werden in der Search Console beobachtet.
17. 404-Einträge werden täglich geprüft, fehlende Weiterleitungen ergänzt.
18. Sitzungen, Seitenaufrufe und Conversion-Zahlen werden in Analytics mit der Vorperiode verglichen.
19. Feedback vom Vertriebsteam wurde eingeholt: Funktionieren die von ihnen geteilten Links?
20. Es wurde bestätigt, dass Formularübermittlungen weiterhin im CRM landen.

Erste drei Monate nach dem Livegang:

21. Organischer Traffic und Rankingveränderungen werden auf Seitenebene beobachtet.
22. Daten zum Nutzerverhalten (Heatmap, Session Recording) wurden gesammelt und ausgewertet.
23. Für Seiten mit schwacher Conversion-Performance wurde ein Testplan erstellt.

Die letzte Gruppe ist nicht der Abschluss, sondern die Fortsetzung des Projekts. Die Grundannahme des CRO-Ansatzes ist, dass Conversion-Optimierung kein einmaliger Vorgang ist und dass regelmäßige Datenanalyse und Tests nötig sind, weil sich Nutzerverhalten und Wettbewerb ständig verändern. Die neue Website sollte ein besserer Ausgangspunkt dieses Kreislaufs sein, nicht sein Endpunkt.

Wie interpretiert man einen Traffic-Rückgang nach dem Livegang?

Schwankungen im Traffic nach einem Relaunch sind normal. Entscheidend ist, unterscheiden zu können, welcher Art die Schwankung ist. Das folgende hypothetische Szenario dient dazu, die Interpretationslogik zu zeigen.

Nehmen wir an, drei Wochen nach dem Livegang ist die Zahl der organischen Sitzungen im Vergleich zu den vorherigen drei Wochen von 12.000 auf 9.600 gesunken. Ein Rückgang von 20 Prozent. Bevor Sie in Panik verfallen, sind das die Fragen:

Auf welchen Seiten tritt der Rückgang auf? Wenn der gesamte Rückgang von den 30 bewusst gelöschten Blogbeiträgen kommt, ist das ein erwartetes Ergebnis und ein bereits akzeptierter Preis. Wenn der Rückgang auf den Hauptproduktseiten mit erhaltener URL auftritt, sollte nach einem technischen Problem gesucht werden.

Ist der Vergleichszeitraum fair? Im B2B ist die Saisonalität stark. August mit Oktober zu vergleichen ist irreführend. Wenn möglich sollte auch der gleiche Zeitraum des Vorjahres betrachtet werden.

Ist die Indexierung abgeschlossen? Wenn sich URLs geändert haben, brauchen Suchmaschinen Zeit, die neue Struktur zu crawlen. Die dritte Woche ist noch kein Zeitpunkt für eine endgültige Bewertung.

Ist die Messung dieselbe? Wenn sich das Analytics-Setup auf der neuen Website geändert hat, messen die Zahlen möglicherweise unterschiedliche Dinge. Einstellungen wie Bot-Filterung, Ausschluss internen Traffics oder Sitzungsdefinition können von Null neu aufgesetzt worden sein.

Das Urteil „das Redesign hat den Traffic gesenkt“, gefällt ohne Antwort auf diese vier Fragen, führt meist zu falschen Maßnahmen. Die richtige erste Maßnahme ist, den Rückgang nach Seiten aufzuschlüsseln und zu prüfen, ob diese Aufschlüsselung zu den Entscheidungen im Inventar passt.

Ebenso muss die Ursache eines Rückgangs bei den Conversions nicht das Design sein. Ein Formularfeld könnte zum Pflichtfeld geworden sein, im Datenfluss zum CRM könnte es einen Verlust geben, die Dankesseite könnte nicht als Conversion gezählt werden. Ohne technische Verifizierung sollte nicht das Design beschuldigt werden.

Häufige Fehler

Dieser Abschnitt ist keine Sammelzusammenfassung der in den vorherigen Abschnitten indirekt angesprochenen Risiken, sondern Verhaltensmuster, die eine eigene Erwähnung verdienen.

Mit dem Design beginnen. In Projekten, in denen das Design ohne Inventar und Informationsarchitektur begonnen wird, wird das Design meist noch einmal gemacht. Denn wenn die Seitenstruktur klar wird, zeigt sich, dass die Templates nicht ausreichen.

Inhalte auf die letzte Woche verschieben. Content-Produktion ist der langsamste und abhängigkeitsreichste Teil von Projekten. Die Meinung der Produktexpertin einzuholen, die Freigabe der Rechtsabteilung zu bekommen, die Erlaubnis eines Referenzkunden einzuholen, dauert Wochen. Den Content-Kalender am Projektanfang aufzusetzen und an einen regelmäßigen Rhythmus zu binden, macht diese Arbeit handhabbar; die Beobachtung, dass der Rhythmus in der Content-Produktion meist nicht durch neues Wissen, sondern durch fehlende Planungsdisziplin gestört wird, gilt auch hier (B2B-Content-Kalender).

Die alte Website sofort abschalten. Nach dem Livegang mindestens einige Wochen Zugriff auf eine Kopie der alten Website (nicht öffentlich zugänglich) zu haben, ist wertvoll, um verloren gegangene Inhalte zu finden.

Das Tracking-Setup als letzten Schritt der Entwicklung betrachten. Analytics, Messung und CRM-Integration sind keine Aufgaben, die man am Tag des Livegangs nach dem Motto „fügen wir noch das hinzu“ erledigt. Es sind Funktionen, die getestet werden müssen.

Erfolg nicht definieren. Wird nicht von Anfang an festgehalten, worauf man am Projektende schaut, bewertet jeder nach seinen eigenen Erwartungen. Genauso wichtig wie die Frage, was das Kriterium ist, ist die Frage, wann gemessen wird. Bei einem Relaunch wegen technischer Schulden ist es sinnvoll, nach drei Monaten auf Seitengeschwindigkeit und Publikationsgeschwindigkeit zu schauen; auf die Conversion-Rate zu schauen ist meist zu früh.

Alles gleichzeitig ändern. Wenn Design, Inhalte, URL-Struktur, CMS und Hosting gleichzeitig wechseln, wird es schwer, bei einem Problem die Ursache zu finden. Wenn möglich bewahrt die Trennung von Plattformmigration und Designrelaunch Ihre Diagnosefähigkeit. Das ist nicht immer möglich, verschafft aber, wenn es möglich ist, einen erheblichen Vorteil.

Wo sollten Sie anfangen?

Wenn Sie noch kein Umfangsdokument haben, kann die Reihenfolge so aussehen:

Schreiben Sie zuerst die Begründung des Relaunchs auf einer Seite auf: welches Problem, welcher Nachweis, worauf wir nach dem Projekt schauen. Erstellen Sie dann das Content-Inventar; dieser Schritt allein zeigt Ihnen die tatsächliche Größe des Projekts und ergibt meist ein anderes Bild als die erste Schätzung. Wenn das Inventar fertig ist, schreiben Sie Umfang und Nicht-Umfang auf, bestimmen Sie die Entscheiderin oder den Entscheider und bauen Sie den Zeitplan Phase für Phase auf.

Sind diese drei Schritte abgeschlossen, verändert sich das Gespräch mit der Agentur oder dem internen Team qualitativ. Anstelle des Satzes „wir möchten unsere Website erneuern“ setzen Sie sich mit einem Briefing an den Tisch, das enthält, wie viele Seiten übernommen werden, wie viele Templates nötig sind, welche Integrationen migriert werden müssen und wie der Erfolg gemessen wird. Dieses Briefing beeinflusst direkt sowohl die Qualität des Angebots als auch das Ergebnis, das Sie am Projektende in der Hand haben.

Häufig gestellte Fragen

Wie lange dauert ein Relaunch-Projekt für eine Unternehmenswebsite?

Eine allgemeine Dauer zu nennen wäre irreführend, denn den Zeitplan bestimmen weniger die Seitenanzahl als die Anzahl der Templates, die Kapazität der Content-Produktion, die Anzahl der Sprachen und die Komplexität der Integrationen. Der zuverlässigste Weg, die Dauer zu schätzen, ist, die Phasen einzeln zu betrachten: Inventar und Umfang, Informationsarchitektur, Design, Content, Entwicklung, Migration und Monitoring nach dem Livegang. Stellen Sie von Anfang an fest, welche dieser Phasen bei Ihnen zum Engpass wird. In den meisten B2B-Unternehmen ist dieser Engpass die Content-Produktion, nicht das Design.

Sollten wir unsere URLs beim Relaunch ändern?

Nicht, solange es nicht nötig ist. Ein neues Design erfordert keine URL-Änderung. Ändern Sie die URL nur, wenn sich die Informationsarchitektur wirklich geändert hat, die bestehende Struktur sinnlos ist oder Seiten zusammengeführt werden. Richten Sie für jede geänderte URL eine permanente Weiterleitung (301) ein, erzeugen Sie keine Weiterleitungsketten und testen Sie die Weiterleitungen vor dem Livegang. Die Seiten mit dem höchsten Traffic und den meisten externen Verlinkungen bewusst nicht anzufassen, ist die einfachste Entscheidung zur Risikoreduktion.

Kann man ein Projekt starten, ohne das Content-Inventar erstellt zu haben?

Technisch ja, aber das bedeutet, Budget und Zeitplan zuzusagen, ohne die tatsächliche Größe des Projekts zu kennen. Ohne Inventar weiß man nicht, welche Seiten übernommen, welche neu geschrieben werden und wie viele Weiterleitungen nötig sind. Außerdem fehlt Ihnen der Referenzpunkt, um die Traffic-Veränderung nach dem Livegang zu interpretieren. Das Inventar ist die günstigste Versicherung des Projekts.

Was sollten wir tun, wenn der Traffic nach dem Livegang sinkt?

Schlüsseln Sie den Rückgang zuerst nach Seiten auf. Kommt der Rückgang von bewusst gelöschten Seiten, ist das ein erwartetes Ergebnis. Kommt er von wichtigen Seiten mit erhaltener URL, suchen Sie ein technisches Problem: Das noindex-Tag könnte noch gesetzt sein, eine Weiterleitung könnte fehlen, das Analytics-Setup könnte anders messen. Prüfen Sie auch, ob der Vergleichszeitraum saisonal fair ist. Wenn sich die URL-Struktur geändert hat, braucht die Indexierung Zeit, um sich zu setzen; die ersten Wochen sind für eine endgültige Bewertung zu früh.

Löst eine neue Website das Problem, wenn unsere Conversion-Rate niedrig ist?

Nicht immer. Die Ursache eines Conversion-Problems kann im Design liegen, aber auch im Angebot selbst, in einer falschen Zielgruppe, in der Länge des Formulars oder in der Klarheit der Botschaft. Vor der Relaunch-Entscheidung auf Analytics-Daten, Nutzerverhalten und wenn möglich Nutzer-Feedback zu schauen, gibt Ihnen Sicherheit, dass Sie das richtige Problem lösen. Außerdem ist Conversion-Verbesserung kein einmaliges Projekt, sondern ein fortlaufender Kreislauf aus Test und Messung; eine neue Website kann der Anfang dieses Kreislaufs sein, sie kann ihn nicht ersetzen.

Wie beschleunigen wir den Entscheidungsprozess im Projekt?

Bestimmen Sie eine einzige entscheidungsbefugte Person und kommunizieren Sie sie von Anfang an schriftlich. Positionieren Sie die übrigen Beteiligten als Beitragende; sagen Sie vorab, in welcher Phase und in welchem Format Sie ihre Rückmeldungen einsammeln. Begrenzen Sie die Anzahl der Design-Revisionsrunden und sammeln Sie Feedback nicht über verstreute Kanäle, sondern an einer Stelle. In Unternehmensprojekten verschiebt sich der Zeitplan am meisten nicht in der Produktion, sondern in den Wartezeiten auf Freigaben.

Hinweis: Alle Zahlenbeispiele, Tabellen und Szenarien in diesem Beitrag sind ausdrücklich hypothetische Lehrbeispiele. Sie beruhen nicht auf einem echten Kundenprojekt, einem gemessenen Ergebnis oder einem Branchendurchschnitt. Arbeiten Sie für Umfang, Zeitplan und Risikoprofil Ihres eigenen Projekts mit Ihren eigenen Daten.