Warum die meisten Website-Relaunches 40–60% des organischen Traffics vernichten
Ein Website-Relaunch ist eines der riskantesten SEO-Ereignisse, die einem Unternehmen passieren können. Wir haben in den letzten Jahren über ein Dutzend Kunden übernommen, deren vorheriger Relaunch zu einem dramatischen Traffic-Einbruch geführt hat. In einem Fall verlor ein Stuttgarter B2B-Software-Anbieter nach einem Relaunch binnen sechs Wochen 58% seines organischen Traffics — trotz besserem Design, schnellerer Ladezeiten und modernerem Tech-Stack. Die Ursache: fehlende 301-Redirects von alten URLs auf neue, veränderte URL-Strukturen ohne Weiterleitung und ein komplett überarbeiteter Content, der die rankenden Keywords nicht mehr enthielt.
Der Recovery dauerte neun Monate. Neun Monate, in denen Leads ausblieben, die auf organischen Traffic angewiesen waren. Das ist kein Einzelfall. Laut einer Studie von Sistrix verlieren Websites nach Relaunch im Median 23% ihrer Sichtbarkeit — mit hoher Standardabweichung nach oben. Wer unprepared relaunct, riskiert weit mehr als 23%.
Das Tragische: Fast alle dieser Verluste sind vermeidbar. Sie entstehen nicht durch unvorhersehbare Algorithm-Updates — sie entstehen durch Prozessfehler bei der Migration. Fehlende Redirects. Vergessene Canonical Tags. Content, der gelöscht statt umstrukturiert wurde. Meta-Daten, die im Eifer des Relaunches nicht übertragen wurden. Diese fünf Phasen eliminieren diese Fehler systematisch.
Die Goldene Regel des Relaunchs:Kein Content darf gelöscht werden, ohne zu prüfen, ob er Traffic oder Backlinks hat. Kein URL darf sich ändern, ohne dass ein 301-Redirect gesetzt wird. Diese beiden Regeln allein verhindern 80% aller Relaunch-SEO-Schäden.
Phase 1: Audit vor dem Relaunch — was du behalten, was du löschen kannst
Bevor auch nur eine Zeile neuen Codes geschrieben wird, muss du wissen, was deine aktuelle Website SEO-seitig leistet. Dieser Audit dauert je nach Website-Größe zwei bis fünf Tage — und ist die wichtigste Investition des gesamten Relaunch-Projekts.
Schritt 1: Vollständiges URL-Crawling
Crawle deine gesamte aktuelle Website mit Screaming Frog SEO Spider oder Sitebulb. Ziel: eine vollständige Liste aller indexierten URLs mit deren Status-Codes, Titles, Meta-Descriptions und internen Verlinkungen. Diese Liste ist deine Baseline. Exportiere sie als CSV — du wirst sie während der gesamten Migration als Referenz brauchen.
Schritt 2: Traffic-Analyse pro URL
Verbinde deine URL-Liste mit Google Search Console und Google Analytics. Ziel: für jede URL wissen, wie viel organischen Traffic und Impressionen sie in den letzten 12 Monaten hatte. Seiten mit regelmäßigem Traffic sind dein SEO-Kapital — sie müssen auf der neuen Seite mit neuer URL weiter verfügbar sein oder per 301 weitergeleitet werden. Seiten mit null Traffic und null Impressionen sind Kandidaten für Konsolidierung oder Löschung.
Schritt 3: Backlink-Audit
Externe Links auf deine Website sind Ranking-Signale. Wenn du eine URL löschst, auf die externe Websites verlinken, verlierst du diese Ranking-Signale. Nutze Ahrefs, Semrush oder die kostenlose Google Search Console (Abschnitt „Links“) um die URLs mit den meisten eingehenden Backlinks zu identifizieren. Diese URLs brauchen auf jeden Fall 301-Redirects auf semantisch äquivalente neue URLs.
Schritt 4: Keyword-Mapping
Erstelle ein Keyword-Mapping: welche URL rankt für welche Keywords? Diese Information verhindert, dass im Relaunch-Eifer Content-Seiten zusammengeführt werden, die für unterschiedliche Keywords ranken. Das Tool deiner Wahl: Google Search Console (Leistung → nach Seite filtern → Keywords pro Seite). Bei größeren Websites hilft Semrush oder Ahrefs für eine vollständigere Übersicht.
Deliverable aus Phase 1:Ein Google Sheet mit vier Spalten: Alte URL | Traffic letzte 12 Monate | Backlinks | Ranking Keywords. Dieses Dokument ist die Grundlage für alle weiteren Entscheidungen — URL-Struktur, Content-Strategie und Redirect-Mapping.
Phase 2: URL-Struktur entscheiden — einmal richtig, für immer
URL-Änderungen sind wie Umzüge: teuer, aufwendig und je seltener desto besser. Jede URL-Änderung erfordert Redirects, riskiert vorübergehende Ranking-Verluste und erzwingt Re-Crawling durch Google. Wenn du relaunchst, nutze die Gelegenheit, eine URL-Struktur zu definieren, die für die nächsten fünf bis zehn Jahre hält — und ändere sie dann nie wieder.
Prinzipien einer SEO-optimalen URL-Struktur
Flache Hierarchie: Idealerweise maximal drei Ebenen tief — /kategorie/unterkategorie/produkt. Tiefere Hierarchien machen es für Crawler schwieriger, Seiten zu entdecken, und verwässern den Link Equity. Keywords in URLs: Die URL sollte das primäre Keyword der Seite enthalten. Nicht /page?id=1234 sondern /webdesign-agentur-muenchen. Konsistenz: Einmal Bindestriche als Wort-Trennzeichen gewählt? Immer Bindestriche. Nie Unterstriche mischen. Immer Kleinbuchstaben. Keine Sonderzeichen oder Umlaute in URLs.
Behalte bestehende URLs wo möglich
Die SEO-sicherste Entscheidung ist, bestehende URLs zu behalten — besonders für Seiten mit Traffic, Backlinks oder Rankings. Wenn die alte URL-Struktur nicht fundamental falsch ist, lass sie so. Die Versuchung, „alles sauber zu machen“, führt zu unnötigen Redirect-Kaskaden. Ändere URLs nur, wenn es einen klaren funktionalen oder SEO-Grund dafür gibt.
Phase 3: 301 Redirects korrekt setzen — die technische Grundlage
301-Redirects sind die wichtigste technische Maßnahme bei einer Migration. Sie signalisieren Google: „Diese Seite existiert dauerhaft an einer neuen Adresse — übertrage alle Rankings und Backlink-Signals dorthin.“ Ein korrekt gesetzter 301-Redirect überträgt ca. 90–99% des Ranking-Potenzials der alten URL. Kein Redirect bedeutet: der komplette Verlust des aufgebauten SEO-Kapitals.
301 vs. 302 — ein kritischer Unterschied
301 bedeutet „dauerhaft verschoben“ und überträgt Link-Equity. 302 bedeutet „vorübergehend verschoben“ und überträgt kein Link-Equity. Der häufigste Fehler beim Relaunch: Entwickler setzen versehentlich 302-Redirects statt 301. Prüfe nach dem Launch alle Redirects mit einem Tool wie Redirect Checker oder Screaming Frog auf den korrekten Status-Code.
Redirects in Next.js (next.config.js)
Für Next.js-Projekte werden Redirects in der next.config.js oder next.config.ts definiert:
// next.config.ts
import type { NextConfig } from 'next'
const nextConfig: NextConfig = {
async redirects() {
return [
// Einfacher permanenter Redirect
{
source: '/alte-seite',
destination: '/neue-seite',
permanent: true, // 301
},
// Wildcard-Redirect für gesamte alte Kategorie
{
source: '/leistungen/:path*',
destination: '/services/:path*',
permanent: true,
},
// Alte Blog-Struktur auf neue mappen
{
source: '/news/:slug',
destination: '/blog/:slug',
permanent: true,
},
]
},
}
export default nextConfigRedirects in Apache (.htaccess)
# .htaccess — Apache Server
RewriteEngine On
# Einzelne URL umleiten
Redirect 301 /alte-seite.html https://www.domain.de/neue-seite/
# Gesamtes altes Verzeichnis auf neues umleiten
RedirectMatch 301 ^/old-kategorie/(.*)$ https://www.domain.de/neue-kategorie/$1
# www zu non-www (oder umgekehrt) — immer konsistent
RewriteCond %{HTTP_HOST} ^www\.domain\.de [NC]
RewriteRule ^(.*)$ https://domain.de/$1 [R=301,L]
# HTTP zu HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Redirects in Nginx
# nginx.conf — Nginx Server
server {
# Einzelne Seite permanent weiterleiten
location = /alte-seite {
return 301 https://domain.de/neue-seite/;
}
# Gesamtes altes Verzeichnis umleiten
location /old-blog/ {
rewrite ^/old-blog/(.*)$ /blog/$1 permanent;
}
# HTTP zu HTTPS
server_name domain.de www.domain.de;
if ($scheme != "https") {
return 301 https://$host$request_uri;
}
}Keine Redirect-Ketten!Redirect-Ketten (A → B → C) kosten Page Rank und verlangsamen den Seitenaufbau. Wenn eine URL bereits auf eine andere umleitet und du die Ziel-URL ebenfalls umleiten willst, aktualisiere den ersten Redirect direkt auf das finale Ziel: A → C. Screaming Frog findet Ketten mit dem „Redirect Chains“-Report.
Phase 4: Technische Migration — alles prüfen, bevor es live geht
Die Staging-Phase ist deine letzte Chance, Fehler zu finden, bevor Google sie sieht. Eine vollständige technische Prüfung auf der Staging-Umgebung ist kein optionaler Schritt — sie ist Voraussetzung für jeden seriösen Launch.
robots.txt und noindex auf Staging sperren
Das häufigste und verheerendste Versehen: die Staging-Umgebung wird versehentlich von Suchmaschinen gecrawlt und indexiert, bevor die echte Seite live geht. Verhindere das mit zwei Maßnahmen: erstens einerobots.txt auf der Staging-Domain, die alle Crawler blockiert:
# robots.txt auf staging.domain.de
User-agent: *
Disallow: /Und zweitens, falls dein CMS oder Framework es unterstützt, ein globalesnoindex-Meta-Tag im <head> der Staging-Umgebung:
// In Next.js: layout.tsx für Staging
// (via Umgebungsvariable steuern)
export const metadata: Metadata = {
robots: process.env.NODE_ENV === 'production'
? { index: true, follow: true }
: { index: false, follow: false },
}Canonical Tags korrekt setzen
Jede Seite sollte einen selbst-referenzierenden Canonical-Tag haben, der die kanonische URL der Seite angibt. Das verhindert Duplicate-Content-Probleme bei URL-Varianten (mit/ohne Trailing Slash, mit/ohne www, HTTP/HTTPS-Mischung). In Next.js über das Metadata-API:
// Jede Seite: Canonical-Tag via Metadata
export const metadata: Metadata = {
alternates: {
canonical: 'https://domain.de/seiten-url',
},
}
// Oder dynamisch in einer dynamischen Route:
export async function generateMetadata({ params }) {
return {
alternates: {
canonical: `https://domain.de/blog/${params.slug}`,
},
}
}XML-Sitemap aktualisieren und einreichen
Deine XML-Sitemap muss alle neuen URLs enthalten und darf keine alten URLs mehr listen, die jetzt 301 weiterleiten. Nach dem Launch: die neue Sitemap in der Google Search Console unter „Sitemaps“ einreichen. Das beschleunigt das Re-Crawling der neuen URL-Struktur erheblich.
Structured Data (Schema.org) übertragen
Wenn deine alte Website JSON-LD oder Microdata hatte (für Produkte, Bewertungen, FAQ, Breadcrumbs), muss das auf der neuen Seite vollständig übertragen werden. Prüfe mit dem Google Rich Results Test, ob alle Structured-Data-Implementierungen korrekt erkannt werden.
Phase 5: Post-Launch Monitoring — die ersten 90 Tage entscheiden
Der Launch ist nicht das Ende des Relaunch-Projekts. Die ersten 90 Tage nach dem Go-live sind eine kritische Phase, in der du Google dabei zusiehst, wie es die neue Website bewertet. Probleme, die jetzt nicht erkannt werden, können sich festigen und sind später teurer zu beheben.
Woche 1: Sofort-Check nach Launch
Crawle die neue Produktions-Seite sofort mit Screaming Frog. Was suchst du: 4xx-Fehler (Seiten, die nicht mehr existieren ohne Redirect), 5xx-Server-Fehler, fehlende Meta-Tags (leere oder doppelte Titles/Descriptions), Bilder ohne Alt-Attribute, interne Links auf 404-Seiten. Alle Befunde werden sofort behoben — nicht „nächste Sprint“. Google beginnt nach dem Launch sofort mit Re-Crawling.
Google Search Console: URL-Inspection für kritische Seiten
Nutze das URL-Inspection-Tool in der Search Console für deine 10–20 wichtigsten Seiten (nach Traffic und Rankings). Prüfe: Wird die Seite als indexierbar erkannt? Wurde der Canonical korrekt erkannt? Gibt es Crawling-Fehler? Wenn eine wichtige Seite nicht indexierbar ist, kannst du hier direkt eine Neuindexierung beantragen.
Ranking-Monitoring einrichten
Richte in Semrush, Sistrix oder Ahrefs ein wöchentliches Ranking-Tracking für deine Top-50-Keywords ein. Ein normaler Relaunch führt zu kurzfristigen Schwankungen in den ersten 4–8 Wochen — das ist kein Alarm-Signal. Alarm-Signal ist ein anhaltender Trend nach unten über mehr als 6 Wochen. In diesem Fall: Google Search Console auf Crawling-Fehler prüfen, Redirect-Chain-Analyse wiederholen und Content auf fehlende Keywords prüfen.
Core Web Vitals nach Relaunch prüfen
Ein Relaunch kann Core Web Vitals stark verändern — positiv wie negativ. Neues JavaScript, neue Bilder, neue Fonts. Miss nach dem Launch sofort mit PageSpeed Insights und prüfe die Search Console nach 4–6 Wochen auf den neuen CWV-Report. Verschlechterte Werte müssen innerhalb der ersten 30 Tage adressiert werden, bevor sie als Field Data in Google Rankings einfließen.
Häufige Fehler — und wie du sie vermeidest
Aus 47 begleiteten Projekten haben sich fünf Fehler-Muster herauskristallisiert, die immer wieder für Ranking-Verluste sorgen.
Fehler 1: Content-Merger ohne Traffic-Prüfung
Zwei Seiten zu einer zusammenführen klingt nach Strukturverbesserung. Wenn aber beide Seiten für unterschiedliche Keywords ranken, verlierst du unweigerlich Rankings für eine der beiden Keyword-Gruppen. Prüfe vor jedem Merge: Für welche Keywords rankt jede Seite? Wenn die Keyword-Sets sich nicht überschneiden, sei sehr vorsichtig mit dem Zusammenführen.
Fehler 2: Robots.txt-Fehler im Launch
Die auf der Staging-Umgebung gesetzte Disallow: /-Direktive vergessen zu entfernen. Das passiert erschreckend oft. Der Effekt: Google kann die neue Seite gar nicht crawlen, alle Rankings brechen ein. Prüfe die robots.txt unmittelbar nach dem Launch: https://domain.de/robots.txt — manuell im Browser.
Fehler 3: Verlust der internen Verlinkungsstruktur
Interne Links übertragen Link Equity innerhalb deiner Website. Wenn ein Relaunch die interne Verlinkung komplett neu strukturiert, ohne die alten Link-Juice-Flows zu berücksichtigen, können Seiten Rankings verlieren, weil sie plötzlich schlechter intern verlinkt sind. Dokumentiere die wichtigsten internen Links vor dem Relaunch und stelle sicher, dass sie auf der neuen Seite erhalten bleiben.
Fehler 4: Title und Description nicht übertragen
Entwickler übertragen beim Relaunch gerne Templates, vergessen aber, die spezifischen Title-Tags und Meta-Descriptions der alten Seiten zu übernehmen. Plötzlich haben 200 Seiten generische Titel wie „Webdesign Agentur | Home“ statt spezifischer, keywordreicher Titles. Das Google Such-Snippet ändert sich, die Click-Through-Rate sinkt, die Rankings folgen.
Fehler 5: Launch ohne Backup-Plan
Was passiert, wenn nach dem Launch ein kritisches Problem auftaucht? Hast du einen rollback-fähigen Stand der alten Website? Bei Vercel und Netlify ist das trivial — jeder Deploy hat eine eindeutige URL und kann in 60 Sekunden wiederhergestellt werden. Bei selbstgehostetem Hosting braucht es einen expliziten Backup-Plan. Ohne Rollback-Möglichkeit arbeitest du unter Zeitdruck an einem Live-System, was die Fehlerrate erhöht.
Die vollständige Relaunch-SEO-Checkliste
Diese Checkliste fasst alle kritischen Maßnahmen zusammen. Drucke sie aus oder kopiere sie in dein Projekt-Tracking-Tool. Kein Punkt darf beim Go-live als „offen“ markiert sein.
Vor dem Relaunch
Während der Entwicklung
Launch-Tag
Post-Launch Monitoring
Ein strukturiertes Vorgehen nach diesem Leitfaden ist kein Garantieschein für perfekte Rankings nach dem Relaunch — Google-Algorithmen sind komplex und kurzfristige Schwankungen sind normal. Aber er eliminiert alle vermeidbaren Fehler. Und vermeidbare Fehler sind der Grund für 80% der Relaunch-SEO-Katastrophen, die wir gesehen haben.
PixelCraft Media
Webdesign Agentur
Wir bauen Websites, die Besucher in Kunden verwandeln — mit Handwerk bis ins letzte Pixel.
Website kostenlos analysieren →