Field Note: Wie ich einen Relaunch prüfe, bevor er live geht

Ein Relaunch ist für mich eine Systemmigration

Ich gebe einen Relaunch nicht frei, nur weil die neue Website gut aussieht und die wichtigsten Seiten einen Statuscode 200 zurückgeben. Für mich ist ein Relaunch eine kontrollierte Systemmigration: Inhalte, URLs, Funktionen und Betriebsabläufe wechseln gemeinsam in einen neuen Zustand. Geprüft werden muss deshalb nicht nur die Oberfläche, sondern das Zusammenspiel.

Mein erster Impuls wäre lange gewesen, eine Runde durch die Seiten zu machen: Startseite, Navigation, ein paar Unterseiten, mobil und am Desktop. Das gehört dazu. Aber es beantwortet nur einen Teil der Frage. Eine Seite kann korrekt dargestellt werden und trotzdem auf die falsche Adresse verweisen, wichtige Inhalte verlieren oder ein Formular abschicken, ohne dass der Vorgang im nächsten System ankommt.

Ich behandle den Go-Live deshalb nicht als Designabnahme mit einem technischen Anhang. Design, Content, SEO, Technik, Nutzung und Betrieb sind verschiedene Perspektiven auf dasselbe System. Wenn eine davon fehlt, ist der Check unvollständig.

Zuerst prüfe ich, ob der Inhalt angekommen ist

Vor dem Relaunch interessiert mich nicht nur, ob einzelne Seiten vorhanden sind. Ich prüfe, ob die Inhalte, die im neuen System gebraucht werden, tatsächlich mitgekommen sind und dort sinnvoll funktionieren. Dazu gehören vollständige Texte, passende Seitentitel und eine nachvollziehbare Überschriftenstruktur. Auch interne Links müssen auf die vorgesehenen Ziele führen.

Bei einer Migration können Inhalte formal übertragen sein und trotzdem in der neuen Struktur nicht mehr richtig arbeiten. Ein Link kann auf eine alte URL zeigen. Eine Überschrift kann visuell wie ein Titel aussehen, aber in der Dokumentstruktur an der falschen Stelle stehen. Ein Metadatenfeld kann leer bleiben, weil sich sein Platz oder seine Bedeutung im neuen Modell geändert hat. Das sind keine Fragen, die sich mit einem schnellen Blick auf die Startseite erledigen.

Ich gehe deshalb vom Inhalt und seiner Funktion aus: Welche Seitenarten gibt es? Welche Informationen müssen auf ihnen erhalten bleiben? Welche Beziehungen zwischen Seiten sind wichtig? Und woran erkenne ich, dass eine Seite nicht nur übertragen, sondern sinnvoll in die neue Struktur eingeordnet wurde?

Dabei hilft mir der Gedanke, dass Sichtbarkeit nicht erst bei den Metadaten beginnt. Sie hängt auch davon ab, wie Inhalte strukturiert sind und wie sie miteinander verbunden werden. Wenn der Relaunch die Contentstruktur verändert, muss ich diese Veränderung mitprüfen – nicht erst später in einem separaten SEO-Audit.

SEO ist mehr als ein grüner Statuscode

Bei einem Relaunch prüfe ich gezielt, was mit den bisherigen URLs passiert. Gibt es für veränderte Adressen passende Redirects? Zeigen Canonicals auf die beabsichtigten Seiten? Ist die Sitemap stimmig, und lässt sich die neue Website so indexieren, wie es vorgesehen ist? Diese Punkte hängen zusammen: Eine Seite kann erreichbar sein, während Suchmaschinen eine andere Adresse als maßgeblich verstehen oder wichtige Inhalte gar nicht zur Entdeckung angeboten werden.

Redirect-Regeln und Prüfskripte nutze ich auch bei meinen eigenen Nischenportalen für SEO- und Linkaudits. Dabei geht es mir nicht darum, möglichst viele technische Signale abzuhaken. Ich will nachvollziehen, welche Verbindungen zwischen bestehenden und neuen Seiten erhalten bleiben müssen und ob die Regeln das tatsächlich abbilden. Ein Redirect ist nicht einfach eine Weiterleitung irgendwohin; er soll den Übergang zu einem passenden Ziel ermöglichen.

Für mich ist wichtig, Regeln vor dem Livegang überprüfbar zu machen. Wenn ich eine URL-Zuordnung ändere, will ich nicht allein darauf vertrauen, dass sie plausibel aussieht. Ich prüfe, ob die vorgesehene Adresse erreichbar ist und ob interne Links und andere Verweise zum neuen Zustand passen. So wird aus einer Liste von Annahmen ein überprüfbares Ergebnis.

Was ich zuerst prüfe: Welche Adressen und Inhaltsbeziehungen müssen den Wechsel überstehen? Erst wenn das klar ist, kann ich Redirects, Canonicals und Sitemap sinnvoll beurteilen.

Funktionen prüfe ich entlang ihrer Nutzung

Ein Relaunch verändert oft mehr als Seiten und Gestaltung. Formulare, Events oder API-Verbindungen können betroffen sein, auch wenn die Oberfläche unverändert wirkt. Darum prüfe ich Funktionen nicht nur danach, ob sie sichtbar vorhanden sind, sondern danach, ob der vorgesehene Ablauf funktioniert.

Bei einem Formular gehören für mich mehrere Fragen zusammen: Kann ich es ausfüllen und absenden? Wird der nächste Zustand verständlich angezeigt? Sind Fehlermeldungen hilfreich, wenn etwas nicht funktioniert? Falls Daten an einen weiteren Dienst übergeben werden, kommt die Übergabe dort an? Dass ein Button klickbar ist, beweist noch nicht, dass die Funktion zuverlässig arbeitet.

Ähnlich sehe ich Events und APIs. Entscheidend ist nicht allein, ob eine Verbindung technisch erreichbar scheint. Ich möchte verstehen, welcher Vorgang sie auslöst und was bei einer erfolgreichen oder fehlgeschlagenen Antwort passiert. Fehlerlogs sind dabei eine zusätzliche Sicht auf das System. Sie ersetzen keinen Nutzungstest, können aber zeigen, ob im Hintergrund Probleme auftreten, die sich in einer kurzen Sichtprüfung nicht offenbaren.

Auch UX ist für mich nicht auf den idealen Ablauf beschränkt. Ich prüfe Navigation und mobile Darstellung, aber auch leere Zustände und Fehlermeldungen. Was sieht jemand, wenn noch keine Ergebnisse vorhanden sind? Ist erkennbar, wie es weitergeht? Eine leere Fläche kann technisch korrekt sein und trotzdem keine gute Orientierung geben. Der Relaunch muss nicht nur im Erfolgsfall verständlich bleiben.

Betrieb gehört in den Go-Live-Check

Wenn Inhalte und Funktionen geprüft sind, bleibt eine Frage, die im Designreview leicht untergeht: Wie lässt sich die Änderung betreiben und notfalls zurücknehmen? Vor dem Go-Live will ich wissen, ob ein Backup vorhanden ist, ob Monitoring vorgesehen ist und wie ein Rollback grundsätzlich möglich wäre. Das ist keine pessimistische Zusatzübung. Es ist Teil davon, eine Änderung kontrolliert auszuführen.

Ein Check sollte außerdem trennen zwischen dem, was vor dem Start nachweisbar ist, und dem, was erst im laufenden Betrieb sichtbar wird. Vorher kann ich Redirect-Regeln, Seiten, Formulare und vorgesehene Verbindungen prüfen. Danach brauche ich weiterhin einen Blick auf Fehler und Funktion. Der Go-Live beendet die Prüfung nicht; er verschiebt sie in einen anderen Betriebszustand.

Inzwischen denke ich dabei in einer einfachen Abfolge: erst den vorhandenen Zustand verstehen, dann die geplante Änderung prüfen und freigeben, schließlich belegen, was sich verändert hat. Das entspricht dem Prinzip Know → Change → Prove. Es verhindert, dass ich eine Änderung mit einem Erfolg verwechsle, nur weil sie technisch ausgeführt wurde.

Meine Faustregel: Ich gebe einen Relaunch erst frei, wenn ich nicht nur sehe, dass die neue Website funktioniert, sondern auch nachvollziehen kann, was mit Inhalten und URLs passiert ist, wie zentrale Abläufe geprüft wurden und wie sich der neue Zustand beobachten oder zurücknehmen lässt.

Weiterführend

• WordPress-Relaunch ohne Kontrollverlust planen
• Know → Change → Prove: WordPress-Änderungen sicher durchführen
• Was eine gute Übergabe enthält