SEO-Relaunch-Checkliste für KMU: Rankings beim Relaunch schützen

Welche Relaunches sind aus SEO-Sicht riskant?

„Relaunch“ kann vieles bedeuten. Ein neues Farbschema bei unveränderten URLs ist etwas anderes als der Wechsel von Domain, CMS und Seitenstruktur. Bevor du Aufgaben verteilst, ordne das Projekt deshalb nach seiner tatsächlichen SEO-Wirkung ein.

Das Risikoniveau bestimmt, wie früh SEO einbezogen und wie streng die Freigabe gestaltet werden sollte. Die folgende Entscheidungsmatrix hilft bei der Planung.

Phase 1: Bestand und Ziele vor dem Relaunch sichern

Der häufigste Planungsfehler ist, nur die neue Website zu betrachten. Für SEO musst du zuerst verstehen, welche Signale die alte Website bereits besitzt. Die Bestandsaufnahme schafft deine Referenz für Entscheidungen und das spätere Monitoring.

Bestehende URLs vollständig erfassen

Kombiniere mehrere Datenquellen, weil keine einzelne Liste zuverlässig alle relevanten URLs enthält:

• URLs aus der aktuellen XML-Sitemap
• intern verlinkte Seiten aus einem vollständigen Crawl
• Seiten mit Impressionen oder Klicks in der Google Search Console
• Landingpages mit organischen Sitzungen oder Conversions im Analytics-System
• URLs mit relevanten externen Links
• wichtige Kampagnen-, Produkt-, Standort- und Service-Seiten
• PDFs und andere indexierbare Dateien, sofern sie Suchsichtbarkeit oder Backlinks besitzen

Führe diese Quellen in einer Masterliste zusammen und entferne erst danach Duplikate. Eine URL ohne aktuellen Traffic kann trotzdem eine sinnvolle Zielseite, einen wertvollen externen Link oder eine saisonale Funktion besitzen.

Messbasis dokumentieren

Speichere vor dem Relaunch mindestens die wichtigsten organischen Landingpages, Suchanfragen, Impressionen, Klicks, Conversions und indexierten Seitentypen. Ergänze zentrale Rankings, wenn sie geschäftlich relevant sind. So kannst du Veränderungen nach dem Go-live einordnen.

Lege außerdem fest, woran das Projekt gemessen wird. Für ein KMU können das qualifizierte Kontaktanfragen, Terminbuchungen, Anrufe oder Verkäufe sein. Ein Relaunch ist nicht erfolgreich, nur weil die neue Website moderner aussieht.

SEO-Audit als Bestandsaufnahme nutzen

Ein vorbereitender Audit zeigt technische Altlasten, doppelte Inhalte, schwache interne Verlinkung und Indexierungsprobleme. Er sollte hier als Inventur dienen: Was muss erhalten bleiben, was wird bewusst verbessert und was darf entfallen? Eine ausführliche Prüflogik findest du in unserer SEO-Audit-Checkliste.

Übernimm alte Fehler nicht blind, dokumentiere aber jede bewusste Korrektur. Nur so lassen sich Auswirkungen der Migration von beabsichtigten Inhaltsänderungen unterscheiden.

Rollen und Rückfallplan festlegen

Benennen solltest du mindestens eine verantwortliche Person für Entwicklung, Inhalte, SEO, Tracking und finale Freigabe. Definiere außerdem:

• wer Redirect-Regeln einspielt und kurzfristig korrigieren kann,
• wer DNS, Hosting oder CDN kontrolliert,
• wer am Go-live-Tag Entscheidungen treffen darf,
• wie ein Rollback technisch funktioniert,
• welche Fehler den Launch stoppen,
• wie Support und Monitoring in den ersten Tagen besetzt sind.

Ein Backup allein ist noch kein Rückfallplan. Das Team muss wissen, welche Version wiederhergestellt wird, wie lange das dauert und wie dabei neue Daten wie Bestellungen oder Anfragen geschützt werden.

URL-Mapping: Jede alte URL braucht eine Entscheidung

Das URL-Mapping ist das operative Herzstück einer SEO-Migration. Für jede relevante alte URL hältst du fest, ob sie unverändert bleibt, permanent umzieht, zusammengeführt oder ohne Ersatz entfernt wird. Eine pauschale Regel, die alle alten Seiten zur Startseite schickt, ist kein Mapping. Wenn du die Zuordnung noch strukturieren musst, hilft dir unsere Anleitung zum Keyword- und URL-Mapping.

Beispiel für ein sauberes URL-Mapping

Die folgende Tabelle ist ein Modell und muss mit den tatsächlichen URLs deines Projekts gefüllt werden.

Ordne eine alte URL nur dann einer neuen Seite zu, wenn diese denselben Zweck oder eine sehr nahe Suchintention erfüllt. Werden mehrere alte Seiten sinnvoll zu einer stärkeren Zielseite zusammengeführt, darf jede von ihnen direkt dorthin weiterleiten. Gibt es keinen passenden Ersatz, ist ein korrekter 404 Not Found oder 410 Gone ehrlicher als eine irrelevante Weiterleitung.

Für eine echte Wartungsunterbrechung ist dagegen meist ein temporärer 503 Service Unavailable mit sinnvoll gesetztem Retry-After passender als eine Umleitung auf eine andere Inhaltsseite.

Kopierbare Vorlage für dein URL-Mapping

Übernimm die folgende Struktur in eine Tabelle und ergänze jede indexierbare, besuchte oder verlinkte Bestands-URL. Für große Websites kommen bei Bedarf Spalten für Seitentyp, Sprache und Priorität hinzu.

Das Feld „Teststatus“ wird erst nach einem technischen Abruf gepflegt. Ein Redirect gilt nicht allein deshalb als korrekt, weil die Ziel-URL eingetragen wurde: Statuscode, Endziel, Canonical und mögliche Ketten müssen ebenfalls stimmen.

301 und 308 richtig einsetzen

301 und 308 sind permanente serverseitige Redirects. Beide signalisieren, dass eine Ressource dauerhaft umgezogen ist. Für typische Inhaltsseiten ist 301 die einfache Standardwahl; 308 ist eine permanente technische Alternative. Entscheidend ist, dass das Ziel inhaltlich passt und die Weiterleitung serverseitig korrekt ausgeliefert wird.

Wichtiger als die Wahl zwischen 301 und 308 ist die Qualität der Zuordnung. Leite direkt auf das endgültige Ziel weiter. Ketten wie alt → zwischenziel → neu verlangsamen Aufrufe und erschweren die Kontrolle. Kreise wie A → B → A müssen vollständig ausgeschlossen sein.

Permanente Redirects sollten mindestens ein Jahr bestehen bleiben. Wenn alte Links, Bookmarks oder externe Verweise weiterhin genutzt werden, ist eine längere beziehungsweise dauerhafte Beibehaltung sinnvoll. Aktualisiere parallel die internen Links, damit Nutzer und Crawler nicht dauerhaft über Weiterleitungen gehen müssen. Wie du dabei wichtige Seiten gezielt stärkst, zeigt unsere Anleitung zur internen Verlinkung.

404 und 410 sind nicht automatisch Fehler

Eine entfernte Seite ohne gleichwertigen Ersatz darf einen echten 404- oder 410-Status liefern. 404 bedeutet, dass die Ressource nicht gefunden wurde; 410 erklärt ausdrücklich, dass sie entfernt wurde. Beide sind für endgültig entfallene Inhalte möglich.

Problematisch wird es, wenn wertvolle Seiten versehentlich verschwinden, eine optisch gestaltete Fehlerseite technisch 200 OK zurückgibt oder große URL-Mengen ohne Prüfung entfernt werden. Eine benutzerfreundliche Fehlerseite sollte hilfreiche Navigation bieten, aber trotzdem den korrekten Fehlerstatus senden.

Phase 2: Das Staging-System aus SEO-Sicht prüfen

Auf dem Staging-System wird nicht nur das Design abgenommen. Hier prüfst du, ob die neue Website technisch dieselben oder bessere Voraussetzungen für Crawling, Indexierung und Conversion besitzt.

Staging zuverlässig vor Indexierung schützen

Schütze die Testumgebung vorzugsweise durch Anmeldung, HTTP-Authentifizierung oder einen vergleichbaren Zugriffsschutz. Ein öffentlich erreichbares Staging mit noindex kann trotzdem gecrawlt werden und interne Informationen offenlegen.

Verlasse dich nicht auf eine Sperre in der robots.txt, um Indexierung zu verhindern. Eine dort blockierte URL kann unter Umständen als Adresse bekannt bleiben, und der Crawler kann ein noindex im HTML nicht sehen, wenn er die Seite nicht abrufen darf. Für die Live-Schaltung brauchst du deshalb eine dokumentierte Liste aller Zugangssperren, noindex-Anweisungen und X-Robots-Tag-Header, die entfernt werden müssen.

Template für Template testen

Prüfe nicht nur Startseite und Kontaktformular. Wähle aus jedem Seitentyp mindestens mehrere repräsentative URLs: Leistungsseite, Standortseite, Blogartikel, Kategorie, Formularseite und gegebenenfalls Produkt- oder Fallstudienseite.

Kontrolliere dabei:

• eindeutigen Meta Title und eine passende Meta Description,
• eine klare, sichtbare Hauptüberschrift, die den Seiteninhalt beschreibt,
• vollständigen Hauptinhalt auch im gerenderten HTML,
• selbstreferenzierenden Canonical auf die endgültige Live-URL,
• korrekte index,follow-Steuerung für indexierbare Seiten,
• interne Links auf finale URLs statt Staging-Adressen,
• strukturierte Daten ohne veraltete oder erfundene Angaben,
• Bildquellen, Alt-Texte und responsive Darstellung,
• Analytics, Consent-Modus und wichtige Conversion-Ereignisse,
• mobile Bedienbarkeit und Ladeleistung.

Für die vollständige Seitenprüfung kannst du die Punkte mit unserer OnPage-SEO-Checkliste abgleichen.

Canonicals sind ein Signal für die bevorzugte URL, kein Ersatz für Redirects. Vermeide widersprüchliche Angaben: Eine URL sollte nicht in der Sitemap stehen, sich per Canonical auf eine andere Seite beziehen und gleichzeitig intern als Hauptversion verlinkt werden.

Neue Sitemap vorbereiten

Die neue XML-Sitemap sollte ausschließlich kanonische, indexierbare URLs mit erfolgreichem 200-Status enthalten. Redirects, Fehlerseiten, noindex-URLs und Staging-Adressen gehören nicht hinein. Prüfe außerdem, ob die Sitemap nach dem Go-live unter der vorgesehenen URL erreichbar ist und in der robots.txt korrekt referenziert wird.

Redirects vorab automatisiert testen

Erzeuge eine Testliste aus dem URL-Mapping und prüfe jede Regel gegen eine produktionsnahe Umgebung. Das Ergebnis sollte zeigen:

• alten Status und Redirect-Ziel,
• Anzahl der Weiterleitungsschritte,
• finalen Statuscode,
• finalen Canonical,
• Übereinstimmung mit dem geplanten Ziel.

Ein paar manuelle Browserchecks reichen bei einer größeren Migration nicht. Schon ein fehlendes Zeichen in einer globalen Regel kann ganze Verzeichnisse falsch umleiten.

Wenn du technische Umsetzung und Qualitätssicherung nicht intern abdecken kannst, unterstützt dich unser Bereich technisches SEO bei Crawling, Indexierungssteuerung und Migrationstests.

Stop or Go: Darf die neue Website live gehen?

Eine klare Freigabetabelle verhindert, dass Zeitdruck kritische Fehler relativiert. Lege die Schwellen vor dem Launch fest.

Bei einem Stop-Kriterium ist eine Verschiebung meist günstiger als ein überstürzter Launch. Besonders globale Indexierungssperren, fehlerhafte Redirect-Regeln und nicht messbare Conversions sind keine Schönheitsfehler.

Phase 3: Go-live kontrolliert durchführen

Plane den Launch in einem Zeitraum mit niedrigerem Geschäfts- und Websiteaufkommen, sofern das für dein Unternehmen möglich ist. Das schafft Raum für Kontrollen, ist aber kein SEO-Trick. Entscheidend bleibt, dass das verantwortliche Team erreichbar ist.

Empfohlene Reihenfolge am Launch-Tag

1. Änderungsstopp aktivieren: Friere alte und neue Inhalte kurzzeitig ein, damit Mapping und Datenbestand nicht auseinanderlaufen.
2. Backup und Rückfallpunkt bestätigen: Prüfe, ob die letzte funktionsfähige Version tatsächlich wiederhergestellt werden kann.
3. Neue Version veröffentlichen: Spiele Anwendung, Daten, Assets und Serverkonfiguration in der abgestimmten Reihenfolge aus.
4. Permanente Redirects aktivieren: Setze die freigegebenen 301- oder 308-Regeln serverseitig um.
5. Indexierung freigeben: Entferne Staging-Schutz, globale noindex-Anweisungen und versehentliche Crawler-Sperren vom Livesystem.
6. Smoke Tests durchführen: Prüfe Startseite, wichtigste Landingpages, Formulare, Navigation, Statuscodes und Redirect-Stichproben auf Desktop und Mobilgerät.
7. Interne Signale kontrollieren: Teste Canonicals, interne Links, strukturierte Daten, Sprachversionen und die neue XML-Sitemap.
8. Messung verifizieren: Löse echte Test-Conversions aus und kontrolliere, ob sie korrekt erfasst werden.
9. Search Console aktualisieren: Reiche die neue Sitemap ein und prüfe einzelne Schlüssel-URLs mit der URL-Prüfung.
10. Monitoring starten: Beobachte Serverfehler, Crawling, Indexierung, organische Landingpages und Geschäftsziele ab der ersten Stunde.

Wann das Change-of-Address-Tool sinnvoll ist

Das Tool zur Adressänderung in der Google Search Console ist für einen vollständigen Wechsel von einer Domain oder Subdomain auf eine andere vorgesehen. Das Google-Konto, mit dem du die Änderung meldest, braucht Inhaberrechte für die alte und die neue Property. Die permanenten Weiterleitungen müssen bereits funktionieren. Prüfe außerdem separat eingebundene Subdomains und Property-Varianten, wenn sie Teil des Umzugs sind.

Nutze es nicht für reine Pfadänderungen innerhalb derselben Domain, einen Wechsel von HTTP auf HTTPS, einen Wechsel zwischen www und non-www oder einen Hostingwechsel ohne sichtbare URL-Änderung. In diesen Fällen sind korrekte Redirects, Canonicals, interne Links und Sitemaps die entscheidenden Signale.

Direkt nach der Veröffentlichung prüfen

Teste nicht nur neue URLs. Rufe auch eine Stichprobe alter URLs aus unterschiedlichen Verzeichnissen auf. Jede muss genau die im Mapping festgelegte Antwort liefern. Prüfe zusätzlich:

• 200 für indexierbare neue Seiten,
• 301 oder 308 für dauerhaft umgezogene Seiten,
• 404 oder 410 für bewusst entfernte Inhalte ohne Ersatz,
• keine unerwarteten 302, 307 oder 5xx-Antworten,
• keine Redirect-Schleifen oder mehrstufigen Ketten,
• keine Staging-Domain in Quellcode, Canonical, Bildern oder internen Links.

Phase 4: SEO-Monitoring nach dem Relaunch

Ein erfolgreicher Go-live beendet die Migration nicht. Google muss alte und neue URLs erneut abrufen, Signale verarbeiten und den Index aktualisieren. Dabei können Rankings und Sichtbarkeit vorübergehend schwanken. Wie schnell sich die Lage stabilisiert, hängt unter anderem von Umfang, Crawl-Frequenz, Serverleistung und Qualität der Umsetzung ab.

Praktischer Monitoring-Zeitplan

Die Intervalle sind ein Arbeitsplan. Passe sie an Umfang, Crawling und Geschäftswirkung deiner Website an.

Abweichungen richtig priorisieren

Nicht jeder Positionswechsel ist sofort ein Notfall. Priorisiere Fehler nach Reichweite und Geschäftswirkung:

1. Kritisch: Website nicht erreichbar, globale noindex-Regel, flächendeckende 5xx-Fehler, defekte Formulare oder Redirect-Schleifen.
2. Hoch: wichtige Landingpages liefern 404, Canonicals zeigen auf falsche Domains, zentrale Inhalte fehlen oder Tracking fällt aus.
3. Mittel: einzelne Redirect-Ketten, fehlende Metadaten, nicht aktualisierte interne Links oder Sitemap-Abweichungen.
4. Beobachten: normale kurzfristige Rankingbewegungen ohne technische Auffälligkeit und ohne breiten Verlust wichtiger Landingpages.

Vergleiche dabei nicht nur den Gesamttraffic. Ein stabiler Gesamtwert kann Verluste auf einer wertvollen Leistungsseite verdecken, wenn ein Blogartikel gleichzeitig mehr Besuche erhält. Prüfe deshalb URL-Gruppen, Suchintentionen und Conversions getrennt.

Kompakte SEO-Relaunch-Checkliste zum Abhaken

Vor dem Relaunch

• Ziele, KPIs und geschäftskritische Landingpages dokumentiert
• vollständige URL-Liste aus Sitemap, Crawl, Search Console, Analytics und Backlinkdaten erstellt
• Rankings, Klicks, Impressionen, Conversions und Indexierungsstand gesichert
• jede alte URL einer Aktion und gegebenenfalls einer Ziel-URL zugeordnet
• Inhalte, Metadaten, strukturierte Daten und interne Links geplant
• Redirect-Regeln aus dem freigegebenen Mapping vorbereitet
• Rollen, Launchfenster, Backup und Rollback festgelegt

Auf dem Staging-System

• Testumgebung durch Zugriffsschutz vor Indexierung geschützt
• alle Seitentemplates auf Inhalt, H1, Title, Description und Canonical geprüft
• indexierbare Seiten für index,follow auf dem Livesystem vorbereitet
• keine internen Links oder Assets verweisen auf Staging-Adressen
• mobile Darstellung, Rendering und Ladeleistung getestet
• Sitemap enthält nur kanonische, indexierbare 200-URLs
• Redirects automatisiert auf Ziel, Status, Ketten und Schleifen geprüft
• Analytics, Consent und Test-Conversions funktionieren

Beim Go-live

• neue Website, Serverkonfiguration und Redirects vollständig veröffentlicht
• Zugriffsschutz, noindex und unbeabsichtigte robots.txt-Sperren entfernt
• wichtige neue URLs liefern 200 und den richtigen Canonical
• alte URLs liefern die im Mapping definierte Antwort
• Navigation, Formulare, Bilder und interne Links funktionieren
• neue Sitemap in der Search Console eingereicht
• Change of Address nur bei tatsächlichem Domain- oder Subdomainwechsel genutzt
• Monitoring und Fehlereskalation aktiviert

Nach dem Go-live

• Serverfehler, 404/410, Redirects und Crawling regelmäßig geprüft
• Indexierung und Canonical-Auswahl wichtiger URLs beobachtet
• organische Landingpages, Suchanfragen und Conversions verglichen
• interne Links auf finale URLs umgestellt und Betreiber besonders wichtiger verlinkender Websites um Aktualisierung gebeten
• Redirects mindestens ein Jahr bestehen lassen
• Erkenntnisse, Korrekturen und offene Punkte im Migrationsprotokoll dokumentiert

Typische Fehler, die Rankings unnötig gefährden

SEO wird erst kurz vor dem Launch eingebunden. Dann sind URL-Struktur und Templates oft bereits festgelegt. Korrekturen werden teuer oder unter Zeitdruck ausgelassen.

Die neue Navigation ersetzt wichtige interne Links. Eine schlankere Menüstruktur kann sinnvoll sein, darf aber zentrale Seiten nicht zu tief verstecken. Prüfe, wie Nutzer und Crawler weiterhin zu ihnen gelangen.

Inhalte werden aus Designgründen stark gekürzt. Ein moderneres Layout gleicht nicht automatisch den Verlust hilfreicher Antworten, lokaler Relevanz oder klarer Leistungsbeschreibungen aus.

Canonicals zeigen noch auf Staging oder die alte Domain. Das erzeugt widersprüchliche Konsolidierungssignale. Prüfe den tatsächlich ausgelieferten Quellcode, nicht nur die Einstellung im CMS.

Die robots.txt wird mit Indexierungssteuerung verwechselt. Crawling zu blockieren ist nicht dasselbe wie eine URL per noindex aus dem Index zu halten. Beim Relaunch muss jede Maßnahme den richtigen Zweck erfüllen.

Alle 404-Fehler werden pauschal weitergeleitet. Echte entfernte Inhalte dürfen 404 oder 410 liefern. Nur URLs mit einem passenden Nachfolger sollten permanent umziehen.

Nach dem Launch wird nur auf Rankings geschaut. Prüfe ebenso Crawling, Statuscodes, Landingpages, Leads und Umsätze. Rankings können schwanken, während ein technischer Conversionfehler bereits reale Anfragen kostet.