Wenn du relauncht, sieht Google eine neue Website. Dein Job ist: Signale sauber übertragen.
Damit das zuverlässig klappt, brauchst du zwei Dinge:
- Eine saubere Vorbereitung (Inventar + Mapping)
- Einen kontrollierten Launch (Checks + Monitoring)
In diesem Beitrag bekommst du eine technische Checkliste, die du wirklich abarbeiten kannst – inklusive Templates, typischen Fehlern und „Launch Day“-Plan.
Die häufigsten Ursachen für Rankingverluste
Wenn nach einem Relaunch Sichtbarkeit wegbricht, liegt es fast nie an „Google mag das neue Design nicht“, sondern an diesen Klassikern:
- Wichtige URLs liefern 404 oder werden falsch weitergeleitet
- Redirect-Ketten (A → B → C) statt 1:1 Weiterleitung
- Falsche Canonicals (z.B. auf alte URLs, auf die Startseite oder auf falsche Host-Variante)
- Indexierung blockiert (robots/meta noindex) oder Sitemap/Robots sind „kaputt“
- Interne Links zeigen nach dem Launch noch auf alte Pfade
- Content/Struktur wird stark geändert, ohne dass Google „versteht“, was wohin gehört
- Performance wird schlechter (Core Web Vitals), gerade bei neuen Bildern/Fonts/Tracking
Wenn du diese Punkte sauber abfängst, sind Relaunches sehr gut beherrschbar.
Schritt 0: Vorher sichern
Bevor du irgendetwas umstellst, machst du eine Bestandsaufnahme. Ziel: Du willst wissen, welche Seiten wirklich zählen – und welche Signale du übertragen musst.
A. URL-Inventar erstellen
- Sitemap(s) ziehen (aktuell live)
- Crawl durchführen (z.B. Screaming Frog / Sitebulb) → Liste aller indexierbaren URLs
- (Optional) Server-Logs auswerten: welche URLs werden wirklich besucht?
B. Top-Seiten bestimmen
- Google Search Console: Top Seiten nach Klicks/Impressionen
- Analytics/Matomo: Top Landingpages nach Sessions/Conversions
- Wichtig: nicht nur „Traffic“, sondern Seiten mit Leads/Conversions priorisieren
C. Aktuelle interne Linkstruktur sichern
- Export aus dem Crawl: interne Inlinks pro URL
- So findest du später schnell „wichtige Hubs“ (Seiten mit vielen internen Links)
Faustregel: Wenn du nur 20% der URLs perfekt mappst, aber genau die 20% mit 80% Wert, ist das schon die halbe Miete.
1) URL-Mapping (das Herzstück)
Für jede wichtige alte URL:
- passende neue URL definieren
- 1:1 Redirect (ohne Kette)
Das URL-Mapping ist der wichtigste Teil des Relaunches. Hier wird entschieden, ob Linkkraft/Rankings sauber „umziehen“.
Mapping-Template (einfach als Tabelle führen)
Du kannst es als Google Sheet/Excel oder CSV pflegen. Spalten, die sich bewährt haben:
| Alte URL | Neue URL | Status | Redirect-Typ | Notiz |
| --- | --- | --- | --- | --- |
| /leistungen/webdesign | /webseiten | 301/308 | permanent | Inhalt zusammengeführt |
| /blog/alter-post | /blog/neuer-post | 301/308 | permanent | Slug geändert |
| /produkte/xyz | (entfällt) | 410 | gelöscht | kein Ersatz |
Wichtig:
- Nicht alles auf die Startseite redirecten. Das ist fast immer ein Ranking-Killer.
- Wenn eine Seite wirklich wegfällt: lieber 410 (Gone) oder eine saubere Alternative.
- Vermeide Ketten: alte URL muss direkt zur finalen neuen URL gehen.
Welche Statuscodes?
- 301 / 308 = permanent (beides ok; 308 ist „permanent + Method beibehalten“)
- 302 / 307 = temporär (für Relaunch meist nicht das richtige Signal)
Mehr Kontext: Canonicals & Redirects
Praxis-Beispiele (typische Muster)
- Trailing Slash vereinheitlichen:
/seite↔/seite/ - Groß-/Kleinschreibung:
/SEO→/seo - Parameter-Versionen:
?utm=sauber auf Canonical-URL - Kategorien/Strukturwechsel:
/leistungen/webdesign→/webdesign
2) Canonicals & Host-Konsistenz
- www → non-www permanent
- http → https permanent
- Canonical pro Seite korrekt
Details: Canonicals & Redirects
Ergänzende Checks, die oft vergessen werden:
- Nur eine Host-Variante ist „die echte“ (z.B.
https://22orbit.deohne www) - Self-Canonical auf jeder indexierbaren Seite (außer du hast bewusst Duplicate-Strategie)
- Keine Canonicals auf 404-/Redirect-URLs
- Pagination / Filter: prüfen, ob Canonical logisch ist (nicht alles auf Seite 1)
3) Indexierung & Robots/Sitemap
robots.txtnicht aus Versehen zu striktsitemap.xmlnur Canonicals- keine 404/Redirect-URLs in der Sitemap
Guide: Robots.txt & Sitemap.xml
Zusatz-Checkliste:
- Meta Robots: keine „versteckten“
noindex/nofollowaus Staging - X-Robots-Tag Header (kommt gerne bei PDF/Assets oder Proxy/CDN vor)
- Staging-Domain: sollte blockiert sein, Live-Domain nicht
- Sitemap nach Launch in GSC einreichen und auf Fehler prüfen
4) Interne Links aktualisieren
Wenn du nur Redirects machst, verlierst du interne Effizienz.
Struktur-Ansatz: Interne Links & Topic Clusters
Was du konkret tun solltest:
- Navigation/Footer/CTA-Links auf neue URLs umstellen (nicht über Redirect laufen lassen)
- In Content-Seiten: die wichtigsten internen Links direkt aktualisieren (vor allem Hubs)
- Prüfen: interne Links auf 404/Redirects → Fixliste erstellen
Interne Links sind „Google-Navigation“. Je weniger Umwege, desto besser.
5) Content & Struktur: “Gleiche Intention” bewahren
Relaunch = oft neue Texte, neue Struktur, zusammengelegte Seiten. Das ist okay – aber du solltest die Suchintention sauber abbilden.
- Wenn du 3 alte Seiten zu 1 neuen machst: die neue Seite muss alles Relevante abdecken
- Wenn du Seiten splittest: jede neue Seite braucht klare Keywords/Intention
- Titles/H1 nicht komplett „random“ ändern, wenn du Rankings behalten willst
Praktisch: Exportiere vor dem Relaunch Titles/H1 und vergleiche nach dem Relaunch.
6) Structured Data & Snippets (optional, aber wertvoll)
Wenn du strukturierte Daten nutzt (z.B. Organization, BreadcrumbList, FAQPage, Article), dann:
- Nach Launch testen (Rich Results Test)
- Breadcrumbs prüfen (passen Pfade/URLs?)
- FAQ-Markup nur einsetzen, wenn die Inhalte wirklich FAQ sind
Guide: Structured Data (JSON-LD) lokal
5) Performance nach dem Relaunch
Relaunch = neue Assets. Miss LCP/INP/CLS.
Basis: Core Web Vitals erklärt
Typische Performance-Fallen nach Relaunch:
- Hero-Bilder zu groß / nicht optimiert → LCP schlecht
- Webfonts blockieren Rendering
- Zu viel Third-Party (Chat, Tracking, Consent, Widgets)
Vertiefung:
7) Tracking, Consent & Messbarkeit nicht kaputt-launchen
Viele Relaunches „sehen“ nach dem Launch gut aus – aber Leads brechen ein, weil Tracking/Forms/Events nicht mehr sauber laufen.
Checkliste:
- Kontaktformulare/Bewerbungsformulare testen (auch mobile)
mailto:/Telefonlinks testen- Tracking-Events (Form Submit, Button Klicks) testen
- Consent-Banner: lädt Tracking erst nach Consent?
Passend dazu:
Launch Day: Ablaufplan (damit nichts vergessen wird)
Ein stabiler Relaunch ist weniger „Hoffen“, mehr „Prozess“.
Vor dem DNS-/Deploy-Switch
- Redirect-Regeln deployed und getestet (Stichprobe + wichtige URLs)
robots.txtkorrekt (Live nicht blockiert)- Sitemap zeigt nur 200er Canonicals
- Canonicals stimmen (Stichprobe)
- 404-Seite vorhanden, aber 404 wirklich 404
Direkt nach dem Launch (erste 60 Minuten)
- Crawl der wichtigsten Seiten (Homepage + Top Landingpages + Service-Seiten)
- Stichprobe alter URLs → landen sauber auf neuer Ziel-URL (ohne Kette)
- GSC: Sitemap einreichen, URL-Prüfung für zentrale Seiten
Tag 1–7 nach Launch
- 404-Report (GSC + Logs) → Fehlerliste abarbeiten
- Index Coverage / Seitenindexierung beobachten
- Rankings/Traffic nicht „minütlich“ bewerten, aber Trends prüfen
Monitoring: Was du in den ersten Wochen beobachten solltest
Relaunches stabilisieren sich meist nicht am selben Tag. Diese Dinge sind normal:
- leichte Schwankungen (Google muss neu crawlen/verstehen)
- einzelne Keywords „springen“ kurz
Unnormal ist:
- viele 404 für wichtige alte URLs
- massenhaft Canonical auf falsche Ziele
- GSC meldet „Submitted URL seems to be a Soft 404“
Wenn du das siehst, reagierst du sofort: Mapping/Redirects nachziehen, Canonicals fixen, Sitemap bereinigen.
Nächster Schritt
Wenn du vor einem Relaunch stehst, machen wir einmal ein Relaunch-Blueprint (Mapping, Redirects, Canonicals, Launch-Check) – damit du nicht 8 Wochen Sichtbarkeit verlierst.
