Content-Migration — Audit, Export, Redirects & Cutover

Content-Migration ist der operative Kern jeder Modernisierung: Du behältst Marke, Botschaften und Medien — und tauschst die fragile CMS-/Builder-Schicht gegen deterministisches HTML. Das ist kein „Theme neu und DNS umstellen“, sondern ein sequenzielles Programm mit Inventar, Export, Mapping und Cutover. Gesamtrahmen und Verantwortlichkeiten: Ablauf & Projekt. Plattform-Sonderfälle: WordPress-Migration, Elementor-Migration, Wix/Jimdo-Migration, WooCommerce-Migration.

Was ist Content-Migration — und was ist sie nicht?

Antwort zuerst: Content-Migration überträgt Bedeutung und Assets; sie kopiert kein Pagebuilder-DOM und erzwingt keinen Text-Rewrite.

Sie ist: strukturierte Übernahme von Seiten, Beiträgen, Medien, Meta-Titeln/Descriptions, Canonicals, interner Verlinkung und Schema-Fakten in einen SSR/SSG-Stack.

Sie ist nicht: 1:1-Klon von Elementor-/Divi-Layouts, Shortcode-Zoo, Plugin-Logik oder „Theme-Wechsel auf demselben PHP-Host“. Layouts werden neu gebaut; Inhalte und Hierarchie bleiben.

Sie ersetzt auch nicht ein vollständiges Redesign oder Conversion-Rebuild. Wenn Informationsarchitektur und Angebotstexte veraltet sind, kommt Redesign/Conversion als Modul — parallel oder danach, nicht als versteckte Last im „einfachen“ Export.

Warum scheitern naive Exports — und wann lohnt sich die Migration?

Antwort zuerst: Naive Exports verlieren Relationen, Medien und URLs; professionelle Migration inventarisiert zuerst und mappt erst dann.

Typische Auslöser: Plugin-Konflikte, Pagebuilder-Ballast, langsame Themes, fragiles Hosting, fehlende Maschinenlesbarkeit. Dann ist Content-Migration der richtige Hebel — Inhalte tragen, die Plattform nicht.

Allein zu wenig, wenn: die Story komplett neu muss (dann Migration + Redesign) oder ein Shop mit Warenkorb-/Payment-Logik im Scope liegt (dann WooCommerce-Migration als eigener Pfad).

Was der Census zur Content-Migration sagt

Antwort zuerst: Migration allein macht dich nicht „AI-ready“ — sie entfernt den Legacy-Bottleneck; der Maschinen-Layer kommt danach.

In der AI-Readiness-Studie (6.675 Audits) laufen 69,4 % der Sites auf Legacy-CMS. Benchmarks: Agent-Ready Ø 25/100, llms.txt 15,6 %, JSON-LD 41,9 %, Sitemap 73,5 %, robots 72,5 %, Markdown-Negotiation 0,3 %.

Content-Migration liefert deterministisches HTML und die Technical-SEO-Basis. Knowledge Graph, llms.txt und strukturierte Daten sind die nächste Schicht — nicht Ersatz für den Stack-Wechsel. Primärstudie: AI-Readiness-Studie.

Wie unterscheiden sich Export-Pfade nach Quelle?

Antwort zuerst: WordPress kann strukturiert exportieren; Elementor/Divi und Baukasten-Systeme erzwingen oft Scrape und Rebuild — Ziel-HTML ist immer dasselbe.

WordPress (klassisch / Gutenberg)

Bevorzugt: WordPress REST API oder WPGraphQL — typisierte Seiten, Medien, Taxonomien, Relationen. Der native WXR-Export ist Backup-tauglich, bildet Plugin-Beziehungen, Custom Tables und viele Meta-Felder aber oft unvollständig ab. Gutenberg speichert Blöcke als HTML-Kommentare in post_content — das ist die zentrale technische Hürde beim Mapping auf React-/MDX-Komponenten. Details: WordPress-Migration.

Elementor / Divi

Kein sauberes Gutenberg-Blockmodell, sondern tief verschachteltes Builder-DOM mit Widget-IDs, Inline-Styles und oft doppelten Containern. Export heißt hier: Struktur und Inhalte extrahieren (Hierarchie, Texte, Bilder, CTAs), Markup nicht 1:1 übernehmen. Eigene Ablösepfade: Elementor-Migration, Divi-Migration, Überblick Pagebuilder-Ablösung.

Wix / Jimdo (und ähnliche Baukästen)

Plattform-Exporte sind häufig unvollständig: fehlende Medien-URL-Stabilität, begrenzte SEO-Felder, keine echten Block-Typen. Praxis: Crawl + manueller Content-Abgleich + Rebuild. Siehe Wix/Jimdo-Migration und Baukasten.

Vergleich: Export-Realität

Wie läuft Content-Migration phasenweise ab?

Antwort zuerst: Erfolgreiche Migration ist Inventar → Export/Mapping → Medien → URL-Matrix → Staging → Cutover — nicht „Inhalte kopieren und DNS drehen“.

Gesamtprozess und Rollenverteilung: Ablauf & Projekt.

Phase 1 — Audit-Inventar und SEO-Baseline

Automatisierter Crawl erfasst Seiten, Beiträge, Archive, Custom Post Types, Medien und Attachment-URLs. Anreicherung mit Search Console / Analytics: Top-Traffic-URLs vs. Null-Traffic der letzten 12 Monate (Archiv-/Konsolidierungskandidaten). Parallel: Meta-Titles, Descriptions, Canonicals, H1, vorhandenes Schema.org, Formulare, Consent, kritische Downloads.

Zusätzlich im Inventar festhalten:

• Rechtstexte: Impressum, Datenschutz, AGB — NAP und Kontakt müssen zur Live-Marke passen.
• Conversion-Punkte: jedes Formular, WhatsApp-Link, Telefon, Kalender-Embed.
• Thin Content: Blog-/News-URLs ohne Traffic der letzten 12 Monate — Übernahme, 301 auf Elternseite oder 410.
• Alt-URLs: Legacy-Pfade aus alten Kampagnen, PDF-Landingpages, Parameter-Varianten.

Ergebnis: Content-Inventar + 1:1-URL-Matrix Alter Pfad → neue Route. Ohne diese Matrix gibt es keinen verantwortbaren Cutover. Je vollständiger Phase 1, desto weniger Überraschungen in Phase 5/6.

Phase 2 — Export und Block-/Widget-Mapping

Je Quelle den stärksten Export wählen (siehe oben). Gutenberg-Blöcke und Builder-Widgets werden auf typisierte Zielkomponenten gemappt — nicht als Roh-HTML „durchgereicht“.

Zwei Implementierungsmuster (WordPress/Gutenberg):

1. GraphQL-Content-Blocks: Blöcke serverseitig in typisierte Objekte; im App Router mappt ein Component-Mapper Block-Typ → React-Komponente.
2. HTML-Parse: Roh-HTML analysieren und Gutenberg-/Builder-Klassen durch Komponenten ersetzen — mit Fallback für unbekannte Typen.

// Prinzip: Quell-Block/Widget → React-Komponente (vereinfachtes Muster)
const CONTENT_COMPONENTS = {
  'core/paragraph': DynamicParagraph,
  'core/heading': DynamicHeading,
  'core/image': DynamicImage,
  'builder/cta': CtaSection,
}

export function mapContentNodes(nodes) {
  return nodes.map((node, index) => {
    const Component = CONTENT_COMPONENTS[node.type] ?? FallbackBlock
    return <Component key={node.id ?? index} {...node.props} />
  })
}

Shortcodes, eingebettete Formulare und „HTML-Widgets“ werden explizit inventarisiert — sonst entstehen nach Go-Live leere Kästen statt Kontaktformularen. Für Elementor/Divi gilt dasselbe Prinzip auf Widget-Ebene: Hero, Leistungs-Grid, FAQ, CTA und Galerie werden als Sektionen neu verdrahtet, nicht als verschachtelte div-Wüste kopiert. Wix/Jimdo-Texte wandern oft über manuelles Abgleichsprotokoll (Quellseite ↔ Staging), weil der Plattform-Export selten vollständige Relationen liefert.

Phase 3 — Medien-Pipeline

Asset-Inventar, Deduplizierung, Upload in Object Storage/CDN, URL-Rewrites in Texten und Markdown. Fehlende Alt-Texte und verwaiste Attachments gehören in dieselbe Pipeline. Im Zielstack: moderne Formate, responsive Größen, CLS-Reserven — keine 4000px-Hotlinks vom alten Host.

Praktische Reihenfolge:

1. Crawl aller src/href-Medien aus HTML und Sitemap.
2. Hash-basierte Deduplizierung (gleiche Datei, unterschiedliche Dateinamen).
3. Upload mit stabilen Ziel-URLs; Rewrite-Map Alt-URL → CDN-URL.
4. Alt-Text-Audit: fehlende Alts als Ticket, nicht als „später“.
5. Stichprobe der Top-Landingpages im Staging (visueller Diff).

Gate: Jede Top-20-Landingpage ohne kaputtes Bild; Download-Liste ohne 404. Fehlende Alts treffen Barrierefreiheit und Bildsuche — deshalb Teil der Migration, nicht Nacharbeit nach dem Go-Live.

Phase 4 — URL-Matrix, 301 und Canonicals

Jede Zeile der Mapping-Matrix wird zum 301 (Redirect). Soft-404 und Kettenredirects sind FAIL. Canonical zeigt auf die Apex-Version pro Inhalt. Parameter-, Session- und www/Apex-Duplikate bereinigst du in derselben Runde.

Regel: URLs behalten, die Rankings und Backlinks tragen; ändern nur, wenn die Struktur klar besser wird — dann dokumentierter 301 pro alte URL. Rankingschutz-Detail: Rankingverlust vermeiden. Technische Basis: Technical-SEO-Basis.

Matrix-Felder, die in der Praxis fehlen und später wehtun: HTTP-Status alt, HTTP-Status neu, Canonical-Ziel, „übernehmen / konsolidieren / 410“, Owner-Freigabe. Ohne diese Spalten entsteht Chaos in der Staging-QA.

Phase 5 — Staging-QA

Checkliste vor DNS:

• Inhaltsparität der Top-20-URLs (Text, H1, CTAs, Medien)
• Redirect-Smoke (Stichprobe + kritische Alt-URLs)
• Formular-E2E (Submit, Notify, Spam-Schutz)
• Mobile LCP-Stichprobe (Core Web Vitals)
• robots/sitemap, Canonical-Konsistenz
• AI-Bot-Allowlist (kein unbeabsichtigtes Blocken von GPTBot/PerplexityBot)
• Rechtstexte: NAP, Mail, Telefon/WhatsApp konsistent zu Footer und Schema
• Interne Links: keine toten Querverweise auf alte CMS-Pfade

Staging und spätere Live-Origin müssen denselben Redirect- und Canonical-Contract teilen — sonst „funktioniert auf Staging“, scheitert nach DNS. Performance-Vergleich vor/nach hilft, den Stack-Wechsel zu belegen; typische WordPress-LCP-Spannen und Next.js-SSG-Werte findest du im Kontext Next.js vs WordPress.

Phase 6 — Cutover, Monitoring und Altsystem-Abschaltung

Cutover mit Wartungsfenster: DNS/Proxy auf neuen Stack → Redirect-Smoke → 48-Stunden-Monitoring (Verfügbarkeit, Search Console, Core Web Vitals). Altes CMS nur so lange parallel, bis Stabilität bestätigt ist — dann Hosting bereinigen. Kein „Freitag 17 Uhr ohne Plan“. Hosting-Kontext: Hosting nach Migration.

Nach dem Cutover: IndexNow bei inhaltlichen Updates, Search-Console-Coverage prüfen, Soft-404-Stichprobe wiederholen. Analytics- und Search-Console-Zugänge müssen vor dem Cutover gesichert sein — sonst siehst du Rankingverlust erst, wenn die Datenlücke schon da ist.

Welche Failure Modes musst du vor dem Go-Live abfangen?

Antwort zuerst: Drei Ausfälle dominieren nach Cutover — fehlende Medien, Soft-404, Formular-Ausfall; jeder braucht ein Gate, keine Hoffnung.

Jeder FAIL in Staging stoppt den Cutover — nicht „wir fixen live“.

Wie schützt die URL-Matrix Rankings beim Cutover?

Antwort zuerst: 301 pro alte URL + eine Canonical-Strategie; ohne beides verlieren Backlinks und Bookmarks Signal.

Behalte URLs mit Traffic und Backlinks. Konsolidiere Thin Content bewusst (301 auf sinnvolle Elternseite oder 410, wenn endgültig tot). Vermeide Redirect-Ketten (A→B→C) und Soft-404. IndexNow und Search-Console-Monitoring nach Go-Live schließen den Kreis — Details unter Rankingverlust vermeiden.

Praktische Entscheidungsregeln:

1. Traffic + Backlinks: URL 1:1 behalten, Inhalt migrieren.
2. Traffic ohne sinnvolle Zielseite: Inhalt retten, URL behalten oder klarer 301 auf die nächste Elternseite.
3. Null-Traffic, Thin Content: nicht mitmigrieren — 301 oder 410 entscheiden und dokumentieren.
4. Parameter-Duplikate: auf Canonical-URL zusammenführen, Tracking-Parameter nicht als eigene Routen bauen.

hreflang nur, wenn du wirklich mehrsprachiges HTML auslieferst — nicht für englische Frontmatter-Felder allein. Eine kanonische Apex-URL pro Inhalt verhindert sonst Duplicate-Signale nach dem Cutover.

Formulare, Medien und Rechtstexte neu verdrahten

Antwort zuerst: Formulare und Rechtstexte sind Cutover-kritisch — sie gehören nicht in die „später“-Liste.

Formulare und Conversion-Module werden neu angebunden: Spam-Schutz (z. B. Turnstile + Honeypot), Notify an die Live-Kontaktadresse, konsistent zum Designsystem. Alte SMTP-Plugins und Contact-Form-7-Ketten entfallen mit dem PHP-Stack. WhatsApp als sichtbare Kontaktoption bleibt, wo sie vorher Conversion getragen hat.

Medien wandern mit Alt-Texten und stabilen CDN-URLs; defekte Downloads markiert das Audit. Impressum, Datenschutz und AGB prüfst du auf NAP und Kontakt konsistent zur Live-Marke — Widersprüche zwischen Footer, Schema und Maps fallen nach der Migration oft erst auf, wenn du aktiv abgleichst.

Was wird migriert — und was bewusst nicht?

Antwort zuerst: Botschaften, Medien und Meta ja; Builder-Layouts und unnötige Client-Skripte nein.

Migriert: Seiteninhalte, Medien, Formulare (neu verdrahtet), Meta, interne Verlinkung, Schema-Fakten, sinnvolle URLs.

Nicht 1:1: Pagebuilder-Layouts, jQuery-Widget-Zoo, SMTP-Plugin-Ketten, Caching-/Security-Plugin-Konfigurationen, Theme-Optionen.

Ziel: dieselben Botschaften in answer-first HTML — lesbar für Menschen, extrahierbar für Crawler und generative Engines. Parallel zur Migration kannst du Inhalte verdichten, musst aber nicht: erst technisch sicher live gehen, dann GEO-Schichten ausbauen. So vermeidest du Ranking-Risiko und Content-Stau in einem Big-Bang.

Wie hängt Content-Migration mit GEO und AI-Sichtbarkeit zusammen?

Antwort zuerst: Sauberes HTML senkt RAG-Rauschen; zitierfähige Inhalte und Entities kommen danach.

Generative Engines extrahieren Passagen — nicht ganze Builder-Seiten. Pagebuilder-DIV-Wüsten und Shortcode-Reste erhöhen Halluzinationsrisiko im Retrieval. Princeton GEO (Aggarwal et al., arXiv:2311.09735) zeigt, dass Zitate, Statistiken und Quellen Sichtbarkeit heben können — aber nur auf technisch extrahierbarer Basis.

Der Census unterstreicht die Lücke: nach dem Stack-Wechsel sind llms.txt, JSON-LD und Markdown-Negotiation die Hebel, die im Feld selten vorkommen (15,6 % / 41,9 % / 0,3 %). Content-Migration schafft die Voraussetzung — ohne sie optimierst du Rauschen.

Reihenfolge bei Modern Stack: Content-Migration → optional Redesign → Knowledge Graph / llms.txt / JSON-LD → Conversion. Stack und Markup zuerst, Content-Taktiken danach. Einstieg: GEO & AI-Sichtbarkeit.

Was kostet Content-Migration — und was ist im Basispaket?

Antwort zuerst: Content-Migration ist Teil der Webseite-Modernisierung ab 500 € für bis zu 10 Seiten — Inventar, Export, Rebuild und Redirect-Map im Scope.

Im Basisumfang typisch: Content-/URL-Audit, Export der Seiteninhalte, Rebuild auf Next.js, Medien-Übernahme im Scope, Redirect-Map, Staging-QA, Cutover-Begleitung.

Außerhalb: WooCommerce/Shop-Logik, umfangreiche CPTs, Custom-Plugin-Verhalten, Design-System von Grund auf, laufende Redaktions-Schulungen für Headless-Setups, großes Redesign.

Preise im Kontext: Preise & Pakete. Referenz mit sauberem Cutover: Mallorca Expats; weitere Praxis: Alexandre Liard.

Wer liefert was — und wie lange dauert es?

Antwort zuerst: Du lieferst Zugänge und Freigaben; Modern Stack liefert Audit, Mapping, Build, QA und Cutover — Dauer folgt Seitenumfang und Export-Chaos.

Typische Projekte laufen in Wochen, nicht Monaten. Beschleuniger: saubere REST/GraphQL-Quelle, wenige Builder-Sonderseiten, klare Top-20-Liste. Verzögerer: Elementor-/Divi-Chaos, unvollständige Wix/Jimdo-Exporte, Shop-Scope, fehlende Zugänge. Rollen und Meilensteine: Ablauf & Projekt.

Checkliste vor dem Kick-off

Domain- und Hosting-Zugang, CMS-/Builder-Admin, Export-Rechte, Liste kritischer Formulare und Downloads, Top-20-URLs aus Search Console, bekannte Alt-URLs/Redirects, Klarheit über Quellplattform (WordPress vs. Elementor/Divi vs. Wix/Jimdo vs. Shop), Analytics- und Search-Console-Zugang für durchgängige Messung.

Je vollständiger das Audit, desto ruhiger der Go-Live. Einstieg über WordPress-Migration oder direkt Webseite-Modernisierung. Anfrage stellen