Ein Website Relaunch ist für Hamburger Unternehmen oft ein wichtiger Schritt: Die Marke soll moderner wirken, Inhalte sollen besser konvertieren, die Technik soll wartbarer werden und die Website soll in Google stabil sichtbar bleiben. Genau hier entsteht das Risiko. Wenn Design, CMS oder Framework wechseln, ändern sich häufig URLs, interne Links, Ladezeiten, Metadaten, Tracking und technische Signale.
Ein Relaunch ist deshalb kein reines Designprojekt. Er ist ein technisches SEO-Projekt, ein Performance-Projekt und ein Qualitätsprojekt. Für Unternehmen in Hamburg, die lokal gefunden werden möchten, betrifft das nicht nur allgemeine Rankings, sondern auch Sichtbarkeit für Suchanfragen wie Dienstleister, Agentur, Beratung oder Softwareentwicklung in Hamburg.
Wenn Sie Ihren Relaunch mit moderner Webentwicklung, sauberer Barrierefreiheit und messbarer Performance verbinden möchten, sollten die folgenden Punkte vor dem Go-live geklärt sein.
Relaunch-Inventar: Bestehende Seiten, Rankings und Signale sichern
Am Anfang steht ein vollständiges Inventar. Ohne Bestandsaufnahme ist unklar, welche Seiten organischen Traffic bringen, welche URLs Backlinks haben, welche Inhalte zusammengelegt werden können und welche Seiten aus geschäftlicher Sicht wichtig sind.
Ein gutes Relaunch-Inventar enthält:
- alle indexierbaren URLs aus Crawl, XML-Sitemap, Analytics und Google Search Console
- Seitentitel, Meta-Descriptions, H1-Überschriften und Canonicals
- organische Einstiegsseiten mit Klicks, Impressionen und Conversions
- lokale Landingpages mit Hamburg-Bezug
- Seiten mit externen Links, Erwähnungen oder Kampagnen-Traffic
- Statuscodes, Weiterleitungen und Noindex-Signale
- Inhalte, die bestehen bleiben, ersetzt, zusammengeführt oder entfernt werden
Wichtig ist, auch alte und weniger sichtbare Inhalte zu erfassen: Blogartikel, PDFs, Kampagnen-URLs, alte Leistungsseiten, Bild-URLs und lokalisierte Varianten. Genau dort liegen oft Signale, die beim Relaunch versehentlich verloren gehen.
Redirects: Jede alte URL braucht eine Entscheidung
Weiterleitungen gehören zu den kritischsten Relaunch-Aufgaben. Wenn alte URLs nach dem Go-live auf 404 laufen oder pauschal auf die Startseite zeigen, verlieren Nutzer und Suchmaschinen Kontext. Für jede alte URL sollte es deshalb eine klare Zielentscheidung geben.
Typische Entscheidungen sind:
- 1:1-Redirect: Die alte Seite hat eine direkte neue Entsprechung.
- Themen-Redirect: Der Inhalt wurde sinnvoll in eine neue, thematisch passende Seite integriert.
- Keine Weiterleitung: Die URL bleibt bestehen und wird weiterhin ausgeliefert.
- 410 oder 404: Der Inhalt wurde bewusst entfernt und hat keine passende Alternative.
Dauerhafte Änderungen sollten serverseitig mit 301 oder 308 umgesetzt werden. Redirect-Ketten wie alt -> zwischen-url -> neu sollten vermieden werden, weil sie Crawling verlangsamen und Fehler wahrscheinlicher machen. Prüfen Sie vor dem Launch besonders die wichtigsten organischen Einstiegsseiten, URLs mit Backlinks, alte Sitemap-URLs und Varianten mit oder ohne Slash, www, HTTP und HTTPS.
Eine ausführlichere operative Checkliste finden Sie im Beitrag Website-Relaunch ohne SEO-Verlust.
Canonical Host und URL-Varianten festlegen
Ein Relaunch ist der richtige Zeitpunkt, die kanonische Domain eindeutig festzulegen. Die Website sollte technisch konsistent beantworten:
- Wird
https://example.comoderhttps://www.example.comverwendet? - Leiten HTTP-Varianten konsequent auf HTTPS weiter?
- Gibt es einheitliche Regeln für Trailing Slashes?
- Werden Groß- und Kleinschreibung sauber behandelt?
- Zeigen Canonical-Tags auf die finale indexierbare URL?
- Stimmen Canonicals, interne Links, Sitemap und hreflang-Verweise überein?
Canonical-Tags sind kein Ersatz für Weiterleitungen, wenn alte URLs dauerhaft ersetzt werden. Sie helfen aber, bevorzugte Varianten und Duplikate sauber zu signalisieren. Gerade bei mehrsprachigen Websites sollte geprüft werden, ob deutsche und englische Pfade, Canonicals und hreflang-Verweise zusammenpassen.
Metadaten, Struktur und interne Links prüfen
Neue Templates können SEO-Elemente verändern. Deshalb sollten Title Tags, Meta-Descriptions, Überschriften, Open-Graph-Daten, strukturierte Daten und interne Links nicht erst nach dem Launch geprüft werden.
Für jede wichtige Seite sollten Sie kontrollieren:
- Hat die Seite einen eindeutigen Title Tag?
- Passt die Meta-Description zur Suchintention?
- Gibt es genau eine klare H1?
- Sind strukturierte Daten valide und realistisch?
- Verweisen interne Links auf finale URLs?
- Sind Breadcrumbs, Navigation und Footer konsistent?
- Enthalten lokale Seiten relevante Hamburg-Signale, ohne Keyword-Stuffing?
SEO-optimierte Metadaten ersetzen keine guten Inhalte. Sie helfen aber, vorhandene Inhalte korrekt einzuordnen und in Suchergebnissen verständlich darzustellen.
Barrierefreiheit früh mitplanen
Barrierefreiheit sollte nicht als nachträglicher Prüfpunkt behandelt werden. Sie beeinflusst Struktur, Komponenten, Farbkontraste, Tastaturbedienung, Formularlogik und Fehlermeldungen. Je später diese Themen geprüft werden, desto teurer werden Korrekturen.
Zum Relaunch gehören mindestens:
- semantische HTML-Struktur mit nachvollziehbarer Überschriftenhierarchie
- ausreichende Farbkontraste
- bedienbare Navigation per Tastatur
- sichtbare Fokuszustände
- verständliche Formularlabels und Fehlermeldungen
- Alternativtexte für relevante Bilder
- keine Inhalte, die nur über Hover oder Animation erreichbar sind
Barrierefreiheit ist außerdem ein Qualitätsindikator für technische Umsetzung. Eine Website, die strukturell sauber, tastaturbedienbar und verständlich ist, ist häufig auch robuster für SEO, Wartung und Conversion-Optimierung. Mehr dazu finden Sie unter Barrierefreiheit.
Performance und Core Web Vitals realistisch planen
Performance entsteht nicht am letzten Projekttag. Sie hängt von Architektur, Bildstrategie, JavaScript-Budget, Hosting, Caching, Font-Ladung, Drittanbieter-Skripten und Komponenten-Design ab.
Für einen Relaunch sollten Sie früh definieren:
- Welche Seitentypen sind geschäftskritisch?
- Welche Bilder müssen in welcher Größe ausgeliefert werden?
- Welche Skripte sind wirklich notwendig?
- Wird serverseitig, statisch oder clientseitig gerendert?
- Welche Cache-Regeln gelten für Seiten, Assets und APIs?
- Wie werden Fonts geladen?
- Welche Performance-Budgets gelten für JavaScript, CSS und Bilder?
Lighthouse und Core Web Vitals sind dabei keine reinen Score-Ziele. Sie zeigen konkrete Nutzerprobleme: langsame Hauptinhalte, Layout-Verschiebungen, blockierendes JavaScript oder träge Interaktionen. Wichtig sind vor allem Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift. Laborwerte aus Lighthouse sollten mit Felddaten aus echten Nutzersitzungen kombiniert werden, sobald genügend Daten vorliegen.
Tracking, Consent und Messbarkeit
Ein Relaunch ohne funktionierendes Tracking macht Erfolge und Fehler schwer sichtbar. Vor dem Go-live sollte klar sein, welche Ereignisse gemessen werden, welche Consent-Regeln gelten und welche Daten wirklich benötigt werden.
Prüfen Sie mindestens:
- Analytics- oder Webanalyse-Setup
- Consent-Banner und Consent Mode, falls relevant
- Conversion-Ziele für Kontaktanfragen, Buchungen, Downloads oder Käufe
- Formular- und Button-Events
- Search Console Propertys für die kanonische Domain
- Ausschluss interner Zugriffe, soweit sinnvoll
- korrekte UTM- und Kampagnen-Auswertung
Tracking muss datenschutzkonform umgesetzt werden. Gleichzeitig sollte es belastbar genug sein, um nach dem Relaunch organische Sichtbarkeit, Leads, technische Fehler und Conversion-Veränderungen beurteilen zu können.
Launch-Checkliste für den Go-live
Am Launch-Tag geht es nicht darum, alles neu zu entscheiden. Es geht darum, geplante Kontrollen strukturiert abzuarbeiten.
Eine kompakte technische Checkliste:
- DNS, SSL und Hosting sind korrekt konfiguriert
- HTTP leitet auf HTTPS weiter
- die kanonische Host-Variante ist eindeutig
- alte URLs leiten korrekt auf neue Ziele weiter
- keine wichtigen Seiten sind versehentlich auf Noindex
robots.txtblockiert keine produktiven Ressourcen- XML-Sitemap enthält nur finale indexierbare URLs
- interne Links zeigen nicht auf Staging, alte Domains oder Redirects
- Metadaten und strukturierte Daten sind vorhanden
- wichtigste Formulare, CTAs und Kontaktwege funktionieren
- Tracking und Consent funktionieren in realen Browsern
- Lighthouse-Checks zeigen keine kritischen Regressionen
Gerade für lokale Unternehmen in Hamburg sollten Kontaktseite, Standortinformationen, Impressum, lokale Leistungsseiten und strukturierte Unternehmensdaten besonders sorgfältig geprüft werden.
Post-Launch-Monitoring: Die ersten Wochen entscheiden
Nach dem Go-live beginnt die wichtigste Kontrollphase. Suchmaschinen müssen die neue Struktur crawlen, Nutzer treffen auf neue Seiten, Tracking sammelt neue Daten und technische Fehler werden sichtbar.
In den ersten zwei bis vier Wochen sollten Sie regelmäßig prüfen:
- 404-Fehler und fehlerhafte Weiterleitungen
- Crawl-Statistiken und Indexierungsberichte in der Search Console
- organische Klicks und Impressionen für wichtige Seiten
- Ranking-Veränderungen bei zentralen Suchbegriffen
- Core Web Vitals und Lighthouse-Regressionen
- Server-Logs oder Hosting-Fehler, falls verfügbar
- Conversion-Rate und Formularfehler
- auffällige Einbrüche bei lokalen Landingpages
Kleinere Schwankungen sind nach einem Relaunch normal. Kritisch sind strukturelle Fehler: verlorene URLs, falsche Canonicals, blockierte Ressourcen, fehlende Metadaten, kaputtes Tracking oder langsame Templates. Diese Themen sollten schnell behoben werden, bevor sie sich dauerhaft in Sichtbarkeit und Nutzerverhalten niederschlagen.
Fazit: Ein Website Relaunch braucht technische Führung
Ein erfolgreicher Website Relaunch in Hamburg ist kein einmaliger Go-live, sondern ein kontrollierter Prozess. Design, Inhalte, SEO, Performance, Barrierefreiheit und Tracking müssen gemeinsam geplant werden. Erst dann entsteht eine Website, die nicht nur besser aussieht, sondern auch schneller, zugänglicher, messbarer und langfristig sichtbarer ist.
Wenn Sie einen Relaunch planen und technische Risiken früh klären möchten, sprechen Sie uns über die Kontaktseite an.




