seo relaunch checklisteseo checklistewebsite relaunch seo

SEO Relaunch Checkliste: 50 Punkte vor dem Go-Live

12. března 2026

9 min read

Lukas Lavicka

SEO-Relaunch: Warum 90% der Traffic-Verluste vermeidbar sind

Ein Website-Relaunch ist für Entwickler ein Upgrade. Für SEO ist es ein Risiko. Wenn du die URL-Struktur änderst, das CMS wechselst oder das Frontend neu baust, kann organischer Traffic innerhalb von Tagen einbrechen.

Das passiert nicht, weil Google Relaunches bestraft. Es passiert, weil Entwickler und Agenturen die SEO-Basics bei der Migration vergessen. Fehlende Redirects, verwaiste Canonical Tags und gelöschte Inhalte sind die typischen Ursachen.

Diese Checkliste ist kein allgemeiner SEO-Guide. Sie ist spezifisch für Entwickler und Agenturen, die einen technischen Relaunch durchführen und den organischen Traffic erhalten wollen.

Phase 1: Vor dem Relaunch (2-4 Wochen vorher)

1.1 Komplettes Crawl der alten Seite erstellen

Bevor du irgendetwas anfasst: Crawle die bestehende Seite und dokumentiere den Ist-Zustand.

Was du brauchst:

Vollständige URL-Liste aller indexierten Seiten
Seitenstruktur mit Status-Codes
Interne Verlinkung
Meta-Daten (Title, Description) aller Seiten
Bestehende Redirects
Sitemap.xml Inhalt

Tools dafür:

Screaming Frog (kostenlos bis 500 URLs)
Google Search Console > Seiten (indexierte URLs)
site:deine-domain.de in Google (Quick-Check)

Exportiere alles in eine Tabelle. Diese Daten sind deine Referenz für das URL-Mapping.

1.2 URL-Mapping erstellen

Das URL-Mapping ist das wichtigste Dokument im gesamten Relaunch-Prozess. Es definiert, welche alte URL auf welche neue URL weiterleitet.

# URL-Mapping Beispiel
Alte URL                           → Neue URL                          → Status
/leistungen/webdesign              → /services/webdesign               → 301
/blog/2024/seo-tipps               → /blog/seo-tipps                   → 301
/kontakt.html                      → /kontakt                          → 301
/team/max-mustermann               → /ueber-uns#team                   → 301
/altes-produkt                     → (gelöscht)                        → 410

Regeln für das URL-Mapping:

Jede URL mit organischem Traffic bekommt einen 301-Redirect
Jede URL mit Backlinks bekommt einen 301-Redirect
Seiten die ersatzlos entfallen: 410 Gone (nicht 404)
1:1 Mapping wo möglich (alte Seite auf inhaltlich identische neue Seite)
Keine Redirect-Chains (alt > zwischenseite > neu)

1.3 Backlink-Profil dokumentieren

Welche externen Seiten verlinken auf dich? Diese URLs brauchen zwingend Redirects. Prüfe mit Ahrefs, Semrush oder der Search Console, welche Seiten die meisten Backlinks haben.

Wenn du 50 Backlinks auf /altes-blog/seo-guide-2024 hast und diese URL nach dem Relaunch ins Nichts führt, verlierst du den gesamten Link Equity.

1.4 Rankings und Traffic dokumentieren

Erstelle einen Snapshot der aktuellen Performance:

Top 50 Keywords mit Rankings (Search Console)
Top 20 Seiten nach organischem Traffic (Search Console oder Analytics)
Core Web Vitals Werte (PageSpeed Insights)

Das ist deine Baseline. Ohne diese Daten kannst du nach dem Relaunch nicht messen, ob etwas schiefgelaufen ist.

1.5 Search Console vorbereiten

Verifiziere die neue Domain/URL-Variante in der Search Console (falls sich die Domain ändert)
Richte die neue Property ein, bevor der Relaunch live geht
Bei Domain-Wechsel: Adressänderung in der Search Console vorbereiten

Phase 2: Technische Umsetzung

2.1 301-Redirects implementieren

301-Redirects sind der Kern jeder SEO-Migration. Sie leiten User und Suchmaschinen von der alten URL auf die neue weiter und übertragen den Großteil des Link Equity.

Für Nginx:

# Einzelne Redirects
location = /alte-seite {
    return 301 /neue-seite;
}

# Pattern-basierte Redirects
location ~ ^/blog/(\d{4})/(.+)$ {
    return 301 /blog/$2;
}

# Gesamte Domain
server {
    server_name alte-domain.de www.alte-domain.de;
    return 301 https://neue-domain.de$request_uri;
}

Für Apache (.htaccess):

# Einzelne Redirects
Redirect 301 /alte-seite https://deine-domain.de/neue-seite

# Pattern-basierte Redirects
RedirectMatch 301 ^/blog/([0-9]{4})/(.+)$ https://deine-domain.de/blog/$2

Für Next.js (next.config.js):

module.exports = {
  async redirects() {
    return [
      {
        source: '/alte-seite',
        destination: '/neue-seite',
        permanent: true,
      },
      {
        source: '/blog/:year(\\d{4})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
    ];
  },
};

Für Vercel (_redirects oder vercel.json):

{
  "redirects": [
    {
      "source": "/alte-seite",
      "destination": "/neue-seite",
      "permanent": true
    }
  ]
}

2.2 Redirect-Chains vermeiden

Ein häufiger Fehler bei Relaunches: Die alten Redirects bleiben bestehen und es entsteht eine Chain.

/seite-2020 → 301 → /seite-2022 → 301 → /seite-2026

Google folgt Redirect-Chains (bis zu einem gewissen Punkt), aber jeder Hop kostet Crawl-Budget und kann Link Equity verlieren. Löse alle Chains zu direkten Redirects auf:

/seite-2020 → 301 → /seite-2026
/seite-2022 → 301 → /seite-2026

2.3 Canonical Tags setzen

Jede Seite der neuen Website braucht einen self-referencing Canonical Tag:

<link rel="canonical" href="https://deine-domain.de/neue-seite" />

Häufige Fehler:

Canonical zeigt auf die alte URL (CMS-Migration übernimmt alte Werte)
Canonical fehlt komplett
Canonical zeigt auf HTTP statt HTTPS
Trailing Slash Inkonsistenz (/seite vs. /seite/)

2.4 Sitemap.xml aktualisieren

Die neue Sitemap muss:

Alle neuen URLs enthalten
Keine alten/redirecteten URLs enthalten
In der Search Console eingereicht sein
Korrekte lastmod Daten haben

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://deine-domain.de/</loc>
    <lastmod>2026-03-25</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://deine-domain.de/leistungen</loc>
    <lastmod>2026-03-25</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

2.5 robots.txt prüfen

Einer der häufigsten Relaunch-Fehler: Die Staging-Seite hatte ein Disallow: / in der robots.txt, und das wird auf die Live-Seite übernommen.

# FALSCH (Staging-Überbleibsel)
User-agent: *
Disallow: /

# RICHTIG
User-agent: *
Allow: /
Sitemap: https://deine-domain.de/sitemap.xml

Prüfe nach dem Go-Live sofort https://deine-domain.de/robots.txt im Browser.

2.6 Hreflang Tags (bei mehrsprachigen Seiten)

Wenn du mehrsprachige Seiten hast, müssen die Hreflang Tags auf die neuen URLs zeigen:

<link rel="alternate" hreflang="de" href="https://deine-domain.de/de/seite" />
<link rel="alternate" hreflang="en" href="https://deine-domain.de/en/page" />
<link rel="alternate" hreflang="x-default" href="https://deine-domain.de/en/page" />

Hreflang-Fehler nach einem Relaunch sind einer der hartnäckigsten Probleme, weil sie in der Search Console erst nach Wochen auftauchen.

Phase 3: Testing vor Go-Live

3.1 Staging-Checkliste

Teste auf der Staging-Umgebung:

3.2 Automatisierter Redirect-Test

Für große Seiten (100+ URLs) lohnt sich ein automatisierter Test:

#!/bin/bash
# redirect-test.sh
# Testet alle Redirects aus einer CSV-Datei

while IFS=, read -r old_url new_url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$old_url")
  final_url=$(curl -o /dev/null -s -w "%{url_effective}" -L "$old_url")

  if [ "$final_url" != "$new_url" ]; then
    echo "FEHLER: $old_url -> $final_url (erwartet: $new_url, Status: $status)"
  else
    echo "OK: $old_url -> $new_url ($status)"
  fi
done < redirects.csv

3.3 Core Web Vitals vergleichen

Teste die wichtigsten Seiten der neuen Website mit PageSpeed Insights und vergleiche mit den Baseline-Werten. LCP sollte unter 2,5 Sekunden bleiben, CLS unter 0,1, INP unter 200ms.

Wenn die neue Seite langsamer ist als die alte, ist das ein SEO-Problem, das du vor dem Go-Live lösen musst.

Phase 4: Go-Live und Monitoring

4.1 Go-Live Checkliste

Am Tag des Relaunches:

DNS umstellen oder Deployment durchführen
robots.txt live prüfen (kein Disallow!)
Sitemap in Search Console einreichen
Indexierung der wichtigsten Seiten manuell anfordern (URL-Prüfung > Indexierung beantragen)
Google Rich Results Test für die Homepage
SSL-Zertifikat prüfen

4.2 Die ersten 48 Stunden

Stündlich die wichtigsten URLs auf korrekte Status-Codes prüfen
Search Console auf neue Fehler prüfen (Abdeckung > Fehler)
Analytics auf Traffic-Einbrüche monitoren
Server-Logs auf 404-Fehler prüfen

4.3 Die ersten 4 Wochen

Wöchentlich Rankings der Top-Keywords vergleichen (Baseline vs. aktuell)
Search Console: Indexierung, Crawl-Statistiken, Mobile Usability
Neue 404-Fehler identifizieren und mit Redirects abfangen
Core Web Vitals im Feld (CrUX-Daten) nach 28 Tagen prüfen

4.4 Wann du eingreifen musst

Ein Ranking-Drop von 10-20% [SCHÄTZUNG] in den ersten 2 Wochen ist normal. Google muss die neue Struktur neu bewerten. Das gleicht sich in der Regel innerhalb von 4-8 Wochen [SCHÄTZUNG] aus.

Alarmzeichen:

Traffic-Drop von über 50% nach einer Woche
Wichtige Seiten werden deindexiert
Redirect-Loops (5xx Fehler in der Search Console)
Massive 404-Fehler (100+ neue Fehler)

In diesen Fällen: Sofort handeln. Redirects prüfen, robots.txt prüfen, Search Console Fehler-Report analysieren.

Die 5 häufigsten Relaunch-Fehler

1. Kein URL-Mapping erstellt

"Wir haben ja fast die gleichen URLs." Fast ist nicht gleich. Jede URL-Änderung, auch wenn es nur ein Trailing Slash oder die Entfernung von .html ist, braucht einen Redirect.

2. robots.txt blockiert alles

Das Staging-Disallow: / überlebt den Relaunch. Oft vergehen Tage, bis es jemand bemerkt. Dann hat Google bereits aufgehört zu crawlen.

3. Alte Canonical Tags

Das CMS übernimmt die Canonical Tags aus der alten Seite. Jede Seite zeigt jetzt auf eine URL, die nicht mehr existiert oder auf eine Redirect verweist. Google bewertet das als Signal, diese Seite nicht zu indexieren.

4. Interne Links nicht aktualisiert

Die Redirects funktionieren, aber die interne Verlinkung zeigt noch auf die alten URLs. Jeder interne Klick löst einen Redirect aus. Das kostet Performance und Crawl-Budget.

Durchsuche den gesamten Code und die Datenbank nach alten URLs:

# Alte URLs in Dateien finden
grep -r "alte-domain.de" --include="*.html" --include="*.tsx" --include="*.json" ./src

5. Kein Monitoring nach Go-Live

Der Relaunch ist live, alle gehen in den Feierabend. Drei Tage später: 60% Traffic-Verlust. Ohne Monitoring merkst du Probleme erst, wenn es zu spät ist.

Relaunch SEO-Audit: Wie crawlix hilft

Ein SEO-Audit vor dem Relaunch gibt dir die Baseline. Ein Audit nach dem Relaunch prüft, ob alles sauber umgesetzt wurde.

Was crawlix bei Relaunch-Audits prüft:

Redirect-Vollständigkeit (alle alten URLs abgefangen?)
Canonical-Korrektheit
Indexierungs-Status
Schema-Migration
Core Web Vitals Vergleich
Interne Verlinkung (keine verwaisten Seiten)

Für Agenturen, die regelmäßig Relaunches für Kunden durchführen, ist das ein skalierbarer Quality Check. Du lieferst dem Kunden nicht nur die neue Website, sondern den Nachweis, dass der organische Traffic gesichert ist.

Fazit

Ein SEO-sicherer Relaunch ist keine Raketenwissenschaft. Es ist ein strukturierter Prozess mit klaren Checkpoints. Die meisten Traffic-Verluste passieren nicht wegen technischer Komplexität, sondern wegen fehlender Vorbereitung.

Die Kurzversion:

Vorher: Crawl, URL-Mapping, Backlink-Profil, Baseline-Daten
Umsetzung: 301-Redirects, Canonicals, Sitemap, robots.txt
Testing: Staging-Checkliste, automatisierte Redirect-Tests
Nachher: 4 Wochen Monitoring, schnelles Reagieren bei Problemen

Wer die Checkliste durcharbeitet, behält den Traffic. Wer sie ignoriert, repariert hinterher.

SEO als neues Standbein für Ihre Agentur

Professionelle SEO-Audits anbieten ohne eigenes SEO-Team. Mit Code-Snippets und 4-Phasen-Umsetzungsplan.

Audit-Details ansehen