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, sondern ein technisches SEO-, Performance- und Qualitätsprojekt. Google selbst dokumentiert in den Hinweisen zu Site Moves, wie viel von einem sauberen Redirect-Mapping abhängt. Für lokale Unternehmen, die für Suchanfragen wie Agentur, Beratung oder Softwareentwicklung in Hamburg gefunden werden wollen, steht dabei sichtbare Reichweite auf dem Spiel.
Ein Relaunch ist ein technisches Projekt, kein reines Redesign
Der häufigste Fehler ist, einen Relaunch als Designprojekt zu behandeln und SEO und Technik erst kurz vor dem Launch dazuzunehmen. Sobald Design, CMS oder Framework wechseln, verändern sich URLs, Ladeverhalten, Metadaten und Tracking gleichzeitig. Jede dieser Ebenen ist ein eigenes Risiko – und alle treffen am selben Tag auf produktiven Traffic.
Der finanzielle Einsatz ist real: Ein professioneller Relaunch im Mittelstand kostet 2026 laut Marktauswertungen meist zwischen 25.000 und 60.000 €, einfachere Projekte starten ab rund 8.000 €. Wer in diesem Rahmen investiert, sollte technische Führung von Anfang an einplanen – nicht erst, wenn die Rankings nach dem Go-live einbrechen. Wir verbinden Relaunches deshalb mit moderner Webentwicklung und messbarer Qualität statt mit reinem Oberflächenwechsel.
Inventar und Redirects: jede alte URL braucht eine Entscheidung
Am Anfang steht ein vollständiges Inventar – ohne Bestandsaufnahme ist unklar, welche Seiten Traffic, Backlinks und Conversions tragen. Ein gutes Inventar führt alle indexierbaren URLs aus Crawl, XML-Sitemap, Analytics und Google Search Console zusammen, samt Titeln, H1, Canonicals, organischen Einstiegsseiten und Statuscodes. Gerade alte Blogartikel, PDFs, Kampagnen-URLs und Bild-URLs werden leicht übersehen – und genau dort gehen Signale verloren.
Anschließend braucht jede alte URL eine bewusste Entscheidung. Dauerhafte Änderungen werden serverseitig mit 301 oder 308 umgesetzt – beide verlieren laut Google keinen PageRank. Redirect-Ketten wie alt -> zwischen-url -> neu sollten vermieden werden (idealerweise höchstens drei Hops), und die Weiterleitungen sollten mindestens 180 Tage bestehen bleiben.
| Entscheidung | Wann | Umsetzung |
|---|---|---|
| 1:1-Redirect | Direkte neue Entsprechung vorhanden | 301/308 serverseitig |
| Themen-Redirect | Inhalt in passende neue Seite integriert | 301/308 auf Zielseite |
| Keine Weiterleitung | URL bleibt unverändert bestehen | – |
| 410 oder 404 | Inhalt bewusst entfernt, keine Alternative | 410 (oder 404) |
Eine ausführlichere operative Checkliste findest du im Beitrag Website-Relaunch ohne SEO-Verlust.
Canonical-Host, Metadaten und interne Links festlegen
Ein Relaunch ist der richtige Zeitpunkt, die kanonische Domain eindeutig zu definieren. Die Website sollte technisch konsistent beantworten, ob https://example.com oder https://www.example.com gilt, ob HTTP konsequent auf HTTPS weiterleitet, wie Trailing Slashes behandelt werden und ob Canonical-Tags auf die finale indexierbare URL zeigen. Canonicals sind dabei kein Ersatz für Weiterleitungen, wenn alte URLs dauerhaft ersetzt werden.
Neue Templates verändern oft SEO-Elemente, ohne dass es auffällt. Prüfe deshalb vor dem Launch für jede wichtige Seite: einen eindeutigen Title Tag, eine zur Suchintention passende Meta-Description, genau eine klare H1, valide strukturierte Daten und interne Links, die auf finale URLs zeigen. Bei mehrsprachigen Websites müssen deutsche und englische Pfade, Canonicals und hreflang-Verweise zusammenpassen. Lokale Seiten sollten relevante Hamburg-Signale enthalten – ohne Keyword-Stuffing.
Core Web Vitals und Performance realistisch planen
Performance entsteht nicht am letzten Projekttag, sondern in Architektur, Bildstrategie, JavaScript-Budget, Caching und Rendering-Strategie. Schon vor dem Relaunch sollte klar sein, welche Seitentypen geschäftskritisch sind, ob server-, statisch- oder clientseitig gerendert wird und welche Performance-Budgets für JavaScript, CSS und Bilder gelten.
Core Web Vitals sind keine reinen Score-Ziele, sondern konkrete Nutzerprobleme: langsame Hauptinhalte, Layout-Verschiebungen und träge Interaktionen. Maßgeblich sind heute drei Metriken – und seit dem 12. März 2024 hat INP die ältere FID-Metrik abgelöst.
| Metrik | Gut | Verbesserung nötig | Schlecht |
|---|---|---|---|
| LCP (Ladezeit) | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP (Reaktivität) | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Layout-Stabilität) | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Die Schwellen stammen von web.dev und werden am 75. Perzentil bewertet. Laborwerte aus Lighthouse sollten mit Felddaten echter Nutzersitzungen kombiniert werden. Wie wir Performance systematisch verbessern, zeigt unser Beitrag zur Core-Web-Vitals-Optimierung.
Barrierefreiheit ist seit dem BFSG Pflicht
Barrierefreiheit ist kein optionaler Prüfpunkt mehr, sondern für viele Websites gesetzlich vorgeschrieben. Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) – ohne Übergangsfrist für betroffene digitale Produkte und Dienstleistungen, etwa Onlineshops und viele B2C-Angebote. Maßstab sind EN 301 549 und WCAG 2.1 Level AA; Verstöße können mit Bußgeldern bis 100.000 € geahndet werden. Kleinstunternehmen mit unter 10 Beschäftigten und höchstens 2 Mio. € Jahresumsatz sind bei Dienstleistungen ausgenommen.
Ein Relaunch ist der ideale Moment, Barrierefreiheit strukturell einzubauen: semantisches HTML mit nachvollziehbarer Überschriftenhierarchie, ausreichende Farbkontraste, Tastaturbedienbarkeit, sichtbare Fokuszustände, verständliche Formularlabels und Alternativtexte. Wer das früh mitdenkt, vermeidet teure Nachbesserungen – und gewinnt nebenbei robustere Struktur für SEO. Mehr dazu unter Barrierefreiheit und in unserer BFSG- und WCAG-Checkliste.
Tracking, Go-live und Post-Launch-Monitoring
Ein Relaunch ohne funktionierendes Tracking macht Erfolge und Fehler unsichtbar. Vor dem Go-live sollte klar sein, welche Ereignisse gemessen werden (Kontaktanfragen, Buchungen, Formular- und Button-Events), welche Consent-Regeln gelten und ob die Search-Console-Property auf die kanonische Domain zeigt. Am Launch-Tag selbst geht es nicht um neue Entscheidungen, sondern um eine strukturierte Abarbeitung: DNS, SSL und HTTPS-Weiterleitung korrekt, kanonischer Host eindeutig, keine versehentlichen Noindex-Tags, robots.txt blockiert keine produktiven Ressourcen, Sitemap enthält nur finale URLs.
Nach dem Go-live beginnt die wichtigste Phase. In den ersten zwei bis vier Wochen sollten 404-Fehler, Indexierungsberichte, organische Klicks, Ranking-Veränderungen und Core-Web-Vitals-Regressionen engmaschig kontrolliert werden. Kleinere Schwankungen sind normal; kritisch sind strukturelle Fehler wie verlorene URLs, falsche Canonicals oder blockierte Ressourcen. Genau hier zahlt sich technische Führung aus – Qualität ist messbar, wie wir in Qualität ist messbar zeigen.
Nächste Schritte
Drei Fragen klären die Risikolage eines Relaunchs schneller als jede Design-Diskussion:
- Inventar: Liegt ein vollständiges URL-Mapping inklusive Redirect-Entscheidungen vor?
- Performance & Barrierefreiheit: Gibt es definierte Budgets und einen BFSG-Check vor dem Go-live?
- Kontrolle: Wer überwacht in den ersten Wochen Indexierung, Rankings und Core Web Vitals?
Wenn du einen Relaunch planst und technische Risiken früh klären möchtest, sieh dir unsere Webentwicklung an oder sprich uns direkt über die Kontaktseite an.
