CMS-Migration ohne SEO-Rankings zu verlieren: Ein vollständiger Leitfaden

Ich habe Unternehmen dabei zugesehen, wie sie über Nacht 40-60% ihres organischen Traffic verloren haben, weil jemand dachte, eine CMS-Migration wäre "nur ein technisches Projekt". Das ist nicht wahr. Es ist ein SEO-Projekt mit technischen Komponenten, und die Reihenfolge dieser Worte ist wichtig.

In den letzten sieben Jahren habe ich persönlich Migrationen von WordPress zu Headless-Setups, Drupal zu Sanity, Legacy-.NET-Sites zu Next.js und allem dazwischen geleitet oder beaufsichtigt. Einige verliefen fehlerfrei. Einige waren Katastrophen, die ich geerbt und reparieren musste. Dieser Leitfaden ist alles, was ich von beiden Seiten dieser Medaille gelernt habe.

Die Einsätze sind real. Laut einer Studie von Ahrefs aus dem Jahr 2024 erleben 34% der Websites, die eine CMS-Migration durchlaufen, einen Traffic-Rückgang von mehr als 20%, dessen Erholung länger als sechs Monate dauert. Aber hier ist das Ding – das muss nicht so sein. Mit dem richtigen Prozess können Sie Ihre CMS migrieren und mit intakten Rankings herauskommen, manchmal sogar mit verbesserten.

Inhaltsverzeichnis

• Warum CMS-Migrationen SEO zerstören (wenn sie schiefgehen)
• Das Vor-Migrations-Audit: Ihr Sicherheitsnetz
• URL-Struktur: Der wichtigste einzelne Faktor
• Redirect-Mapping: Die mühsame Arbeit, die alles rettet
• Content Parity: Mehr als nur Copy-Paste
• Technisches SEO Checkliste für Migration Day
• Meta Data, Schema und strukturierte Daten Migration
• Interne Link Bewahrung
• Leistung und Core Web Vitals
• Post-Migration Monitoring Protokoll
• Headless CMS Migrationen: Spezielle Überlegungen
• Recovery Plan: Was zu tun ist, wenn Rankings fallen
• FAQ

Warum CMS-Migrationen SEO zerstören (wenn sie schiefgehen)

Google kümmert sich nicht, welches CMS Sie verwenden. Es kümmert sich um URLs, Inhalte, Seitengeschwindigkeit, interne Links und die Tausenden von Signalen, die es über Jahre hinweg über Ihre Website aufgebaut hat. Wenn Sie all das herausreißen und durch etwas Neues ersetzen, bitten Sie Google im Grunde, Ihre gesamte Website von Grund auf neu zu bewerten.

Hier ist, was typischerweise schiefgeht:

• URL-Strukturen ändern sich ohne ordnungsgemäße Umleitungen (dies macht allein etwa 70% der Post-Migration Traffic-Rückgänge aus)
• Inhalte werden geändert, gekürzt oder reorganisiert auf eine Weise, die die topikalen Relevanzsignale verändert
• Interne Links werden unterbrochen, weil die neue CMS unterschiedliche URL-Muster generiert
• Die Seitengeschwindigkeit wird langsamer, weil niemand die neue Template-Leistung getestet hat
• Meta-Daten gehen verloren – Title Tags, Beschreibungen, Canonical Tags, Hreflang-Attribute
• Strukturierte Daten verschwinden, weil das alte CMS Plugins hatte, die diese automatisch generierten

Das Schlimmste? Diese Probleme verstärken sich gegenseitig. Eine einzelne unterbrochene Redirect-Kette kann sich über Hunderte von Seiten ausbreiten.

Das Vor-Migrations-Audit: Ihr Sicherheitsnetz

Bevor Sie eine einzelne Codezeile auf dem neuen CMS anfassen, benötigen Sie einen vollständigen Snapshot Ihres aktuellen SEO-Zustands. Stellen Sie sich das wie einen Save Point in einem Videospiel vor – Sie brauchen etwas, um es dagegen zu vergleichen.

Was zu crawlen und zu exportieren ist

Verwenden Sie Screaming Frog, Sitebulb oder Ahrefs Site Audit, um Ihre gesamte bestehende Website zu crawlen. Exportieren Sie alles:

# Wichtigste zu erfassende Datenpunkte:
- Alle URLs (jede einzelne, einschließlich Seiten mit Paginierung)
- HTTP-Statuscodes
- Title Tags
- Meta-Beschreibungen
- H1-Tags
- Canonical Tags
- Hreflang-Tags (falls mehrsprachig)
- Interne Links (Quelle und Ziel)
- Wortanzahl pro Seite
- Schema Markup Typen pro Seite
- Bild-URLs und Alt-Text
- Antwortzeiten
- Core Web Vitals Scores

Baseline Ihre Rankings

Pullen Sie Ranking-Daten aus der Google Search Console für die letzten 16 Monate. Exportieren Sie diese. Pullen Sie auch Daten von jedem Drittanbieter-Tool, das Sie verwenden – Ahrefs, SEMrush, Moz. Sie möchten:

• Top 500 Seiten nach organischem Traffic
• Top 1000 Keywords nach Klicks
• Alle Seiten, die auf Seite 1 für ein beliebiges Keyword rangieren
• Seiten mit Featured Snippets
• Seiten mit Rich Results

Speichern Sie all dies in einem Spreadsheet oder einer Datenbank, auf die Sie nach der Migration verweisen können. Ich verwende normalerweise ein Google Sheet mit Tabs für jeden Datensatz, aber für größere Websites (10k+ Seiten) werde ich schnell eine PostgreSQL-Datenbank aufdrehen.

Identifizieren Sie Ihre geldwertigen Seiten

Nicht alle Seiten sind gleich. Eine Migration, die 95% Ihrer Seiten perfekt bewahrt, aber die Top 20 umsatzgenerierenden Seiten bricht, ist immer noch eine Katastrophe. Identifizieren Sie Seiten nach:

1. Organisches Traffic-Volumen
2. Konversionsrate
3. Einnahme Attribution
4. Backlink-Anzahl (diese übertragen Autorität)
5. Ranking-Position für hochwertige Keywords

Diese Seiten erhalten während der Migration besondere Behandlung.

URL-Struktur: Der wichtigste einzelne Faktor

Ich werde etwas sagen, das extrem klingen könnte: Wenn Sie die exakt gleiche URL-Struktur behalten können, sollten Sie das tun. Auch wenn die alten URLs hässlich sind. Auch wenn sie Daten enthalten. Auch wenn sie Query-Parameter verwenden.

Jede URL-Änderung ist ein Risiko. Punkt.

Wenn URL-Änderungen unvermeidlich sind

Somnotime müssen Sie URLs ändern. Vielleicht konsolidieren Sie Subdomains, wechseln von HTTP zu HTTPS (obwohl das vor Jahren hätte passieren sollen), oder Ihr altes CMS generierte URLs wie /index.php?id=4523&cat=7.

Wenn Sie URLs ändern müssen, folgt hier die Risikhierarchie:

Änderungstyp	Risikostufe	Beispiel
Domain-Änderung	Sehr hoch	oldsite.com → newsite.com
Protokoll-Änderung	Mittel	http → https
Subdomain-Änderung	Hoch	blog.site.com → site.com/blog
Path-Umstrukturierung	Mittel-Hoch	/2024/01/post-name → /blog/post-name
Slug-Änderung	Mittel	/old-slug → /new-slug
Parameter zu Path	Mittel	/?p=123 → /actual-slug
Trailing Slash Änderung	Niedrig	/page → /page/

URL Mapping Spreadsheet

Erstellen Sie ein Mapping-Dokument mit diesen Spalten:

| Alte URL | Neue URL | Statuscode | Priorität | Notizen |
|---------|---------|-------------|----------|--------|
| /old-page | /new-page | 301 | Hoch | Top 10 nach Traffic |
| /removed-page | /relevant-page | 301 | Mittel | Inhalte zusammengeführt |
| /still-exists | /still-exists | 200 | Niedrig | Keine Änderung erforderlich |

Für eine Website mit 500 Seiten dauert dies etwa 2-3 Tage konzentrierter Arbeit. Für eine Website mit 10.000 Seiten benötigen Sie Regex-Muster und automatisierte Mapping-Skripte. Wir haben für genau diesen Fall benutzerdefinierte Migrations-Tools erstellt, wenn wir an Headless CMS Entwicklungsprojekten arbeiten.

Redirect-Mapping: Die mühsame Arbeit, die alles rettet

Umleitungen sind Ihr Sicherheitsnetz. Jede alte URL, die sich ändert, muss auf 301 zu ihrem neuen Äquivalent umleiten. Nicht die Homepage. Nicht eine Kategorieseite. Der tatsächliche äquivalente Inhalt.

Regeln für Umleitungen

1. Verwenden Sie immer 301 (permanente) Umleitungen, nicht 302 (temporär). Google behandelt sie unterschiedlich bei der Übertragung von Link Equity.
2. Vermeiden Sie Redirect-Ketten. Wenn A auf B umleitet und B auf C umleitet, das ist eine Kette. Jeder Hop verliert etwas Equity (Google sagt, dass es nicht so ist, aber empirische Daten aus 2024-Studien von Cyrus Shepard und anderen deuten andernfalls hin).
3. Leiten Sie nicht alles auf die Homepage um. Dies wird "Soft 404" genannt und Google wird diese URLs schließlich als wirklich weg behandeln.
4. Map 1:1 wo möglich. Alte Seite → äquivalente neue Seite.
5. Behandeln Sie gelöschte Inhalte richtig. Wenn eine Seite kein Äquivalent hat, finden Sie die nächste topisch relevante Seite oder geben Sie einen korrekten 410 (Gone) Status zurück.

Implementierung in verschiedenen Umgebungen

Für Next.js (das wir ausgiebig in unserer Next.js Entwicklung verwenden):

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-blog/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      {
        source: '/category/:cat/post/:id',
        destination: '/blog/:id',
        permanent: true,
      },
      // Für große Umleitungslisten aus einer JSON-Datei importieren
      ...require('./redirects.json'),
    ]
  },
}

Für Nginx:

# Individuelle Umleitungen
rewrite ^/old-page$ /new-page permanent;

# Pattern-basierte Umleitungen
rewrite ^/blog/(\d{4})/(\d{2})/(.*)$ /blog/$3 permanent;

# Map-basierte Umleitungen für große Listen
map $request_uri $new_uri {
    include /etc/nginx/redirects.map;
}

server {
    if ($new_uri) {
        return 301 $new_uri;
    }
}

Für Vercel/Edge-basiertes Hosting:

// vercel.json
{
  "redirects": [
    {
      "source": "/old-path/:match*",
      "destination": "/new-path/:match*",
      "permanent": true
    }
  ]
}

Umleitungen vor Go-Live testen

Das ist nicht verhandelbar. Ich habe Teams gesehen, die 3.000 Umleitungsregeln schreiben und bereitstellen, ohne zu testen. Seien Sie nicht dieses Team.

# Einfaches Bash-Skript zum Testen von Umleitungen
while IFS=, read -r old_url expected_url; do
    actual_url=$(curl -Ls -o /dev/null -w %{url_effective} "$old_url")
    if [ "$actual_url" != "$expected_url" ]; then
        echo "FAIL: $old_url -> $actual_url (erwartet $expected_url)"
    fi
done < redirect_test_urls.csv

Content Parity: Mehr als nur Copy-Paste

Wenn ich "Content Parity" sage, meine ich nicht nur, dass der Body-Text übereinstimmt. Ich meine, dass das gesamte Content-Erlebnis gleichwertig oder besser sein muss.

Was als Inhalt für Google zählt

• Haupttext
• Überschriften (H1-H6 Hierarchie)
• Bilder mit Alt-Text
• Videos und Einbettungen
• Tabellen
• Listen
• Autoreninformationen (E-E-A-T Signale)
• Veröffentlichungs- und Aktualisierungsdaten
• Kommentare (ja, Google indexiert diese)
• Verwandte Inhaltslinks

Häufige Content Parity Fehler

Die Sidebar-Inhalte fallen lassen. Ihre alte Website hatte eine Seitenleiste mit verwandten Artikeln, beliebten Beiträgen oder kontextbezogenen Links. Ihr neues Design ist vollbreite und sauber. Diese Links waren Teil Ihrer internen Linking-Architektur. Sie haben das gerade unterbrochen.

Änderung der Überschriften-Hierarchie. Wenn Ihre alte Seite einen H1 von "Beste React Frameworks in 2026" hatte und Ihre neue CMS-Template ändert ihn zu "React Frameworks", weil jemand sauberere Titel wollte, haben Sie ein Ranking-Signal geändert.

Alt-Text verlieren. Die meisten CMS-Migrations-Tools importieren Bilder, aber entfernen Alt-Text. Überprüfen Sie dies manuell für mindestens Ihre Top 100 Seiten.

Inhalte zusammenführen oder aufteilen. Wenn Sie zwei Seiten zu einer zusammenführen, müssen Sie die sekundäre URL auf die zusammengeführte Seite umleiten. Wenn Sie eine Seite auf mehrere aufteilen, sollte die ursprüngliche URL auf die relevanteste neue Seite umleiten, und Sie werden wahrscheinlich temporäre Ranking-Schwankungen sehen.

Technisches SEO Checkliste für Migration Day

Hier ist die Checkliste, die ich am Migration Day verwende. Drucken Sie sie aus. Kleben Sie sie auf Ihren Monitor.

## Vor dem Start (Tag der Migration)
- [ ] Alle Umleitungen getestet und bestätigt funktionierend
- [ ] XML-Sitemap mit neuen URLs aktualisiert
- [ ] Alte Sitemap entfernt oder umgeleitet
- [ ] robots.txt überprüft (neue Website NICHT blockieren)
- [ ] Canonical Tags zeigen auf richtige neue URLs
- [ ] Hreflang Tags aktualisiert (falls mehrsprachig)
- [ ] SSL-Zertifikat auf allen Domains/Subdomains gültig
- [ ] CDN Cache gelöscht
- [ ] DNS TTL 48 Stunden vorher gesenkt

## Nach dem Start (innerhalb von 1 Stunde)
- [ ] Neue Website mit Screaming Frog crawlen
- [ ] Neue Sitemap in Google Search Console einreichen
- [ ] Indexierungsanfrage für Top 20 Money Pages
- [ ] Überprüfen auf versehentliche Noindex Tags
- [ ] Überprüfen robots.txt ist zugänglich
- [ ] 50 zufällige Umleitungen manuell testen
- [ ] Überprüfen strukturierte Daten im Rich Results Test
- [ ] Überprüfen Core Web Vitals auf Top Pages

## Nach dem Start (innerhalb von 24 Stunden)
- [ ] Überwachen Sie Google Search Console auf Crawl-Fehler
- [ ] Überprüfen Sie Server-Logs auf 404 Spitzen
- [ ] Überprüfen Sie Google Analytics/Tag-Tracking auf allen Seiten
- [ ] Vergleichen Sie indexierte Seitenzahl (site:yourdomain.com)
- [ ] Testen Sie alle Formulare und Konversionspfade

Meta Data, Schema und strukturierte Daten Migration

Hier ist, wo viele WordPress-zu-Headless-Migrationen auseinanderfallen. WordPress-Websites verlassen sich oft auf Yoast SEO oder Rank Math, um Meta-Tags, Open Graph Daten und Schema Markup automatisch zu generieren. Wenn Sie zu einem Headless CMS wie Sanity, Contentful oder Storyblok wechseln, verschwindet diese Automatisierung.

Was Sie bewahren müssen

Element	Wo es lebt (WordPress)	Wohin es geht (Headless)
Title Tag	Yoast SEO Plugin	Frontend Framework Head Verwaltung
Meta Beschreibung	Yoast SEO Plugin	Frontend Framework oder CMS Feld
OG Bild	Yoast/Auto-generiert	CMS Feld + Frontend Rendering
JSON-LD Schema	Plugin-generiert	Benutzerdefinierten Code im Frontend
Breadcrumb Schema	Plugin-generiert	Component-Level Implementierung
FAQ Schema	Plugin oder manuell	CMS strukturierter Inhalt + Frontend
Canonical URL	Auto-generiert	Explizite Implementierung erforderlich

Für Astro-basierte Builds behandeln wir dies normalerweise mit einer dedizierten SEO-Komponente:

---
// src/components/SEOHead.astro
const { title, description, canonical, ogImage, schema } = Astro.props;
---
<title>{title}</title>
<meta name="description" content={description} />
<link rel="canonical" href={canonical} />
<meta property="og:title" content={title} />
<meta property="og:description" content={description} />
<meta property="og:image" content={ogImage} />
{schema && (
  <script type="application/ld+json" set:html={JSON.stringify(schema)} />
)}

Interne Link Bewahrung

Interne Links sind das Kreislaufsystem Ihres SEO. Sie verteilen Page Authority, signalisieren Content-Beziehungen zu Google und helfen bei der Crawlbarkeit.

Während einer Migration werden interne Links auf zwei Arten unterbrochen:

1. Hardcodierte Links in Inhalten, die auf alte URLs verweisen
2. Programmgesteuerte Links (Navigation, Fußzeilen, Seitenleisten, verwandte Beiträge), die die neue CMS anders generiert

Fixing Content Links

Vor der Migration führen Sie ein Skript aus, um alle internen Links in Ihrem Inhalt zu finden und zu ersetzen:

import re

def update_internal_links(content, redirect_map):
    """Ersetzen Sie alte interne URLs durch neue in Inhalten."""
    for old_url, new_url in redirect_map.items():
        # Übereinstimmung mit absoluten und relativen URLs
        content = content.replace(f'href="{old_url}"', f'href="{new_url}"')
        content = content.replace(
            f'href="https://yourdomain.com{old_url}"',
            f'href="https://yourdomain.com{new_url}"'
        )
    return content

Verlassen Sie sich nicht nur auf Umleitungen für interne Links. Ja, die Umleitungen funktionieren, aber jeder Umleitungs-Hop fügt Latenz hinzu und (möglicherweise) verdünnt die Link Equity. Beheben Sie die Links an der Quelle.

Leistung und Core Web Vitals

Eine CMS-Migration ist Ihre einzige Chance, eine massive Leistungsverbesserung zu machen oder Ihre Core Web Vitals absolut zu beschädigen.

Der Ranking-Algorithmus von Google für 2026 nutzt weiterhin Core Web Vitals als Ranking-Signal. Die Schwellwerte haben sich nicht geändert:

Metrik	Gut	Verbesserungsbedürftig	Schlecht
LCP (Largest Contentful Paint)	≤ 2,5s	2,5s - 4,0s	> 4,0s
INP (Interaction to Next Paint)	≤ 200ms	200ms - 500ms	> 500ms
CLS (Cumulative Layout Shift)	≤ 0,1	0,1 - 0,25	> 0,25

Wenn Ihre alte WordPress-Website ein LCP von 3,8s hatte und Ihre neue Next.js-Website 1,2s erreicht, das ist ein echtes Ranking-Boost, der darauf wartet, zu passieren. Aber wenn Ihre neue Website ein 2MB JavaScript Bundle lädt und Ihr LCP auf 5s springt, haben Sie gerade ein neues Problem auf top der Migration erstellt.

Testen Sie Ihre Staging-Website gründlich mit Lighthouse, WebPageTest und dem Chrome UX Report, bevor Sie live gehen.

Post-Migration Monitoring Protokoll

Die 30 Tage nach der Migration sind kritisch. Hier ist der Überwachungsplan, dem ich folge:

Woche 1: Tägliche Überwachung

• Google Search Console: Crawl-Stats, Coverage Report, Performance
• Server Logs: 404 Fehler, 500 Fehler, Redirect Loops
• Rankings Tracker: Top 50 Keywords
• Organischer Traffic: Vergleich Tag für Tag mit Vorjahr

Woche 2-4: Wöchentliche Überwachung

• Vollständiger Website-Crawl Vergleich gegen Vor-Migrations-Baseline
• Indexierte Seitenzahl Trend
• Neue Backlink Akquisition (unterbrochene Links von externen Seiten)
• Konversionsrate Vergleich

Monat 2-3: Zweiwöchentliche Überwachung

• Ranking Stabilität für Long-Tail Keywords
• Neue Keyword Erscheinungen
• Core Web Vitals Felddaten (dauert ~28 Tage zum Auffüllen)

Eine vorübergehende Ranking-Schwankung in den ersten 2-4 Wochen ist normal. Google crawlt und bewertet Ihre Website neu. Wenn Sie alles richtig gemacht haben, sollten sich die Rankings innerhalb von 4-6 Wochen stabilisieren und zur Baseline zurückkehren. Wenn sie nicht nach 8 Wochen erholt haben, ist etwas schiefgelaufen.

Headless CMS Migrationen: Spezielle Überlegungen

Die Migration zu einer Headless CMS Architektur führt zu einzigartigen Herausforderungen, die traditionelle CMS-zu-CMS Migrationen nicht haben.

Server-Side Rendering ist nicht verhandelbar

Wenn Ihr Headless Frontend alles Client-seitig rendert (SPA-Stil), wird Google einen schwereren Zeit haben, Ihren Inhalt zu indexieren. Google kann JavaScript rendern, aber es ist langsamer und weniger zuverlässig als das Crawlen von server-gerenderten HTML.

Verwenden Sie SSR oder SSG. Punkt. Frameworks wie Next.js (App Router mit Server Components) und Astro (Server-first standardmäßig) machen das unkompliziert.

Content Modellierungsunterschiede

Traditionelle CMSes speichern Inhalte als HTML Blobs. Headless CMSes wie Sanity verwenden strukturierte Inhalte (Portable Text, Blocks). Während der Migration müssen Sie:

1. Alte HTML-Inhalte in strukturierte Blöcke analysieren
2. Semantische Bedeutung bewahren (Überschriften, Listen, Hervorhebung)
3. Eingebettete Medien handhaben (Bilder, Videos, Iframes)
4. Interne Links konvertieren
5. Alle Inline-Schema oder spezielle Formatierungen bewahren

Das ist wirklich schwierige Arbeit, und das ist, wo wir einen signifikanten Chunk der Zeit in unseren Headless CMS Entwicklungsprojekten verbringen. Automatisierte Tools bringen Sie 80% des Weges dorthin. Die letzten 20% sind manuelle Überprüfung und Aufräumarbeiten.

Preview- und Staging-Workflows

Bevor Sie den Schalter umschalten, benötigt Ihr neues Headless Setup eine Staging-Umgebung, die die Produktion spiegelt. Das bedeutet:

• Gleiche Umleitungsregeln
• Gleiche CDN-Konfiguration
• Gleiches Rendering-Verhalten
• Echter Inhalt (nicht lorem ipsum)

Crawlen Sie die Staging-Umgebung mit Screaming Frog und vergleichen Sie sie mit Ihrer Vor-Migrations-Baseline. Jede Abweichung ist ein potenzieller Ranking-Verlust.

Recovery Plan: Was zu tun ist, wenn Rankings fallen

Trotz bester Bemühungen gehen manchmal die Dinge schief. Hier ist der Triage-Prozess:

1. Überprüfen Sie auf Crawl-Blöcke. Blockiert robots.txt Googlebot? Gibt es versehentliche Noindex Tags? Das ist der #1 Fehler nach der Migration.
2. Überprüfen Sie, dass Umleitungen funktionieren. Spot-Check 100 zufällige alte URLs. Leiten sie 301 richtig um?
3. Suchen Sie nach Redirect-Ketten und Schleifen. Das sind stille Killer.
4. Vergleichen Sie Inhalte. Ziehen Sie Ihre Top 20 Seiten in der Wayback Machine auf und vergleichen Sie mit aktuell. Fehlt Inhalt?
5. Überprüfen Sie Canonical Tags. Verweisen sie auf die richtigen URLs? Self-referencing Canonicals auf jeder Seite?
6. Überprüfen strukturierte Daten. Verwenden Sie Googles Rich Results Test auf Ihren Top Pages.
7. Core Web Vitals überprüfen. Hat sich die Leistung verschlechtert?
8. Senden Sie eine Überprüfung oder Re-Indexierungsanfrage für kritische Seiten in der Search Console ein.

Wenn Sie das Problem identifiziert und behoben haben, bewertet Google typischerweise innerhalb von 1-3 Wochen neu. Bei schwerwiegenden Rückgängen kann die Wiederherstellung 2-4 Monate dauern.

Benötigen Sie Hilfe bei einer Migration, die schiefgelaufen ist, oder möchten Sie es von Anfang an richtig machen? Wir haben Dutzende davon behandelt – wenden Sie sich an uns, um Ihre spezifische Situation zu besprechen.

FAQ

Wie lange dauert eine CMS-Migration ohne Verlust von SEO Rankings?

Für eine Website unter 1.000 Seiten planen Sie 4-8 Wochen Vorbereitung, Migration und Stabilisierung. Größere Websites (10k+ Seiten) können 3-6 Monate dauern. Der eigentliche Cutover könnte an einem Tag passieren, aber die Vorbereitung und Post-Migration Überwachung nehmen den Großteil der Zeit in Anspruch. Die Vorbereitung zu überstürzen ist, wie Rankings verloren gehen.

Verliere ich Rankings temporär während einer CMS Migration?

Einige Schwankungen in den ersten 2-4 Wochen sind normal und erwartet. Google muss Ihre Website neu crawlen, die Umleitungen verarbeiten und Seiten neu indexieren. Wenn Sie 301 Umleitungen ordnungsgemäß implementiert haben und Content Parity beibehalten, sollten Sie sehen, dass Rankings innerhalb von 4-6 Wochen zur Baseline zurückkehren. Große Rückgänge, die länger als 8 Wochen anhalten, deuten auf ein Problem hin, das untersucht werden muss.

Sollte ich meine URL-Struktur während einer CMS-Migration ändern?

Nur wenn Sie absolut müssen. Jede URL-Änderung ist ein Risiko für Ihre Rankings. Wenn Ihre aktuellen URLs funktional sind (auch wenn hässlich), behalten Sie sie. Wenn Sie URLs aus technischen Gründen ändern müssen, stellen Sie sicher, dass jede alte URL eine ordnungsgemäße 301 Umleitung zu ihrem neuen Äquivalent hat. Leiten Sie alte URLs niemals in Batches auf die Homepage um.

Was ist das beste CMS für SEO in 2026?

Ehrlich gesagt, fast jedes moderne CMS kann für gutes SEO konfiguriert werden. Was wichtiger ist, ist die Frontend Implementierung. Ein Headless CMS (Sanity, Contentful, Storyblok) gepaart mit einem gut gebauten Next.js oder Astro Frontend kann WordPress auf technischen SEO Metriken wie Core Web Vitals übertreffen. Aber WordPress mit gutem Hosting und den richtigen Plugins ist immer noch perfekt fähig. Das "beste" CMS ist das, das Ihr Team korrekt verwenden kann. Schauen Sie sich unsere Preisseite an, wenn Sie einen Headless Build evaluieren.

Wie viele 301 Umleitungen sind zu viele?

Es gibt kein hartes Limit. Google hat bestätigt, dass es 301 Umleitungen ohne Probleme verarbeitet, auch in großem Maßstab. Websites mit 100.000+ Umleitungen funktionieren einwandfrei. Was wichtig ist, ist, dass jede Umleitung genau ist (auf das richtige Ziel verweist) und dass Sie Ketten vermeiden (Umleitung → Umleitung → Umleitung). Auf der Server Leistungsseite halten Sie Umleitungsregeln effizient – verwenden Sie map-basierte Lookups für große Listen anstelle von sequentieller Regelbewertung.

Kann ich meine CMS in Phasen migrieren anstelle auf einmal?

Ja, und für große Websites sind phasierte Migrationen oft sicherer. Sie könnten zuerst den Blog migrieren, dann Produktseiten, dann Landing Pages. Dies ermöglicht es Ihnen, die Auswirkungen jeder Phase zu überwachen und Probleme zu fangen, bevor sie die gesamte Website beeinflussen. Der knifflige Teil ist die Verwaltung des hybriden Zustands, in dem einige Inhalte auf dem alten CMS und einige auf dem neuen CMS leben. Dies erfordert normalerweise eine sorgfältige Reverse-Proxy- oder Routing-Konfiguration.

Welche Tools benötige ich für ein CMS-Migrations-SEO-Audit?

Mindestens: Screaming Frog (oder Sitebulb) zum Crawlen, Google Search Console für Ranking- und Indexierungsdaten und ein Redirect-Test-Skript. Hilfreich sind Ahrefs oder SEMrush für Backlink- und Ranking-Tracking, Google Analytics für Traffic-Vergleich und einen Server-Log-Analyzer. Für Headless Migrationen benötigen Sie auch Lighthouse CI oder WebPageTest für Leistungsüberwachung.

Verbessert die Migration zu einem Headless CMS das SEO?

Nicht automatisch. Ein Headless CMS selbst beeinflusst SEO nicht – es ist das Frontend, das wichtig ist. Aber Headless Architekturen führen oft zu schnelleren, leichteren Websites, da Sie volle Kontrolle über den Frontend Code haben. Wenn Sie mit SSR/SSG bauen, Bilder optimieren, JavaScript minimieren und ordnungsgemäße technische SEO implementieren, können Sie bedeutungsvolle Verbesserungen bei Core Web Vitals sehen und folglich Rankings. Die Migration selbst ist neutral; was Sie mit der neuen Architektur bauen, ist das, was einen Unterschied macht.