Ein erfolgreicher Build ist nur der Anfang
Ein Produktionsbuild ist wichtig, weil er viele strukturelle Fehler früh sichtbar macht. Er zeigt unter anderem, ob TypeScript, Routing und statische Erzeugung zusammenpassen. Für einen Launch reicht dieses Signal allein aber nicht. Ein Build kann erfolgreich sein, obwohl eine Seite ein falsches H1, eine zu kurze Meta Description oder einen Link auf eine nicht veröffentlichte Route enthält.
Deshalb behandeln wir den Build als eine Ebene in einer Kette von Prüfungen. Jede Ebene beantwortet eine andere Frage: Ist der Code syntaktisch sauber? Sind die Daten gültig? Entspricht die veröffentlichte Seite dem vorgesehenen SEO- und Publication-Contract? Funktioniert sie auch in realen Viewports?
Lint und Typecheck sind frühe Schutzschichten
Linting und Typechecking verhindern nicht jeden Fehler, aber sie reduzieren eine große Klasse vermeidbarer Probleme. Unbenutzte Variablen, fehlerhafte Typannahmen oder inkonsistente Schnittstellen sollten nicht erst im Browser auffallen. Je früher solche Fehler sichtbar werden, desto günstiger und eindeutiger lassen sie sich beheben.
Diese Haltung passt zu unserer Arbeitsweise: Fehler sollen möglichst dort auffallen, wo sie entstehen. Technische Qualität beginnt deshalb nicht erst beim finalen Test, sondern bereits bei klaren Datenstrukturen und strengeren Entwicklungsregeln.
Publication und Sitemap müssen zusammenpassen
Eine Seite sollte nur dann in der Sitemap auftauchen, wenn sie tatsächlich zur Veröffentlichung freigegeben ist. Umgekehrt darf eine veröffentlichte Seite nicht versehentlich aus der Sitemap fehlen. Deshalb prüfen wir Veröffentlichungsstatus, Routen und Sitemap gegeneinander und behandeln Abweichungen als Fehler.
Das wird besonders wichtig, sobald geplante Veröffentlichungen dazukommen. Ein zukünftiger Beitrag darf bereits vollständig im Repository liegen und trotzdem noch nicht indexierbar sein. Erst wenn das Veröffentlichungsdatum erreicht ist, sollen Seite, Kategorie und Sitemap den neuen Stand widerspiegeln.
SEO prüfen wir auf Seitenebene
SEO-Qualität besteht für uns nicht aus einer einzelnen Kennzahl. Wir prüfen Titel, Meta Description, Canonical, H1-Struktur und Indexierbarkeit jeder veröffentlichten Seite. Bei Artikeln kommen strukturierte Daten wie Article und BreadcrumbList hinzu. So lassen sich Inkonsistenzen erkennen, bevor Suchmaschinen sie dauerhaft erfassen.
Gerade auf einer Dachmarken-Seite wie Heaviside Solutions ist diese Konsistenz wichtig, weil Projektprofile, Vertrauensseiten und redaktionelle Einblicke unterschiedliche Rollen haben, aber trotzdem unter einer gemeinsamen technischen Basis ausgeliefert werden.
Browser-Tests finden andere Fehler als der Build
Ein Build kennt keine reale Bildschirmbreite. Deshalb testen wir veröffentlichte Seiten zusätzlich in echten Browsern und auf unterschiedlichen Viewports. Dabei fallen Probleme auf, die im Code unauffällig bleiben können: horizontaler Overflow, nicht sichtbare Fokuszustände, kontrastarme Texte oder Elemente, die auf kleinen Displays ihre Struktur verlieren.
Die Seite zur Barrierefreiheit beschreibt den Anspruch dahinter. Automatisierte Browser- und WCAG-Prüfungen ersetzen keine vollständige manuelle Prüfung, erhöhen aber die Chance, wiederkehrende Probleme konsequent zu erkennen.
Security Header gehören zum Launch
Security Header sind kein sichtbares Designmerkmal, aber Teil einer belastbaren Auslieferung. Content Security Policy, Referrer Policy, X-Content-Type-Options, Frame-Schutz und Permissions Policy begrenzen bestimmte Browserfähigkeiten und reduzieren unnötige Angriffsflächen.
Wir prüfen diese Header sowohl lokal als auch nach der eigentlichen Veröffentlichung. Denn erst der Live-Server zeigt, ob die Konfiguration tatsächlich so beim Browser ankommt, wie sie vorgesehen war.
Der Live-Audit ist der letzte Schritt
Nach dem Deploy ist die Arbeit noch nicht automatisch abgeschlossen. Wir prüfen die Produktionsdomain erneut: HTTP-Status, Weiterleitungen, Canonicals, Sitemap, robots.txt, Security Header und TLS. Bei mehreren Subdomains gehört auch ein Smoke-Test der angrenzenden Projekte dazu, damit ein Domainwechsel nicht unbeabsichtigt andere Systeme beeinträchtigt.
Diese Trennung war beim Wechsel der Hauptdomain besonders relevant, weil Revora, Elanvoro und ScopeLedger eigenständig erreichbar bleiben mussten. Ein Launch gilt für uns erst dann als sauber, wenn auch solche Abhängigkeiten ausdrücklich geprüft wurden.
Ein Launch ist ein kontrollierter Übergang, kein einzelner Klick
Der wichtigste Gedanke hinter diesen Prüfungen ist für uns, einen Launch nicht als isolierten Moment zu behandeln. Eine Website wechselt von einem kontrollierten Entwicklungszustand in eine öffentliche Umgebung, in der Browser, Suchmaschinen, externe Dienste und reale Nutzer gleichzeitig auf sie zugreifen. Deshalb prüfen wir nicht nur, ob der neue Stand funktioniert, sondern auch, ob bestehende Verbindungen erhalten bleiben, Weiterleitungen korrekt greifen und die veröffentlichte Struktur tatsächlich der geplanten Informationsarchitektur entspricht. Gerade bei einem Relaunch ist diese Übergangsphase mindestens so wichtig wie der eigentliche Build.
Nach der Veröffentlichung beobachten wir deshalb weiterhin, ob Suchmaschinen die neue Sitemap übernehmen, ob unerwartete alte URLs auftauchen und ob externe Dienste weiterhin erreichbar sind. Ein erfolgreicher Launch beendet nicht die Verantwortung für das System; er verändert lediglich die Art der Prüfung. Vorher suchen wir Fehler in einer kontrollierten Umgebung, danach achten wir stärker auf reale Auslieferung, Indexierung und Rückmeldungen. Diese Kombination aus Vorbereitung und Nachkontrolle ist für uns wesentlich belastbarer als die Hoffnung, dass ein grüner Deploy allein bereits alle relevanten Risiken abgedeckt habe.