Website-Relaunch ohne Ranking-Verlust: 12-Punkte-Checkliste mit 301-Redirects, Sitemap-Migration und Search Console Hand-Off

Wir machen das seit über 20 Jahren — und kein Projekt erzeugt so viel Bauchschmerzen wie ein Website-Relaunch. Neue Optik, neue Struktur, neues CMS, oft alles gleichzeitig. Und drei Wochen nach Go-Live klingelt das Telefon: "Unsere Anfragen sind eingebrochen, wir finden uns bei Google nicht mehr." Wir hören das regelmäßig von Unternehmen aus Mannheim, Heidelberg, Speyer und der Region Rhein-Neckar — meistens nicht von unseren eigenen Kunden, sondern von denen, die zu uns kommen, nachdem der neue Auftritt schon online ist und die Sichtbarkeit weg ist.

Die Wahrheit ist: Ein Relaunch muss kein SEO-Drama sein. Wenn du strukturiert vorgehst, behält Google deine Rankings — oft sogar mit leichtem Plus, weil die neue Seite technisch sauberer ist. Was du brauchst, ist ein Plan. Diesen Plan haben wir hier in 12 Punkten zusammengefasst, so wie wir ihn intern selbst abarbeiten — eingebettet in unseren bewährten 8-Phasen-Prozess für Homepage-Projekte, in dem der Relaunch-Teil eine eigene Phase bildet.

Warum so viele Relaunches Rankings kosten

Die häufigste Ursache ist banal: Niemand hat die alte URL-Struktur dokumentiert, bevor sie überschrieben wurde. Plötzlich liefert /leistungen/webdesign-mannheim einen 404-Fehler, weil die neue Seite jetzt /services/webdesign heißt. Google hat über Jahre Vertrauen in die alte URL aufgebaut — Backlinks, interne Verweise, Klick-Historie. Mit dem 404 ist das alles weg.

Der zweite Klassiker: Der neue Auftritt steht wochenlang auf einer Staging-Domain mit noindex-Tag — und beim Live-Schalten vergisst jemand, das Tag zu entfernen. Wir haben Fälle gesehen, in denen die komplette neue Website drei Wochen lang von Google deindexiert war, ohne dass es jemandem auffiel. Bis die Anfragen ausblieben.

Beides ist vermeidbar. Hier ist die Checkliste.

Die 12-Punkte-Checkliste für deinen sicheren Relaunch

1. Vollständigen Crawl der alten Site erstellen — bevor irgendwas passiert

Bevor du auch nur ein Pixel an der neuen Seite zeigst, musst du wissen, was du eigentlich hast. Lass Screaming Frog (kostenlos bis 500 URLs) oder Sitebulb über die alte Site laufen und exportiere:

• alle URLs mit Status-Code 200
• Title-Tags und Meta-Descriptions
• H1-Überschriften
• interne Linkstruktur
• alle Bilder mit Alt-Texten
• Canonical-Tags und hreflang-Angaben

Speichere diesen Export an einem sicheren Ort. Das ist deine Versicherung — falls später etwas fehlt, kannst du genau nachvollziehen, was die alte Seite an dieser URL ausgespielt hat.

Ergänze diesen Crawl mit den Top-Seiten aus der Search Console der letzten 12 Monate (Sortierung nach Klicks und Impressionen). Das sind die URLs, die du auf keinen Fall verlieren darfst.

2. Redirect-Map sauber planen

Jetzt wird gemappt: jede alte URL bekommt eine neue. Eine Tabelle reicht — Spalte A: alte URL, Spalte B: neue URL, Spalte C: HTTP-Status (in der Regel 301).

Drei Regeln, die wir uns hart erarbeitet haben:

• Keine Kettenredirects. Wenn /a auf /b und /b auf /c umleitet, leite /a direkt auf /c um. Jede Kette kostet Crawl-Budget und PageSpeed.
• Keine Massen-Weiterleitungen auf die Startseite. Wenn 200 alte Detailseiten alle auf / zeigen, behandelt Google das als Soft-404. Lieber sauber auf die thematisch passende neue Kategorie leiten.
• Wenn es kein Pendant gibt — überlegen. Manche Inhalte sterben tatsächlich. Dann lieber ein bewusster 410 Gone als ein erzwungener 301 auf eine unpassende Seite.

3. 301-Redirects technisch korrekt umsetzen

301 heißt "permanent verschoben". Google überträgt den Großteil der Linkjuice der alten URL auf die neue. 302 ist temporär — Linkjuice bleibt bei der alten URL. Für Relaunches: immer 301.

Beispiel für Apache (.htaccess):

# Einzelne Redirects
Redirect 301 /leistungen/webdesign-mannheim /webdesign/mannheim
Redirect 301 /blog/seo-tipps-2024 /blog/seo-grundlagen-fuer-kleine-unternehmen

# Pattern-Redirect für komplette Kategorie
RewriteEngine On
RewriteRule ^alte-kategorie/(.*)$ /neue-kategorie/$1 [R=301,L]

Beispiel für Nginx:

server {
    # Einzelne Redirects
    location = /leistungen/webdesign-mannheim {
        return 301 /webdesign/mannheim;
    }

    # Pattern-Redirect mit Capturing
    location ~ ^/alte-kategorie/(.*)$ {
        return 301 /neue-kategorie/$1;
    }
}

Bei Next.js, WordPress oder JTL-Shop läuft das über die jeweiligen Mechanismen (next.config.js Redirects-Block, Plugin wie Redirection, oder im Backend hinterlegte Weiterleitungen). Egal wie — alle Redirects nach dem Go-Live einmal manuell stichprobenartig prüfen. Vertrauen ist gut, Browser-Test ist besser.

4. XML-Sitemap an die neue Struktur anpassen

Deine alte Sitemap hat URLs, die es nicht mehr gibt. Die muss komplett neu generiert werden — nur die neuen URLs gehören rein, ohne 301-Ziele oder 404-Reste.

In Next.js läuft das über app/sitemap.ts, in WordPress über Yoast oder RankMath. Wichtig:

• Nur Status-200-URLs aufnehmen
• Keine paginierten Seiten, keine Filter-Parameter, keine Tag-Archive ohne Inhalt
• lastmod korrekt setzen — Google nutzt das als Crawl-Hinweis

Die neue Sitemap unter /sitemap.xml erreichbar machen und in der robots.txt referenzieren:

Sitemap: https://digitalmann.de/sitemap.xml

5. robots.txt auf Live-Tauglichkeit prüfen

Der Klassiker, den wir am häufigsten in Audits finden: Aus der Staging-robots.txt wird:

User-agent: *
Disallow: /

— und dieses Disallow geht beim Deployment versehentlich mit live. Google crawlt die Seite dann nicht mehr; bestehende URLs verschwinden über die nächsten Tage bis Wochen aus dem Index. Wir haben Fälle gesehen, in denen es 4–6 Wochen dauert, bis die Auswirkung in Search Console sichtbar wird — und dann ist viel Schaden schon passiert.

Vor dem Go-Live muss die robots.txt einmal manuell geprüft werden. Live sollte sie ungefähr so aussehen:

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/

Sitemap: https://digitalmann.de/sitemap.xml

Genauso für Meta-Robots-Tags: Stelle sicher, dass kein <meta name="robots" content="noindex"> mehr in den Templates steckt, der noch aus der Entwicklungszeit stammt.

6. Search Console Hand-Off durchführen

Wenn du die Domain behältst und nur die URL-Struktur änderst, reicht der normale Reindexierungsprozess. Wenn du die Domain wechselst (z. B. alte-firma.de → neue-marke.de), nutzt du das Adressänderungs-Tool in der Google Search Console — Voraussetzung: beide Domains sind verifiziert und 301-Redirects stehen.

Was nach dem Go-Live in der Search Console konkret zu tun ist:

• Neue XML-Sitemap einreichen (unter "Sitemaps")
• Alte Sitemap noch ein paar Wochen drinlassen — Google findet darüber die alten URLs und sieht die 301s
• Über "URL-Prüfung" stichprobenartig wichtige neue URLs einreichen lassen
• Den Bericht "Seiten" beobachten: Sind die alten URLs als "weitergeleitet" gekennzeichnet? Werden die neuen URLs indexiert?

Ein Fehler, den wir oft sehen: Leute löschen die alte Search-Console-Property nach dem Relaunch. Mach das nicht. Du brauchst sie noch monatelang zur Diagnose.

7. Internal Linking auf neue URLs umbauen

Das wird gerne vergessen: Auch interne Links müssen direkt auf die neuen URLs zeigen — nicht auf alte URLs, die sich dann via 301 auflösen. Jeder interne Link auf eine 301-URL kostet einen unnötigen Hop.

Konkret prüfen:

• Navigation, Footer, Sidebar
• Verlinkungen aus Blog-Artikeln und Content-Seiten
• Buttons und CTAs
• Breadcrumbs

Nach dem Go-Live noch einmal Screaming Frog drüberlaufen lassen mit Filter "Status 301 (Internal)" — das zeigt dir genau, welche internen Links du noch fixen musst.

8. Canonical Tags und hreflang neu setzen

Jede Seite braucht ein Canonical-Tag, das auf sich selbst zeigt — mit der neuen Domain und dem neuen URL-Pfad:

<link rel="canonical" href="https://digitalmann.de/webdesign/mannheim" />

Falsches Canonical ist einer der teuersten Relaunch-Fehler. Wir hatten einen Kunden aus Heidelberg, bei dem nach dem Relaunch alle Seiten ein Canonical auf die Startseite trugen — das CMS-Template war fehlerhaft konfiguriert. Innerhalb von 6 Wochen waren 80 % der Seiten aus dem Index. Korrigiert, neu eingereicht, vier Monate Erholung.

Bei mehrsprachigen Sites: hreflang-Tags an die neuen URL-Strukturen anpassen, sonst zeigt Google die falsche Sprachversion.

9. Strukturierte Daten neu testen

JSON-LD Markup (Organization, LocalBusiness, FAQPage, Article, Product, BreadcrumbList) muss auf der neuen Seite genauso sauber sein wie vorher — sonst verlierst du Rich-Snippets und Sichtbarkeit in der lokalen Suche.

Testen mit:

• Schema.org Validator
• Google Rich Results Test

Häufiger Fehler: aggregateRating mit String-Werten statt Zahlen, falsche @type-Hierarchien, oder LocalBusiness-Knoten ohne Adresse. Alles Dinge, die im Validator sofort auffallen — aber eben nur, wenn jemand reinschaut. Strukturierte Daten sind dabei kein Relaunch-Spezialthema, sondern gehören zu den SEO-Grundlagen für kleine Unternehmen — beim Relaunch musst du sie nur sauber mitnehmen statt fallenlassen.

10. Pre-Launch-Test mit Lighthouse und PageSpeed Insights

Bevor du das Go-Live freigibst: Lighthouse-Audit auf der Staging-Umgebung durchziehen. Mindestziele für Mobile:

• Performance: > 80 (Marketing-Site mit GTM realistisch)
• Accessibility: > 95
• Best Practices: 100
• SEO: 100

Core Web Vitals separat checken über PageSpeed Insights — LCP unter 2,5 s, CLS unter 0,1, INP unter 200 ms. Schlechte Performance schadet nicht direkt den Rankings, aber schlechte Mobilwerte plus Relaunch-Volatilität ist eine ungute Kombination.

Mehr Details dazu in unserem Artikel zu Core Web Vitals als Wettbewerbsvorteil.

11. Backup und Rollback-Plan parat halten

Vor dem Go-Live: vollständiges Backup der alten Site (Datenbank + Dateien) plus aktueller DNS-Stand. Wenn nach dem Live-Schalten gravierende Probleme auftauchen, willst du in unter 30 Minuten zurückrollen können — nicht erst stundenlang Daten zusammensuchen.

In der Praxis: Wir machen Relaunches grundsätzlich nicht freitags und nicht vor Feiertagen. Dienstag oder Mittwoch früh, dann ist das Team da, wenn etwas brennt. Klingt selbstverständlich, wird trotzdem regelmäßig ignoriert.

12. 30–90 Tage Monitoring nach Go-Live

Der Relaunch ist nicht am Tag des Go-Live abgeschlossen. Die nächsten 30 bis 90 Tage entscheiden. Was wir täglich (Woche 1–2), dann wöchentlich beobachten:

• Search Console — Leistung: Klicks und Impressionen vs. Vorperiode. Aus unserer Praxis: ein Drop von 5–15 % in den ersten zwei Wochen ist nicht ungewöhnlich (Google muss neu crawlen und einsortieren). Eine offizielle Google-Zahl gibt es dafür nicht. Über 30 % Verlust über mehrere Wochen ist ein klares Alarmsignal — dann meistens 301 oder Canonical fehlerhaft.
• Search Console — Seiten: Wie viele URLs sind indexiert? Gibt es plötzlich viele "Soft-404" oder "Doppelte Seite ohne ausgewähltes Canonical"?
• Server-Logs: Crawlt der Googlebot die neuen URLs? Stolpert er über 404er oder 5xx?
• Rankings: Top-20 Keywords vor/nach Relaunch in einem Tool wie SISTRIX, Ahrefs, AccuRanker, oder einfach manuell in einem Sheet.
• Conversions: Anfragen, Käufe, Newsletter-Anmeldungen. Wenn Rankings stabil sind, aber Conversions einbrechen, liegt's am neuen Design — nicht am SEO.

Die 5 häufigsten Fehler beim Relaunch

Aus 20 Jahren Praxis — die Klassiker, die uns immer wieder begegnen:

1. Keine 301-Redirects gesetzt. Alte URLs liefern 404. Zwei Wochen später hat Google die Vertrauenssignale halbiert.
2. noindex aus der Staging-Phase überlebt das Go-Live. Komplette Site verschwindet aus dem Index. Wir haben das bei einem Mannheimer Onlineshop erlebt — drei Wochen unbemerkt.
3. URLs ohne Not geändert. Wenn die alte URL-Struktur sauber war (sprechend, kurz, kategorisiert), gibt es keinen SEO-Grund, sie zu ändern. "Wir machen alles neu" ist kein Grund.
4. Content gekürzt oder gelöscht. Inhalte, die jahrelang Traffic gebracht haben, werden im neuen Design "ausgemistet". Mit jeder gelöschten Unterseite verschwindet ein Long-Tail-Keyword aus den Rankings.
5. Kein Crawl der alten Seite vor dem Relaunch. Klassisches "Hätten-wir-mal" — wenn die alte Datenbank weg ist und du nicht mehr weißt, welche URLs es gab, kannst du keine vollständige Redirect-Map bauen.

Wann ist ein Relaunch sinnvoll — und wann nicht?

Ehrliche Einordnung, weil wir auch schon Kunden vom Relaunch abgeraten haben:

Sinnvoll, wenn:

• Die alte Seite technisch nicht mehr wartbar ist (veraltetes CMS ohne Sicherheitsupdates)
• Mobile-Erfahrung katastrophal ist und nicht durch Optimierung im Bestand zu retten
• Strukturwechsel im Geschäftsmodell (neue Zielgruppe, neue Positionierung) inhaltlich einen Schnitt erfordert
• Performance-Werte (Core Web Vitals) durch das alte Setup nicht zu retten sind

Nicht sinnvoll, wenn:

• Du nur "ein neues Design" willst — dafür reicht oft ein Re-Design im Bestand
• Die aktuelle Seite gut rankt und du noch keinen klaren Plan hast, was an Inhalten besser werden soll
• Das Budget für die 12 Punkte oben nicht reicht — dann lieber kleinerer Scope, dafür sauber

Ein gut sortiertes Refresh schlägt einen halbgaren Relaunch jeden Tag. Wenn du eine ehrliche Einordnung der Größenordnung suchst, findest du in unserem Artikel zu den realistischen Kosten einer Website 2026 auch konkrete Spannen für Relaunch-Projekte.

Tools, die wir für Relaunches nutzen

Wichtig: Tools sind nur so gut wie der Prozess dahinter. Die teuersten Relaunch-Schäden, die wir bisher gesehen haben, hätte ein 50-Euro-Crawl mit Screaming Frog vorher verhindert — niemand hat ihn gemacht.

Fazit: Relaunch ist Handwerk, kein Glücksspiel

Ein Website-Relaunch ohne Ranking-Verlust ist keine Hexerei — es ist ein strukturierter Prozess, der vor dem ersten Pixel der neuen Seite beginnt und mindestens drei Monate nach Go-Live weiterläuft. Die 12 Punkte oben sind die Mindestabsicherung. Wer sie konsequent abarbeitet, verliert nicht nur keine Rankings — sondern gewinnt oft sogar dazu, weil die neue Seite technisch sauberer, schneller und zielgerichteter ist als die alte.

Was wir aus 20 Jahren mitgenommen haben: Der teuerste Fehler beim Relaunch ist die Annahme, dass "das Google schon irgendwie merkt". Tut es nicht. Google sieht 404er und denkt: weg, gelöscht, kein Vertrauen mehr. Genau deshalb ist die Vorbereitung wichtiger als das Design.

Du planst einen Relaunch — und willst die Sichtbarkeit nicht verlieren?

Wir übernehmen den SEO-kritischen Teil deines Relaunches: vollständiger Pre-Launch-Crawl, Redirect-Map, technische Umsetzung der 301s, Search Console Hand-Off und Monitoring in den ersten 90 Tagen nach Go-Live. Egal, ob die neue Site bei uns gebaut wird oder bei einer anderen Agentur.

Für Unternehmen aus Hockenheim, Mannheim, Heidelberg, Speyer und der Region Rhein-Neckar bieten wir ein kostenloses Relaunch-Vorab-Audit: Wir crawlen deine bestehende Seite, identifizieren die Top-100-URLs nach Traffic und sagen dir, was beim Relaunch unbedingt erhalten bleiben muss.

Jetzt Relaunch-Audit anfragen →