Im letzten Jahr haben wir eine 34.000-seitige E-Commerce-Site von einer monolithischen WordPress-Installation zu einer Headless-Architektur mit Next.js und einem Headless-CMS migriert. Der organische Traffic des Kunden machte 72% seines Umsatzes aus. Kein Druck, oder?

Die Migration dauerte 14 Wochen Planung und 6 Wochen Ausführung. Als wir den Schalter umlegten, fiel der organische Traffic in der ersten Woche um 3,2%, erholte sich in der dritten Woche und war nach zwei Monaten um 11% gestiegen. Das ist kein Glück -- das ist Prozess.

Ich habe gesehen, wie Migrationen katastrophal schiefgingen. Ein Konkurrent desselben Kunden war sechs Monate zuvor migriert und verlor über Nacht 40% seines organischen Traffics. Acht Monate später hatten sie sich immer noch nicht erholt. Der Unterschied zwischen einer erfolgreichen großflächigen Migration und einer Katastrophe liegt in der Vorbereitung, der Verwaltung von Weiterleitungen und einem Rollback-Plan, dem man wirklich vertraut.

Dieser Artikel durchläuft alles, was wir tun, wenn wir Websites mit Zehntausenden von Seiten migrieren. Es ist derselbe Prozess, egal ob Sie von WordPress zu Next.js, Drupal zu Astro oder einer anderen Plattformänderung wechseln.

Inhaltsverzeichnis

So migrieren Sie eine Website mit 30.000 Seiten ohne SEO-Verluste

Warum großflächige Migrationen fehlschlagen

Die meisten Migrationsfehler haben die gleichen Grundursachen. Wenn man sie vorher versteht, kann man vermeiden, sich dem Friedhof fehlgeschlagener Launches anzuschließen.

Das Weiterleitungsproblem

Bei einer 500-seitigen Website können Sie jede URL manuell zuordnen. Bei einer 30.000-seitigen Website können Sie das nicht. Teams schreiben am Ende Regex-basierte Weiterleitungsregeln, die 90% der URLs abdecken, und gehen davon aus, dass die restlichen 10% sich von selbst klären. Diese restlichen 10%? Das sind 3.000 Seiten. Viele davon sind Ihr leistungsstärkster Content.

Eine Ahrefs-Studie aus 2025 ergab, dass Websites, die mehr als 15% ihrer indizierten Seiten während einer Migration verlieren, einen durchschnittlichen Rückgang des organischen Traffics von 34% erlebten. Und die Wiederherstellung dauerte durchschnittlich 4-8 Monate.

Das Paritätsproblem

Google kümmert sich nicht nur um Content -- Google kümmert sich um Struktur. Interne Verlinkungsmuster, Überschriftenhierarchien, strukturierte Daten, kanonische Tags, Paginierungsbehandlung, facettierte Navigation. Ändern Sie gleichzeitig zu viele davon, und Google muss Ihre gesamte Website praktisch von Grund auf neu bewerten.

Das Timing-Problem

Ich habe Teams gesehen, die Monate damit verbracht haben, die neue Website zu perfektionieren, und dann die eigentliche Migration beeilt haben, weil die Geschäftsführung ungeduldig wird. Sie migrieren keine 30.000-seitige Website an einem Freitagnachmittag. Sie migrieren nicht während Ihrer Spitzenlastzeit. Und Sie migrieren definitiv nicht ohne einen getesteten Rollback-Plan.

Phase 1: Pre-Migration-Audit und Crawl

Bevor Sie etwas anfassen, brauchen Sie ein vollständiges Bild von dem, was heute existiert. Dies ist Ihre Baseline, und Sie werden sie durchgehend während der Migration referenzieren.

Vollständiger Site-Crawl

Führen Sie einen vollständigen Crawl mit Screaming Frog, Sitebulb oder einem Cloud-basierten Crawler wie Lumar (ehemals Deepcrawl) durch. Bei 30.000+ Seiten benötigen Sie die Cloud-Option -- Desktop-Crawler bleiben bei Websites dieser Größe stecken, und Sie benötigen die Crawl-Daten, um sie über Ihr Team hinweg freizugeben.

Erfassen Sie alles:

  • Jede URL und ihren HTTP-Statuscode
  • Titel-Tags und Meta-Beschreibungen
  • H1-Tags
  • Kanonische Tags
  • Hreflang-Tags (falls zutreffend)
  • Interne Links (sowohl eingehend als auch ausgehend pro Seite)
  • Vorhandene strukturierte Datentypen
  • Seitenladezeiten
  • Wortanzahl pro Seite
  • Bilder und Alt-Text

Analytics-Baseline

Exportieren Sie die letzten 12 Monate an Google Analytics- und Google Search Console-Daten. Sie benötigen:

  • Top 1.000 Landing Pages nach organischen Sessions
  • Top 5.000 Queries nach Klicks und Impressionen
  • Crawl-Statistiken (pro Tag gecrawlte Seiten, Antwortzeiten)
  • Core Web Vitals-Scores
  • Index-Abdeckungsbericht (indiziert, ausgeschlossen, Fehler)

Markieren Sie Ihre Top 500 organischen Landing Pages. Diese sind die Seiten, die nicht fehlschlagen können. Punkt. Jede einzelne wird während und nach der Migration einzeln überprüft.

Ziehen Sie Backlink-Daten aus Ahrefs, Semrush und Google Search Console. Suchen Sie nach jeder URL, die externe Links auf sich hat. Diese URLs benötigen perfekte 301-Weiterleitungen -- Backlink-Autorität auf hochrangigen Seiten zu verlieren ist einer der schnellsten Wege, um Rankings zu zerstören.

# Beispiel: Export und Deduplizierung von URLs mit Backlinks
ahrefs-export.csv + semrush-export.csv + gsc-export.csv
| sort -u 
| awk -F',' '{print $1}' 
> unique_backlinked_urls.txt

wc -l unique_backlinked_urls.txt
# Output: 8.247 eindeutige URLs mit Backlinks

Phase 2: URL-Zuordnung und Weiterleitungsstrategie

Hier werden Migrationen gewonnen oder verloren. Bei einer 30.000-seitigen Website benötigen Sie einen systematischen Ansatz, der automatisierte Zuordnung mit manueller Verifikation für kritische Seiten verbindet.

Aufbau der Weiterleitungskarte

Beginnen Sie damit, Ihre URLs in Muster zu kategorisieren. Die meisten großen Websites haben eine relativ kleine Anzahl von URL-Mustern, die für die Mehrheit der Seiten verantwortlich sind:

URL-Muster Beispiel Seitenanzahl Strategie
Produktseiten /products/blue-widget-123 18.000 Regex + ID-Zuordnung
Kategorieseiten /category/widgets 450 Manuelle Zuordnung
Blog-Posts /blog/2024/03/post-title 3.200 Slug-Beibehaltung
Tag/Filter-Seiten /products?color=blue 6.500 Bewerten: Weiterleitung oder noindex
Statische Seiten /about, /contact 85 Manuelle Zuordnung
Paginierte Seiten /category/widgets/page/3 1.800 Zu neuer Paginierung zuordnen

Der Drei-Ebenen-Ansatz

Ebene 1: Manuelle Zuordnung (Top 500 Seiten) Ihre höchstverkehrten, höchstumsatzreichsten Seiten werden einzeln zugeordnet. Ein Mensch überprüft jede Weiterleitung. Keine Ausnahmen.

Ebene 2: Musterbasierte Zuordnung (nächste ~25.000 Seiten) Schreiben Sie Transformationsregeln, die alte URL-Muster in neue umwandeln. Testen Sie diese Regeln gegen Ihre vollständige URL-Liste, bevor Sie sie bereitstellen.

# Beispiel: Weiterleitungsregel-Generierung
import csv
import re

def generate_redirect(old_url):
    # Produktseiten: /products/blue-widget-123 -> /shop/blue-widget
    product_match = re.match(r'/products/([a-z-]+)-(\d+)$', old_url)
    if product_match:
        slug = product_match.group(1)
        return f'/shop/{slug}', 301
    
    # Blog-Posts: /blog/2024/03/post-title -> /blog/post-title
    blog_match = re.match(r'/blog/\d{4}/\d{2}/(.+)$', old_url)
    if blog_match:
        slug = blog_match.group(1)
        return f'/blog/{slug}', 301
    
    return None, None

# Alle URLs verarbeiten
with open('all_urls.csv') as f:
    reader = csv.reader(f)
    unmapped = []
    for row in reader:
        old_url = row[0]
        new_url, status = generate_redirect(old_url)
        if new_url is None:
            unmapped.append(old_url)
    
    print(f"Nicht zugeordnete URLs: {len(unmapped)}")

Ebene 3: Verbleibende nicht zugeordnete Seiten (~4.500 Seiten) Dies sind Ihre Sonderfälle. Gehen Sie sie manuell durch. Einige sind Seiten, die Sie absichtlich einstellen möchten (Weiterleitung zur nächstgelegenen relevanten Seite). Einige sind URLs, die Sie in Ihrer Musteranalyse übersehen haben. Lassen Sie keine 404s für Seiten übrig, die Traffic oder Backlinks hatten.

Weiterleitungsketten und Schleifen

Wenn die alte Website bereits Weiterleitungen an Ort und Stelle hat, könnten Ihre neuen Weiterleitungen Ketten erstellen (A → B → C). Lösen Sie diese vor dem Launch auf. Jede Weiterleitung sollte direkt von der alten URL zum endgültigen Ziel in einem einzigen Hop führen. Weiterleitungsketten vergeben PageRank -- Googles John Mueller hat mehrmals bestätigt, dass Google Ketten folgen wird, eine direkte Weiterleitung aber immer vorzuziehen ist.

So migrieren Sie eine Website mit 30.000 Seiten ohne SEO-Verluste - Architektur

Phase 3: Technische SEO-Paritätsprüfliste

Die neue Website muss technische SEO-Parität mit der alten Website bewahren -- und idealerweise darauf verbessern. Hier ist, was wir überprüfen:

Kritische Paritätselemente

  • Titel-Tags: Gleich oder verbessert. Lassen Sie sie während der Migration nie leer.
  • Meta-Beschreibungen: Tragen Sie sie über, auch wenn Sie planen, sie später neu zu schreiben.
  • H1-Struktur: Ein H1 pro Seite, das die Keyword-Ausrichtung der alten Website widerspiegelt.
  • Kanonische Tags: Self-referenzierende kanonische auf jeder Seite. Falls die alte Website bereichsübergreifende Kanonische hatte, behalten Sie diese.
  • Robots.txt: Blockieren Sie Googlebot beim Launch nicht versehentlich. Ich habe dies mehr als einmal passieren sehen.
  • XML-Sitemaps: Generieren Sie neue Sitemaps mit allen neuen URLs. Senden Sie sie innerhalb von Stunden nach dem Launch ein.
  • Strukturierte Daten: Migrieren Sie alle Schema-Markups. Produktschema, FAQ-Schema, Breadcrumb-Schema -- alles.
  • Interne Verlinkung: Das interne Link-Diagramm der neuen Website sollte das der alten Website eng spiegeln.

Leistungsanforderungen

Cores Web Vitals von Google sind Ranking-Faktoren. Ihre neue Website sollte die Leistung der alten Website erfüllen oder übertreffen:

Metrik Guter Schwellenwert Ziel
LCP (Largest Contentful Paint) ≤ 2,5s ≤ 2,0s
INP (Interaction to Next Paint) ≤ 200ms ≤ 150ms
CLS (Cumulative Layout Shift) ≤ 0,1 ≤ 0,05
TTFB (Time to First Byte) ≤ 800ms ≤ 400ms

Dies ist ein Bereich, in dem die Migration zu einem modernen Stack wie Next.js oder Astro tatsächlich einen Vorteil gibt. Statische Generierung und Edge-Rendering können TTFB dramatisch verbessern. Wir haben gesehen, dass TTFB von 1,2s auf unter 200ms fällt, wenn von traditionellem WordPress zu Next.js mit ISR oder Astro mit statischer Ausgabe gewechselt wird.

Phase 4: Content-Migration und Validierung

Automatisierte Content-Extraktion

Bei 30.000 Seiten benötigen Sie automatisierte Content-Extraktion. Wir bauen typischerweise benutzerdefinierte Scraper oder verwenden die Export-APIs des CMS, um Content in ein strukturiertes Format (normalerweise JSON oder CSV) zu ziehen, bevor es in das neue Headless-CMS importiert wird.

Wichtige Validierungen nach Import:

  • Zeichenkodierung (achten Sie auf beschädigte Sonderzeichen)
  • Bildreferenzen (lösen sich alle Bilder auf?)
  • Interne Links (werden sie zu neuen URL-Mustern aktualisiert?)
  • Eingebettete Medien (Videos, iframes, Widgets)
  • Tabellenformatierung
  • Code-Blöcke

Content-Diff-Testing

Wir führen automatisierte Vergleiche zwischen alten und neuen Seiten für unsere Top 500 URLs durch. Das Script ruft beide Versionen ab, entfernt HTML und vergleicht den Textinhalt. Jede Seite mit weniger als 95% Textähnlichkeit wird zur manuellen Überprüfung gekennzeichnet.

// Vereinfachter Content-Vergleich
const { diff } = require('fast-diff');
const cheerio = require('cheerio');

async function comparePages(oldUrl, newUrl) {
  const oldHtml = await fetch(oldUrl).then(r => r.text());
  const newHtml = await fetch(newUrl).then(r => r.text());
  
  const oldText = cheerio.load(oldHtml)('main').text().trim();
  const newText = cheerio.load(newHtml)('main').text().trim();
  
  const changes = diff(oldText, newText);
  const unchanged = changes
    .filter(([type]) => type === 0)
    .reduce((sum, [, text]) => sum + text.length, 0);
  
  const similarity = unchanged / Math.max(oldText.length, newText.length);
  
  return {
    similarity: Math.round(similarity * 100),
    oldLength: oldText.length,
    newLength: newText.length,
    needsReview: similarity < 0.95
  };
}

Phase 5: Testing der Staging-Umgebung

Starten Sie eine Migration nie ohne gründliches Staging-Testing. Hier ist, was wir validieren:

Weiterleitungs-Testing

Testen Sie jede einzelne Weiterleitung. Ja, alle 30.000. Verwenden Sie ein Script, das der Weiterleitungskette folgt und das endgültige Ziel validiert:

# Weiterleitungen aus Zuordnungsdatei testen
while IFS=, read -r old_url new_url; do
  response=$(curl -s -o /dev/null -w "%{http_code} %{redirect_url}" "$old_url")
  status=$(echo $response | cut -d' ' -f1)
  redirect=$(echo $response | cut -d' ' -f2)
  if [ "$status" != "301" ] || [ "$redirect" != "$new_url" ]; then
    echo "FAIL: $old_url -> $status $redirect (expected 301 $new_url)"
  fi
done < redirect_map.csv

Rendering-Validierung

Wenn Sie Client-Side-Rendering (CSR) oder hydrationslastige Ansätze verwenden, überprüfen Sie, dass Googlebot Ihren Content tatsächlich sehen kann. Verwenden Sie Google's Rich Results Test oder das URL Inspection Tool in Search Console, um die gerenderte Ausgabe zu überprüfen.

Dies ist ein besonders häufiges Problem bei React-basierten Frameworks. Wenn Ihr Content JavaScript benötigt, um zu rendern, und Sie SSR oder SSG nicht richtig implementiert haben, könnte Google eine leere Seite sehen. Wir verwenden immer Server-Side Rendering oder statische Generierung für SEO-kritische Seiten.

Phase 6: Ausführung am Launch-Tag

Die Launch-Checkliste

  1. DNS TTL: DNS TTL mindestens 48 Stunden vor der Migration auf 300 Sekunden reduzieren
  2. Weiterleitungen bereitstellen: Alle 301-Weiterleitungen live auf dem alten Server/CDN erhalten
  3. DNS umschalten: Domain zu neuer Infrastruktur weiterleiten
  4. Weiterleitungen überprüfen: Automatisierte Weiterleitungstests gegen Production ausführen
  5. Sitemaps senden: Neue XML-Sitemaps in Google Search Console einreichen
  6. Indexierung anfordern: URL Inspection Tool verwenden, um Indexierung Ihrer Top 50 Seiten anzufordern
  7. Überwachen: Real-Time-Analytics auf Anomalien überwachen
  8. Robots.txt überprüfen: Bestätigen, dass Googlebot nicht blockiert ist
  9. CDN/Caching überprüfen: Sicherstellen, dass Weiterleitungs-Header nicht falsch gecacht werden

Timing

Starten Sie an einem Dienstagvormittag oder Mittwochvormittag. Nie Freitag. Sie möchten mindestens 3 volle Arbeitstage haben, um zu überwachen und Probleme vor dem Wochenende zu beheben. Vermeiden Sie Starts während Spitzenlastzeiten oder großer Einkaufsereignisse.

Wir stellen auch sicher, dass nach dem Launch jemand die Nacht über überwacht. Google crawlt oft aggressiver während Off-Peak-Stunden, und wenn Ihre Weiterleitungen Probleme haben, möchten Sie diese schnell erfassen.

Rollback-Plan

Haben Sie einen getesteten Rollback-Plan, der in unter 15 Minuten ausgeführt werden kann. Dies bedeutet normalerweise, die alte Infrastruktur mindestens 2 Wochen nach der Migration parallel zu betreiben. Die Kosten für die vorübergehende Wartung zweier Umgebungen sind nichts im Vergleich zu den Kosten einer fehlgeschlagenen Migration.

Phase 7: Überwachung nach der Migration

Tägliche Überwachung (Wochen 1-2)

  • Crawl-Fehler: Überprüfen Sie Google Search Console täglich auf neue 404s und Serverfehler
  • Index-Abdeckung: Überwachen Sie den Index-Abdeckungsbericht auf Rückgänge
  • Organischer Traffic: Vergleichen Sie tägliche organische Sessions mit Ihrer Baseline
  • Rankings: Verfolgen Sie Ihre Top 200 Keywords täglich
  • Server-Logs: Analysieren Sie Googlebots Crawl-Muster auf der neuen Website
  • Core Web Vitals: Überprüfen Sie Felderdaten, während diese anfallen

Wöchentliche Überwachung (Wochen 3-8)

  • Vergleichen Sie organischen Traffic wöchentlich
  • Überwachen Sie auf Ranking-Volatilität
  • Überprüfen Sie auf neue Crawl-Fehler
  • Überprüfen Sie, ob nicht versehentlich Weiterleitungsketten erstellt wurden
  • Überwachen Sie das Backlink-Profil auf verlorene Links

Erwartete Traffic-Muster

Eine gut ausgeführte Migration zeigt normalerweise:

  • Woche 1: 5-15% Traffic-Rückgang (Google verarbeitet die Änderungen)
  • Woche 2-3: Wiederherstellung auf Vor-Migrations-Niveaus
  • Woche 4-8: Wenn die neue Website technisch überlegen ist, sehen Sie oft einen Traffic-Anstieg

Wenn Sie einen Rückgang von 30%+ sehen, der sich bis Woche 3 nicht erholt, ist etwas mit Ihren Weiterleitungen oder der technischen Implementierung schiefgelaufen. Graben Sie sofort in Search Console.

Umsetzung von Weiterleitungen im großen Maßstab

Wo Sie Weiterleitungen implementieren, ist wichtig. Bei 30.000+ Weiterleitungen, stopfen Sie sie nicht alle in eine .htaccess-Datei oder ein Next.js redirects Config-Array -- das zerstört Leistung.

Empfohlene Ansätze

Edge-Level-Weiterleitungen (beste Leistung) Implementieren Sie Weiterleitungen auf der CDN/Edge-Ebene mit Cloudflare Workers, Vercel Edge Middleware oder Netlifys _redirects-Datei. Edge-Weiterleitungen werden vor dem Code Ihrer Anwendung ausgeführt, daher sind sie extrem schnell.

// Vercel Edge Middleware Beispiel
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

// Weiterleitungskarte laden (vorab bei Deploy gebaut)
import redirectMap from './redirects.json';

export function middleware(request: NextRequest) {
  const path = request.nextUrl.pathname;
  const redirect = redirectMap[path];
  
  if (redirect) {
    return NextResponse.redirect(
      new URL(redirect.destination, request.url),
      redirect.permanent ? 301 : 302
    );
  }
  
  return NextResponse.next();
}

Datenbank-gestützte Weiterleitungen (beste Flexibilität) Speichern Sie Weiterleitungen in einer Datenbank und schlagen Sie sie zur Request-Zeit nach. Dies ermöglicht Ihnen, Weiterleitungen ohne Neubereitstellung hinzuzufügen, zu ändern und zu prüfen. Fügen Sie aggressive Caching (Redis oder ähnliches) hinzu, so dass die Datenbank-Nachschau keine Latenz hinzufügt.

Hybrid-Ansatz (das, was wir normalerweise tun) Musterbasierte Weiterleitungen am Edge, einzelne Weiterleitungen in einer Datenbank. Das Beste aus beiden Welten.

Umgang mit internationalen und mehrsprachigen Websites

Wenn Ihre 30.000-seitige Website mehrere Sprachen oder Regionen enthält, vervielfacht sich die Komplexität. Jede Sprachversion benötigt ihre eigene Weiterleitungskarte. Hreflang-Tags müssen aktualisiert werden, um auf neue URLs zu verweisen. Und Sie müssen überprüfen, dass das Sprach-/Regions-Targeting in Search Console immer noch korrekt funktioniert.

Häufige Probleme:

  • Vergessen, Hreflang-Anmerkungen über alle Sprachversionen gleichzeitig zu aktualisieren
  • Verletzung der Hreflang-Gegenseitigkeit (wenn Seite A auf Seite B zeigt, muss Seite B auf Seite A zurückzeigen)
  • Verlust sprachspezifischer URL-Strukturen, die Google als Signale verwendet

Häufige Fehler, die Rankings zerstören

  1. 302 statt 301 verwenden: Temporäre Weiterleitungen geben nicht die volle Link-Autorität weiter. Überprüfen Sie dreifach Ihre Weiterleitungs-Statuscodes.
  2. Staging-Site blockieren und vergessen freizugeben: Ihr robots.txt auf Staging sagt Disallow: /. Sie stellen Staging in Production bereit. Googlebot kann nichts crawlen.
  3. Content und URLs gleichzeitig ändern: Google sieht eine neue URL mit anderem Content. Ist es eine neue Seite? Eine verschobene Seite? Reduzieren Sie Mehrdeutigkeit -- migrieren Sie URLs zuerst, ändern Sie Content später.
  4. Alles zur Homepage umleiten: Faule Weiterleitungs-Implementierungen, die alle alten URLs zur Homepage senden, zerstören Ihre Long-Tail-Rankings sofort.
  5. JavaScript-Rendering ignorieren: Ihre neue React-App sieht in Chrome großartig aus. Googlebot sieht ein leeres <div id="root"></div>.
  6. Trailing Slashes nicht konsistent handhaben: /products/widget und /products/widget/ sind verschiedene URLs. Wählen Sie eine und leiten Sie die andere um.
  7. Seiten ohne Weiterleitungen entfernen: Wenn eine Seite Traffic hatte, benötigt sie eine Weiterleitung. Auch wenn Sie diesen Content einstellen, leiten Sie zur nächstgelegenen relevanten Seite um.

Tools und Stack, den wir verwenden

Tool Zweck Kosten (2026)
Screaming Frog Desktop-Crawling 259€/Jahr
Lumar (Deepcrawl) Cloud-Crawling für große Websites Benutzerdefinierte Preisgestaltung
Ahrefs Backlink-Analyse, Ranking-Tracking Ab 129€/Monat
Google Search Console Index-Überwachung, Crawl-Statistiken Kostenlos
Redirectchecker.com Bulk-Weiterleitungs-Testing Kostenlos mit Free Tier
ContentKing Echtzeit-SEO-Überwachung Ab 99€/Monat
Benutzerdefinierte Python/Node-Scripts Weiterleitungs-Zuordnung, Content-Diffing Ihre Zeit

Für den eigentlichen Site-Build verwenden wir normalerweise Next.js oder Astro je nach den Anforderungen des Projekts, kombiniert mit einem Headless-CMS wie Sanity, Contentful oder Storyblok. Falls Sie eine Migration planen und Architektur diskutieren möchten, schauen Sie sich unsere Preisgestaltung an oder nehmen Sie Kontakt mit uns auf.

FAQ

Wie lange dauert es, eine Website mit 30.000 Seiten zu migrieren?

Rechnen Sie mit insgesamt 12-20 Wochen. Die Planungs- und URL-Zuordnungsphase dauert am längsten -- normalerweise 8-14 Wochen. Die eigentliche technische Migration und der Launch dauern normalerweise 4-6 Wochen. Die Planungsphase zu beeilen ist der einzelne größte Prädiktor für Migrations-Fehler.

Werde ich definitiv etwas SEO-Traffic während der Migration verlieren?

Ein vorübergehender Rückgang von 5-15% ist normal und zu erwarten, auch bei einer perfekten Migration. Google benötigt Zeit, um Zehntausende von Weiterleitungen zu verarbeiten und Ihre neue Website neu zu crawlen. Der Rückgang löst sich normalerweise innerhalb von 2-3 Wochen auf. Wenn Sie einen größeren Rückgang sehen oder er sich nicht erholt, untersuchen Sie sofort Ihre Weiterleitungen und technische Implementierung.

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

Nur wenn es einen starken Grund gibt, dies zu tun. Jede URL-Änderung fügt Risiko hinzu. Wenn Ihre aktuelle URL-Struktur funktional und beschreibend ist, behalten Sie sie. Wenn sie wirklich schlecht ist (z.B. URLs mit Abfrageparametern statt sauberer Pfade), ist die Migration eine gute Gelegenheit, es zu beheben -- aber planen Sie Ihre Weiterleitungskarte entsprechend.

Kann ich meine Website in Phasen statt alles auf einmal migrieren?

Ja, und bei sehr großen Websites ist es oft der sicherere Ansatz. Sie können Abschnitt für Abschnitt migrieren -- erst Blog, dann Produktseiten, dann Kategorieseiten. Dies reduziert Risiko, erhöht aber Komplexität, da Sie gleichzeitig zwei Plattformen betreiben, normalerweise hinter einem Reverse Proxy. Wir haben dies erfolgreich mehrmals getan, aber es erfordert sorgfältige Routing-Konfiguration.

Was passiert mit meinen Google Ads während der Migration?

Aktualisieren Sie Ihre Ad-Zielseiten-URLs zu den neuen URLs vor oder unmittelbar nach der Migration. Falls Sie Weiterleitungen an Ort und Stelle haben, funktionieren Ihre Ads immer noch, aber die Weiterleitung fügt Latenz hinzu und Google Ads Quality Scores können durch Weiterleitungsketten negativ beeinträchtigt werden. Die direkte Aktualisierung der URLs ist immer besser.

Wie handhabe ich Seiten, die ich während der Migration entfernen möchte?

Wenn die Seite organischen Traffic oder Backlinks hatte, leiten Sie sie zur relevantesten bestehenden Seite auf der neuen Website um. Wenn sie weder das eine noch das andere hatte, können Sie ein 404- oder 410-Status (Gone) zurückgeben. Leiten Sie irrelevante Seiten nicht zur Homepage um -- Google behandelt Mass-Homepage-Weiterleitungen als sanfte 404s.

Sollte ich 301- oder 308-Weiterleitungen verwenden?

Verwenden Sie für die meisten Fälle 301. Beide sind permanente Weiterleitungen, aber 301 wird von allen Bots und Browsern universell verstanden. 308 behält die HTTP-Methode bei (POST bleibt POST), was für API-Endpunkte wichtig ist, aber nicht für SEO-fokussierte Seiten-Weiterleitungen.

Wann sollte ich die alten Weiterleitungen entfernen?

Behalten Sie sie mindestens ein Jahr lang, vorzugsweise unbegrenzt. Weiterleitungen sind billig zu unterhalten, und ihre Entfernung bedeutet, dass alte Lesezeichen, externe Links oder gecachte Suchergebnisse auf 404s treffen. Es gibt fast nie einen guten Grund, funktionierende 301-Weiterleitungen zu entfernen.