Divi zu Next.js migrieren — Strategie & Umsetzung

Divi von Elegant Themes hat WordPress Jahre lang „visuell schön“ gemacht — und viele Unternehmenswebseiten an ein gekoppeltes Theme+Builder-Modell gebunden, das niemand mehr vollständig dokumentieren kann. Die Seite „funktioniert“ im Visual Builder, bis PHP-Upgrade, Child-Theme-Konflikt oder Core Web Vitals sie stoppen. Divi-Migration heißt: Botschaften und Conversion-Pfade retten, die Shortcode- und Builder-Schicht ersetzen. Dieser Beitrag analysiert die Divi-spezifische Rationale, den Extraktionspfad und die Umsetzungsfolge — und bindet sie an den Modern-Stack-Migrationspfad, nicht an generische „WordPress raus“-Floskeln.

Warum Elegant-Themes-Lock-in und Performance die Divi-Migration erzwingen

Antwort zuerst: Divi koppelt Theme und Builder — Layout lebt in Shortcodes und Builder-Daten, nicht in portablem HTML; Next.js liefert vorkompiliertes oder edge-nahes HTML ohne Divi-Runtime; der Unterschied zeigt sich an LCP und INP.

Klassisches Divi speichert Seiten als Hierarchie aus Sections → Rows → Modules. Im Post-Content stehen Shortcodes wie [et_pb_section], [et_pb_row], [et_pb_text] und Dutzende Modulvarianten. Das Frontend rendert daraus tief verschachteltes Markup plus Divi-eigene CSS-/JS-Bundles. Globale Styles (Farben, Typografie, Buttons) sitzen in Divi-Optionen und Theme Customizer — oft ergänzt um Custom CSS und ein Child Theme, das PHP-Overrides für Header, Footer oder Module hält.

Caching (WP Rocket, LiteSpeed, Divi-eigene Performance-Optionen) kaschiert TTFB, löst aber nicht Shortcode-Parsing, globales Builder-CSS und Child-Theme-Schuld. Im internen Vergleich Next.js vs WordPress liegen typische WordPress-/Divi-LCP-Werte bei 2,5–4,0 s, während SSG/Edge-Next.js oft bei ~0,8 s landet. Core Web Vitals (LCP, INP, CLS) sind damit Ranking- und Extraktionssignal: langsame Origins verlieren bei Crawler-Timeouts und bei Nutzerabbruch. Für den Business-Case ist Divi-Migration deshalb Core-Web-Vitals-Modernisierung plus Architekturwechsel — nicht „Divi etwas leichter machen“.

Vergleich: Divi-Monolith vs. entkoppeltes Next.js

Warum Theme-Wechsel und 1:1-Kopie von Divi scheitern

Antwort zuerst: Wer Divi nur „abschaltet“ oder Shortcodes „mitnimmt“, zerlegt die Seite oder transportiert dieselbe Wartungs- und Performance-Schuld — nur ohne den Visual Builder, der die Schuld bisher kaschiert hat.

Divi ist kein reines Plugin auf einem austauschbaren Theme. Elegant Themes liefert Theme und Builder als Einheit. Layout ist nicht die sichtbare HTML-Ausgabe, sondern Shortcodes und Builder-Strukturen, die erst die Divi-Runtime interpretiert. Ein Theme-Wechsel (Astra, GeneratePress, Block-Theme) ohne Extraktion führt typischerweise zu:

1. Roh-Shortcodes im Frontend — [et_pb_section] als Text, weil die Runtime fehlt.
2. Fehlenden Header/Footer, die nur im Divi Theme Builder existierten.
3. Kaputten Abständen und Farben, weil globales Divi-CSS und Child-Theme-Overrides wegfallen.
4. Form- und Modul-Leichen, deren Markup ohne Divi-JS/CSS bricht.

Eine 1:1-Kopie des Frontend-HTML (View-Source speichern) hilft ebenfalls nicht dauerhaft: Visual Builder und Frontend erzeugen Rauschen — Wrapper-DIVs, data-Attribute, Utility-Klassen und inline Styles, die Semantik begraben. Migration heißt deshalb Komponenten-Rebuild, kein Theme-Swap und kein HTML-Spiegel. Inhalte und Hierarchie (H1 → Abschnitte → CTAs) bleiben; Markup wird neu geschrieben. Das ist der Kern der Pagebuilder-Ablösung — Divi ist der Elegant-Themes-Fall, Elementor-Migration der Sibling mit Widget-JSON statt Shortcodes.

Visual Builder vs. Frontend-HTML — was die Wahrheit ist

Antwort zuerst: Der Visual Builder zeigt dir eine Editieroberfläche; die Wahrheit für Migration ist die redaktionelle Hierarchie — nicht das gerenderte Divi-DOM und nicht die Shortcode-Rohdaten als Zielmodell.

Im Alltag bearbeitest du Seiten im Visual Builder und siehst „fertige“ Module. Crawler und KI-Extraktoren sehen dagegen:

• verschachtelte et_pb_*-Container,
• Modul-CSS-Klassen und data-Attribute,
• oft zusätzliches globales CSS aus Divi-Theme-Optionen,
• Child-Theme-Overrides, die im Builder unsichtbar bleiben.

content.rendered aus der REST API liefert bereits Builder-HTML — Rohstoff, nicht Ziel. Shortcodes im post_content sind die Bearbeitungsquelle für Divi, aber kein portables Dokumentformat. Wir parsen daraus Semantik (Hero, Leistungsgrid, FAQ, CTA, Kontakt) und bauen Komponenten — analog zur Media-/Redirect-Disziplin der Content-Migration.

Was an Divi-Seiten wirklich migriert wird — und was nicht

Antwort zuerst: Texte, Medien, Seitenlogik, Markenfarben/Typo und Conversion-Felder — nicht et_pb_*-Shortcodes, Theme-Builder-JSON, globales Divi-CSS als Blackbox oder Child-Theme-PHP.

Übernehmen wir

• Seitentypen: Startseite, Leistungen, Über uns, Kontakt, Blog/News, Landingpages
• Copy, Bilder, Icons (als Assets), sinnvolle Alt-Texte
• Informationsarchitektur und URL-Kandidaten für die 301-Matrix
• Design-Entscheidungen: Primärfarbe, Schriftfamilie, Abstandsrituale — als Tokens, nicht als Divi-Preset-Export
• Formularfelder und Pflichtlogik (Name, Mail, Nachricht, Honeypot-Äquivalent)
• Navigation, Footer-Links und Pflichtangaben aus Theme-Builder-Layouts (explizit inventarisiert)

Lassen wir bewusst weg

• Divi Builder Runtime und Frontend-CSS/JS (et-core, Divi Module Styles)
• Sections/Rows/Modules-Shortcodes als Speicherformat
• Theme-Builder-Templates als Blackbox-JSON
• Globales Divi-CSS und undokumentierte Child-Theme-Overrides ohne Markennutzen
• Divi Contact Modules + SMTP-/Mailer-Plugin-Ketten
• Slider-, Blurb- und Animationseffekte ohne nachweisbaren Conversion-Nutzen
• Yoast-/Rank-Math-Keyword-Automaten ohne Qualitätsprüfung (Title/Description/Canonical selektiv)

Nach dem Cutover läuft die öffentliche Origin ohne /wp-admin, ohne Elegant-Themes-Lizenzpflicht und ohne „Divi vor PHP-Upgrade updaten“. Betrieb verschiebt sich auf Wartung & Updates und Hosting nach Migration im modernen Stack.

Wie läuft die Divi-Migration phasenweise ab?

Antwort zuerst: Erfolgreiche Ablösung ist sequenziell: Inventar der Builder-Artefakte → Extraktion → Komponenten-Rebuild → Redirects → Cutover — nicht „neues Theme und DNS umstellen“.

Phase 1 — Audit: Shortcodes, Theme Builder, globales CSS und Child Theme

Crawl und manuelles Inventar erfassen:

• Seiten/Beiträge mit Divi-Builder (vs. klassischem Content)
• Häufigkeit von Sections, Rows und Module-Typen (Text, Image, Blurb, CTA, Contact, Slider, Accordion, …)
• Theme Builder-Layouts: Header, Footer, Body, Product/Archive — inkl. Assignment-Rules
• Globale Styles und Custom CSS in Divi-Theme-Optionen
• Child Theme: functions.php, Template-Overrides, enqueued Assets
• Formulare, Pop-ups/Overlays, Animationen, Hintergrundvideos
• SEO-Plugins, Caching, Security — als Kontext, nicht als Mitnahme-Pflicht

Ergebnis: Extraktionsmatrix Seite → Sektionen → Zielkomponenten (Hero, Feature-Grid, FAQ, CTA, Form). Parallel: SEO-Baseline (Titles, Descriptions, Canonicals, H1) und Top-Traffic-URLs aus Search Console — Basis für Rankingverlust vermeiden.

Phase 2 — Extraktion: Content-Hierarchie statt Shortcode-Parität

Export über WordPress REST liefert oft nur gerendertes HTML. Für Divi reicht das als Rohstoff. Wir parsen die Hierarchie:

1. Visuelle Sektionen und Überschriften-Reihenfolge ableiten
2. Wiederkehrende Module (Blurbs, FAQs, Testimonials, Preistabellen) in strukturierte Daten überführen
3. Medien deduplizieren und in Object Storage/CDN legen
4. Formularfelder und Submit-Ziele dokumentieren
5. Theme-Builder-Navigation und Footer-Pflichttexte separat erfassen (nicht „aus Shortcodes raten“)

// Prinzip: Divi-Sektion → React-Komponente (vereinfachtes Muster)
const SECTION_COMPONENTS = {
  hero: HeroSection,
  featureGrid: FeatureGrid,
  faq: FaqSection,
  cta: CtaBand,
  contactForm: ContactForm,
}

export function mapSections(sections) {
  return sections.map((section, index) => {
    const Component = SECTION_COMPONENTS[section.type] ?? FallbackSection
    return <Component key={section.id ?? index} {...section.props} />
  })
}

Das Muster ist bewusst nicht et_pb_blurb → Komponente. Ziel ist Semantik (Hero, FAQ), nicht Modul-Parität. Details zur gesamtprojektlichen Medien- und Redirect-Pipeline: Content-Migration.

Phase 3 — Rebuild: Theme Builder und globales CSS als Layout-System

Header/Footer aus dem Theme Builder werden zu einer Layout-Komponente mit klaren Varianten — nicht zu Assignment-Spaghetti. Globale Farben und Typografie werden CSS-Variablen (--ms-orange und Marken-Tokens), nicht Divi-Preset-Importe. Buttons, Cards und Formularfelder folgen dem Designsystem der Zielwebseite; wo das bestehende Divi-Look-and-Feel trägt, bilden wir es nach — ohne et_pb_*-Klassen.

Child-Theme-Logik bewerten wir hart: nur Business-Regeln (z. B. spezielle CPT-Templates mit inhaltlichem Wert) fließen als echte Routen/Komponenten ein — PHP-Hooks und Divi-Filter nicht. Rendering-Wahl wie im WordPress-Gesamtpfad: Marketingseiten → SSG; häufig aktualisierte Listen → Revalidation; geschützte Bereiche → SSR. Strukturierte Daten (Organization, LocalBusiness, FAQ, Article) setzen wir im Code — Census-Benchmark: nur 41,9 % der Branchenwebseiten liefern überhaupt JSON-LD; Sitemap-Benchmark 73,5 %.

Phase 4 — Redirect-Matrix, Parität und Staging

Jede Zeile der URL-Mapping-Matrix wird zum 301. Soft-404 und Ketten sind FAIL. Staging-Checkliste Divi-spezifisch:

• Keine et_pb_* / Divi-Asset-URLs mehr im Quelltext der Top-20-Seiten
• Keine Roh-Shortcodes und kein Visual-Builder-Rest-HTML
• Visuelle Parität der Botschaften (nicht Pixel-Identität jedes Schattens)
• Formular-E2E: Submit, Notify an den Modern-Stack-Mailweg der Zielumgebung
• Mobile LCP-/INP-Stichprobe gegen die alte Divi-Baseline
• robots/sitemap und AI-Bot-Allowlist (kein unbeabsichtigtes Blocken)

Ranking-Risiken und Rollback: Rankingverlust vermeiden. Performance-Schwerpunkt optional als Core-Web-Vitals-Modernisierung.

Phase 5 — Cutover und Divi-Abschaltung

DNS/Proxy auf den neuen Stack, Redirect-Smoke-Tests, 48-Stunden-Monitoring (Verfügbarkeit, Search Console, Core Web Vitals). WordPress/Divi nur parallel lassen, bis Stabilität bestätigt ist — dann Hosting bereinigen, Elegant-Themes-Lizenz kündigen, Child Theme entfernen. Kein Cutover „Freitag 17 Uhr ohne Plan“. Übergeordneter Ablauf: WordPress-Migration.

Was der Census zur Divi-Migration sagt

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

In der AI-Readiness-Studie (6.675 Audits) laufen 69,4 % der Sites auf Legacy-CMS. Divi ist in dieser Gruppe ein häufiger visueller Builder — besonders bei Agentur-Themes und „One-Page“-Dienstleisterseiten. Benchmarks der Stichprobe: Agent-Ready Ø 25/100, llms.txt 15,6 %, JSON-LD 41,9 %, Sitemap 73,5 %.

Divi-Migration liefert deterministisches HTML und technische SEO-Basis. Knowledge Graph, llms.txt und Conversion-Module sind die nächste Schicht — nicht Ersatz für den Builder-Ausstieg.

Wie verbessert Divi-Migration GEO und AI-Sichtbarkeit?

Antwort zuerst: Flaches HTML senkt RAG-Rauschen aus Shortcode-/Modul-Wüsten; zitierfähige Inhalte und Entities kommen danach.

Generative Engines extrahieren Passagen — nicht Section/Row/Module-Bäume. Verschachtelte et_pb_*-Container und globales CSS erhöhen Halluzinationsrisiko im Retrieval, weil der eigentliche Satz unter Wrapper-Schichten begraben liegt. Princeton GEO (Aggarwal et al., arXiv:2311.09735) zeigt, dass Statistiken, Quellen und Zitate Sichtbarkeit in generativen Engines heben können — aber nur auf technisch extrahierbarer Basis.

Reihenfolge bei Modern Stack: Divi-/WordPress-Migration → optional Redesign → GEO / Knowledge Graph → Conversion. Stack zuerst, Content-Taktiken danach — sonst optimierst du Rauschen.

Theme Builder, globales CSS, Child Theme, Forms und Module

Antwort zuerst: Theme-Builder-Layouts und globales CSS inventarisieren wir explizit; Child-Theme-PHP entfällt; Forms bauen wir neu; Module bewerten wir nach Conversion-Nutzen vs. INP-/Wartungsrisiko.

Theme Builder: Header/Footer/Body sind oft der unsichtbare Ballast. Assignment-Rules („nur auf Leistungen“, „nur Blog“) erzeugen Varianten, die im Alltag niemand dokumentiert. Nach Migration: ein Layout, Varianten im Code. Archive- und Single-Layouts werden zu Routen und Listenkomponenten — sonst schleppst du Builder-Conditions mit, die ohne Divi-Runtime tot sind.

Globales CSS: Divi-Theme-Optionen und Custom CSS wirken seitenübergreifend. Wir übernehmen nur Regeln mit Marken- oder Lesbarkeitsnutzen und übersetzen sie in Tokens/Utility-Klassen. Blindes Portieren von Tausenden Zeilen Divi-CSS reaktiviert CLS- und Spezifitätsprobleme.

Child Theme: Viele Divi-Projekte hängen an einem Child Theme, weil das Parent Theme Updates sonst Overrides überschreibt. Das ist Lock-in im Lock-in: Layout im Builder, Verhalten im PHP. Migration bricht diese Abhängigkeit bewusst — wertvolle CPT-Inhalte bleiben, PHP-Theme-Schuld nicht.

Module & Extensions: Blurbs, Sliders, Counters, Fullwidth Header, Accordion — häufig ersetzbar durch statische Abschnitte oder leichte Client-Inseln ohne Divi-Bundle. Entscheidungskriterium: Braucht der Nutzer Interaktion, oder war das Modul nur Layout-Bequemlichkeit im Visual Builder? Layout-Bequemlichkeit wird zu HTML; echte Interaktion wird sparsam und messbar neu gebaut.

Forms: Divi Contact Forms speichern oft in WordPress und brauchen SMTP-/Transactional-Plugins. Das ist eine fragile Kette (Plugin-Update bricht Mail, Spam füllt die WP-Datenbank, Absender driftet). Ziel: Stack-native Formulare mit Turnstile/Honeypot-Disziplin und klarem Notify — siehe Conversion. Feldmapping (Labels, Pflichtfelder, Erfolgstext) behalten wir; die Modul-Runtime und das SMTP-Plugin nicht.

Animation / Parallax / Video-Hintergründe: Ohne belegten Conversion-Lift fliegen sie raus oder werden statisch. Häufige CLS-/INP-Treiber auf Divi-Seiten. Stakeholder dokumentieren wir vorab, damit „fehlende Magie“ nicht als Regression missverstanden wird.

Komponenten-Rebuild-Muster (Praxis)

Statt Modul-Parität arbeiten wir mit einem festen Satz Seitentyp-Komponenten. Beispiel Startseite: Hero (Headline, Subline, primärer CTA, optional URL-Sofortcheck), Problem-/Nutzen-Band, Leistungs-Grid, Trust/Referenzen, FAQ, Anfrageformular. Jede Divi-Section mappt auf genau eine dieser Rollen — oder wird gestrichen, wenn sie nur Builder-Füllung war (leere Spacer-Stapel, doppelte CTA-Bänder, dekorative Blurbs ohne Aussage). So entsteht eine Webseite, die du später erweitern kannst, ohne erneut in Elegant Themes zu fallen.

Blog, Custom Post Types und Divi-Layouts in Beiträgen

Antwort zuerst: Alte Blogposts und CPT-Einträge mit Divi-Layout-Shortcodes werden in lesbare Artikel-/Detailseiten überführt — Autor, Datum, Taxonomien bleiben, Modul-Müll nicht.

Viele Divi-Sites speichern nicht nur Landingpages, sondern auch Beiträge und Referenzen als Builder-Layouts. Custom Post Types (Team, Projekte, Leistungen) rendert das Theme oft nur mit Divi. Im Audit prüfen wir: Welcher CPT trägt echten Inhalt? Export-Plugins allein lösen Shortcode-Schuld selten sauber — manuelles Mapping bleibt ehrlicher und zitierfähiger. Das gehört zur gleichen Disziplin wie Content-Migration.

Wann lohnt sich eine Divi-Migration — und wann nicht?

Antwort zuerst: Sinnvoll, wenn Inhalte und Marke tragen, Theme+Builder aber Performance-, Lizenz- oder Exit-Risiko sind — nicht als Ersatz für eine komplett neue Story.

Sinnvoll bei: Shortcode-/Modul-Ballast, Child-Theme-Abhängigkeit, schlechten Core Web Vitals trotz Caching, fragilen Formularen, Theme-Builder-Chaos, drohenden PHP-/Divi-Inkompatibilitäten, gescheiterten Theme-Wechsel-Versuchen.

Allein zu wenig, wenn: Informationsarchitektur und Angebote veraltet sind — dann Migration + Redesign + Conversion. Geschwisterfall mit anderem Builder: Elementor-Migration. Generischer Rahmen: Pagebuilder-Ablösung. Übergeordneter Pfad: WordPress-Migration.

Was kostet die Divi-Migration — und was ist im Basispaket?

Antwort zuerst: Basis ab 500 € für bis zu 10 Seiten — Inhalte und sinnvolle URLs inklusive; Redesign, Knowledge Graph und Conversion separat.

Im Basisumfang typisch: Shortcode-/Theme-Builder-/CSS-Audit, Extraktion der Seiteninhalte, Komponenten-Rebuild auf Next.js, Redirect-Map für den Scope, Staging, Cutover-Begleitung. Außerhalb: sehr große Template-Bibliotheken, Custom Divi Modules, umfangreiche Child-Theme-Logik, Shop, Design-System von Grund auf.

Zehn inhaltlich dichte Divi-Landingpages sind mehr Arbeit als zehn Textseiten — deshalb Seitenumfang und Sonderlayouts vor Angebot klären. Preise im Kontext: Preise & Pakete. Methode und Vorher/Nachher-Logik analog zur WordPress-Migration.

Wie weist du die Qualität nach dem Cutover nach?

Antwort zuerst: Messbar sind DOM-Größe, Core Web Vitals (LCP, INP, CLS), Statuscodes, fehlende Divi-Assets/Shortcodes und mobile Conversion-Pfade.

Go-Live-Checkliste:

• Top-Landingpages: LCP/INP-Stichprobe vs. Divi-Baseline
• Quelltext frei von et_pb_*, Divi-Asset-URLs und Visual-Builder-Ballast auf kritischen Pfaden
• 301 für geänderte Slugs; keine Soft-404
• Formular-Test Ende-zu-Ende
• JSON-LD dort, wo fachlich sinnvoll — bewusst über dem Branchenanteil von 41,9 %
• Search Console: Coverage und Core Web Vitals in den ersten 48 Stunden beobachten

Betrieb danach: Wartung & Updates ohne Elegant-Themes-Update-Roulette.

Checkliste vor dem Kick-off

WordPress-Admin mit Divi-Zugriff, Elegant-Themes-Lizenzstatus, Liste aktiver Theme-Builder-Layouts (Header/Footer/Body) inkl. Assignments, Screenshot oder Export der globalen Styles/Custom CSS, Child-Theme-Überblick (functions.php, Template-Overrides), Modul-Inventar der Top-20-Seiten, Formular- und Overlay-Inventar inkl. SMTP-Plugin, Search-Console-Zugang, bekannte Alt-URLs/Redirects, Klarheit Re-Platforming (Standard) vs. Headless-Ausnahme, Design-Tokens soweit bekannt. Je vollständiger das Audit, desto ruhiger der Go-Live — und desto weniger Überraschungen durch versteckte Theme-Builder-Bedingungen und Child-Theme-Hooks.

Kurz: Divi-Migration ist Infrastrukturentscheidung — Inhalte behalten, Theme+Builder-Schicht tauschen, Shortcodes und globales CSS in echte Komponenten übersetzen. Gleiche Botschaft, weniger DOM, bessere Core Web Vitals, klarere Extraktion für KI-Antworten. Agent-Ready liegt im Census bei Ø 25/100; Pagebuilder-HTML ist ein Hauptgrund. Anfrage stellen